Modern JavaScript Tools

[Diogo Schneider]

Hi all,

I'm the main author of the Quick game engine / lib and I have been reading a lot about these tools such as npm and browserify for the client side of web applications. I have been very comfortable with the current structure of the project but I would like to hear your opinions on adopting the new structure that these tool can facilitate, e.g. separate class files, et al.

Coming from Java, I can appreciate that, though it's not a real need. Anyway, I already use npm for unit testing so it feels like it would make sense to go further into this trend. Any comments are more than welcome. Thank you.

[PsichiX]

Hi! Generally focusing on ES6+ features and toolsets that works based on them is good idea - let me tell you how i've made this done here: https://github.com/PsichiX/Oxygen

Engine itself is compiled with babel CLI, but projects that use it uses Webpack bundler and engine has tools and plugins for webpack to make game bundled and assets archived. Secondary, webpack/babel approach gives you possibility to easly use any JS transpiler to code your game logic (ES6+ or TypeScript, or even CoffeScript - all together can be used when your code architecture is modular! :D)

[mattstyles]

Might be worth phrasing the question a little differently, what problems do you (as author) or your consumers have with your current workflow?

By phrasing like this you might get better answers as to how a different (newer) system might help to solve those problems.

Browserify and NPM primarily give you access to node's commonJS module flavour. Personally I was never comfortable with weird JS namespacing solutions (or revealing module pattern) so access to a proper module system was the problem that these tools solved.

Partly access to a proper module system is a convenience but it also helps resolve the very real problem of naming conflicts in the runtime environment (i.e. the client). Take for example the following problem:

* I 'publish' my Eventemitter module for implementing pub/sub.

* Consumers consume this module by including a script tag which dumps an `EventEmitter` global in to the page, whereby the application code can access and use my module.

* Someone else publishing a module that also exposes an `EventEmitter` global in to the page.

* As a consumer I want both modules but now I have a problem as they both conflict over that `EventEmitter` global and there is no clean way to resolve this.

For large libraries like Phaser or, say, React, or `quick`, this probably isn't too much of a problem as you likely won't have a naming conflict, particularly if the library in question uses an obscure and fairly unique name (i.e. not EventEmitter), but, this brings another problem.

The Unix Philosophy states that a program/process/module/thing should do one thing well and that complexity is achieved through composing small 'things' into larger things. Including larger catch-all libraries (or frameworks)  works directly against this and when you're worried about conflicts (particularly seemingly trivial things like naming conflicts) it actively prohibits the release of smaller modules, or even individual functions. Take the case of underscore and lodash which are simply a collection of convenience methods, the chance of conflicts between functions named 'map', 'reduce', 'concat' etc is very high if you're after a 'small module' philosophy.

Using a proper module system, one where the consumer can optionally choose to name their imports, solves this problem cleanly i.e. as a consumer I can name things as I choose if/when required:

const FooBarBaz = require('phaser')

import CrazyUniqueName from 'React'

Now I have no naming conflict problem.

Take this further with named exports and as a consumer I can pick and choose what I want from a module, again, optionally renaming it if necessary:

const {render} = require('react')

import Rectangle as NearlySquareThing from 'Phaser'

Now take this even further and introduce additional automated tooling that can take this specification for how modules are consumed and create smarter builds, all in the hands of the consumer, and you're on to a real winner i.e. if I only want to include 'map' from lodash then current modern tooling allows me to take that without dumping the entirety of lodash into the page as a script include just to access one function. You could have achieved this before but it would require knowledge of knowing how to create custom builds of dependencies and that is painful, Bootstrap had several helpers for creating custom builds (for example) but its still a pain and updating the dependency becomes close to impossible when you're using custom builds.

This is another advantage of using NPM, dependency version management. This is achievable in the old method, just download a new version and include it as a script tag, however, NPM have automated this workflow. I have worked on several complex applications over the past couple of years, all with dependency management handled by NPM, some projects only contained a handful of top-level dependencies but all projects ended up with hundreds (and sometimes thousands) of actual dependencies, imagine trying to update these by hand! It is practically impossible unless you have a huge amount of time, NPM helps (doesn't totally solve) to eradicate this problem via automation (via specification) and mostly it just works.

For me it almost boils down to these two workflows:

1:

* Find a download link

* Remember the download link

* Download the file

* Place the file somewhere, probably inside my repository

* Include as a script tag

* Handle naming conflicts

* Use the global the script exposes

vs 2:

* find the module name I want

* npm install my-awesome-module

* include module in source code and use it

Most of the steps from #1 are removed in #2 because it becomes automated i.e. the name of the module you are using is stored in the `package.json` and updating it becomes trivial (of course, the update could break your stuff, which is certainly non-trivial, but the actual update is automated and trivial).

Workflow 1 highlights another potential issue, if I have a repository do I really want to keep all dependencies in it? Almost certainly no, but you might want to depending on how much of a masochist you are.

 

I had a look at your main `src/quick.js` file, seems extremely well structured and very clean to me. On the flip-side it also seems super easy (trivial even) to extract those functions to separate files and then include them in an index file (or main) of some sort to expose them and get all the advantages listed above. But, again, if you're comfortable with your current workflow (looks like it works, your structure, I think, is superb, I personally would hate to work on such a large file but I imagine the practicality is that it is easy as you've separated everything up very cleanly) then why change? Do you think you might be more comfortable with an alternate workflow?

[PsichiX]

@mattstyles man, you've nailed it!

[Diogo Schneider]

Hi guys,

Thank you for your insight, I really appreciate it. I think the main motivation for me right now is based on two factors: keeping current with whatever trends are becoming the best standards (I just refactored everything to ES6 after being stubborn in ES5 for a long time) and also add value to the consumers, I'm just not sure that such move would actually help the user very much. It looks to me like a "potato potato" situation right now. And there are so many other features that I'd like to see available as soon as possible that I should probably just focus on them right now.

Thanks again! Cheers!

 

[MrPancakes]

I always try and keep main focus on productivity for the end goal, would npm or a bundler help you in any way? 

Seems in this case it wouldn’t.

 

[Diogo Schneider]

Hi! Yes, I guess you are right. But just yesterday I realized now that the quick ecosystem has grown to several projects involving assets, demos and plugins that go beyond the main framework's library, it would be useful to have some sort of automatic dependency management. Since these separate components evolve in their own separate pace, it should be good not to care about manually matching the compatible versions. So maybe it still makes sense to think about NPM. We'll see about that.

By the way, I just checked your link and it seems that I landed at the portal's home page. So I could not find a way to check on your own games. Thanks!

[MrPancakes]

10 minutes ago, Diogo Schneider said:

Hi! Yes, I guess you are right. But just yesterday I realized now that the quick ecosystem has grown to several projects involving assets, demos and plugins that go beyond the main framework's library, it would be useful to have some sort of automatic dependency management. Since these separate components evolve in their own separate pace, it should be good not to care about manually matching the compatible versions. So maybe it still makes sense to think about NPM. We'll see about that.

By the way, I just checked your link and it seems that I landed at the portal's home page. So I could not find a way to check on your own games. Thanks!

Automatic dependency management is great for just that task, just a heads up when one start with this (package management and bundling) there is no end for the rabbit hole and you can get stuck for days or even weeks, there is always new things to learn. Just keep focus on what you want out of it.

The game I made there is called Fish bowl run, made ages ago and the cat sounds are all mine  Think I made it in in a day. I am a Javascript developer by trait and just now putting in some real effort for game development.

[Diogo Schneider]

Very valuable advice, indeed. All of these automation tools have their own overhead, so I think for now I'll just keep things as they are, it works and it's never been an actual burden to keep track of versioning so far.

I tried to play your game in one computer, it had no Flash. Then I tried on another but the game didn't load, even after a few refreshes. I'll give it another try later, but I can tell from the thumbnail that it looks really fun. The graphics are pleasant to the eye, too.

I can tell you JavaScript game development is very exciting. I have been writing games since the mid '80s, but it's never been as cool as when I found out about HTML5 in 2011. It was like rediscovering game development altogether. Let me know if you'd like to give quick a try, I would gladly help you creating your game.

Thanks!