Pinderkent

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.