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)<a
href=”http://www.untyped.com/untyping/archives/2005/11/rich_web_client.html”>type
system and<a
href=”http://www.untyped.com/untyping/archives/2005/12/printf_in_ajax.html”>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<a
href=”http://www.mozilla.org/scriptable/avoiding-leaks.html”>here
and<a
href=”http://blogs.msdn.com/ericlippert/archive/2003/09/17/53028.aspx”>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.<a
href=”http://calculist.blogspot.com/2005/12/dynamic-scope.html”>Javascript’s
crazy scoping rules are just bad; there’s no way of
getting around that. Javascript would really benefit from coroutinesfor 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!
)