Which JavaScript Framework to Use? (Dojo, JQuery, Prototype)
Okay, so I’ve had two projects in the last year, and in both cases, I’ve been largely responsible for the UI JavaScript development. In the first project, prototype was chosen before I joined the project, and in the second project, which is ongoing, it was opted to use the JQuery framework (even though I wanted Dojo
), because the designers liked JQuery and didn’t like that dojo added attributes into tags that don’t actually exist and thus throw warnings when running the code through an XHTML validator (turns out, we ended up adding attributes to tags anyway to handle a JQuery tree control…but oh well). Finally, on my own personal projects, I’ve been working to use Dojo.
In any case, having gotten a modicum of experience in these 3 frameworks, I figured I’d throw out my two cents for anyone looking into JavaScript frameworks and trying to decide what to use.
Prototype
Prototype is a great object-oriented base-code, with features that are very useful for building your own code. It has some really handy methods, at least one of which I can’t live without: Function.prototype.bind (look it up). However, overall, even with script.aculo.us, it just seemed like we were always re-inventing the wheel. That’s great, as I love the experience of creating all my own tools, but with deadlines, etc., you end up with a wooden wheel when you really want a high performance radial tire. So, my opinion is that if you’re going to use prototype, use it in conjunction with another library that has more pre-built standard features. Or just take the useful features of prototype and add just those parts to the other library.
JQuery
JQuery is a step up from prototype in terms of it’s pre-built features. With the JQuery UI, you have access to a lot of common functionality features: Accordian, Dialog, ProgressBar, DatePicker. You also have ways to easily implement things like drag/drop and making a list sortable. There are also a lot of really nice plugins that you can use in conjunction with JQuery. So, JQuery is a great library to work with. If you want to use JQuery and like how they did things, then I don’t think you can really go wrong with it.
That said, I did end up adding an additional method to handle class inheritance, and I borrowed the Function.prototype.bind that Prototype uses and is extremely handy if you ever pass functions that are within a class to an event handler. However, these things were easy to add and I don’t really consider them as a detraction from JQuery. Really, about the only problem I have with JQuery is that I have a $(document).ready() with about 50 calls in it to get it to make conversions on the HTML, whereas, I would really like it if JQuery had a parser that would automatically convert HTML on the page based on tag attributes, which leads me to Dojo.
Dojo
I have to say that I really love the dojo framework. It is the behemoth of JavaScript frameworks, with more extensions that come with it by default then you’ll probably ever need. Additionally, since it only loads up the extensions that you need (on-demand) you have access to EVERYTHING without weighing down your users with the entire framework of code. However, I love dojo for a completely different reason, and thats for its parseOnLoad ability. You simply specify an attribute in a tag like so: <tag dojoType=”namespace.to.type”>, and add any other attributes applicable to that type, and dojo will automatically parse the page, load the needed JavaScript files for that type (again, on-demand), and convert the tag to that type using the attributes that you specified. This allows your HTML and CSS to define the attributes of what is displayed instead of having to assign those values via JavaScript in an onload handler like you would with JQuery. I consider this to be a much more natural way of defining things in a web page.
To try to explain this, though, an example is much better. So, let’s say we want a tooltip that can display HTML formatted text rather than just the text tooltip we get with the title attribute. Well, we can do this quite easily, and the greater part is that we can do it with ZERO Javascript coding, like so:
<a id="phrase">Hello World</a> <div dojoType="dijit.Tooltip" connectId="phrase"> <b>a phrase that is apparently impossible to program without</b> </div>
If Dojo is set to parse automatically, it will parse the above, find the dojoType=’dijit.Tooltip’ tag, convert it to a tooltip popup and hide it from the browser display. Then, the connectId=”phrase” tells it to assign onmouseover and onmouseout event handlers to the tag with the id “phrase”…presto, no JavaScript in your HTML at all, no need to call anything onload…it’s non-programmer friendly because it’s just HTML, and it’s programmer friendly because there is a nice separation between the code and HTML.
Now, I was originally going to finish this block by talking about how big of a file size dojo has, and how it was the heaviest framework of the bunch to somewhat show it’s negatives. However, then I took a closer look at JQuery. Once you add JQuery-UI, which for my own use is a must…JQuery doesn’t really provide much (if any) bandwidth savings. Combine that with Dojo’s ability for on-demand script, so that you’re only loading what you need, when you need it…and it just comes across as dojo being the all-around winner, at least in my book. Additionally, if you do use particular extensions on a regular basis, you can compile these into a single file and gzip compress it for additional savings.
Note on GZip Compression
In the case of either JQuery or Dojo, make sure that you do take advantage of gzip compression. If you use something like the Google CDN, then google takes care of this for you. However, if you’re using a local copy, make sure to take a look into getting compressed files, or how to compress them using server-side script for custom solutions.
No comments yet.
Leave a comment
| Next »