Survey Results: JavaScript Frameworks

Introduction

Initially when I started this survey, I had a half and half desire to test out Google’s Spreadsheet Form capabilities but to also get an inkling of what other developer’s thought about the JavaScript framework / toolkit they use. When I launched the survey and blogged, tweeted and emailed it to some folks, my best hope was to get about 100 submissions. I was delightfully surprised that when I closed it two weeks later, I had just a little over 600 submissions!

Read on…

This was a great learning experience for me in so many ways. First off, I never planned on this being a professional survey that would give me extremely valuable data. I knew that because of the methods I was using to gain submissions were going to be skewed based on the communities I sent it to. In addition, I provided no incentive for people to take the survey. I had to lure them in on the notion that it would be anonymous, very short, and I would be sharing the results later on.

As I watched the results come in the first week and I started to read some of the comments and suggestions, folks suggested a couple of ideas for the survey. With that, I added those changes immediately. Obviously, that is going to change my results slightly and I also won’t get quite as valuable of data had a left it alone from the beginning. But the suggestions were good enough that I implemented them. Also, any changes to the survey were made before it had reached a 200 response level. The majority of the respondents were submitting the final draft of the survey.

Another key point that I learned through this process was that I may not have been comparing apples to apples. A few respondents wrote in their notes that the “frameworks” I had put in the list were not all the same type of JavaScript frameworks. One respondent replied with the following:

IMHO it doesn’t make much sense to compare JavaScript libraries with such a different focus and feature set:

1. “JavaScript Libraries”
Prototype, jQuery and MooTools are merely cross-browser abstraction layers for DOM-oriented low-level tasks, e.g. for enhancing a traditional website.

2. “RIA Frameworks”
YUI, Dojo and qooxdoo are much more comprehensive, include widgets, a GUI toolkit and come with development tools like code compressors.

Once I read this, I realized this individual was completely correct. YUI, Dojo, and qooxdoo are quite a bit more expansive in their size, functionality, and overall support for building a “framework” for JavaScript. Right now is a good point to mention my underlying reason for conducting this survey. At work, I’ve been tasked to restructure the JavaScript architecture for the family of websites we operate. These are fairly large sites and are becoming very frontend heavy as we move to a static model employing RESTful requests to pull in dynamic data; our dependance on JavaScript will be increasing quite a bit over the coming months.

The main requirements I was looking for to implement in the new architecture was a faster executing JavaScript library (we currently use YUI), integrated test-driven development, JavaScript templating, lazy-loading of JavaScript source files, and the library needs to be namespaced to reduce conflict in our existing code.

Analysis

The first question that I get asked about the survey is which library was most popular. The answer there is jQuery. jQuery has been gaining quite a bit of steam lately and has generated a lot of buzz as well. However, just because it appears to be the most popular doesn’t mean it is the best and I don’t want folks to read the below results in that manner. Each individual developer needs to research and understand the different components of every library and framework they are interested in, to understand which components are going to be most useful in their projects. In fact, some projects may be require one library, and other projects may be best suited for a different library.

Many folks that read my blog are from the ColdFusion community and I felt that most of the respondents would be swayed towards jQuery. With that, I submitted the survey to a Django forum, a Ruby on Rails forum, a very large PHP forum, and TheServerSide.com (namely a large following of Java folks). I wanted to get as wide of an audience as possible.

Keep in mind when you read the responses below that the questions were all aimed at the developer’s feeling of the framework they used. While most responses are going to be biased, some developer’s were on the framework because they had adopted it early on and couldn’t switch or were forced to use it because of the project that they came on to.

Library Preference

The chart below illustrates the “Which JavaScript framework do you use the most in your projects?” question:

As I mentioned earlier, jQuery clearly dominated this question. My opinion on why is that jQuery is insanely easy to implement into your projects, it’s fast, it’s easy to pick up, and it is seems to be a buzzword among blogs. For a lot of developers, it is the clear choice as it does everything they need it to do.

Quality of Documentation

I felt that this question provided the most accurate results as documentation is something that developers have to be in tune with on a daily basis when working with a particular library. If the documentation consistently performs poorly then a developer is likely to stick with that toolkit.


The chart below illustrates the following question, “In regards to the framework you chose above, rate the quality of the documentation provided by the creators.”:

As someone who has worked with YUI in the past year, I would also agree that it has excellent documentation compared to other libraries I have worked with in the past.

Quality of Community Support

This was an interesting question. I am basically asking the developer to rate how they feel about the overall quality of the community support for the library. This can be just about anything such as a forum, newsgroup, IRC channel, blog, etc. While qooxdoo did rank the highest, it also has a very small following, hence the data is not as sparse as it would be for one of the large libraries such as jQuery and Prototype. However, it is still good to note that those who do use qooxdoo seem to be a passionate group.

The chart below illustrates the following question, “Rate the quality of support provided by the community.”:

Light-Duty / Heavy-Duty Performance

If I were to do conduct this survey again, I would leave these two questions out. Looking back, I realized that the information provided was pretty much useless for a few reasons. First of all, the question asks to the user to report how they feel the libraries perform under certain conditions, but I gave no specific cases in which for them to test these observations. Second of all, there is already much more valuable statistics available from SlickSpeed.

Ease of Implementation

In questioning about the ease of implementation, I was asking the developer to describe how easy they felt it was to not only install the framework into their page (whether the code was hosted on Google/Yahoo/AOL or whether they had to download it) but also to integrate the library functions into existing code/functions.

Again, it does not surprise me that jQuery sits on top for this one but I think it is due to it’s overwhelming popularity and the buzzword case I mentioned earlier. The problem with this question is that I am not asking the developer to compare the ease of implementation to their chosen library versus another one. The data has no relativity and is also pretty much useless. That data represented could contain many developer’s who have only ever tried jQuery and the installation + integration was easy! But perhaps if they had tried something like Dojo or YUI, they may have found those even easier and rated jQuery lower. It’s hard to determine from the data provided what exactly the developer is communicating for their chosen rating.

Perceived Popularity

This may sound like a funny question and that’s true, it is kind of a funny question. My motive for this question was to extract if the developer was using a framework like YUI, if they personally knew that it was not a very popular framework? And if so, it’s clear that they are going against the flow in using it. Most likely in this case, the developer’s using the “less popular” libraries are likely using them because they prefer the organizations that back them up, prefer the functionality, or are forced to use them. Nonetheless, I was very surprised to find the ZK framework come in 2nd for this. However, this goes back to the fact that a very small sample of the ZK community was captured in this survey.

The chart below illustrates the following question, “Rate how popular you feel your chosen framework is above similar JavaScript frameworks”:

3rd Party Plugin Quality

Plugins may or may not be important to developers. In my opinion, they should be very important. As a busy developer, you should always be on the lookout for the opportunity to use pre-written code to speed up your development. Granted, you should always inspect the code if you can and test it to make sure it will not only suit your needs, but it is implemented the way you would do it and that it is well-designed. The latter is what I was trying to get at. I wanted to know how developer’s felt about any of the plugins that were not included along with the library itself.

While a lot folks like the jQuery library, I’ve also heard many say what they don’t like about it is how quickly their page can grow in size by pulling in more plugins. This definitely makes sense as when the user loads a page, their browser has to download all those external JavaScript files slowing down the page quite a bit. It would be different if the library contained a dynamic loading method that allowed the plugins only to be actually downloaded when they were being used such as the dojo.require() method provided by the Dojo Toolkit.

The chart below illustrates the following question, “If your framework supports 3rd party plugins, rate the average quality of those plugins in terms of documentation, stability, quality, and implementation”:

Conclusion

I felt that this was a great learning experience for me in a few ways. One, I learned that developing a survey needs to take some more time to come up with questions that are going to more accurately provide the type of data you are looking for. Two, broad results are difficult to achieve on your own. Three, Google Docs is pretty darn good at creating an easy solution for forms and data entry/input! Four, comments and suggestions entry boxes on surveys are one of the most useful questions. So often I don’t fill these out because I am too lazy, but I received the most valuable input in that question.

When choosing a JavaScript library / toolkit / framework, do not choose the one that is most popular for the sake of it. Really dig deep and spend some time on it to find out the strengths and weakness of each one to ensure you choose the right tool for the right job.

I hope the information above was useful if not just generally interesting. As promised, here is the raw results from Google Spreadsheets.

In addition, please leave comments on what you thought about this experiment. Would you like to see another one focusing on different aspects and getting more comparisons in?

Popular Posts

• Developing Applications with Transfer ORM
• The First ActionScript MySQL Driver
• Safely Arrived at North Bethesda Marriott
• Merry Christmas
• Multiple SQL Statements