Pingdom has complied a list of the Javascript frameworks used by the top sites on the web (top 100 in Alexa US, Webware’s top 100 web apps). jQuery and Prototype are the top choices, getting 11 and 13 respectively.
It’s interesting to note that Dojo is not even featured on this list, though if you check the comments you’ll see that it is used partially at the apple site (in the apple store). This makes me wonder even more regarding Zend’s latest decision to integrate Dojo into their framework. As I commented in that release statement (comment #6 is mine), I feel that Dojo isn’t appropriate as the default for the framework as it is more complex and much less documented than the other top frameworks.
As a long time jQuery developer I have no intentions of integrating a new Javascript library into my development environment, so I’m obviously biased. I still feel as though Zend missed an opportunity here to better cater to the needs of a broader user base and instead chose to prioritize its partners best interests.
2008 - The Future
Caveat: I’m a Software Architect for Zend Framework, and you link to me above.
Many people were surprised with Zend’s adoption of Dojo. When we were evaluating solutions, we were looking at several areas: licensing, design, contributions to standards, and comprehensibility. When it comes down to it, no matter what we chose, we would have alienated a good part of the community. I’ve heard feedback from YUI, jQuery, Prototype, ExtJS, MooTools, and other supporters in the past couple months — all of them wondering why we didn’t pick _their_ particular javascript toolkit. The answer is quite simply that Dojo fit the criteria we’d set for the project — which serves our user base.
Please be aware, however, that we are not entering an exclusive agreement with Dojo. The entire plan is to (a) allow ZF developers to have an out-of-the-box solution for rich internet applications, and (b) provide a blueprint that community contributors can follow for developing integration with their own preferred javascript toolkit. For (b) to succeed, we have to show that the integration, while rich, will not be deep, and can be easily swapped with other toolkits. Right now, you can use any ajax toolkit you want with ZF, and I for one intend to keep it that way.
Comment by Matthew Weier O'Phinney — 24 June @ 1:11 pm
Thanks for the comment Matthew.
However I still feel as if Dojo was the least compatible choice given the reasons I listed here and on your blog post. It’s a shame that you (Zend) choose to model your first javascript library integration after Dojo, as it will instill certain ways to do things with the JS integration components that are less relevant for other frameworks.
Comment by Eran Galperin — 24 June @ 2:04 pm
Would you care to elaborate on what things you feel will occur that will be less relevant for other frameworks? Your statement is awfully vague, and gives me absolutely nothing to go on… and it does not address anything specifically in the public proposals we’ve posted. If there truly is something we could do with the integration that could potentially impact how future integrations are performed, now is the time to know — as the integration is in active development. Additionally, while we suggest the Dojo integration would serve as a blueprint for other frameworks, we’re not creating any interfaces or abstract classes for JS integration — we fully realize that each JS toolkit has a different approach, and we do not wish to limit what can be done with each.
I invite you to message me privately if you wish — I am more than willing to listen to your concerns, and I’d like to get the Dojo integration done right — which includes making sure that it is done in a way that will accomodate the needs of other toolkits.
Comment by Matthew Weier O'Phinney — 24 June @ 2:17 pm