My PHP and MQTT post provoked a number of questions in the comments, via IM and on Twitter about why I chose Prototype over jQuery or Dojo (and I imagine there may be other choices too). I was also asked why I’m not using WebSphere sMash.
I have no particular affiliation or preference here. The simple and most honest answer is that I was looking for an easy way to make an Ajax call and the Prototype introduction made it sound really straightforward (which it is). I also wanted something compact, as I knew that in the long run this is going to be embedded into an iPhone webapp where (down)loading times will matter. I admit I’ve done absolutely zero analysis of the relative sizes of the three frameworks, but Prototype seemed OK, even though it could be smaller. [just checked, and prototype.js is marginally larger than jquery.js by a few bytes, not looked at dojo… but wow, OK, 90Kb is not so small!] Given that this is for an iPhone app I might be better looking at whether iUi offers what I need instead.
So I’m doing this partly for my own education – I’ve talked a lot about Ajax and Web 2.0 and stuff but have been away from web coding for a while. I may well try all three frameworks, and I’m interested in opinions. At the moment the only requirement is the ability to easily update an inline div in a page with the results of an HTTP POST call. I could probably hand-code the XMLHttpRequest call if I want to be super-compact about it, but Prototype seemed quick and convenient. I suppose on the Dojo side, I have a perception that it’s more about widgets and will take more of a mental jump for me to use. Thinking about it now, I assume it must have the core Ajax call stuff in there too, but again the Prototype sample just popped out at me and worked after a web search 🙂
As for the PHP vs sMash question – I have nothing against sMash / Project Zero, but I do have a small Ubuntu box which has PHP installed already, and I didn’t need to do much more to that (except get SAM added as a PHP module). Again, speed and convenience was pretty much the driver here.
Feel free to chime in with your thoughts. I have no axes to grind and I’m interested to learn!
Andy, I think it’s good to just experiment so keep plugging away. I’ve become a big jQuery fan recently and think the applause is well deserved.
If it’s for an iphone app you may want to consider using the google javascript hosting service (so it may be cached).
Here’s how I’d do it in jQuery.
google.load(“jquery”, “1”);
$(document).ready(function() {
$(“div#content”).load(“content.html”, { ‘postdata[]’: [“foo”, “bar”] });
});
Given that you did no research, I’d say you’re fortunate to have avoided the intensely bletcherous and awful dojo, but less fortunate to have missed the neato jQuery.
This is the nicest looking textarea I’ve ever seen.
Dojo itself isn’t about widgets. Dijit is a widget framework built on top of Dojo, which by itself is comparable in size and functionality of the other core frameworks mentioned.
http://dojofindings.blogspot.com/2009/02/dojonot-in-6k-but-comparable-to-jquery.html
Dojo has many progressive uses, and is designed to become as large or small as needed when needed. There is only “more to know” about Dojo if you wish to go beyond simple event connections, fx, ajax, query and dom manipulation.
I’ve done a few “Base Dojo” articles in the past. Recently http://dev.opera.com/articles/view/introducing-the-dojo-toolkit/
“Base Dojo” refers to the dojo.js file, 26k after gzip. All the rest of the toolkit can be considered a “plugin”, though benefits from a unified release cycle, common naming conventions and open community.
Regards
It’s important to do an apples to apples comparison with the toolkits. Each has their own history, and reasons they came about and focus on different areas that they excel in based on the needs of their communities.
Prototype, Dojo, jQuery all have very similar capabilities when you compare their “core” functions. ie. What’s available in out of the box with just jquery.js, prototype.js, dojo.js. With each, the ability to do progressive ajax page enhancement to do DOM queries via CSS selectors, DOM and CSSOM manipulation via chaining api calls, basic effects, etc. *is possible in all three libraries* with only a small download–but check the individual features of each library because some provide more than others in the core file. If you aren’t doing really large scale web applications, where you need to share, just make sure the capabilities in the base are sufficient for your needs.
It’s once you get into larger projects where reuse, building widgets, internationalization, accessibility where the toolkits begin to differentiate themselves. The other are is in the plugins provided with the toolkits. Make sure you are comparing apples to apples. For example: Dojo base vs. jQuery vs. Prototype, and Dojo Dijit vs. JQuery UI vs. Scriptaculous. Are all the plugins QA’d together with each release, or do you have to go to each plugin’s author to understand the level of quality (or things like the pedigree of code, whether the widgets are accessible, or internationalized, etc.). Some toolkits provide both declarative and programmatic api’s for page content (this can simplify getting pages prototyped). Others provide just programmatic (fastest, works best with xhtml and w3c validation).
If you are doing large scale web app development with Ajax, some of the additional things to compare are:
1) modularity: Once you have the base file in place, what is the toolkits mechanism for modularity?
2) Does the toolkit pollute the global JS and CSS namespaces? jQuery and Dojo have fewer global objects that Prototype (1-2 vs. hundereds). If you’re ever going to use more than one library on the same page (portal for example), namespace pollution and native object extension are bad things.
3) Does the toolkit extend standard JS Object/Array, etc. objects (considered bad practice in big projects, but considered helpful shorthand in single page websites ). jQuery and Dojo are clean from these types of extensions compared to Prototype. (few vs. many)
4) Does your website need to be accessible? If so check the toolkit features. The toolkits vary greatly in their support for keyboard navigation, high contrast and screen readers. (Dojo’s Dijit leads here, jQuery UI, prototype third).
5) Is your website features going to be used internationally. The toolkits vary quite a bit with support for internationalized calendars, date fields, etc. (Dojo has international features like built into its dojo.js, with Dijit widgets like Date picker that are already translated into many languages)
6) Does the library make it easy to do OO-style class declaration? Dojo: yes, jQuery: yes via plugin
7) Does the library make it easy to encapsulate common patterns into widgets? Does it provide features to help with tab ordering, events, CSS variation on different browsers. On big projects where you need to share your widgets with other teams, this can be a very important feature. Dojo Dijit: has Django-style templating for widgets, jQuery has it’s plugin mechanism and many plugins to help.
8) The individual features of widgets themselves. If you need to use widgets of a toolkit, you’ll need to compare their features individually, but make sure that the widgets you need are qa’d/tested together when the core toolkit version moves to newer versions. Do the grid widgets scale nicely when viewing millions of rows. Do you charts support the plot styles you need, etc.
9) Data connectivity and Data binding: What does the toolkit provide to make it easy to connect widgets to data (read and write)? Dojo has a core data api with basic JSON connectors, and many types of data connectors as plugins/extensions in DojoX. The widgets work with the standard data api so that you can replace the data connector layer with your own. Not sure if you can do this in jQuery now, but you cant in Prototype and Scriptaculous.
I hope the above points help you when considering the features of an Ajax library.
Also, here’s an article on Dojo that may help with the perception that its too big.
http://dojofindings.blogspot.com/2009/02/dojonot-in-6k-but-comparable-to-jquery.html
chrism,
That’s a nice, comprehensive bunch of criteria. I’ll take strong exception only to #6, as I believe that a framework that adds classes to JavaScript is doing way more harm than good. One should learn to use JavaScript for its strengths, and not try to shoehorn it into a broken inheritance-based style of OO programming.
It looks like file size and simplicity are important for you. If that’s the case, I’d recommend midori. At only 45K uncompressed, it supports CSS selectors, AJAX, events, and even some basic UI widgets like drag & drop and auto complete.
http://www.midorijs.com/
Thanks Aycan, I’m very interested in Midori. I can’t see any examples as to how I might use the response from an AJAX request to update an existing inline div though – I think it would really help if you had more examples on your site. If you are able to do that, it looks like it might be a very cool library for iPhone webapp developers to think about (maybe split into a core and an FX type package too to further simplify / reduce the size)
Andy, Thanks for the feedback. I have added a tutorial about how you can update a div by using the response from an AJAX request.
http://www.midorijs.com/AJAX-Made-Simple.html