AJAX framework survey
Filed under: Discussion, Survey
By Sebastian Werner @ September 24, 2006 11:04 am
The guys at ajaxian.com have reported about a current survey regarding the popularity of common AJAX frameworks. It is quite clear why prototype is the winner. It's well-known, small and easily embedable into existing pages. However I think it is interesting that Mochikit is less widely used, because the targets of these libraries are comparable in my opinion. And Mochikit does not depends on extensions of native objects (especially Object.prototype) which makes it the better choice.
I should mention that in my opinion the whole survey is quite problematic because of their comparison of different levels of so named "AJAX frameworks". For a next survey I would suggest to divide the list into these groups:
AJAX wrappers & DOM utilities:
- Prototype & Scriptaclous & Rico
- Moo.fx
- jQuery
- Yahoo UI
- Mochikit
- XAJAX
- DWR (includes backend code, too)
Framework & Toolkits:
- Dojo
- Atlas
- GWT
- qooxdoo (seems to be missing ;))
I've grouped together Scriptaclous and Rico because they both depend on Prototype which means they are more or less an extension of this library and not a real separate solution.
What do you think?
Comment by Ben Galbraith
Hi,
qooxdoo was actually included in the survey, and just barely didn’t make the cut for the graphs on the site (it was at 1%, along with a bunch of other libs that were in the 1%-2% range).
I think your idea of organizing the survey a bit more makes sense. We’ll probably do something like that for the next one.
I’m not sure I understand the notion of combining Prototype, Script.aculo.us, and Rico. These were ranked quite differently whilst apart, and I personally very much enjoy understanding the relative popularity of all of them…
Ben
September 25, 2006 4:41 pm
Comment by Maxime Haineault
Hi,
I think you’ve pointed out an issue, framework should be better categorized. Prototype & Co are great, but nothing comparable to qooxdoo, which somehow doesn’t seem to
raise a lot of attention in the web 2.0 hype. But when it comes to building web applications I think qooxdoo leaves every other in the dust.. in the open source at least (DomAPI is quite complete, but is commercial).
I agree too that Scriptaculous and Rico are more “extensions” of the Prototype framework than a framework by itself.
And I don’t get the problem with extending the javascript language since it was designed to do so. It’s like saying that using macros in LISP is a bad coding technique while it makes this language more powefull than most others. Sure there is a lot of “bad ways” to do it, but if it’s done right I don’t see any problems with that.. I think that the problem comes from the fact that most people try really hard to use commons OO patterns in javascript while it’s a prototyped language.. Also, people tend to mix more than one framework to achieve the effects they want, that’s a great way to get yourself in trouble.
Anyway, i’m not a language architecture specialist, I might be wrong too.
September 25, 2006 7:44 pm
Comment by Sebastian
@Ben: Wow, qooxdoo was really in. Thank you for this information. Yes, I understand your interest in knowing “the relative popularity of all of them”. It might be interesting which users of prototype use these extensions, too. But maybe this is better placed into a second question. Especially large frameworks have sometimes the same featureset (or even more) than these prototype based ones. So it might be interesting which features of what framework other users really use e.g. user data storage (Dojo), history support (Dojo), Rico (LiveGrid), build system for the whole application (qooxdoo), custom API viewer (qooxdoo), …
@Maxime: While I’m sure DomAPI is one of the bigger ones, I think that it couldn’t measure with the other currently available closed frameworks like Bindows or Backbase. It is just a bit old-style fashioned. But hey, just my 2cents
@Maxime: The extension of native objects in general is no problem for me. It could be problematic in cases where you want to combine features of several libraries, but otherwise it’s OK. The problem of prototype however is, that they completely destroys the simple hash map feature of JavaScript because of their additions to the basic JavaScript Object. This is definitely a “bad way”.
September 25, 2006 9:56 pm
Comment by jolee
I write database applications. I have tried many frameworks in different languages. Finally, I use Qooxdoo + MochiKit + Helma + PostgreSql together. Now, I can totally forget about JAVA, PHP, PYTHON, RUBY… etc, and use javascript only to write all the programs.
I like the internal structure and design of Qooxdoo very much!
Currently, the widgets in Qooxdoo is just like traditional windows application. It might not be the taste of web designers and web programmers. It is because they always want their user interfaces more stylish and unique. I do think Qooxdoo will be more popular when having more fancy and beautiful widgets later.
September 26, 2006 2:23 pm
Comment by Leland Scott
Hi,
Earlier this year, I did a comprehensive review of all the active DHTML/Ajax toolkits and libraries and included Qooxdoo on the list. Unfortunately, Qooxdoo rated only a “C” because it has no support for WebKit-based browsers, which are the dominant browser on Mac OS X. I wrote to Qooxdoo and was told you do no testing with WebKit. I visited your site again today and sadly found no change in that. Nothing works.
I think you would see much more interest in your framework if you were truly cross-browser and cross-platform. Supporting only IE and Firefox is just not sufficient. WebKit is an open source project (http://www.webkit.org), and Safari and the other browsers built on it (Shiira, OmniWeb, and others) is one of the best web browsers out there–screaming fast, lots of developer support, and fully standards compliant. A large percentage of web developers use the Mac as their platform, and a Javascript library—particularly one that has ambitions of being an heir to DOMAPI—that doesn’t work on the native Mac OS X browser is out of the running before you get too far. (FYI, there’s a nascent project to port WebKit to Windows and Linux. There are already alpha products for those platforms available, though they’re pretty lame at this point. You can find more about that on the WebKit blog and wiki.)
Here’s what I wrote about Qooxdoo in March 2006:
C
qooxdoo
“qooxdoo is an advanced open-source javascript based toolkit. qooxdoo continues where simple HTML is not enough anymore. This way qooxdoo can help you to get your rich web application interface done - easier than ever before.”
This is primarily a framework for dhtml interfaces… A generic Ajax implementation was just released in February 2006. The online demos do not work in Safari 2.0, and the developers state that they do no testing for Safari. Most of the tests work fine in Firefox, but it’s clear from the look/feel applied to the GUI components that this is intended for use on Windows systems only and that other platforms are not being contemplated.
I will be doing an update to the original scoring in the next month, and I’d love to be able to say something nicer about Qooxdoo. The original scorecard, which has been widely referenced on the web over the last 6 months, is at http://www.musingsfrommars.org/2006/03/ajax-dhtml-library-scorecard.html
I did a followup in June, re-reviewing a number of toolkits and adding just as many new ones: http://www.musingsfrommars.org/2006/06/howre-we-doing-now-ajax-browsers.html
As I’ve said to other developer groups in the last few months, you should just buy a Mac to have available for testing. Doesn’t cost much, and I assure you it will get you a lot more favorable review that trying to build a platform for Windows (and perhaps Linux) only. In my experience, the cost of including Opera and Safari in your code to ensure compatibility is far lower than the cost of trying to include IE, and doing both will gain you a lot more goodwill with developers–your primary target audience at this point.
Regards,
Leland Scott
Musings from Mars
September 27, 2006 3:08 pm
Comment by Markus
@Sebastian: I came to the same conclusion and I agree with your idea to divide the list into several groups. For me prototype and jquery are collections of nice code for a quick implementation of ajax functionality and not a framework. They work on an lower level and don’t try to implement GUI features.
Level 1 scripts: Collections of Javascript functionality
- Prototype
- jQuery
- MochiKit
Level 2 scripts: Based on others. GUI features
- Scriptaclous
- Rico
- Moo.fx
Level 1+2 scripts (frameworks):
- qooxdoo
- Dojo
The others mentioned in your blog-entry I haven’t tested yet - or forgotten
September 27, 2006 6:59 pm
Comment by Sebastian
< ?xml version="1.0" encoding="utf-8"?> < !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
@Leland: Regarding Safari suppoer. Interesting analysis, but it's not true. Yes the demos does not work because of some layout issues in Safari and other webkit like browsers. But we have achieved major improvements in the overall compatibility. All the JavaScript crashes in Safari are gone. However and that's true - the GUI doesn't work in Safari yet. Respecting that many Mac OS users use Safari on a daily basis you must admit that the overall usage is just 2-3 percent. That mean, Safari is quite interesting, but it simple does not have the same focus than IE and Mozilla. It's better comparable to the position Opera is in, too. It's a small nice browser with a nice concept and a nice GUI. But Safari has many more bugs than even Opera. The most time these problems are no errors in qooxdoo, but malformed or even missing implementations in Safari. If you search the source code for Safari you can already found some comments about stuff that seems to be broken. I hope this explains why especially such advanced toolkits like qooxdoo have some problems here. A simple cross-browser XmlHttp wrapper is simple compared to this job.
Please don't forget that the performance of Safari is only good using tradional web pages. In our tests, you can find them in the performance section, the most things are about 3-10 times slower in Safari than in Firefox. It's just not correct that Safari has a good JavaScript performance. Even if qooxdoo will work it will be dramatically slower. That's not bad. Remember, even Firefox has needed many years of development to reach the todays stability and performance. Hopefully the Apple guys invest even more time to improve Safari in aspects which are interesting for qooxdoo. The other point you mentioned is not true, too. The default appearance of qooxdoo is comparable to Windows, but this does not mean, that qooxdoo must look this way. As a framework with a professional ambition, we created a toolkit that tries to solve the look&feel of the worlds leading operating system first. Please take a look at the power of our appearance themes. You can configure everything yourself, you can use textures, complex border styles, different colors, icons, …
If you have more questions and suggestions please feel free to contact me via mail: sebastian dot werner at 1und1 dot de.
September 29, 2006 12:14 am
Comment by Anonymous
Here’s why I think Qooxdoo is behind in the polls
NON EXISTENT MARKETING (Almost). The only way I managed to find Qooxdoo is via the ajaxian listing…. its so obsure nobody even heard of it. The Qooxdoo guys need to write and post public regular introductory articles on Ajaxian and other Java, PHP and .Net to tell people how to use it, what benefit it has, the fantastic property, queues and events system etc … generate hype (Which it deserves 10Xs more).
OO decorator pattern type of programming model is so much more powerful and the way you guys did it is simply amazing. But it departs from traditional DHTML web development and is forbidden territory to many who fear the unknown. People will resist change till they see that the potential benefits too irresistable overcoming their fears. People need to know how it really is so much easier and so much more powerful. Again … more public articles please! And I don’t mean on your own website
You need an evangelist!
September 29, 2006 3:54 am
Comment by Leland Scott
Sebastian,
Some of your comments, and your negative attitude toward Safari in general, clarify why QooxDoo hasn’t “grown up” to full cross-browser support in the Ajax/DHTML world. You are welcome, of course, to continue viewing Safari and Mac OS X as simply niche players too small to bother with, but then you’re missing the bigger picture. Web 2.0 isn’t supposed to be about writing for one browser or another. It’s supposed to be about writing to standards, and using advanced CSS and Javascript to enhance the overall web user interface. Every browser has “bugs,” but that doesn’t mean you just write them off. Safari/WebKit is a huge player in the browser world today, and nearly all the open source Ajax toolkits/frameworks support it by now. I don’t have any figures on this, but it’s pretty clear to me that the percentage of web developers–especially web 2.0 developers–who use the Mac as their base platform is much higher than in the population at large. Just to mention a few that I know of, the developers of Prototype/Script.aculo.us and Dojo all develop using Mac OS X. I know of at least one major player in the Yahoo YUI project who’s a Mac developer. That’s already a very high percentage—and huge influence—of Mac developers in today’s Ajax marketplace. If you believe the Ajaxian results, that means that Mac developers have built the Ajax platforms chosen by 97% percent of the folks who voted in it. There’s a reason for this—Prototype and Dojo both a full and unconditional support for Mac OS X and Safari 2.x.
If you really want QooxDoo to be as highly respected, you need to take support for Safari seriously.
I’ll be emailing you some data for your records, too…. I ran the performance test you mentioned. Indeed, Safari performs more poorly than the other two browsers I tried–Opera 9 and Camino. I wonder if that’s not a reflection of the fact that the tests are optimized for Gecko, however? Camino outperformed Opera by a significant margin as well, yet Opera shows much faster JavaScript performance than Firefox in other tests I’ve see. I couldn’t get your test to run in Firefox 1.5, or I’d have done that one, too. I made some screen movies I’ll email to you.
Regarding the box test you’ve posted, however, I’m pleased to report that the latest WebKit performs flawlessly. I’ll send you screenshots… they were actually made with Safari 3.0, which is included with the Leopard (Mac OS X 10.5) preview, but use a recent WebKit build for the JavaScript engine. The latest nightly WebKit has an even more current build than Safari 3.0 at this point, so you should be able to confirm the results with the latest nightly download.
Finally, let me remark that JavaScript performance isn’t the total picture when you’re measuring performance of a Web 2.0 interface. As you know, CSS is a huge part of the picture there, and CSS rendering performance is probably at least a big a factor as JavaScript performance in measuring how an interface actually “feels” to the end user. From what I’ve read and understand, Safari has been leading in CSS standards compliance for some time now (it was the first to pass the “Acid” test last year), and the WebKit guys continue to push the limits of CSS implementations.
Regards,
Leland
September 29, 2006 11:46 pm
Comment by Sebastian
@Leland: It seems you have misunderstood me. As I have already mentioned we have invested many hours to improve the support for Safari in qooxdoo. You should even be able to confirm this. Many stuff is already working well. For example the whole OO model, properties, events, AJAX related stuff, etc. The layout is just one part of the whole thing.
This explains why I think that a comparison to other, especially smaller toolkits, isn’t really fair. Compared to Prototype/Scriptaclous or even Dojo, qooxdoo includes a complete GUI toolkit. That makes it probably more complicated to support each browser. In Dojo for example much of the widget implementation code includes cross-browser code, too (or even CSS). You don’t find stuff like this in qooxdoo. The layout engine of qooxdoo automatically tries to fix these issues. You should better compare qooxdoo with Backbase or Bindows. Even if they are commercial.
Regarding priority of Safari I think our standpoints are a little different. We think in user percentage of customers and not of developers. In the real world the customers (or product managers) decide and not the developers. Even if there are many Mac developers, they could also use Camino or Firefox to develop for example. Safari is not the only option.
The JavaScript bugs of Safari are really quite ugly. It isn’t interesting for qooxdoo if Safari is better in the CSS world and even have support for ACID2. They have invested much of their development time to increase the support for CSS and for current web pages. Safari is now a good option for general web surfing. But they haven’t nearly invested as much time to JavaScript compared to the Mozilla guys for example. This should be also one big TODO item on the list of the webkit developers.
In general the time is limited. We have to decide how many hours we spend for general new or improved features or for fixing bugs and improve existing code. To enhance the support for the different browsers is just one of the points. And as I explained already the marked share in the customer world of Safari is about 2-3%. As more users Safari use, as easier it will be, to explain to our product managers, that we need more time, to better support this browser.
Under Windows Opera seems to be the one with the fastest JS engine. Seems to be different under Mac OS. We have no special optimizations for the different browsers. I even don’t know how to optimize for gecko for example.
I hope this explains that I would love to have full Safari support in qooxdoo.
September 30, 2006 6:45 am
Comment by sharmak
In my view Qooxdoo is advanced JavaScript based frame work with best ui widgets. Currently JavaScript frameworks are not caught attention, because in most of the web application being developed today, the MVC is still at the server side. In future, the MVC will move to the client side and Qooxdoo will be in the developer’s radar. All the browser’s have to implement JavaScript cleanly to survive in the market, which will improve the cross browser compatibility of Qooxdoo and similar framwworks.
October 13, 2006 2:14 am
Comment by Joe
Check out this http://www.ajaxdiff.com site which is a new community platform for comparing AJAX frameworks. It is completely open for community contributions allowing adding and updating framework details and indexing related publications. The platform was aired today with initial content and is waiting for you guys to start pumping information to it.
I will be happy to receive feedbacks. The site is built upon a dedicated framework that will be updated with your ideas.
Thanks,
Joe Abrams
April 5, 2007 11:24 pm