Was JavaScript a mistake?

Standardizing on a single language puts too many eggs in the browser's basket.

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.