Slashdot Mirror
Five AJAX Frameworks Reviewed
prostoalex writes "Dr. Dobb's Journal reviews 5 AJAX frameworks: Dojo 0.3.1, Prototype and Scriptaculous 1.4, Direct Web Reporting 1.0, Yahoo! User Interface Library 0.11.1 and Google Web Toolkit 1.0. Each framework was tested in two basic scenarios — writing a 'hub' (titled collapsible link list frequently seen on sidebars of many Web sites) and a 'tab panel' (horizontal tabbed navigation bar). During the process, Dr. Dobb's Journal reviewers noted that 'Dojo provides more features and HTML widgets than YUI and Prototype' but eventually 'settled on the Yahoo! User Interface Library.'"
Am I the only one who usually finds frameworks to be pointless for serious web development? It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want. In many cases, the frameworks have a ton of little "gotchas". For example, Prototype has a set of functions that are supposed to make it easy to show and hide elements. The only problem is that if you define the "display" element in the style sheet (say, to make an element invisible by default) you can't change the element's state. This is because the Prototype library works in a stateless fashion, assuming that the default value for "display" is the way to make an item visible. Which may not be not be true.
;)
Other libraries have some cool GUI widgets, but often those are actually too much for a project. In some cases they even require you to build the entire project out of their widgets! That's nice if you're writing the next Outlook on the Web, but not so nice if you're trying to add interactive elements to an existing webpage. Especially if you like the more open HTML design rather than the cluttered pseudo-GUI design.
In general, I've found that these libraries may be kind of nice if you're not too familiar with DOM/CSS and want to perform some neat effects. (Scriptaculous in particular does some nice effects without a whole lot of difficulty. Just watch the download size!) But if you're doing a complex website, you'll probably be better off with a custom library for now. At least until some standard practices emerge among professional sites.
Now if you want to talk about libraries that patch minor browser issues like no DOM 2 Events, lack of Object.toSource, unified XMLHttpRequest instantiation, etc., then I'd have to jump in and add glowing support for such pieces of code. The key is, though, that they're very passive libraries. You include them, and they make sure that your code works the same everywhere. Which is a bit different than being forced to structure your project around a framework. If there's one thing I love about Javascript, it's that everything is virtual.
Javascript + Nintendo DSi = DSiCade
what about mootools?
Website Hosting
Curious. With javascript hijacking attacks just discovered a few weeks ago, security was not a consideration in the evaluation at all.
I'm a bit disappointed.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
MS's toolkit has been great - FF & Safari support is a breeze in most instances, allowing us to develop our applications really quickly
Having downloaded and hacking a few quick demos with the silverlight BETA API, I am looking forward to integrating the CLR in our future releases
This sounds like the classic Framework versus Library debate. Some good reading:
0 5-May/000231.html
l .3.219431.12
0 6/07/frameworks_vs_l.html
The Dojo mailing list thread "dojo: framework vs library"
http://dojotoolkit.org/pipermail/dojo-interest/20
Joel Spolsky's "Why I Hate Frameworks"
http://discuss.joelonsoftware.com/default.asp?joe
Arnon Rotem-Gal-Oz's "Frameworks vs. Libraries"
http://www.ddj.com/blog/architectblog/archives/20
That being said, there are plenty of features in Prototype which are more library-like than framework-like, so it is easy to use parts of it without buying into a whole framework methodology. I don't know much about the other evaluated tools.
I have had an experience very close to the author's. My group at work maintains an internal app served with Websphere, just like the author. We have a tree of nodes that recently ballooned in size to 40,000 nodes and this was causing our CSS/javascript tree to choke as it loaded everything once and used the CSS to handle opening and closing of nodes. It would take about 5-10 seconds to load the tree once, but after that it would perform nicely. We wanted a near instant load at start and then whenever you expanded a node it would grab its children from the database and display them then. My coworker and I didn't have any AJAX experience when we started working on this problem so we turned to frameworks.
First think I looked at was the Google Web Toolkit, and dismissed it as quickly as the author. I suppose if we ever rewrite our app from scratch we'll maybe consider it, but not right now. Then I found dojo, and we started using that to implement a dynamic loading tree. I got it working and plugged into our database fairly quickly, but found out it wouldn't help us much. Clicking on a parent to display its children can take anywhere from 1 to 15 seconds depending on the how many children it has, and also basically freeze your browser while it's doing that. It also either had a memory leak or just managed memory inefficiently because the browser's memory footprint would balloon in size as you clicked more and more nodes.
My coworker eventually took it into his own hands and started hacking the dynamic loading himself. I've been busy with other projects so I don't know how he did it exactly, but it's a combination of our old CSS tree and some dynamic loading to speed up the initial load. Clicking on a massive parent can still cause some slow loading, but it was better than dojo. I think dojo is a great toolkit, but when you just want to pull one specific piece out of it, it can be cumbersome and bloated. Also, the documentation sucks and if I needed help, I mostly just read over old bug fixes and such. I forwarded my coworker this article so maybe we'll look into YUI.
Reviewing just the first hour of video games.
Was it digg?
Nerd rage is the funniest rage.
It takes the magical $() selectors of prototype, expands on them, and somehow delivers it all in 19k.
You have to understand what you are using, as was discussed earlier often frameworks are not needed, simple custom script should be sufficient for most cases. However people do tend to wrap even simplest of things into large complex frameworks, supposedely for introducing commonalities, providing familiar interfaces, whatever. AJAX is just so simple that in most cases any of those would be overkill.
As the article (I RTFAd) states there are many cons and pros using these various frameworks. The main cons were:
1. Not supporting the development model chosen for the project.
2. Not providing enough documentation with the framework.
3. Not providing enough widgets (many widgets still have to be custom made even with the frameworks.)
4. The framework is too large and impacts performance.
5. The resulting code is difficult to maintain.
The pros were:
1. Not having to write the AJAX code by hand.
2. Not having to write some widgets by hand.
I would say there for those cases when it is absolutely decided to go with a framework, do mix and matching. Use the simplest AJAX framework and mix and match it with widget libraries, but not entire libraries, extract what is absolutely necessary, in all cases custom code will have to be created by hand.
You can't handle the truth.
is jQuery and it's plugins.
I'm Alex Russell, Project Lead for Dojo,
We're obviously flattered that our little project got covered in DDJ, couldn't they have reviewed newer versions of the tools they covered?
Dojo: defanging browsers so you don't have to
Something I also missed was xajax. They use AJAX as RPC layer, calling a server-side method from JavaScript, and in reverse call methods on the clients back. This is easy to implement in existing pages, and leaves much room for implementation.
Instead of parsing data structures in the client, xajax allows you to send HTML chunks, JavaScript method calls and DOM operations back (making it two-way RPC). The most interesting part is you can reuse all server-side code created in the "web 1.0" days, like HTML template engines. :-)
The best way to accelerate a windows server is by 9.81 m/s2
Dojo is nice if you want widgets (month selector/accordian/...) but the documentation is rather weak. Personally I like JQuery, good docs and everything in 1 rather small file.
"jQuery is a fast, concise, JavaScript Library that simplifies how you traverse HTML documents, handle events, perform animations, and add Ajax interactions to your web pages. jQuery is designed to change the way that you write JavaScript." - jQuery homepage
jQuery is great because it's really small and really easy to use. I know very little about js and have absolutely no interest in learning all the gotchas related to cross-browser js development so I leave it to jQuery to do that for me. jQuery allows me to use js in a powerful way, easily and quickly.
It's disappointing to not see jQuery in that list as if to say it's any less well made than the others.
Comment removed based on user account deletion
I think people are getting confused by the /. blurb. This article is not a review, it is a case study. This company is describing the process that it went through months ago in determining which software to use. That's why some of the versions are out of date. That's why they quickly discounted software packages that didn't work with their existing infrastructure. If you read the very first paragraph it tells you that they had very specific design constraints and that's why some packages weren't evaluated fully. You simply don't have that in a review.
A case study is supposed to give an overview of the decision making process and the implementation phases of the project. And that's exactly what this does. They goal was never to produce a document that gave an objective evaluation of the products, it was to show the decision making process they went through in their evaluation. No where does the Dr. Dobb's site call this a review.
The name of the software is Direct Web Remoting
How can we take this seriously if they don't know the name of the software they are evaluating?
WTF - this article might as well have been written last summer. DWR version 2.0 is now out and has been in beta for a while.
./ post are incorrect.
The 'R' in DWR does not stand for for Reporting, but rather "Remoting". Both TFA and the
Piping it all over X11, RDP, VNC, or SSH merely shifts the pseudo-problems of your Levels 5 thru 8. How are you going to handle authorization, authentication and access control for these protocols? What about transport-layer vulnerabilities in each? All four of your suggested protocols have had a plethora of vulnerabilities, and they still have a handful even now (we just haven't found them yet).
You have only repeated and restated the existing problem but using different words. The problem hasn't gone away, in this scenario; it has just been shifted and re-dressed.
Microsoft got sued by a patent troll. Like it or not, MS were the good guys in this particular case, and aren't intentionally screwing anybody. Microsoft is trying to do the smart (and decent) thing by starving Eolas of future revenue. Microsoft and its deep pockets "took one for the team".
The other 3 aren't really reviewed either, except to describe how well or poorly they matched up with how the author's development team already developed code for their projects. This article is more of a story about one development team's choices during their process of developing a new site for their company than it is a review.
Browser inconsistencies
This is the most obvious one, but only the entry to the rabbit hole. If you are not familiar with the example (maybe not exactly the same, but any AJAX web developer worth his salt should have seen one like that) I give below, then please, PLEASE, do yourself, your fellow developers and your users a favor, resist the urge to hack things together for once, use a mature AJAX framework.
An important part of AJAX is that you need to update what is displayed on the web browser in the client side (by JavaScript), without refreshing the page. This implies that you're very likely to have to create and destroy DOM nodes on the fly. Now, how do you create a radio button in JavaScript?
How about...
That's what you would do if you follow the DOM standard. But sorry, this does not work. Try to create a radio button with the above code segment in Internet Explorer 6, you'll get a broken radio button - you can't select it. The correct way to create a radio button by DOM manipulation is described in this MSDN article:
Memory leaks
The last one was easy. Do you know you can make a web application that leaks memory like a sieve in Internet Explorer 6 by making a simple circular reference like the following one?
If you're a good programmer, I might have sounded an alarm in your head right now - any circular references involving DOM nodes in IE6 results in memory leaks that persist after URL changes or page refreshes - unless you use an AJAX toolkit that takes care of the issue for you. Have you assigned a DOM as an attribute value under another DOM node in the past? Yes? Then you'd better check your web application for memory leaks with Drip, now.
What's more, it's not just assigning DOM nodes as attributes that would result in memory leaks, closures in JavaScript can also form circular references and cause memory leaks. What makes closures particularly dangerous is that circular references with closures are not easy to spot. For example, the following code segment leaks:
Looks innocent enough, but you've already formed a leaky circular reference here. node->clickHandler->node.
For more information about memory leaks under IE6, read these:
Mihai Bazon's blog entry
MSDN's lengthy and confusing description of the problem
The XMLHttpRequest object is not as simple as you think
Much of the magic of AJAX comes from the XMLHttpRequest object (or its ActiveX equivalent, or an iframe, etc.), right? Sure. If you're only doing something simple via AJAX (like, updating the server time), then you can just copy an XMLHttpRequest code snippet from sites like this and hack away, right?