MS, Mozilla Clashing Over JavaScript Update

jfruhlinger writes "JavaScript has become a crucial part of Websites built on AJAX underpinnings, which makes the upcoming revision to the ECMAScript standard crucial for the future of the Web. But in today's browser environment, no one vendor can impose an update path — which may set things up for a nasty conflict. A fight is being fought on blogs between Mozilla Chief Technology Officer (and creator of JavaScript) Brendan Eich, who wants to the new ECMAScript standard to be a radical upgrade, and Chris Wilson, architect of MS's IE team, who would rather keep JavaScript as is and put new functionality into a brand-new language."

Comments

About Silverlight?

[Kelson]

Opera's Haarvard suggests that it's about Silverlight, and Microsoft trying to close the web. Mozilla, Opera and others are pushing to extend open web technologies, but Microsoft is saying, wait, the web doesn't need to be extended at all! Well, except with Silverlight and WPF...

Re:About Silverlight?

[Wylfing]

Microsoft is saying, wait, the web doesn't need to be extended at all! Well, except with Silverlight and WPF

Those are actually Brendan Eich's words. The extended commentary from which that comes is over here.

MS do indeed want to close the internet, and the name of the game is "patent encumberance." It's going to be too hard to lock up JavaScript, so they don't want to play with that anymore. They need to have everyone investing in a new MS-proprietary, patent-encumbered language.

Re:About Silverlight?

[Aewyn]

// TODO: Add 898 lines
function addOneWeek(startDate) {
    var oneWeekInMilliseconds = 1000*60*60*24*7;
    return new Date(startDate.getTime() + oneWeekInMilliseconds);
}

Multithreading!

[Anonymous Coward]

If they're serious about turning the browser into an application platform, there needs to be a multithreaded language with full DOM access, whether that is Javascript or something else. An application where the UI stalls the processing or the other way around is just not acceptable. Since Javascript multithreading has been rejected before, because it's supposedly too difficult for the typical script author, I suspect that Microsoft may have the right instinct here to go with a separate language for "pros", keeping Javascript simple for things like mouse rollovers and other eye candy.

Re:Multithreading!

[_xeno_]

Surely you could solve that particular issue by running Firefox-itself code in one thread, and on-page-javascript-or-whatever-script in another thread (or perhaps one thread per .js, or per site, or per tab, or whatever). You wouldn't need to actually let the script writer work in multiple threads, would you?

Yes, you would. The basic reason is that while, conceptually, you're right that you could use your solution to prevent the browser from locking up, you'd still have to worry about the page locking up.

JavaScript code is generally only executed during events. These events include relatively minor things like scrolling, clicking, typing, or basically any form of interaction with the page. Now you could make the page code "smart" and avoid locking the page if there are no JavaScript event handlers interested in the current event, but you'd still potentially have issues where the page would essentially "freeze" until whatever long-running task completed. Since JavaScript events also fire when the page is unloaded, such a "freeze" could also prevent the user from navigating away from the page.

This leaves us with a potentially responsive browser UI, but a tab that can't be used until its task completes. This is still better than the Firefox situation (and, due to the way Firefox is designed, something that isn't going to change in Firefox for a long while), but still undesirable.

To allow the page to remain responsive while the page is doing some long-running task, you'd have to allow multiple threads so that the event handlers could run.

This is, in a way, the problem that "asynchronous" part of AJAX solves. It doesn't allow another thread to be run via script, but it does allow the page to send the task back to the server to execute, allowing the page to remain responsive while whatever long-running task completes.

I think a similar solution could work via JavaScript: instead of sending it off to the server, allow a script to be executed asynchronously. It would have no access to any information not sent to it when it was started (as otherwise the thread synchronization issues would remain), but it could run a task and then return a result.

There can be some argument over whether JavaScript should ever be used for a "long-running task" but the reality is that more and more web applications are finding that it makes sense to allow certain tasks to run on the client instead of burdening the servers. Most clients have the memory and CPU to spare, and it makes sense to use those resources instead of making the bottle-neck be the server.

Unfortunately the current solutions cause the page to become non-responsive while JavaScript executes and, in the case of poorly designed browsers, cause the entire browser to be non-responsive.

What's this all about?

[Anonymous Conrad]

OK, maybe I'm missing the point here but AFAICS no-one's arguing against the new draft; instead, the argument about whether you accept the new syntax inside tags or not. One side says yes, other says we should keep that for older JS and put the new stuff inside tags or similar so we can tell ahead of time which one we're supposed to be dealing with and make sure we don't break existing web code.

I don't see anything about closing the web or stomping on the little guy or anything like that. Where's that coming from?

Re:Not sure about this...

[Anonymous Coward]

And that is exactly what ECMA 4 does: it leaves ECMA 3 as it is (except for a few really minor and obviously broken things that everyone except for Microsoft agrees on), and then adds some sorely needed extras on top of it which the open web really needs in order to stay competitive with the closed-offerings by the likes of Microsoft.
All current-day JavaScript will continue to work! Backward compatibility has been the number one goal during the development of ECMAScript 4. But Microsoft is scared - web applications have finally started fulfilling the original promise shown by Netscape, making the OS largely irrelevant. And so Microsoft is throwing up any- and all roadblocks it can think of, stalling for as much time as possible in order to create enough lock-in with WPF e.a. that they'll remain relevant. Understandable, of course - they're a company, trying to survive. But a really bad thing for the open web, and something which must be overcome.

STOP OVERSTATING MICROSOFT'S CONTRIBUTION

[ergo98]

but if Microsoft had known that they'd be enabling a general-purpose platform for application delivery -- one that doesn't require Win32, or even a full desktop computer at all -- they'd have found another way or not done it at all

Firstly, at the time there were a huge range of "safe-for-scripting" ActiveX objects that could be created in IE. This was Microsoft's way of clutching every corporate shop that dared to use one in a death grip, instantly destroying their potential to have the versatility that a web application would normally bring. XmlHttp, found in the MSXML library, was just another safe-for-scripting object. At the time the web curious were already exploring a number of ways to do asynchronous calls, most commonly being hidden IFRAME updates, but there were a myriad of other options, including plenty of third-party XmlHttp type components, and even some Java Applet techniques for doing this.

This was a hugely growing need, and while Netscape was beaten to the ground and slowly regrouping Microsoft seemed to lead by default.

The point, I suppose, is that the invention of "AJAX" was absolutely, positively inevitable. Microsoft's influence in those early days is entirely the result of its monopoly, not its technical leadership.