Link to home
Start Free TrialLog in
Avatar of James Hancock
James HancockFlag for United States of America

asked on

Is atom-live-server a good web server solution plugin for web-game coding?

I found an "atom-live-server" Atom plug-in to allow for simple set-up of a live server with the project's files instantly accessible from a browser / runtime
It was recommended by a Javascript web-game coding page.
Does the plugin look suspicious/ not as good as apache? It means I can easily do local / LAN testing.

Avatar of Alex
Flag of United Kingdom of Great Britain and Northern Ireland image

It's looks ok, there are no major warning signs that it's dodgy, essentially it's down to what you want.

Avatar of Dr. Klahn
Dr. Klahn

Have a look at the web server usage statistics at this page:

Atom doesn't even show up on the list of "servers with less than 0.1% use."  It's hard to recommend something that thinly used, if only on the basis of "who will help me when I have problems?"
The above is for public web servers, not ones internally for testing which is what ATOM is used for. Atom is a development server, not something to publish with.

Avatar of David Favor
David Favor
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of James Hancock



That’s what I assumed would be the answer. The plugin is appealing because I don’t know what my final setup will be, if it will happen, even, and am learning

I installed it, and instead of interpreting the javascript into a page, the browser just prints the code at that URL.
I have the same address as the IDE states the server is serving from..and in my browser URL bar.

js/index.js  is my own folders in the IDE/ project folder.
The files can be loaded, but they aren't rendered, just text-dumped

Make any sense?

This likely means an incorrect MIME type is being returned for .js files, which is common for dev type servers.

Again... for best development, use a straight up Apache server running on a public IP, which will eventually become your actual public server.
Thanks a lot

Anything else I should be aware of this early, with an Atom JS project using Apache?

Should be plain sailing?
Yep. Should be smooth sailing.

Tip: Just be sure you have your MIME expires headers for JS + CSS + HTML all set to the past, in other words no caching of any of these MIME types.

The primary problem most people run into testing code is making changes + never seeing the changes, due to expires headers triggering browser caching.

I've never heard of this need before. How is MIME relevant? How do I check it out on a Mac?

Will my players need to worry?
1) How is MIME relevant?

See below.

2) How do I check it out on a Mac?

See below. You'll use curl for this.

3) Will my players need to worry?

Yes. This is highly relevant. In your case likely what you'll do is version all your Javascript files... maybe something like...

lxd: net16-david-favor # tstamp

# Then version your .js file

# Then set your HTML components to expire in the far past, see below
#  which will force any change to the game-system-*.js file name to be
# pushed to browsers for every change.

Open in new window


You'll use curl to fetch some asset, checking headers... as in...

For example...

imac> curl -I -L
HTTP/1.1 200 OK
Date: Thu, 19 Dec 2019 17:18:56 GMT
Server: Apache/2.4.41 (Ubuntu)
Strict-Transport-Security: max-age=63072000; preload
Upgrade: h2,h2c
Connection: Upgrade
Last-Modified: Wed, 01 May 2019 21:14:27 GMT
Accept-Ranges: bytes
Content-Length: 88145
Cache-Control: max-age=2592000
Expires: Sat, 18 Jan 2020 17:18:56 GMT
Vary: Accept-Encoding
X-Edge-Location: YUL
Content-Type: application/javascript

Open in new window

This shows jquery is cached until Date: Thu, 19 Dec 2019 17:18:56 GMT contrasted with...

imac> curl -I -L
HTTP/1.1 200 OK
Date: Thu, 19 Dec 2019 17:20:02 GMT
Server: Apache/2.4.41 (Ubuntu)
Strict-Transport-Security: max-age=63072000; preload
Upgrade: h2,h2c
Connection: Upgrade
Last-Modified: Thu, 01 Aug 2019 11:31:47 GMT
Accept-Ranges: bytes
Content-Length: 11685
Vary: Accept-Encoding
Cache-Control: max-age=0, public, no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Edge-Location: YUL
Content-Type: text/html; charset=UTF-8

Which shows the HTML component for this site expires on Expires: Thu, 01 Jan 1970 00:00:00 GMT which is in the far past.

This is called Cache Busting which ensures MIME types (in this case text/html) is never cached.

When running dev/staging/test servers, best practice is to set expires headers to far past for JS + CSS + HTML + XML... or whatever other MIME types are involved in testing.

This keeps testing very simple.
Note: This question is starting to skew into many long term server runtime configuration considerations.

Best close out this question, then open other questions about how best to configure servers to push file changes to players as soon as any change occurs.

For example...

If a game is being played + changes must be made, doing this via an actual Javascript file change will fail in many ways.

What you'll do instead is have a single Javascript file, which never changes, ever, implementing fast AJAX round trips to the server to actually load your game code changes + share map changes between players, if this will be a multiplayer game.

You may even find using Websockets will be required, depending on game state changes, specific payload size + frequency data changes.

All this items are better dealt with before a single line of code is ever written, as retrofitting all this... will be... near impossible...

Note: Taking this approach also means your game code is far better obfuscated + protected against theft... rather than placing your entire game engine into a Javascript file.

Suggestion: Close out this question + open another question describing your exact game system, asking for design suggestions.
You're welcome!