JavaScript Framework's

[Dal1980]

Just out of curiosity, how does anyone choose an appropriate framework given that at first glance I've found 38 of them!

I mean it would take me weeks to read up on each one and try and cross reference everything (if that was even possible)

My sort list:

• Phaser
• Pixi.js
• Babylon.js
• Panda.js
• melonJS
• Haxe JS
• Kiwi.js
• backbone.js
• darlingJS
• JawsJS
• Enchant.js
• Quintus.js
• Crafty
• Stage.js
• qiciengine
• PlayCanvas
• Cocos2D
• CreateJS
• Unity
• Corona
• Titanium
• Impact JS
• Lime js
• Game Develop
• Isongenic Engine
• MightyEngine
• WiMi5
• RPG Maker MV
• Turbulenz
• Clojurescript
• Construct2
• OpenFL
• GC DevKit
• voxel.js
• WADE
• lycheeJS
• Three.js
• GameMaker
   

[end3r]

Check the html5gameengine.com website for an overview on the most popular ones, and jsbreakouts.org if you want to compare the source code of some of them when building an example 2D Breakout game.

[mattstyles]

Yes, this is a real issue (not a problem) in JS, but choice shouldn't be a burden! It's a privilege! 

I dont know all of them but most are full-featured frameworks, this means they are complex, so, if any don't have commits from the last month ditch them straight away, that'll immediately strip 'unloved' frameworks (this is not true of smaller modules or libraries), ditto for open issues, if there is no progress on open issues (they dont have to be closed) then strip it from the list. This will greatly reduce that number.

Next up work out what you want from a framework and match that against the key points (from on their website/repo readme) for each option, ditch any that don't match your keys, further ditch any that only just meet some of your criteria.

At this stage you're probably left with only a few options.

Check their documentation, check the community more thoroughly, check the active maintainers and contributors (is the project 'busy'?), check the api.

This will give you a feel for which ones you like, at this stage you've basically weedled the list down to frameworks that will work for you, you could just number them and roll a dice, but, to get a better fit, delve a little deeper.

The last step will probably weedle it down to only 2-3. At this stage you really need to kick the tires. Follow a tutorial or two, extend the tutorial. Work out which bits of your project will be the hardest to accomplish and get a feel for how much the framework helps/hinders you.

Then make your choice.

For frameworks it really is essential because frameworks are invasive, they do the work and allow small windows in to them for your code (total opposite of a library/module), because of this you're stuck with them, so its worth the added initial research.

Libraries and services are different and you can sometimes back out if you find you've chosen poorly, after all, further down the line you'll have more info to make a more informed decision, but, with frameworks and larger things you're pretty much stuck and its a crud feeling to get 80% into a project and work out you made a poor choice months ago only because you didn't research properly.

[Gio]

16 hours ago, end3r said:

Check the html5gameengine.com website for an overview on the most popular ones

Sadly html5gameengine is terribly out of date. Tried to contact them several times to update our entry, but no luck - we're stuck with a description and links that were accurate 4 years ago. Quite frustrating given the amount of referrals that we still get from that site. Hopefully someone will make a more up-to-date list that becomes as popular as that one.

Mattstyles has got some very good advice here. I'm not entirely sure about the first part, e.g. we don't commit new code every day, we just release new versions every 2-3 months. Another way to gauge activity is to look at forums / blogs and see if there's anything recent: if the last post is from several months / years ago, then it's probably an abandoned project. But other than that, pretty solid advice.

[Dal1980]

Firstly thank you to end3r for the quick response. I did go off to look at the links you provided. The first one I'd already had linked to me from IRC when trying to discus the rabbit hole I've found. The second link was a great idea, it's a shame these projects are no longer being updated but they were somewhat helpful.

Thank you to mattstyles for a well thought out strategy to tackling this daunting task of identifying a good choice. I shall take this all on board and I appreciate the time you've taken to reply.

Finally thank you Gio for pointing out some things to consider regarding the advice received.

Thanks guys, awesome

Dal

[b10b]

I wanted to provide an alternative perspective on picking frameworks: actively avoid those with large adoption, high issue counts, frequent updates, easily read documentation, etc .  Intentionally buck the trend.  Why?  Because the opportunity to stand-out rarely exists if we follow the herd - and in the crazy game of games standing out is crucial to survival.

Instead abstract the selection criteria a little, spot the trend of the trend, take a chance and pick an obscure and non-obvious solution - prior to "crossing the chasm".  Rely on three arbitrary yet tangible review questions to derisk: 1) can we get something deployed using this tool within a few hours, 2) has someone else produced something noteworthy using this tool, 3) does this tool reflect our personal style, preferences and goals.

[mattstyles]

13 hours ago, b10b said:

Because the opportunity to stand-out rarely exists if we follow the herd - and in the crazy game of games standing out is crucial to survival.

I love this statement, but it would never apply to my dependencies (although I am often tempted). Users don't care how you made your app/game, they just want it to be fun. If the framework/library/tool you use to create games means everything comes out smelling samey then thats a failing of the tool. Most of the big frameworks mentioned in this post are flexible enough to create most styles of games.

The problem with smaller maintained, or smaller used, frameworks/libraries are what happens when it goes wrong, how quickly can the community or the maintainers get you back on your feet? If its OSS I could make the changes myself and contribute, but, I'm using a framework so I don't really have to. How quickly can they make performance, security or other updates? without good docs and a good community how are you going to learn it? Pick through their code, yep, that would work, but slow going.

I'm come to the opinion that peeps can create and maintain small modules in their spare time and most will accept some latency in responding to issues, but for anything mildly complex it really needs a dedicated team, at least part time dedicated, to make it work.

13 hours ago, b10b said:

1) can we get something deployed using this tool within a few hours,

2) has someone else produced something noteworthy using this tool,

3) does this tool reflect our personal style, preferences and goals.

I totally agree with these 3, in my view a great set of criteria for judging dependencies.

[b10b]

9 hours ago, mattstyles said:

The problem with smaller maintained, or smaller used, frameworks/libraries are what happens when it goes wrong, how quickly can the community or the maintainers get you back on your feet?

I understand the appeal of a hidden army, and I agree for trivial issues or initial learning curve this is valuable beyond words.   However I've repeatedly encountered long-term frustration with any external dependency (no matter how large or stable today) because we're betting our future on other people's agendas - and the two will diverge over time.  Whereas self reliance and the ability to fix / invent / adapt is the key to being original (more of a cultural thing than a purely technical thing) plus it provides resilience through diversification opportunities.

Perhaps picking a framework that can easily make what exists today paints us into a corner to make more of the same?  Or perhaps it's obviously the best choice for today?