Five AJAX Frameworks Reviewed 187
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.'"
Frameworks (Score:4, Insightful)
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.
Re:Frameworks (Score:2, Insightful)
Frameworks are what professionals use - the enforce well-formed code and design patterns. Find me a J2EE project that doesn't use Struts/Shale/WebWork/etc. and I will show you inefficiencies.
Re:Frameworks (Score:5, Insightful)
That's not to say that frameworks aren't useful for some purposes, but "enforcing well-formed code and design patterns" is not one of those reasons, nor is failing to use frameworks evidence of bad design.
My experience with Dojo (Score:4, Insightful)
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.
Re:Frameworks (Score:5, Insightful)
Funny thing, though. We "professionals" (I like the insinuation there, BTW) use the right tool for the right job. Sometimes the right tool is NOT someone else's framework. Sometimes, you're actually creating inefficiencies by adding layers unnecessary to the project at hand. Only an amateur selects a server-side framework before knowing the requirements of the project. The "professionals" will use off the shelf if it makes sense or build their own if better results can be achieved.
In the case of Javascripting, you've got a lot of factors working against you. The first is size. You can't afford waste, because you're trying to ensure that the page renders as fast as possible. Dumping 100K+ from the scriptalicious framework just to fade out a single box isn't very effective to your budget. Especially since the same effect can be achieved in a few hundred bytes by using a custom framework.
The second factor working against you is reusability. Javascript is not very well designed to handle this area. Object Oriented concepts we take for granted in Java (interfaces, abstract classes, private methods, final assignments, etc.) are not enforceable in vanilla Javascript. So you have to either be really clever (sounds like trouble), or work through standardized practices.
The third factor working against you is maturity. These frameworks are of varying levels of maturity because such web technologies are anything but old-hat yet. There are plenty of situations they are untested in, potentially leaving you debugging someone else's code rather than moving your project forward. Thus a framework may actually increase your project time if you're not careful.
And with that, there's one last note I'd like to point out. Frameworks are far too often chosen as a crutch rather than a time-saving component. Make sure that when you chose a framework, it's because you know it will do the job you need it to. Not because you heard it's the latest craze (bad), or because you have no idea how to implement the functionality it provides (even worse).
Re:Frameworks (Score:4, Insightful)
Today, you often need to go back to looking at the entire page. Why? Because the cutting edge developments require that the page be looked at as a complete memory model. If you try to take the HTML Component approach, programmer 1 may stomp all over programmer 2's Javascript or document ids by accident. Thus it suddenly makes sense to unify those pieces into libraries akin to more traditional programming methods.
Right tool. Right job.
Re:Frameworks (Score:5, Insightful)
This was my problem in the open source project, partly Ajax driven, I'm involved in. Exactly for this reason it sported custom coded Javascript from the start. I don't want to load 50K+ javascripts, and I don't want one big script with crap I don't need. If you have some fairly basic stuff which doesn't change much, it's much more efficient to hand-code your own javascript. Also, when this problem arose, and it is still true, these libaries are relatively brand new, and I found it silly to commit a codebase to any of them. However, if you do all your own coding, there are problems such as cross-browser compatibility, and also there is a certain threshold of complexity when you find you're factoring out the same code and problems, and one should consider a switch. But it is a dangerous point which should be a warning sign by itself, because it could imply your stuff is getting too bloated.
It turned out jquery (jquery.com) was the best choice in our case, it addresses exactly my worries by sporting a size of just 20KB, all extras come in modules, and it's very powerful. I'd rather have a 10K version, but there you have it, you can't have it all. How it (or I) work, is to load the core when the page is loaded, and only insert additional scripts (mostly dynamic, i.e. when you click something) when needed. Similary, Yahoo! has a fine, modulized lib which is extremely well documented.
Last but not least it must be noted that all of these frameworks use MIT/BSD style licenses, and I'd like to thank them all for their great tools and generosity.
Re:Frameworks (Score:5, Insightful)
Re:Frameworks (Score:5, Insightful)
As for the bloat issue, this is where libraries like Scriptaculous are doing it right by keeping classes of components in separate libraries. Second, this is why browsers cache JS files. Third, if you want cool effects that are cross-browser compatible, you simply have to accept that such effects come with bloat. If bloat is a show stopper, then you probably shouldn't use fading transitions with scaling div boxes anyway.
And if the argument is that these add way too much *unused* bloat, this comes back to the "mom's website" argument I made above. If people want to use machine guns to hunt cockroaches, that's their call. Unlike with a machine gun, if Prototype is too much, you can always cut out the small pieces you need. That's right -- people seem to conveniently forget that if they only really need one small, tiny part of a much larger library, they're always free to simply cut and paste that component out (MIT license is a great thing, huh).
What? But you need the rest, just in case? Then don't complain about the bloat you are willfully accepting. But in all honesty, Prototype's foot print is tiny -- about the size of an extra image banner -- and it gets cached.
I have been using Prototype extensively lately, and I have found it as a major time saver. By using it, I don't have to remember the various undocumented "gotchas" across browers. I'd much rather deal with the well documented [prototypejs.org] show/hide issue than trying to figure out how to make transparent text in all of the browsers. On that note, did you know Prototype tries to prevent the very "gotchas" you talk of? For example, stopping event propogation is the same method no matter what browser you are using, and the Element.setStyle/getStyle methods correctly convert the 'opacity' property depending on the browser being used. So for whatever "gotchas" you are using to discredit Prototype, I think you are conveniently ignoring the hundreds of others that Prototype strives to fix, silently, without the developer ever knowing.
And lastly, about the notion of writing your own custom library -- that's hardly an option for most people. First of all, most web developers are not JavaScript experts. In fact, I've almost never seen someone use exception handling in JavaScript, short of in libraries like these. More importantly, even if you were some kind of JavaScript guru, are you going to test all of your methods in all of the browsers out there? Can you guarantee your AJAX calls work the same in all browsers? What happens if I trigger a second one during the first one? Is your implementation really more efficient than Prototype's? How long is it going to take to design this custom library? Is it extensible? Does it respect the global namespace? Does it play nice with other JS files I include? Does it work in strict/quirks mode? Like I said, writing such a library isn't an option for most people. Prototype is as close as it gets to a "patch" library, which is why so many other frameworks are built on it. That, and it has been extensively tested, which is a requirement for most companies rolling out technologies like it.
This is not a review (Score:3, Insightful)
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.
Re:Frameworks (Score:3, Insightful)
Re:Frameworks (Score:0, Insightful)
Re:Frameworks (Score:2, Insightful)
Re:AJAX is the antithesis of security. (Score:3, Insightful)
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.
Re:My experience with Dojo (Score:3, Insightful)
Are you sure javascript is the problem here?
This isn't much of a "review" (Score:3, Insightful)
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.
Re:Security not a consideration? (Score:2, Insightful)
You're likely referring to the JavaScript Hijacking [fortifysoftware.com] paper from Fortify Software, the one which finds a loophole in a ridiculously contrived scenario that applies to roughly six sites on the planet. The threat they identify is real, but unlikely; it's orders of magnitude less severe than an XSS flaw or SQL-injection attack. Bob Ippolito demystifies the threat [pythonmac.org].
Nine times out of ten, a security exploit that uses JavaScript as the attack vector must be solved on the server-side, not in the JavaScript itself. This isn't buck-passing; it's just the truth. Nothing I can add to a JavaScript library will intercept a XSS attack, since the vulnerability (unsanitized HTML) lies on the server. Once the malicious JavaScript is on the page, the game is over.
That said: one of the suggested ways to protect yourself from this hijacking flaw is to surround the returned JSON with comment delimiters. Prototype 1.5.1, released on Tuesday, can handle this automatically.
(Disclosure: I'm a member of Prototype Core.)