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.

Google's relatively new Web browser, Chrome, has generated a lot of interest since its initial release in September of 2008. It has managed to generate this even without native Linux and Mac OS X, although such ports are now in development.

Unfortunately, if this article from OSNews is correct, it appears that the developers at Google have opted to use GTK+ for the UI. The OSNews article does a good job of asking the obvious question: why not just use Qt for the Windows, Linux and Mac OS X versions of Chrome? The article suggests that Google opted not to use Qt, as they want to use native toolkits only, to allow for better integration with the host platform, and to avoid the warts that tend to accompany cross-platform applications.

I think that's a sensible policy. Mac OS X applications do differ in many ways from Windows desktop applications, both of which differ in many ways from X11 desktop applications. While cross-platform applications can be written that run on all three environments, they usually do feel somewhat out of place, and awkward to work with at times. However, it's too bad that Google has opted to consider GTK+ as the "native" toolkit for their Linux port, instead of using Qt, even if they opted to use the native UI functionality of Windows and Mac OS X for those versions.

It's difficult to give quantitative measures when comparing UI toolkits. So we'll need to rely on more qualitative analysis. Thankfully, GTK+ and Qt have both been used as the basis for a large number of popular open source applications that we can analyze.

One such way to qualitatively compare toolkits is in terms of responsiveness. And this is one area where Qt is often much better than GTK+. Qt-based applications often feel noticeably more responsive than similar GTK+-based applications. We can see this when using Kate and gedit. Kate is a text editor for KDE, while gedit is currently the official text editor of GNOME. Both are similar in terms of features and functionality, but I have always found Kate far more enjoyable to use that gedit. Gedit has a laggy feel to it, when opening menus, working with various dialogs, pasting in significant amount of text, scrolling through large files, and so forth. Kate, on the other hand, has always felt very fast; there is typically no noticeable delay between invoking a particular action, and the results of that action being available.

In relation to Chrome, a more apt comparison would be between existing browsers that use GTK+, and browsers that use Qt. Thankfully, we have several examples we can use. Epiphany is a Gecko-based browser coming from the GNOME project, and uses GTK+ for its UI. Many builds of Mozilla Firefox for Linux also use GTK+ as the underlying toolkit. On the other hand, we have Konqueror from the KDE project, and Opera, both of which use Qt.

An employment opportunity over the past six months has resulted in me making extensive use of all four of those browsers, on a variety of different PCs running various Linux distributions. After all of this use, I have to say that I've found Opera and Konqueror to offer the most pleasant Web browsing experience. While Epiphany and Firefox aren't bad browsers, they've always felt bloated. This isn't the feeling that one gets with Opera, for instance. And while we can't attribute their responsiveness solely to the underlying UI toolkit, it does help that Konqueror and Opera are both built on a solid Qt foundation. Pages appear to render faster in both, scrolling is much smoother, the browser menus and dialogs open without delay and can be manipulated without flicker, and both Konqueror and Qt feel like more polished, professional software products than Firefox and Epiphany do.

So based on my experience using other Web browsers that make use of GTK+ for the UI, I have not been very impressed. Qt-based browsers like Konqueror and Opera offer a much more enjoyable experience. Given Chrome's emphasis on providing a speedy and stable browser, Qt seems like the natural choice. The developers of Qt have put a lot of effort into making their toolkit one of the fastest out there, and this is reflected by the responsiveness of the applications that make use of Qt.

Qt also seems like a better fit for Chrome. Much of the source code for Chromium is implemented in C++. Likewise, Qt is also written in C++. But GTK+, on the other hand, is written in C, using pseudo-OO techniques. Integrating the Qt object model with that of Chromium may not be straightforward, but it likely would be cleaner than trying to integrate GTK+'s object model.

In terms of licensing, the recent announcement from Nokia that Qt 4.5, expected for March, would be available under the terms of the LGPL should make it much more appealing. Chromium already makes use of LGPL'ed software, including the essential WebKit. So while the licensing of Qt may have been a valid concern in the past, this no longer seems to be the issue it might have been.

One benefit that Opera has offered for some time now are Linux binaries that are statically linked against Qt 3. Although this can bring in the various problems associated with static linking, it does greatly reduce dependency-related problems. The user doesn't have to install Qt 3 themselves, whether from source or via the package manager of their distribution of choice. Assuming the licensing could be worked out, it would be helpful if static binaries of Chrome for Linux were available, to make installation more straightforward.

So while GTK+ will no doubt suffice as a toolkit in this case, it is too bad that Google opted not to use Qt. In many ways, Qt appears to be a better choice, and would help allow Chrome become a responsive, stable, high-quality browser for Linux. Like the OSNews article points out, a Qt-based implementation of Chrome may need to be written by the community, rather than by Google. I hope it doesn't come down to that, but it seems that Google has made up their mind and will use GTK+ for the time being. So those of us who prefer a Qt-based browser may need to just stick with Opera and Konqueror for now.

Ron Garret's recent publication of his "Why CSS should not be used for layout" article has resulted in there being much discussion about whether CSS or HTML tables should be used for Web page layout.

This post isn't going to argue in favor of one or the other technique. It'll just link to some of the more prominent articles written recently. But if we do try to draw a conclusion from all of this discussion, it would have to be that as is often the case in the computing world, that there is not a single technique that is sufficient for all users.

Today I was forwarded a link to an article about how Internet Explorer 6's market share appears to finally be declining. Most people, and especially Web developers, would agree that this is a very good development. It is not known as a secure product by any means, and is woefully inadequate compared to other browsers today. Unfortunately, it still has a significant presence within the business community, even almost eight years after its initial release.

The problem in this case isn't really with larger businesses and organizations. Many of them with dedicated IT departments have moved over to Mozilla Firefox, with others moving towards IE7. In many cases, the move away from IE6 was done to improve security, while in other cases it was done because users demanded the better functionality offered by Firefox, like tabbed browsing and ad-blocking support.

But we don't really see this with many smaller businesses and organizations. I'm talking about medical offices, small shops, car dealerships, private schools, and so forth. Most of these places do not have a dedicated IT person, let alone a team. They'll get a small computer network installed, and they'll use it for over a decade. Many don't have a choice; they can't afford a better or more up-to-date IT infrastructure. For many others, computers are an "evil" necessity, which the business owner manages to tolerate.

I work with businesses like this relatively frequently. And many of them still are using IE6, unfortunately, with no plans to upgrade. In some cases, it's relatively easy to talk the owner or manager into switching to Firefox. Even if they don't understand the technical and security-related problems with IE6, they've heard about Firefox, Opera and/or Safari from their children, friends and relatives, and are willing to give them a try.

There are others, however, who refuse to switch. In some cases it took these individuals years to get accustomed to IE6, and they're just not willing to put forth the time and effort to learn how to use another Web browser. Those of us who work in IT and software development might find this laughable, but it's a very real attitude. I've actually worked with one business in the past year where they were still using Windows 95, with IE3 as their Web browser. Even though their browsing experience was terrible, the owner refused to upgrade from Windows 95. To some extent, this actually benefited them. Their staff were unable to use the Web to check their email, use Facebook, or visit other sites that might distract them from their work.

Those who I feel worst for are the businesses who want to switch, but they're unable to due to some part of their application suite only really being supported well by IE6. One company I worked with recently had an intranet app that used a proprietary ActiveX control. They had lost contact with the developers who had originally put together their software, and unfortunately did not have source access to this critical and specialized control. They'd tried upgrading one of their systems to IE7 on their own, but their app wouldn't work with IE7 for some reason. So for the time being they have decided to remain with IE6.

Although IE6's market share is declining, it will still be with us for some time. Hopefully we get to the point fairly soon where its use is marginal, and the vast majority of Web sites can ignore Internet Explorer 6 compatibility for the most part. This will make life easier for many people from the Web developers who have to put in extra effort to make a site work well with IE6, to the system administrators who have to worry about the security flaws it presents, to the users who have come to realize the benefit of ad blocking and tabbed browsing.