Was JavaScript a mistake?
Standardizing on a single language puts too many eggs in the browser's basket.
By Neil McAllister
August 21, 2008
The more I hear about the ongoing efforts to revise the leading Web standards, the less convinced I am that we're approaching Web-based applications the right way.
The latest dust-up involves ECMAScript, the international standard that forms the basis of the JavaScript language. Last week, the committee in charge of the language voted to abandon the proposed ECMAScript 4 standard in favor of a much less ambitious revision, dubbed ECMAScript 3.1.
Had the work continued, it would have brought big changes. "Programming 'in the large' has been a problem with untyped languages like JavaScript," Adobe's Ed Rowe told me in an interview earlier this year. "That's why Adobe has been working with [ECMA] on ECMAScript 4 ... to introduce concepts that are compatible with building large-scale applications."
But while large-scale application development might sound good to Adobe, guaranteed it wouldn't have worked for everyone. The history of traditional systems programming languages is evidence enough of that.
For every methodical, disciplined Java programmer there's a Perl hacker who would much rather play everything by ear. Strong typing, packages, and namespaces may make it a lot easier to maintain large applications, but they're virtually useless to any Web coder who just wants to bash out a little bit of UI glitz.
In fact, the very concept of an all-purpose programming language that's designed by committee is questionable. Once before, a bunch of very smart people got together to write the specification for what was supposed to be the ultimate programming language. It was secure, robust, and so standardized that nothing was left to interpretation. Remember Ada? No? That's probably because, once the specifications became available, the language was so strict and inflexible that most folks preferred to code in C.
So if nobody ever managed to come up with the ultimate, perfect language for systems programming, what makes us think we can do it for the Web? If anything, the more we talk about building large-scale Web applications, the more we should recognize that a single style of programming will never suit every job.
I'm a big fan of the Model-View-Controller design pattern. It doesn't work well for everything, but it can often provide invaluable guidance in the application design process. In a nutshell, one of its core tenets is to separate the View -- the presentation of data -- from the data itself (the Model) and the underlying logic that manipulates it (the Controller).
So here's an idea: Your Web browser window is a View. Maybe it's high time we stopped trying to force it to be a Controller, too.
Ever since the early days of Web browsers we've had this language, JavaScript. Over the years, we've demanded more and more of it, to the point that we're now talking about using it to build entire applications. The simple truth, however, is that JavaScript will never be good for everything.
Rather than shoehorning more and more functionality into the browser itself (and going through all the rigorous standardization procedures that this requires), maybe it's time we separated the UI from the underlying client-side logic. Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.
We already have a means to achieve this separation for client-side code today: browser plug-ins. Of course, most Web developers will tell you that plug-ins are a Bad Thing. Every time you force the user to download and install a plug-in, says the popular wisdom, you throw a roadblock in front of your code. But is that really true?
Early browser plug-ins were mostly designed to deliver multimedia. Typically it didn't take long for them to become vehicles for online marketing -- and this at a time when most computer users connected to the Internet via dial-up. Little wonder that no one could be bothered to download them.
The modern counterexample is Google Gears. Install the Gears plug-in once, and every Gears-enabled application gains additional functionality. To date, the list of enabled sites includes not only Google Docs and Google Reader, but MySpace, Picasa, and even WordPress blogs.
People tend to focus on Gears' ability to allow Web applications to be used while offline. They overlook the WorkerPool module, which allows JavaScript code to run in the background, independent of the code on the main page. WorkerPool is a standalone code execution engine; it just happens to run the same JavaScript as an ordinary browser.
So why JavaScript? Why not Python, or Lisp, or some other, new language designed with an alternative Web application development methodology in mind? If the application that it powers is compelling enough, the incentive to install a plug-in is high -- particularly in this age of readily-available broadband.
An external browser module capable of executing most of the proposed ECMAScript 4 specification already exists: It's the Adobe Flash plug-in. Other platforms are available as plug-ins, as well, including Curl and REBOL.
As Web developers, we tend to shy away from these alternatives, but only because of the never-ending efforts to refine and standardize JavaScript within the browser itself. Because it's a Web standard, we tell ourselves, JavaScript is the "purer" option.
But if sticking to a single way of doing things is what we want, then why reinvent the wheel? We already have an all-purpose client that's capable of acting as a front end to a wide variety of applications, from databases to e-mail. It's installed at thousands of enterprises worldwide, right now. It's called Lotus Notes.
Is that the way we're heading? Is that really the model for the browser of tomorrow? Or is it time for the Web development community to start thinking outside the box?
http://weblog.infoworld.com/archives/emailPrint.jsp?R=printThis&A=http://weblog.infoworld.com/fatalexception/archives/2008/08/was_javascript.html
Topic: Just for you Bonk (Read 1267 times)