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.'"

Comments

Re:Got it wrong

[tomtomtom777]

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

Re:Reasons why browsers are poor application runti

[hypnagogue]

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.