Pinderkent

There was recently a thread at Hacker News asking why "older developers are afraid" of JavaScript. As an older developer, I don't usually feel fear towards JavaScript. It's more a mix of disappointment, disdain and disbelief.

Furthermore, it's not just "older developers" who see JavaScript for what it truly is. There are many younger developers who know how inherently flawed and broken it is. So maybe instead of "older developer", a more appropriate term to use would be "knowledgeable developer". Anyone who has worked with a variety of programming languages should be able to easily see the many problems associated with JavaScript.

We're all very much aware of the implementation-related issues of JavaScript. Performance is one of the most significant problems. Although there has been much in the way of improvement in this area from Google, Mozilla and Apple, the situation is still not ideal. JavaScript, being embedded within all popular browsers, has been responsible for a variety of security-related problems. Aside from such implementation issues, JavaScript has some pretty serious problems with the language itself.

One reply to the Hacker News topic mentioned earlier gives a good example involving semicolon insertion. Others have pointed out this problem, such as in the JavaScript Style - why it's important and Beware Of JavaScript Semicolon Insertion articles, both of which give similar examples. Another example of the problematic nature of semicolon insertion can be found at Wikipedia.

Developers who have used more mature languages than JavaScript don't have much tolerance for oddities like that. They're dangerous and unexpected. More importantly, it's a further example of how trying to dumb down programming technologies to make them usable by Web developers has failed us yet again. HTML parsers, for instance, have to be unnecessarily complex to handle blatantly incorrect HTML markup. Another example of catering to carelessness and a lack of knowledge is PHP's magic quotes, which thankfully will be removed from PHP 6. And as mentioned earlier, we have JavaScript's semicolon insertion, itself a "feature" that exists basically to allow for, and to even promote, careless development.

JavaScript does unfortunately have its place, but only because it's really the only practical option for client-side browser scripting at this time. Regardless, those who use it should take care. Douglas Crockford has put out some useful articles and tools to help with this. His JavaScript coding conventions article, for instance, provides some good tips. His JSLint tool is useful, as well.

Perhaps someday we'll see a stricter, more mature language widely available for client-side Web browser scripting. Although this may not appeal to lazy Web developers, that would be a good thing. Care should always be taken when writing network-accessible software, regardless of whether it's a server of some sort, or client-side scripting. Having a strict and unambiguous language will help prevent many of the problems that JavaScript exhibits.

It's no secret that PC hardware is continually getting faster. For most people, this is a very welcome improvement. Unfortunately, we seem to have a bad habit of throwing yet another layer of software into the mix to negate any such performance improvements. While this made sense in the past, as it often brought a huge increase in productivity, it hasn't made as much sense lately.

One such example of this was the move towards virtual machines, such as those provided by Java and .NET. Aside from a small number of microbenchmarks suggesting otherwise, the performance of real-world applications developed using these technologies took a hit relative to equivalent apps developed using languages like C or C++. But at least such environments provided a boost to programmer productivity. In most cases, this was enough to offset the slower runtime performance of the applications themselves.

Unfortunately, the Web browser has become a similar execution environment. But unlike Java and .NET, it was designed as a tool to retrieve and display hyperlinked documents. Only later was programmability tacked on haphazardly, in the form of JavaScript. This has brought a whole host of problems, ranging from security issues to extremely poor performance to the locking up of the browser itself in some cases.

We have recently seen the canvas element of HTML 5 becoming more prevalent due to it now being supported by the Safari, Firefox, Chrome and Opera Web browsers. It essentially provides a rendering surface that is accessible via JavaScript.

While this increases what can be done with the Web browser, it's clear that this functionality will be misused. One such example of this is Bespin. It claims to be "an open, extensible web-based framework for code editing that aims to increase developer productivity, enable compelling user experiences, and promote the use of open standards."

One part of Bespin is a text editor. Ben Galbraith has recently written about how the canvas element was used to develop this functionality. He does address the performance of this editor by saying, "for large classes of users, performance is really, really good."

On one hand, we shouldn't expect there to be any performance problems. Text editors are not overly complicated, nor are they particularly resource-intensive applications. We've had literally decades of experience writing text editors. Even more advanced features, like syntax highlighting, could be performed suitably fast on computers well over a decade ago. If there were any performance problems implementing a basic text editor, it would be because something has been done very, very incorrectly.

On the other hand, his description of its implementation goes a long way towards showing the wasteful overhead that is required to run such a simple application. Let's suppose we're running Bespin in Firefox on a Linux system. At the highest level, we have the JavaScript code that makes up the logic of the Bespin editor. This JavaScript code in turn is interpreted by Gecko, which also handles the manipulation of the canvas element. Since we're running Firefox on Linux, Gecko is likely using GTK+ to provide the basic UI functionality. GTK+ in turn is calling down to GDK and GLib. GDK and GLib call down to the C standard library, Xlib, other X11 libraries, possibly Cairo, and so on. The X server makes use of the C standard library, video drivers, and the Linux kernel. Finally, the Linux kernel itself accesses the actual hardware.

Only the lowest portion of that stack really provides unique functionality. When it comes to text editors, by the time we get to X we're just repeating what we had at a lower level, albeit with a slightly different API or slightly more expanded functionality. Vim, for instance, is a very full-featured command-line editor, including syntax highlighting, advanced searching, and the ability to invoke makefiles. You get more than you would with Bespin, with a fraction of the resources being needed and used.

It's clear that we've gotten stuck in a cycle of waste. We're now trying to recreate what we already had at a lower level, except with much worse performance, greater memory and CPU usage, and less functionality. And while we've seen some stunning hardware improvements over the past couple of decades, we've done a good job of eliminating them through this repetitious software reimplementation. Unfortunately, we really haven't gotten much benefit from these extra layers. For example, all we get with Bespin is a text editor that pales in comparison to Vim.

I wonder if the next step backwards will be the implementation of an HTML rendering engine written in JavaScript and targeting the HTML 5 canvas element. Running a Web browser in a Web browser may unfortunately be the next step we take to further waste our computing resources.

Although it's not a new concept by any means, the use of JavaScript for server-side development has gotten some attention recently. This is unfortunate, as JavaScript is not the sort of technology you want to use when developing the back-end for a Web site.

Even as a client-side language, JavaScript has proven to be of a very questionable quality. I think Jonathan Edwards was correct when he described JavaScript as being "quick" and "dirty", and only just "good enough" for most users. For years now, even the major JavaScript implementations have exhibited horrible performance. Only after 15 years of use are we seeing that start to change, with faster VMs from Adobe, Mozilla and Google. As a language, JavaScript itself does very little to encourage the development of secure, high-quality code.

Server-side development calls for a more rigorous programming language and environment than JavaScript can offer. Considering JavaScript's performance problems on the client-side, it's likely they'd be magnified when it comes to server-side development. And JavaScript really doesn't offer anything beyond more traditional server-side languages like Java, C#, PHP, Perl, Python and Ruby. As is mentioned in the Ajaxian article, there is a huge amount of basic Web back-end infrastructure that will need to be built to make server-side JavaScript even barely comparable to any of the aforementioned programming languages.

What's worse, however, is the general "attitude" associated with JavaScript. It has always been a language that appeals to those who want to get their scripts written quickly, even if the quality is terrible and there are major security flaws. It has often been used by Web designers to quickly add some interactivity to the pages they have designed, without needing an extensive programming background. Indeed, this amateurish attitude becomes very dangerous on the server.

PHP is a good example of such danger. For years many PHP developers generated SQL queries directly using data sent to their script by the user, with little to no filtering. This resulted in SQL injection attacks becoming very common for PHP-based software. We still even see this sort of development happening today, in some very sad cases. Meanwhile, more mature server-side languages and environments like Java and .NET have for years provided support for parameterized SQL queries. But even the most inexperienced of Java and .NET developers know better than to not appropriately filter user input.

While there will of course be some professionals using it, and using it well, I fear that the rise of server-side JavaScript would lead to nothing but problems. Just as the PHP community is starting to get its collective act together, we might see a new generation of inexperienced, amateurish developers start with server-side development using JavaScript.

Then again, maybe that's not a bad thing. It'll guarantee a steady stream of work for those of us who have made a career out of fixing such mistakes. But it is unfortunate that we couldn't stop such problems in the first place, but using better languages for server-side development. With some work, Haskell could become very useful for server-side development where quality is concerned, while Erlang plays its part in reliable and highly-scalable systems. Regardless, the main thing we need to keep in mind is that JavaScript should be avoided for server-side development.

I saw an article today about the "surrogate scripts" functionality of the NoScript extension for Mozilla-based Web browsers. It essentially allows for a user to provide a replacement for a blocked script that some Web site requires to function properly.

I worked with a Web developer once who took a similar, although more general, approach to this problem. To avoid seeing ads and other unwanted content, he used his /etc/hosts file to resolve a number of such domain names to localhost. But some of the sites he visited often did make the mistake of having scripts that relied upon a function or variable defined in some of the scripts he had blocked. Some of the functionality of these sites was thus unavailable.

As a Web developer, he often switched back and forth between browsers, and often just used the last one he had open after testing work he had done for a client. So he wanted to avoid a browser-specific plugin. That's why he used his /etc/hosts file to block these sites in the first place.

His solution to this problem was to simply set up a Web server locally, and he manually created local JavaScript scripts that stubbed out the minimal functionality needed for the problematic Web sites to work. So regardless of the browser he was using, any requests for the blocked hosts were sent to his local Web server instad, and his minimal version of the script was served up instead. This resolved the problem with the missing functions or variables, prevented the Web sites' JavaScript code from crashing, and allowed him to use those sites.

I'd asked him if he ever ran into problems with two separate blocked hosts that both used the same JavaScript script filename, but the code itself was different. He said it wasn't something he'd ever encountered. If it ever did arise, he said he'd just include both script stubs in the same local file, and chances are there wouldn't be a conflict.

There was a recent thread of discussion at Reddit asking who initially disliked JavaScript, but "later realized it's actually a pretty cool and very unique language." I must say, I disliked JavaScript the first time I had to work with it in the mid-1990s, and having used it extensively since then, I still have to admit that I dislike it.

The only interesting thing about JavaScript is its support for prototype-based programming. But in this regard, it is neither unique nor is it particularly innovative. Much of that credit would need to go to Self, which predates JavaScript by nearly a decade. JavaScript has borrowed ideas that other pioneered, but unfortunately many programmers aren't aware of that, and are mislead into thinking that JavaScript is the original source.

Aside from that, JavaScript doesn't offer anything spectacular. For instance, functional programming languages had been offering first-class functions for decades before JavaScript was developed. Likewise, its syntax is clearly based on that of C, which itself has been around for quite a while. Its regex support is unremarkable. And typically being embedded within a Web browser is more of a hindrance for it than anything else.

JavaScript does offer many drawbacks. One of the most significant is that it is a dynamically-typed language. Some people mistakenly believe that this is a benefit. They say it allows them to develop their code faster. And in a sense, that's true. They may very well produce more code, but that's just because there's no compiler there to point out their numerous coding mistakes, and to force them to fix the mistakes before they can run their code. So they code they produce is heavily flawed, and we often end up with Web sites in production that have numerous problems that are only detected at runtime. Unfortunately for all involved, it's usually customers and clients who detect these problems.

Another major problem with JavaScript is its performance. It probably doesn't help that most implementations are browser-based. Web browsers themselves aren't often known for being fast pieces of software. So it's not unexpected that a scripting language running within the browser is lacking in performance, as well. And it's only now, after nearly 15 years, that's we're beginning to see better-performing JavaScript engines like Tamarin and V8 become available. That's an awfully long time in the world of computing.

Within the Reddit thread, many people said that their favorite things about JavaScript were libraries like jQuery, Prototype, and Ext JS. First of all, those have little to do with the JavaScript language itself. And they're not especially innovative, either. All they're doing is patching up the numerous flaws that make JavaScript-based and Web browser DOM-based development so awkward in the first place. They bring only an illusion of productivity, rather than actual productivity, because JavaScript-based development in the browser was so terrible and unhealthy to begin with.

As we can see, JavaScript can generally be considered a technological failure. That doesn't mean that it isn't widely used; it clearly is! But we should not mistakenly consider it to be an innovative nor a well-designed programming language, for instance. Of the people I know who like JavaScript, most of them are very ignorant about other programming languages and environments. JavaScript only seems acceptable because they don't realize how flawed it is in so many critical ways.