« Yahoo's Customer Disservice | Main | Lessons Learned from Big Web Apps »
January 27, 2006
Ajax: I Fold!
Ok, I fold. It's time to admit I agree with what Matt has been saying: Ajax is an immature technology. To save Matt some effort I'll list the things that most annoy me with the current state of the art:
Matt's already mentioned the (lack of) type system and poor debugging support, so I won't go into them.
Memory leakage is perhaps the biggest obstacle to creating long-lived Ajax applications. The reasons for memory leaks are discussed here and here. These leaks are a result of a flaw in the implementation of (to my knowledge, all) existing browsers. This puts us back into the bad old days of manual memory management. Either we be very careful in our programming, or our long lived application will eat memory till the browser crashes.
Browser incompatabilities and inconsistencies, admirably documented at Quirks Mode, are a major hassle. We have to worry about both browser and version — my code works in Firefox 1.0.4, but will it work in Internet Explorer 5.0 (probably not)?
With the benefit of experience Javascript could be improved in a number of ways. Javascript's crazy scoping rules are just bad; there's no way of getting around that. Javascript would really benefit from coroutines for writing all those animation loops (or heck, let's get full continuations). Javascript's syntax is unnecessarily hard to parse, mostly due to the semi-colon insertion rule .
Finally, current implementations of Javascript are slow and resource hungry, a major impediment to creating really featureful applications.
Ok, so where does this leave us? We still want to build great Internet applications, but the tools are a bit suck. There are three paths forward:
- Build libraries. Requires the least amount of time, but offers the least return.
- Build a better Javascript. This has already started. Just wait two years for the standardisation committee to finish, and then another five Internet Explorer to catch up.
- Use the existing language as the target, but build a better language that compiles into Javascript. Less effort than standardising Javascript, but more effort that writing libraries, this option has some attractive benefits.
So which path are we going to follow? Tune in next time!
Posted by Noel at January 27, 2006 02:01 PM