Framework/libraries for a browser-based game

Question

I am currently half-decided to use Kohana + Zend as needed for the PHP part. What I would need next is an excellent base for JavaScript code. There are a bazillion of contenders here and choosing isn't exactly as easy as with PHP.

I would need practically everything from form posting and retrieving results to skinnable widgets and animations. For this reason using multiple libraries will probably be a must, as no one framework can do it all. The requirements I have would be this (initial list):

1. Good browser support. WebKit-based is hardly an issue and Firefox 3+ is good. However, I'm looking at you Internet Explorer. IE 6 can be ditched, seriously, but 7+ support is needed.
2. Good performance. While WebKit has had a stupidly fast JS implementation for quite a while (and Chrome even before), Firefox has only recently got TraceMonkey and don't even get me started on Internet Explorer. While it is true that you can't do much about IE as anything will be slow, I don't want to try running Chrome Experiments in the others either.
3. Excellent support. This is a total must. The better the support, the more inclined will I be towards a library.

I am currently looking into jQuery as it is a very neat library, but the quality of plugins is questioned by some. Processing.js looks extremely promising, but IE does not support canvas, thus something has to be done about that and I am not sure how it could be replaced.

Answer 1

Go with a known library that is used by many sites. This will ensure all 3 of the points you have mentioned.

Personally, I would go with jQuery for these above reasons:

• Great cross browser support
• Good performance, as it is a thin api layer
• Excellent support. Good documentation, loads of other devs

Answer 2

Although jQuery seems to be the most used library these days, there are other very good candidates as well.
One of them are YUI Library.

YUI has excellent documentation, and support. And the source code is really good. YUI is developed by Yahoo!, where Douglas Crocford is architect (the author of JavaScript: The Good Parts, and the man behind JSON). Yahoo! is well known for their focus on JavaScript development.

YUI has good browser support and is fast and robust.

Answer 3

Dojo is a great library for writing web applications; however, never having written a game, I'm not sure if it is well suited for that sort of application. I must warn you though that the Dojo documentation is crap. Absolute crap. On the other hand, things like dojo.hitch, dojo.require, and dojo.partial are absolute joys.

I would try to avoid using cross-cutting libraries (like Dojo+jQuery) as much as possible. There's not really a good reason to do it and will create bloat and confusion in your application from day one.

That said, using multiple, non-overlapping libraries does make sense for a project like this. You might want to look into using Processing.js for visual needs and either Dojo or jQuery for your core.

---

Some other things to consider. Targeting IE, even IE8, for JavaScript game development is a bit ridiculous because of its slow performance and lack of canvas support. Also, according to John Resig, developing games in JavaScript is hard.

Have you considered being a pioneer (wink) and trying something out in 03D?

Answer 4

If it's war simulation and you have custom objects that you want to animate beyond the simple CSS effects and animations, then canvas tag is your best bet. It's as close as you can get to Flash but much more smoother. Processing.js looks really good for manipulating the canvas.

If that's the core component of your game, then I see the other libraries as adjunct to Processing.js that can be scrapped out without any deep commitments. That said, jQuery is great if you're dealing heavily with the DOM. It has really good support and community. MooTools is highly modular and has been traditionally strong with animations. YUI is a great library too, but a little verbose for my taste. Thought, Yahoo has made heavy changes with v3 to fix that. And a bunch of other libraries, that I don't use at all.