Which JavaScript framework is generally used for high performance websites?

Question

There are different JavaScript frameworks like jQuery, Dojo, mooTools, Google Web Toolkit(GWT), YUI, etc. Which one from this is suitable for high performance websites?

Answer 1

(Full disclaimer: I am a Dojo developer and this is my unofficial perspective).

All major libraries can be used in high load scenarios. There are several things to consider:

Initial load

The initial load affects your response time: from requesting a web page to being responsive and in working mode. Trivial things to do are:

• concatenate several JavaScript files together (works for CSS files too)
• minimize and/or compress your JavaScript

The idea is to send less — good for the server, and good for the client.

The less trivial thing to do:

• structure your program in such a way so it is operational without all modules loaded

Example of the latter: divide your modules into essential (e.g., the core logic), and non-essential (e.g., helpers: tooltips, hints, verifiers, help facilities, various "gradual enhancers", and so on). The idea is that frequently there are things which are not important for frequent users, but nice for casual users ⇒ they can be delayed.

We can load essential modules first and load the rest asynchronously. Example: if user wants to edit an object we need to show it first, after that we have several hundred milliseconds to load the rest: lookup tables, hints, and so on.

Obviously it helps when asynchronous loading of modules is supported by the framework you use. Dojo has this facility built-in.

Distribute files

Everybody knows that due to browser restrictions on number of parallel downloads from the same site it is beneficial to load resources (images, CSS, JavaScript) from different domains:

• we can download more in parallel, if user's line has enough bandwidth — these days it is almost always true
• we can set up web servers optimized for serving static files: huge disk cache, small workers, keep-alive, async serving, and so on
• we can remove all unnecessary features we don't need when serving static files: sessions, cookies, and so on

One frequently overlooked optimization in JavaScript applications is to use CDN:

• your web site can benefit from the geographical distribution of CDN (files can be served from the closest/fastest server)
• user may have required files in her cache, if they were used by other application
• intermediate/corporate caches increase the probability that required files are already cached
• the last but not least: these are files that you don't serve — think about it

Again, Dojo supports CDNs for a long time and distributed publicly by AOL CDN and Google CDN. The latter carries practically all popular JavaScript toolkits too. Obviously you can create your own CDN and your very own CDN- and app- specific Dojo build, if you feel you need it — it is trivial and well documented.

Communication bandwidth

How that can be different for different toolkits? XHR is XHR.

You need to reduce the load on your servers as much as possible. Analyze all traffic and consider how much static/immutable stuff is sent over the pipe. For example, typically a lot of HTML is redundant across several pages: a header, a footer, a menu, and so on. Do you really need all of these to be sent over every time?

One obvious solution is to move from static HTML + "gradual enhancements" with JavaScript to real "one page" JavaScript applications. Again, this is a frequently overlooked, but the most rewarding optimization.

While the idea sounds easy, in reality it is not as simple as it seems. As soon as we go from one-liners to apps we have a plethora of questions, and the biggest of them is the packaging: what your components are, what components are provided by the toolkit, and how to package and deliver them.

Dojo provides modules, good OOP for general classes, widgets (a combination of an optional HTML and related behaviors), and a lot of facilities to work with them. You can:

• load modules on demand rather than in the head
• load modules asynchronously
• find all dependencies between modules automatically and create a "build" — one file in simple cases, or more, if your app is big and requires several layers
• while doing the "build" it can inline all HTML snippets for your widgets, optimize CSS, and minify/compress JavaScript
• Dojo can automatically find and instantiate widgets in HTML saving a lot of boilerplate code
• and much much more

All these features help greatly when building applications on the client side. That's why I like Dojo.

Obviously there are more ways to optimize high load web sites but according to my practice these are the most specific for JavaScript frameworks.

Answer 2

Quite simply: all of them.

All frameworks have been built in order to provide the fastest performance possible and provide the developers with useful functions and tools. Your choice should be based on your requirements.

JavaScript runs on the client-side, so none will affect your server performance. The only difference server-side is the amount of bandwidth used to transfer the .js files to the client.

I'm personally fond of MooTools because it answers my requirements and also sticks to my coding ideals. A lot of people adopted jQuery (I personally don't like it, doesn't mean it's not great). I haven't used the other ones.

But none is better than the other, it's all a question of requirements and personal preference.

Answer 3

I do not really think it makes a bit of difference. The big ones seem to use a mixture of Jquery & prototype along with others.

Quite frankly, it makes no difference what you use for heavily visited websites as we are talking about client technologies. After the file is loaded, there are not really any overheads. So, if you just want to do one simple thing and multiple frameworks support it, use whatever one has the smaller file size (of course, if it performs really bad, use another!)

This being said, google hosts a lot of the frameworks, so even this is really a non issue. I use Jquery hosted by Google and am very happy.

http://code.google.com/apis/ajaxlibs/

Backend and what the server should be using is a whole different question where you will get a thousand different answers!