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: (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.
Re: (Score:2)
In my experience (I admit I'm no software development guru), the frameworks make for clean code in most cases. The exceptions are uses that are not planned for in the framework, or features that are poorly documented. Then you have a hugely kluged workaround or hack to the framework code itself to permit something that might otherwise be straightforward to implement.
And of cou
Re: (Score:2)
Could it just be that people who choose the right framework for their project are more likely to write clean code in the first place, as eviden
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:5, Insightful)
Re: (Score:2)
The second factor working against you is reusability. Javascript is not very well designed to handle this area.
Why do you ruin any otherwise intelligent post with this complete nonsense. Javascript is very well suited for reusability as all prototypical languages are. Prototypical inheritance and Duck Typing make Javascript objects, including constructors some of the most reusable components in software. Miss understanding these elements and being stuck in the static typed, classical inheritance model is no reason to go bashing all other approaches to component reuse.
Object Oriented concepts we take for granted in Java (interfaces, abstract classes, private methods, final assignments, etc.) are not enforceable in vanilla Javascript.
As I implied above, you are right that some o
Re: (Score:2)
Funny thing, though. "Control" was never a term I used. I never even insinuated that it was a problem.
Let me learns you something here, my young friend. There is a time for everything. A time to laugh, a time to cry, a time to make war, and a time to make peace. There is also a time for frameworks th
Re: (Score:2)
Re: (Score:2)
That said, you make the rest of us sub-1000ers look bad.
A low UID is good for one thing, and one thing only - shutting up a "my UID is lower than yours" battle between a pair of 6-digit-plus users.
Re: (Score:2)
It appears you got a specific arguement for GWT, whereas GP was talking about frameworks in general. GWT sounds like a dream come true when you need to build a pretty serious app - but honestly, how often are you going to run into that situation regarding web developers? It sounds like more the exception to the rule.
The issue stated with the other js frameworks is that it provides a breeding around for lazyness, which results in terrible terrible code designed by people that are clearly unsuited for the ta
Re: (Score:2)
So you're suggesting that once the fad is over, we will go back to plain HTML forms with submit buttons, twiddling our thumbs waiting for the whole page to reload to update one piece of data?
I'll take the fad!
Re: (Score:2)
Re: (Score:2)
I don't see much other reason as you point it with the browser cache.
Re: (Score:2, Insightful)
Re: (Score:2)
Struts is great, if you want to handcuff good OO Design, and just use the Struts features. As far as I'm concerned the only thing that make Struts even remotely useful is the Validation framework. The rest is crap for junior web developers who don't know how to use a web.xml and Model-2 MCV; it cripples the rest of us.
Re: (Score:2)
Speaking as a programmer with 8 years professional experience, that's bullshit. Nothing can enforce well-formed code, except perhaps frequent code reviews by a competent, fascist reviewer (with the power to force people to rewrite stuff properly or replace them with people who will/can).
Frameworks have their uses, and can make some things much easier (and other things much harder or even impossible). I'd also strongly d
Re: (Score:2, Informative)
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)[...]
So write a script to remove all the unused functions. At least thats how we do it were I work.
Re: (Score:1)
vs
Father: "Heres a box of lego, it will go nicely with the big duplo bricks you got last year"
No, man, Joel drove them off the cliff: (Score:3, Informative)
Frameworks versus Libraries (Score:5, Informative)
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.
Shameless Plug : Library (Score:2)
all it does is encapsulate the request/response with a couple of handy additions:
1. ability to pass any custom object through to the callback function
2. built-in response codes, so a response that starts "200\n" is a "Good" response, you can also return error codes
2.1. this means a http error wont botch up your nicely formatted site and
2.2. it's immune to the cross-site <script src=...> att
Re: (Score:2)
Thanks for the links. IMHO, only the last one is coherent. To abuse on old joke around here, in Soviet Russia, frameworks call you.
What Spolsky (and everyone here) is complaining about isn't really about frameworks versus libraries but more about heavy weight versus light weight. Frameworks can get heavy because they tend to combine lots of functionality in a way that introduces a lot of dependencies, thus increasing coupling (which, in software engineering, is a bad thing). That's where the feeling of
Re: (Score:2)
Re: (Score:2)
You and your soul-buddies who don't understand that by the time they "have it just right", what you just wrote is already outdated and no one cares about it.
The most crucial two things to succeed today, are:
1. having something to offer that people need, and they don't get;
2. do it FAST, since there are 1000 other geniuses like you who thought of the same thing, and will fill the niche before you manage to write and of
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: (Score:2)
I'm not sure how this negates the framework model. It's exactly a framework that could provide y
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: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Yes, frameworks are always inefficient compared to something tailor-made for a specific case (or even just the set of cases that you customarily deal with across multiple projects). But execution efficiency has never been what (honest) frameworks promise you; what they're after is development efficiency, which is quite a different matter.
Just focusing on Prot
Re: (Score:3, Insightful)
Re: (Score:2)
Am I the only one who usually finds frameworks to be pointless for serious web development?
No, you are right on. I build code for fortune 10's and other very large entities. I am part of a small elite team of Java architects who work fast. Java, yea, we use a very bare-bonus MVC utility library. But overall, we have proof of concepts that the rest of us repeat to ensure that all of our code is consistent as if coming from one developer. Then we pier review our code. Then run it by security scanners. We then beat it all up (especially ajax stuff) in QA. Then release. It works.
For Ajax, especia
Re: (Score:2)
ROFL.
You might want some peer review on your comments as well as the code...
Re: (Score:2)
Re: (Score:2)
What I'm saying is, a small team on senior coders do not need the crutch of a framework. And you will get a better product, lighter more agile JavaScript for Ajax (CSS/Javascript custom coded per the parents post), and faster delivery time.
Re: (Score:2)
When your specifications reach over 2000 pages, you need one small team to set the architecture, and then several small teams to handle each sub application. When you have one large team of average coders "set loose" to work within a generic framework like Struts or any of the Ajax frameworks, you are shooting yourself in the foot delivering average quality applications. When you build you own biz-s
Re: (Score:2)
Re: (Score:2)
But seriously, especially this last post of yours, you are right on the money. I was just telling a client today that this project was going to be 75% meetings, design, and product/business analysis, 20% testing and 5% coding. I bring a MBA with me to these meetings who can listen and talk. We are helping the fix processes that this business adapted around a product they have been using, and are trying to write them a new s
Re: (Score:2)
Imagine for a moment that the year is 3801. Our top computer scientists have invented this super algorithm that would find repetitive patterns in text and replace them with a token, thus decreasing data size. Then imagine that the very same algorithm could be implemented in popular web clients and servers. Now that would be quite a time to live in!
If only
Re: (Score:2)
Re: (Score:2)
The truncation problem referenced in the article refer to problems that have been fixed a while back:
http://support.microsoft.com/kb/871205 [microsoft.com]
I cannot find anything on the etag/gzip problem other than the article you referenced but my testing with fiddler and IE7 cannot replicate the problem. I'm too lazy to start my IE6 VM and test with it but I don't really care. If I spent my time ruling out technologies b
Re: (Score:2)
Re: (Score:2)
This exact point has been raised about most of the frameworks out there, even beyond those listed in the article. I can't speak from experience for all of them, but I agree 100% for both Dojo and the YUI libraries. Even Yahoo's own developers realize that YUI is a little bloaty. Dojo [dojotoolkit.org] has changed their ro [dojotoolkit.org]
MooTools (Score:2, Informative)
Re: (Score:2)
QooXDoo (Score:1)
Security not a consideration? (Score:5, Interesting)
I'm a bit disappointed.
Re: (Score:2)
Re: (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.
Re: (Score:2)
Some choice quotes from his comments:
> NOTHING MochiKit can do is insecure (in this way). Whatever the client sends or decodes is irrelevant. It's a 100% server-side issue. I added comment stripping
Re: (Score:2, Informative)
We believe that JavaScript Hijacking is the only type of vulnerability found so far applicable only to Ajax applications. We've also analyzed 12 most widely used Ajax frameworks (DWR, GWT, Microsoft "Atlas", xajax, Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI,
Re: (Score:2)
I have a minor question, though. I'm currently implementing a JSON-type of interface, but I'm doing things slightly different from the straight-up JSON message described in your paper. Correct me if I'm wrong, but wrapping the JSON request in an XML packet would negate the effects of the exploit, wouldn't it?
For example, if I'm sending this message
Re: (Score:2)
Hey, it's not often that I find an opportunity to compliment a lady without sounding like a total dork. So just enjoy the compliment. ;-)
Thanks for verifying that. I figured I was safe, but every once in a while there is a very clever workaround.
Re: (Score:3, Insightful)
You have only repeated and restated the existing problem but using different words. The problem hasn't gone a
Re: (Score:2)
In my Java/Tomcat app, I use a ServletFilter to make sure all requestrs are either authenticated or they are marked as public. I have very few public pages (login.jsp and the images it depends on, the license agreement, etc.). An AJAX request is still considered a request. If you're not authenticated,
Script# ? (Score:1)
Re: (Score:3, Informative)
Something I also missed was xajax [xajaxproject.org]. 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 t
Re: (Score:2)
As a .NET developer (Score:3, Interesting)
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
Re: (Score:2)
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: (Score:3, Insightful)
Are you sure javascript is the problem here?
Just don't choose them all! (Score:2, Interesting)
The site would download quickly enough, but then the page would just sit blank and churn for about 30 seconds before displaying anything.
It was hideous, and it was never getting closer to completion, so we replaced their 108 man-months worth of Ajax coding with 2 man-months worth of Flash development and everyone was much muc
Re: (Score:3, Funny)
Re: (Score:2)
1. Navigating through a site and I hit back
This is really a problem with any single page site, which is what Ajax is - a single page that loads in the different components. The same methods to make the back button work with Ajax can be used for Flash. It's just that not everyone uses these me
Re: (Score:3, Informative)
Microsoft got sued by a patent troll [wikipedia.org]. 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".
Re: (Score:2)
Flash also has cross-browser problems. SWFs don't execute exactly the same on all browsers because many of the functions are handed off to the web browser. Nowhere is this more evident than with the XML.sendAndLoad APIs. They may work fine on one brows
jQuery, too! (Score:5, Informative)
Use frameworks only when really need them (Score:3, Interesting)
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.
Another good option (Score:5, Informative)
Old News? (Score:5, Informative)
We're obviously flattered that our little project got covered in DDJ, couldn't they have reviewed newer versions of the tools they covered? [dojotoolkit.org]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
We (and all of the other toolkits they reviewed) fixed hundreds and hundreds of bugs in the 11 months since the release of Dojo 0.3.1. Like all of the other (well written) toolkits they reviewed, we take stability and quality seriously. Sure it takes them a while to review stuff, and I understand that they have constraints of publishing on a dead-tree schedule. It's even valuable for them to outline the decision process, but the world (and the toolkits) have moved on since.
Regards
Re: (Score:2)
Jquery (Score:2, Informative)
Umm... hello? jQuery? (Score:2, Informative)
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
Comment removed (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
$$('a').addClassName('test');
$$('a').show();
I don't think addClassName returns the element list, but I don't have an environment to test it in handy.
Why just AJAX? (Score:2)
One of the things that turns me off about frameworks in general, is the almost maniacal focusing upon AJAX. AJAX can do a lot of things nicely (Google Earth as the classic example), but for most web sites, all it does is add a slight bit more interactivity to forms. And many of the frameworks I looked at, h
Re: (Score:2)
What about Microsoft? (Score:2)
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.
DWR (Score:3, Informative)
The name of the software is Direct Web Remoting [getahead.org]
How can we take this seriously if they don't know the name of the software they are evaluating?
Re: (Score:2)
Re: (Score:2)
DWR = Direct Web REMOTING (Score:2, Informative)
The 'R' in DWR does not stand for for Reporting, but rather "Remoting". Both TFA and the
Ajax security (Score:2)
Anything but Yahoo UI! (Score:2)
Anyone used Adobe's Spry framework? (Score:2)
We're currently looking at a few AJAX options at work too so I'd appreciate any feedback from anyone who's evaluated it particularly against jQuery and the others in TFA.
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.
AJAX frameworks are NOT pointless (Score:5, Informative)
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 [microsoft.com]:
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 [outofhanwell.com], 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 [bazon.net]
MSDN's lengthy and confusing description of the problem [microsoft.com]
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 [apple.com] and hack away, right?
Unbloated Javascript library (Score:2)
The whole thing is about 8kb for the js-compressed version (about 4kb if you also serve it gzipped) and is available under a BSD-like license from my blog site [fforw.de]
Re: (Score:2)
The learning curve is higher than the others, but the upside is also much, much greater. With a formal 1.0 release scheduled for later this year, and a ton of momentum (both within the com