Slashdot Mirror
Was Standardizing On JavaScript a Mistake?
snydeq writes "Fatal Exception's Neil McAllister questions the wisdom of standardizing on a single language in the wake of the ECMA Committee's decision to abandon ECMAScript 4 in favor of the much less ambitious ECMAScript 3.1, stunting the future of JavaScript. Had the work continued, McAllister argues, it could have ushered in an era of large-scale application development that would ensure the browser's ability to meet our evolving needs in the years ahead. '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,' McAllister writes. '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.' McAllister's simple truth: JavaScript will never be good for everything — especially as the Web continues to evolve beyond its original vision. His solution? 'Rather than shoehorning more and more functionality into the browser itself, 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.'"
I strongly agree.
I even believe the features of v4 will unnecessarily complicate the language. Most problems in javascript arise when people try to mimic 'normal' OO-behaviour instead of using javascript's powerful prototype-based system as given.
Javascript is extremely useful to create large scale applications but most programmers are to much educated towards 'convetional' OO-programming to use it right.
I guess it is the same problem as with functional programming, which is often preferable above OO-programming for the server-side model layer. The mindset of the common programmer is simply not diverse enough to use a completely different approach, such as prototype-based or pure functional programming
Netscape went with ECMA early on and got good results standardizing Javascript. Since that time ECMA whole-sale sold out to Microsoft. Ask any normal party that has been involved and I think you will get the same answer. They are to be blamed for not only this Javascript failure, but for the whole OOXML fiasco. Microsoft went there with a single goal in mind: to block Javascript to allow their own .net-related standards to become relevant, which they get rubber-stamped through ECMA.
To a lesser degree, W3C has also sold out to Microsoft in their efforts to sell SOAP, deemphasize all the web standards Microsoft does not want to be important so, for example, they don't have to waste effort competing in the browser wars when they think they should just forever be declared the winner without having to do anything that benefits the web in general.
Should Javascript be the defacto standard on the web? Only in so far as it is useful. Like anything else on the web, if it ceases being useful, people will build a new path and do something else (whatwg, anyone?). But it is silly to call it useful or not useful based upon Microsoft/ECMA blocking the way. It sounds to me like there is some good work going on inspite of the monopolist blocade. I would hate to never see it come to light because of the many formal committees that sold out to Microsoft.
I love competition and would love to see something an order of magnitude better take over and rule the day, but that should be based upon technical merit and competing against the current success, ubiquity, and any irreparable flaws of Javascript.
I have every confidence that as ECMA continues to be paid to make good things irrelevant and bad things relevant, other standards organizations, which may start out being ad-hoc, will rise up to fill the void, and Microsoft will continue being irrelevant to those they do not own until they can really come up with something generally useful as a standard.
1. IP is connectionless, but somehow TCP works anyway. Session is a layer.
2. Client side privileges are IMPOSSIBLE to control, relying on the server for security is mandatory.
3. Bandwidth does not govern RPC performance -- service time does.
4. The W3C is addressing XMLHTTPRequest standardization.
Liberty you never use is liberty you lose.
Upon a cursory glance, Javascript seems like a good language. It takes elements from some of the most popular and well-known languages (C,C++,Java) and makes it into something appropriate for scripting. But with experience, I've found that Javascript really only borrowed the most trivial features of those languages, and forgot everything we learned about computer science in the last 20 years.
The most awful example is the concept of "undefined." Javascript is the only language I know of where it is legal to say:
if (MyObject.NonExistantVariable == 7) // Do some work
{
}
(BTW: This expression returns false)
That is the source of most Javascript errors in a large project. A property was removed, a variable renamed, or misspelled, or never initialized. The value of the non-existant variable is "undefined" which is the bane of Javascript. There's even a special === operator for specifically comparing to undefined! And people thought NULL was bad!
It gets worse because Javascript is a glue language between other things like the HTML DOM or XML/SOAP/JSON so those object definitions can change at any time, and you won't know it broke your Javascript until you hit the right line of code in the right order.
Javascript is a language with totally dynamic typing and scoping. So it is impossible to compile, or type check. Even most scripty languages like PERL can detect more errors at load-time of the file than can be detected in Javascript.