The shift to rich user interfaces on the web means that developers around the world are getting to know JavaScript development all over again. Companies who want to ride the much-hyped new AJAX wave may just wipe out when they discover the pitfalls, which haven’t changed since the nineties.
In the early days of the web anybody trying to write a rich interface quickly discovered the abysmal state of browser scripting. We had a great scripting language, developed by Netscape for their version 2.0 broswer. It was highly flexible and easy to pick up for beginners. It used prototype-based inheritance, but was especially great for list-based and functional programming. Its original purpose was to control Java Applets and integrate them into web interfaces. So to make things more confusing, and because Java Applets were all the rage, it was named JavaScript (instead of the planned name "LiveScript.") Based on the relationship between Microsoft's VB and VBScript, many assumed that JavaScript was a subset of Java. The fact that the two have similar syntax encouraged this perception.
Today, Java Applets are largely extinct, while the language created to script them thrives. So it goes.
Unfortunately the language spec for JavaScript was poorly written, and the technology was launched before it was standardized. Netscape started adding their own, non-spec functions and objects and so did Microsoft. On top of this, the interpreters were buggy. Microsoft and Netscape should have been focusing on broken interpreter logic instead of adding non-standard features.
This was the state of things in the nineties: if you wanted to use JavaScript to do anything big – like run a web application – you had to deal with clients who could be using one of two different interpreters, each with its own rules and both quite broken. And they had several versions each, which were broken in different ways.
It's no surprise that a strong interest in server-side web development arose. When CGI programming evolved into more mature technologies like PHP, ASP, JSP, ASP.NET, mod_perl and all the rest, we developers leapt at the chance to bypass the browser and execute our code in a safe place where we could control the rules. The cost was that we were generating and manipulating user interfaces on a web server with a round trip required for every user action. It was simultaneously absurd and empowering, and server-side technologies have dominated web development for years since. JavaScript by was largely relegated to simpler tasks like form validation.
Then the new generation of rich user interfaces, like Google Maps, started to appear. It was like spotting an old lover at a party: man, she is looking good! So responsive and sexy! And she's learned some new tricks – asynchronous XML requests! Document Object Model! Error handling! Suddenly all the past scars seem to disappear, and we can't quite remember why we left her. But memories are short. She's still a bitch.
Personally I really like the JavaScript language. It reminds me of Python or even LISP in its dynamic nature. It's fun to work with. But companies that are considering AJAX development should know what they're in for.
Web Developers Don't Know Enough JavaScript
Many professional web developers have only a superficial familiarity with the language. They can use it to validate forms and perform other minor tasks, but if you want to build a large application like GMail or Flickr a deeper knowledge is required.
Coders who are used to Object Oriented development like in VB.NET or Java must learn about the details of prototype-based inheritance, and should definitely bone up on functional approaches to design.
There's a dearth of good technical documentation about JavaScript. There is a sea of books that just don't get it, and this may be tied to the poorly written ECMA spec. O’Reilly’s JavaScript: The Definitive Guide (4th Edition) by David Flanagan is very good.
JavaScript is Very Different from Traditional "Big" Languages
Coders who haven't used an agile language may get their minds blown, or they might try to force JavaScript to act like an OO language by focusing on a subset of its functionality.
JavaScript uses weak dynamic typing. "Objects" are basically hashtables. There are no classes, only constructors. "Arrays" are arrays, lists, vectors, queues, and stacks all at once. Functions are first class members that can be passed around, examined and manipulated (not just executed.) Strings can be executed as code. Anonymous, a.k.a. "Lambda" functions (borrowed from LISP) are allowed. Functions' parameter signatures are guidelines only and not enforced by the interpreter. Reflection is intrinsic and important.
Like Python, LISP, Ruby, and other agile languages, JavaScript is more like the cedar than the oak. For coders coming from the world of Java, C and other "oak-like" languages this will be a paradigm shift – a bit like switching from Karate to Kung-Fu.
Coding and Testing AJAX Applications is More Work
Browsers have generally improved their JavaScript implementations since the early days, but there are still important differences between them and this will stretch development time. A lot of functions in a production web application will need to check whether the hosting browser supports certain features, then try to work around missing functionality or degrade gracefully (this is one of those situations where reflection is important – not sure if a function exists? Inspect the browser object.) A strong knowledge of these many eccentricities – in Internet Explorer, Firefox, Safari, Opera, Konqueror… video game consoles with web browsers, web-enabled cellphones … and others – is required depending on what browsers you intend to support.
Conclusion
Developing rich web interfaces with JavaScript is easier than it was in the nineties, but it’s still a dog’s breakfast and it’s definitely not as fast and easy as server-side programming. What’s more, I suspect the wow factor of watching an animated “Loading…” icon inside a web page is going to wear off pretty soon, and when the smoke clears AJAX-based sites will be divided into two groups: those that made judicious use of a specialized tool, and those that gratuitously created applications that are larger, more complex and harder to maintain than they ought to be.
JavaScript References and Cool Projects:
