Where is the developer productivity increase with JavaScript-based Web applications?
Posted on Thursday, August 02, 2007 at 7:54 PM.When the computing world moved from manually toggling input switches to machine code encoded on paper tape, there was a vast improvement in programmer productivity. Likewise, when machine code instructions were first represented with more comprehensible text-based mnemonics, we again had a major boost in programmer productivity. It was easier to write programs, and it was easier to maintain them.
Soon enough, the computing world moved on to languages like FORTRAN, COBOL, and PL/I. As had happened earlier, we had a major increase in developer productivity. What was tedious in assembly became far easier in such higher-level languages as those. Likewise, once a program was written, it was much easier for other programmers to come along later and comprehend and modify the program.
We experienced a similar productivity jump with the advent of C in the 1970s and early 1980s. Standard libraries and better portability made it far easier to move programs between two or more systems, often with drastically different architectures. Soon enough we had programmers writing far more complex software in only a fraction of the time and with only a fraction of the cost of earlier methods.
Then in the 1980s, object-oriented languages started to become mainstream. The likes of C++ and Smalltalk became widely used in industry. By the mid-1990s, we had Java. The move to such languages again brought significant productivity increases, especially in the area of graphical user interface implementation. But they also did allow for the construction of larger and far more complex systems than could be easily done in C alone.
Soon enough we entered the 2000s. Languages like Perl, Python and Ruby have started to become popular because they allow developers to perform common tasks quickly and efficiently.
Do you see the trend? Yes, it is one of ever-increasing productivity. That's not to be unexpected. After all, it's what has happened in nearly every other field and industry. It's just how the economy works; increase your productivity or perish.
We're now getting to the point where JavaScript and Web-based applications are being touted as the way we should proceed. Many are calling them the next "revolution" in software development. But I disagree. We just don't see the productivity increases materializing.
A typical AJAX-based Web application is often difficult to effectively create, even for experienced developers working with the latest libraries, frameworks and tools. A lot of developer time is wasted trying to sort out cross-browser incompatibilities. We're not talking about small differences, either. Often these differences require two or more implementations of the same JavaScript code, targeting specific browsers. That's just not effective, nor is it productive.
Debugging AJAX applications is also a terrible experience, even when using a tool like Firebug. Combined with the browser incompatibilities described earlier, it can become very difficult and time consuming to get an AJAX-based application working acceptably, let alone well.
And for the sake of your sanity, I hope you never have to maintain somebody else's AJAX application. I've seen very talented developers struggle for days on end with relatively simple problems in JavaScript-based Web applications. Part of this is because these applications are often developed very poorly in the first place. A second major struggle is the lack of mature, effective tools for mapping existing programs. All of these factors combine to cause problems.
So as you can see, JavaScript-based Web applications are clearly a step backwards. They fly in the face of what we've traditionally seen when moving to a new language paradigm. In the past we've seen clear improvements in terms of developer productivity, and in the complexity and scale of the applications that can be effectively developed. But we just don't see such things when using JavaScript in the browser.
Thankfully, some people have seen the light. They're realizing that languages like Erlang, Common Lisp and Haskell are clearly the way to go. They do deliver the developer productivity boost we've seen several times over and over again in the past. They're better equipped to handle the issues we will soon face with the rise of multicore systems in even the cheapest of desktops. In short, they exhibit an evolution of software development, rather than the devolution we see so often with JavaScript and AJAX-based Web applications.








