Choosing a JavaScript framework

To some developers, the large number of JavaScript frameworks available means they have many fun hours ahead of them while trying them all out before deciding which one to use on a regular basis.

Others don’t want to do that but pick the first one they hear of or the first one that is required by a javaScript tutorial they come across and stick with that. Then there are those who mix and match and end up with three or four different frameworks in the same project.

What I’m getting at is that once you’ve decided that using a JavaScript framework is appropriate for the task you’re faced with, it can be hard to choose the one that is right for you. And to make things worse, what is right for you may not be right for your co-workers.

Brian Reindel shares his thoughts on this in How to choose a JavaScript framework, and lists some questions that may help you decide:

  • What are your project requirements?
  • Does the framework support A-Grade browsers?
  • Is there a core team of developers?
  • How mature is the framework?
  • How often are updates publicly released?
  • How friendly is the documentation?
  • Is there an active community?
  • Are benchmark tests performed regularly?
  • How extensible is the framework?
  • Do you like the API style?

Those are all questions worth asking. Their importance varies, of course, but finding the answers to them will help you make a decision. Four questions I’d like to add are:

  • How much will the end user need to download if I use this framework?
  • Do the other people working on this project feel comfortable with this framework?
  • Does the framework force me to change the way I write my HTML?
  • Will I need to invalidate my HTML to make full use of the framework?

If you’ve read my article Learn JavaScript before tasting the library kool-aid you may think that I am completely opposed to using JavaScript frameworks or libraries, but I am not. I use them when they will help me achieve a better end result.

I’m not particularly attached to one specific framework, however. So far I have ended up using YUI, jQuery, and DOM Assistant, mainly depending on the project requirements and what suits other members of the project team.

Of those three, DOM Assistant is by far the easiest for me to use. It is also the smallest and the one with the least number of features (though a number of very useful additions are in the works). Maybe there is a connection, I don’t know.

What about you? Do you use other criteria than the ones mentioned here when choosing a JavaScript library? What do you normally end up using?

Update: I thought of another couple of important questions to ask yourself before deciding on a particular framework, so I added them to my list.

Posted on December 10, 2007 in JavaScript

Comments

  1. December 10, 2007 by Alejandro Moreno

    I started with DOM Assistant for the same reasons you mention, but I switched to jQuery because some simple effects where required on top of the usual DOM manipulation.

    I do aim for simplicity, and for me jQuery with the right stylesheets can achieve quite a bit without resorting to extra libraries or plugins. Sure, it won’t look or behave like Ext2.0, but honestly, I think Ext2.0 is a bit much.

  2. I currently use prototype, since it is easy to learn and already beneficial in my work for small projects… however as a Domino developer I believe Dojo is going to bethe JS framework that is going to be shipped in the next major release update so big chance I will need to study that JS framework.

    One important aspect in which framework to use would be how easy it willbe to add widgets to it, and how easy updates can be installed…

  3. Don’t forget my framework. It’s about to go beta. ;-)

  4. To me, community is the lifeblood of an open source framework. Here are a few things to check regarding community:

    • Observe how easily extendable and how many users are contributing their own work to the library - plugins, modules, etc.

    • Google Trends (google.com/trends) is also a good indicator of community and buzz. Try typing, “yui javascript, jquery javascript, prototype javascript, etc”

    • Check the numbers of idlers in the IRC (freenode) chat rooms.

    • Also, is the project opening itself up to the community to contribute their ideas and projects? plugins.jquery.com was built by a user, etc.

    I am a big proponent of jQuery myself for community sake and was initially hooked in by ease of use and getting started.

    Thanks for the great summary of things to consider, Roger.

  5. I don’t like using JavaScript that much. If I don’t have to use it, I don’t.

    When I do use it, I go for YUI since it also has a nice CSS framework as part of the full package. I’m using Reset CSS on nearly all of the projects I’m working on.

  6. After some debating within my company over prototype+scriptaculous vs. jquery we decided to go with jquery, based on speed reports, file size, and syntax.

    It helps that it’s userbase is so active as well, and that while jquery does all the dom traversing and editing you want, it also has some nice small effects that can be easily extended.

    Also, you have to admit that the syntax is just sexy ;)

  7. I use Mootools, mostly because I like the name, but also because I can choose what compontents I need so the users don’t have to download code that never are used.

  8. At work, script.aculo.us and jQuery are the most common. However, I usually ending upp writing a script from scratch since the eyecandy effects made from these libraries brakes when they go public. Jeremy Keith and Robert Nyman has a whole bunch of scripts I have collected in the file common.js where they get credits - and these always work as expected.

    So I really cannot say I am blown away by the thought of a library. Yet.

  9. After trying all (or at least many) frameworks I ended up with jQuery. The main reason for me was the documentation for jQuery, which was far better than any other framework.

  10. I use mootools, I started using it because it had some cool effects. But now I’m sticking with it because I like the documentation, the community and the naming of functions is just guessable which is nice.

  11. Do the other people working on this project feel comfortable with this framework?

    Hi Roger,

    That is a great question to add into the mix. Currently, I only work with one interface engineer, and he prefers jQuery as well. It is very likely though if you work with other engineers that they might prefer something completely different. The benefit of all these frameworks being written in JavaScript, is that they are easy to try out in a development sandbox. We should never be afraid to pick up another one.

    As an aside, your article “Learn JavaScript before tasting the library kool-aid” was an enjoyable read, and I have to agree with much of it. I would go so far as to argue if you can’t grasp 80-90% of the core concepts behind JavaScript frameworks, then you might want to reconsider using one. Several designers would probably disagree with me, but having this knowledge can be rewarding personally and professionally. I think it is worth the effort.

  12. I use DOM Assistant and when I need more fx I go for Prototype + Scriptaculous. The main reason for using DOM assistant is that it’s lightweight. Prototype got a really good documentation although i think it’s a bit big in file size. It’s got a lot of nice features though.

  13. December 11, 2007 by Jason Ong

    Write your own library if you can. It’ll help you appreciate JS as a language better and also what better way to strip down to just what you and your team need?

  14. Very cool. It’s interesting to see different perspectives on why people choose frameworks, and what they look for in them. I also find it educational to see ‘how’ people recommend frameworks as well. And Roger, your approach is very non-intimidating, nor threatening (aka, I like your style). And albeit I come across as a YUI Giant, I always encourage developers to find themselves in a JavaScript framework since we all have different needs and wants out of them. I was weary at first when I read the headline of this post, but you’ve maintained yourself very well :). It’s good not to get into the JavaScript Nazi camp. It seems that whenever I use YUI in my examples, people become defensive about their favorite library (mostly jQuery) and feel the need to pull down their pants and show me how long their under-bits are. I long for a day without trolls like that.

  15. December 11, 2007 by Matthew Pettitt

    I started with MooTools, got frustrated with it, looked at a whole bunch of others, then found jQuery and have stuck with that so far: it’s got filesize (small) and documentation (loads) in its favour, as well as a good community which is responsive to queries.

    The main reason for choosing MooTools was down to Joomla (which we use quite a lot) using it, but I’m not that attached to Joomla personally!

  16. I’ve used Prototype and Moo.fx in the past, and had a brief play with YUI, but I’ve pretty much standardised on jQuery for easy to intermediate stuff and Ext (with handy jQuery adapter) for hardcore app-building.

    I think it’s important to also consider how familiar you are with the framework - unless there was a very compelling reason, I wouldn’t be likely to switch to Prototype or YUI for a particular project, even if there was a slight advantage to be gained in terms of features immediately available, because I don’t want to sacrifice the time needed to get up to speed with a new framework.

  17. December 11, 2007 by Pete B

    I use Mootools, initially chosen because the animations and dhtml effects are so smooth and sophisticated, after closer inspection there is really nothing it does not offer in other areas too.

  18. Mootools all over here too. Actually I only use it for the effects etc. For all other problems we mostly have our own in house developed javascript.

    But before this comments stream becomes and endless ‘I use this and you should too’-stream. I think your ideas behind the picking of a framework are good none the less I would weigh in the community and it’s drive to get things done a lot heavier :)

  19. I am happy with the Jquery =)

  20. Up to this point I’ve only used Script.aculo.us because a lot of examples depend on it. I’ve always tried to limit my JavaScript to only helpful little tricks—let the server-side to the thinking.

  21. Almost two years ago I started on developing a new PHP framework for the company I work for. We built in support for Ajax and other Javascript functionality and chose the MochiKit library.

    At the time it was better documented than prototype and was frequently updated, but since the moment we went with MochiKit no updates have been released and the project seems dead.

    So even if you choose to work with one library, you can never know for sure the core developers will keep up the good work.

  22. jQuery FTW! ;) It’s lightweight, robust, and very easy to use. It also has a relatively good documentation.

    I use it when I need to do some basic DOM operations. Anything other than that - I use a custom build set of functions and objects that may be called a framework.

  23. I started with YUI and moved to jQuery for some time. But I found YUI is a complete solution with its CSS solutions (reset and grids in particular, skins to some extent) and better, a content distribution network (yui.yahooapis.com).

  24. December 11, 2007 by Roger Johansson (Author comment)

    Dean:

    Don’t forget my framework. It’s about to go beta. ;-)

    Ooh, nice! :-)

    Kilian:

    Also, you have to admit that the syntax is just sexy ;)

    Well, I guess I’m in the minority here, but the syntax is what is least appealing to me about jQuery. I find myself reading, re-reading, and re-re-reading jQuery code to understand what’s going on. Not sure why since many others seem to love it.

    Brian:

    Several designers would probably disagree with me, but having this knowledge can be rewarding personally and professionally. I think it is worth the effort.

    Yes, I agree that it is absolutely worth the effort.

    Jason:

    Write your own library if you can. It’ll help you appreciate JS as a language better and also what better way to strip down to just what you and your team need?

    Sometimes that may be an option, and yes it is a very good way of learning and getting exactly what you need.

    Dustin:

    I was weary at first when I read the headline of this post, but you’ve maintained yourself very well :). It’s good not to get into the JavaScript Nazi camp.

    LOL :-). Thanks. I guess I’m pretty agnostic about JavaScript libraries, as long as they don’t force me to change the way I write my HTML or depend on invalid attributes. Hmm, that’s another question I should add to the list.

    And I too would like to see less of the “This is rubbish, I can do it all in one line with my darling library!” trolls.

    Niek:

    So even if you choose to work with one library, you can never know for sure the core developers will keep up the good work.

    Good point. I guess you should always be prepared to look at other options if support for the library you use disappears.

  25. Well, I guess I’m in the minority here, but the syntax is what is least appealing to me about jQuery. I find myself reading, re-reading, and re-re-reading jQuery code to understand what’s going on. Not sure why since many others seem to love it.

    I totally agree with you there, Roger. Having used jQuery in a project where I came in late in the game to lend some additional help, I find it easy to write but hard to decipher. I think that’s because many aspects of it are so highly contextual and its API just feels really non-native. Endless chainability? No thank you.

    In addition to jQuery, I’ve also used MooTools and Prototype/Scriptaculous. I’ve also a contributed to a library developed in-house at work which is lighter-weight than the others and doesn’t suffer from feature bloat. Choosing which one to use on a project is always a bit of a challenge, but the specific requirements of the project usually make the choice clear.

    For what it’s worth, I tend to gravitate towards MooTools when I have free reign. I like its feature set, its API makes sense to me and its modularity makes it very flexible in my book.

  26. December 12, 2007 by John Magnusson

    I went deep down through the links and found a post about Mastering JavaScript. Really good reading indeed, so good it had to go out to my team members.

    The reason I’m writing is that I have been put to test out what framework to might use in a fairly large project. The problem here is that we’re stuck with the .Net Ajax Framework that just comes along, which is maybe not the best but still does the job we want for most Ajax bits. Though we might if we find something good, need or would be nice to have a framework for being more efficient when scripting. So does anyone have a clue about how different frameworks fit together?

    Haven’t tested yet but are looking into Prototype and trying to read until I get enough time to try it out, with no luck so far on the subject.

  27. So far I have only really used the YUI framework to build my apps with and found it to be a real timesaver.

    YUI also benefits from the fact that the large community it has is always feeding back bug reports making it a high quality library.

    As for writing your own library…is it worth it with so many solid libraries around…I have been working with JS solidly for year and a half now and I have a good understanding now but I wouldn’t feel comfortable writing one with same quality as YUI…imo unless you are a JS wizard I would just pick up an existing library and add on what you need.

    I need to check out JQuery though…it seems to have a lot of love from the comments in the article.

  28. December 12, 2007 by Matthew Smith

    I am also pretty agnostic about JS libraries. I still feel that a developer should use plain JS for 95+% of the code he/she writes and only supplement it with libraries. When I write code with libraries, I always ask myself, how easy would it be to remove this library or change it to another one?

  29. December 12, 2007 by Paul Collins

    I thought in addition to “A-grade browser support”, it is worth knowing the list of browsers it supports apart from them.

    I have run into some problems of my own when I learned that JQuery didn’t work in IE5 after setting it up and testing. Whilst most people don’t use this browser, it is occasionally a requirement of my clients and would have been worth knowing before I started out the first time!

  30. I find myself reading, re-reading, and re-re-reading jQuery code to understand what’s going on.

    I find the same with prototype and mootools. It takes some brain power to leap between say, mootools to jQuery. It really depends on what you start with which one is easier to understand.

  31. I’m working with jQuery. It’s a good compromise between being lightweight, fast and having many advanced features. DOM Assistant would be my second choice though.

  32. I’m on jQuery in my spare time and YUI at work.

    jQuery really allows you to do some amazing stuff with minimum amount of code, and to me, at least, the syntax is very straight forward:

    $('CSS-selector to:grab #elements to .play[with]').now().do().cool().stuff();
    

    I do like YUI as well though as it feels a bit more professional and geekier than jQuery. It encourages you to write more “real” JS and feels a bit more “stable” for building massive applications for some reason. jQuery feels a bit more like the noob’s choice. Quick and easy. But I still love it tho :)

  33. So, I’ve used and use both jQuery and YUI.

    In any project where I don’t need to use fancy UI widgets and just need to add a little bit extra to a site over what XHTML and CSS can give me then I choose jQuery.

    If I’m building a web application and plan to make it very interactive I choose YUI for most all the reasons stated above and that it’s professionally backed and has a lot of nice UI widgets that work well.

    Hey if you jQuery lovers haven’t seen YUI 2.4.0 now has a [CSS] Selector Utility!

  34. Why would you use a one-for-all framework?

    You will GUARANTEE to force your users to download information they don’t need.

    I allways try to keep JavaScript to a minimum (think progressive enhancement) and I’ve also found that they are severely bloated by trying to cater for every browser on the market. I don’t spend hours on trying to fix css bugs on IE5 so I don’t feel I need to cover issues that MAY arise in the JavaScrip. (Your site SHOULD work perfectly well without it.)

    Just my own oppinion…

  35. I was skeptical of using any JavaScript libraries until Mr. Keith and Mr. Diaz gave positive reviews of jQuery. I took the leap and haven’t looked back.

  36. January 12, 2008 by Cristian Datculescu

    I use mootools baceuse of the modular implementation and ease of use. I find documentation extraordinary and haven’t found bugs so far. Basicly i work a lot with ajax requests, but i am trying to avoid all the fancy effects when i can. I also like the way the getelementbyid is replaced with a more php like syntax and the “getelementbyclassname” is replaced in the same way. I just went mad one day with almost a hundred getelementbyid written in the normal syntax.

  37. I like extjs.com very much, it already integrated with several framework with clean documentation, coding, and I feel like it give me so much impression to be a professional web application developer.

  38. I use mootools, I started using it because it was the first framework I’ve found… Moo is is is realy cool development kit to work with.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.