Pinderkent

Yesterday a colleague forwarded me the link to Underscore.js. It's a JavaScript library that provides some functions commonly offered by functional programming language implementations.

Now, I can understand completely why JavaScript programmers would desire to use such techniques. They bring some very clear and powerful benefits, including shortened development time, fewer lines of code, greater flexibility, and improved readability. However, I do hope that JavaScript programmers using such a library don't come to think that they're actually doing functional programming.

One of the most significant areas where JavaScript fails with respect to functional programming is immutability. Current implementations have spotty support for constants, leading to various workarounds. So while it's possible to manually avoid state changes as much as is possible, it becomes difficult to do when performing browser-based JavaScript development. And it's almost always better to have the language implementation strictly enforce const-ness, rather than trying to have developers communicate this intent through all-caps variable names, for instance.

Many functional languages also offer very rich pattern matching functionality, which we just don't get with JavaScript. While some people have tried to implement pattern matching in JavaScript, it is nowhere near as clean or natural as pattern matching in Haskell or pattern matching in Erlang.

Many, but not all, functional programming languages also offer strict, static typing. There has been much debate about the pros and cons of the various typing techniques employed by various languages. In the end, however, experience shows that static typing results in higher-quality software, and static typing saves developer time. Unfortunately, JavaScript as a language, as well as its current widely-used implementations, don't lend themselves to strong, static typing.

It also doesn't help that JavaScript came mainly from the imperative and prototype-based OO world, and is only now trying to adopt features and techniques from the functional paradigm. It's often much cleaner to start with a purely functional language, and then add useful imperative features like for loops and references, as was done with Objective Caml. So the language and standard libraries have a functional feel to them, and naturally encourage the use of functional techniques, yet still allow the use of imperative features where they may prove to be the best option.

In many respects, I see trying to do functional programming in JavaScript much like doing object-oriented programming in C. While it can be done, to some extent, it never feels very natural because it lacks support that should be provided at the language level and by the implementations of said language. GObject is one of the most widely used C object systems, and as anyone who has written even a moderately sized GTK+-based system in C knows, it's not a very pleasant ordeal. Languages like Objective-C and C++ offer a much more developer-friendly experience.

So I see trying to add features and techniques from functional programming to JavaScript as generally being a pointless exercise. It may help in some cases, but ends up just masking the symptoms of a greater problem, namely that we want (and maybe even need) a true functional programming language available in all of the popular Web browsers. I've suggested Haskell in the past, but just about any functional language would be better than JavaScript.

A common trait among some of the poorer-quality programming languages, namely PHP and JavaScript, is their use of weak typing. While some developers are convinced that it's acceptable, it's generally a bad idea to have a programming language essentially guess at what the programmer means.

Recently, I saw an article describing some problems within a PHP script caused by automatic conversion. Frankly, these kinds of issues should just not exist. Strong, static typing is clearly a better approach. Although it puts slightly more of a burden on the programmer, the act of manually specifying type conversions leads to higher-quality software, especially if any errors are caught at compile-time, rather than run-time.

JavaScript is another language that employs weak, dynamic typing. I recently saw another article that gives some good examples (under the "2. Plus operator overloading" section) of how this behavior may result in unexpected results, especially for novice developers. But even seasoned professionals still make mistakes, and such conversions should at least be flagged with warnings, if not outright disallowed.

Even though we often deal with fuzzy and incomplete specifications when developing software, we shouldn't bring such uncertainty and guesswork to our communication with the computer itself. We should specify exactly what we mean, even if it does take slightly more typing. Then again, when using languages like Haskell and OCaml, we can clearly see how strong, static typing and type inference can be implemented without overly burdening programmers. Any type conversions that must be manually specified help to force the programmers to think about what they're doing, which in some cases may be quite wrong, especially if a type conversion is necessary.

For the sake of trying to achieve even a moderately reasonable level of quality in our software, especially when programming for a hostile environment like the Internet, we shouldn't resort to languages like JavaScript and PHP that allow for type-related errors to occur so easily. It's even worse when they try to make automatic conversions that result in unexpected behavior. That's just plain unacceptable.

I just finished reading Marcus Cavanaugh's recent The Cross-Platform Myth article. The first two-thirds or so of it are quite correct. He points out that when an application is developed for two or more desktop environments that differ in some pretty fundamental ways, like Windows and Mac OS X, the result usually isn't too great. The app likely won't fit in well on one or more of the platforms, which can lead to usability problems, and may even result in users not adopting the software.

At the very end of the article, however, he writes the following:

The only acceptable cross-platform UI toolkit lives in your web browser. If you want your application to work on both Windows and OS X, create a web application. In the browser, you can freely design a custom user interface that won't seem out of place on any operating system. Users understand that web sites operate under different rules.

I find this reasoning quite absurd. First of all, Web browsers are some of the worst-conforming desktop applications around. Early in the article, he even mentions Mozilla Firefox as an example of a cross-platform application that just doesn't fit in anywhere. But Firefox isn't the only browser guilty of this. The Windows port of Apple's Safari Web browser clearly doesn't behave like a typical Windows app, either. And to some extent, the same even goes for Opera.

So not only are Web browsers themselves perfect examples of UIs that target the lowest common denominator, but the environment that they present is that very same philosophy taken to the extreme. The only consistency is that there's inconsistency. The built-in UI controls or widgets are extremely limited. And everyone who has even had to do a minor amount of Web development knows that the environment differs significantly between the different browsers.

When it comes to Web applications, it's not that they "won't seem out of place on any operating system." Rather, it's that they won't fit in with any existing desktop environment. In a sense, Web applications are typically so horrible in that respect that most users can't even recognize how bad these applications are. For some odd reason, users tend to use confusing, inconsistent or poor-quality Web applications far longer than they would the desktop equivalents.

The situation likely won't improve. Like Marcus mentions in a footnote in his article, RIAs only make the bad situation even worse. They allow for further inconsistency in an already inconsistent environment. And the other "innovations" we are seeing are just poor attempts to bring existing desktop application concepts within the browser. The canvas element and O3D are good examples of this. They both pale in comparison even to the cross-platform, desktop-equivalent abstractions of libraries and APIs like wxWidgets, GTK+ and OpenGL.

In fact, the Web development community has even gone so far as to try and abstract away the variety of programming languages we have available with a typical desktop environment. We are stuck using JavaScript, which ends up bringing us the worst of all worlds, like the Web application development environment itself.

All in all, those of us who have developed real desktop applications for years and year end up being quite disappointed with what Web development offers, or more correctly, all that it doesn't offer. We've thrown out everything we learned during the 1970s, 1980s and 1990s, only to replace it with half-baked, browser-based "alternatives" over the past decade. We've essentially taken a huge step backwards, amplifying the very problems that Marcus spoke out against during the first part of his article.

The Where are the RIA "killer apps"? article that Kas Thomas recently wrote is both insightful and absolutely correct. Despite all the hype around them, he correctly points out that RIAs, short for Rich Internet applications, have been an utter failure. And it's not just one vendor's implementation that has failed, either. We just haven't seen anything truly useful produced using Microsoft's Silverlight, Adobe's Flex and Sun's JavaFX.

In the past, I have written about the lack of technical merit of these RIA platforms. I think this contributes to why we really haven't seen anything truly innovative and useful built upon them. They're such a feeble foundation to begin with that perhaps they can't allow for anything truly useful to be done with them.

One thing we can consider is why some people think we even have a need for RIAs in the first place. The typical argument is that the Web browser just isn't a suitable platform for building more complex applications. This is obviously quite true. The browser and the Web were originally intended for displaying documents and allowing for navigation between them. Over time, hacks like JavaScript were integrated into the more popular browsers, allowing for some degree of programmability. Some developers soon mistook the browser as an application development platform. So here we are today, with many believing that the Web and Web browsers are somehow replacements for our existing desktop environments.

Of course, the Web browser is quite a crippled software development environment. You're limited to essentially one language, JavaScript. Pixel-perfect layout is a huge hassle. When you add in the numerous bugs, incompatibilities and inconsistencies between browsers, life becomes even more difficult. In short, what we could do relatively easily with more traditional application development platforms quickly becomes much more awkward in the Web browser, leading to poor-quality applications that take longer to develop.

RIAs have arisen as a bandage to try and make application development within the Web browser more friendly. Java applets and Silverlight are good examples of vendors trying to essentially push their desktop-oriented platforms into the browser. Of course, anyone who has developed software using the non-embedded versions of those platforms know how much nicer they are to work with than the browser-based variants, and more importantly, how much more productive.

I don't think that RIAs and their platforms can be salvaged. They're a failed technology, built specifically to exist within a feeble technology. If we want our applications to be network-aware and network-accessible, there are much better approaches. And nothing is stopping is from using HTTP; we can use it more effectively if it's not returning HTML, JavaScript, or CSS. So perhaps we should just let these RIA platforms die off, so we can get back to writing innovative software using real application platforms that promote developer productivity.

Lately, there has been a trend towards using the Web browser as a general application development platform. This is unfortunate in many ways, namely due to the poor nature of the browser for such a purpose. A system inherently designed for displaying documents and allowing for navigation between them has been perverted into something more. Unfortunately, it's not even a remotely decent platform. All of the efforts so far have basically been very poor reimplementations of what we've already had for years.

In terms of programmability, we're basically limited to using JavaScript. While JavaScript may be usable for minor scripting tasks, it is not the sort of programming language that should be used for developing more complex software. I've written before about some of the problems with JavaScript, as have many others. Needless to say, it's not good to be isolated just to JavaScript for browser-based Web applications, as we currently are. Compared to more traditional software development, we're handicapped significantly by the current situation.

When it comes to actually displaying stuff to the user, we've experienced nothing but problems. We're essentially limited to using CSS, along with JavaScript. Anyone who has had to write even a moderately complex cross-browser stylesheet knows that it's nothing but a huge hassle. And even today, there's still much disagreement about whether CSS is even acceptable for layout. I summarized some of the CSS versus HTML tables arguments the last time that debate flared up. Regardless of one's stance, I think it has to be agreed that the mere act of rendering text, images and other information to the screen is much more of a problem for Web applications than it probably should be. Even then, it doesn't offer the flexibility we can get from traditional software development platforms and techniques.

While it's been noticed that there are significant problems in these core areas, the remedies are less than suitable. A good example of this is the canvas element that has been implemented by several browsers. It essentially provides a drawing surface, much akin to what we've had available on so many other platforms for decades now. But unlike these non-Web-based platforms, the canvas element is primitive. A developer using the canvas element is typically forced into writing a lot of code that would already be provided as part of the more mature platforms.

We've seen an even further step backwards recently with respect to the HTML5 Web Storage specification. So not only will we have a crippled programming environment in terms of JavaScript, and a poor rendering environment in terms of HTML, CSS and the canvas element, but now we may also have a half-baked implementation of a relational database, as well as the interface to access it, available for abuse.

There's been a lot of disagreement lately about this browser-based storage. And I'm not talking about healthy disagreement such as whether it's a bad idea or not. Most of the disagreement is with the nature of the data store itself. That draft specification suggests a very SQL-oriented approach. Others suggest that a JSON-based approach would be better. Some suggest an approach akin to CouchDB, with this already being experimented with.

Based on the current draft of that spec, I think we're looking towards a world of pain. It essentially outlines a very poor reimplementation of what we've had for years in technologies like JDBC, ADO.NET and Perl's DBI module. It's looking much like a case of us getting a small fraction of what we can already do, without any real benefits, improvements or innovation.

It makes little sense to try to build a platform for the future in the Web browser. All we've managed to do so far is reproduce a lousy, stripped-down version of the existing platforms that we've had for decades. But what makes it worse is the monoculture that has developed. We're stuck using JavaScript for programmability. Any form of display must essentially be done using HTML, CSS and the canvas element. Data storage may be done in a form similar to that of the proposed HTML5 Web Storage spec, but even if different it will still likely be very lacking. And given that the platform is provided by the Web browser, it's not like we can really go back and correct all of these deficiencies at the core with ease. We instead have to try to reproduce what we've had for years outside of the browser using JavaScript, which so far has been an absolute failure. We can't make any real forward progress if we're going to be continually trying to bring ourselves up to the level we were at back in the 1990s.