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
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.
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.
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.
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.
You're likely referring to the JavaScript Hijacking 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.
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.)