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!
)