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

Re:Either way...

[WaltBusterkeys]

Maybe this is a naive question, but why isn't a third-party standards organization leading the way on this? I know that W3C didn't do a great job standardizing HTML (as any web developer who has spent hours debugging IE vs Mozilla can attest), but ANY standard is better than no standard here. Where's NIST or ANSI? I hate to even suggest that the US government get involved, but setting some kind of standard could avoid another Blu-Ray vs. HD DVD wasteful standard war that hurts consumers and developers. Everyone would be better off if this conflict could be avoided entirely. What would it take?

Re:Either way...

[RightSaidFred99]

Yeah, design by commitee always works out so well! Seriously, third party standards bodies are only good at post-facto. Don't rely on them to innovate. I say IE and Mozilla battle it out, release the product, and may the best man win. Once a winner is reasonably clear, then the standards bodies can get in and write it in stone.

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:What's this all about?

[Stradivarius]

I think the argument goes like this:

The existing Javascript/ECMAScript has a large installed base. Thus if you simply extend the existing spec in a backwards-compatible way, you allow developers to
keep using Javascript and upgrade with new features at their convenience. This keeps everyone using Javascript and *should* be a smooth and gradual transition.

However, if you switch to a require a separate mechanism to execute or a incompatible language, you force developers to rewrite their code in order to take advantage of the new features. This may be philosophically cleaner, but doesn't have the continuity benefit of the other approach.

Now if you're Microsoft, which situation do you prefer? The second one, because it fragments the installed base and therefore the influence of the platform you don't control. That gives you an opportunity to sell people on using your technology platform instead, since they'll have to rewrite either way to use new advanced features. But if they don't have to rewrite completely, it makes more economic sense for developers to stick with Javascript.

Now there may very well be other technical arguments too, but the above is why people are suspicious of Microsoft's arguments. After all, Microsoft knows very well the power of an installed base and the benefits of having control over common technology platforms.

MS Trying to undo the Outlook Web Access Mistake

[TheNarrator]

I think Microsoft royally screwed up with outlook web access. They added XMLHttpRequest to the browser so outlook web access would work more like a desktop app. They built an application on a technology that did not require full access to the latest version of the win32 api and x86 assembly language and it was off to the races. Most of Google, Yahoo and indeed the entirety of Web 2.0 was built on this mistake. They are desperately trying to put the web back in the original box they intended it to be in which is people without access to the latest version of the full Win32 API, and an X86 processor will be denied access to all online content.

Re: Unfortunately, Microsoft has a point

[Dolda2000]

I don't see a good way out of this. Who can provide leadership? I'm not usually a proponent of Java (quite the opposite, rather), but in this particular case, I cannot see why people would even think twice about adopting Java as the solution to these problems.

We already have a hypertext web that works very well with XHTML and CSS (not that they don't have their flaws, as you rightly point out, but they certainly work). What people are looking for with AJAX and Silverlight and what not is ways of delivering programs over the Internet in a secure manner, and Java already has that problem solved with both applets and Java Web Start. Java is also both an open specification and open source and it has a number of interpreters for almost any platform you can beg for, it has been around for far over a decade, and is very mature by now.

I don't see why people are not using Java. What's the problem? There are the obvious problems with Java being a horrible language to work in, but even so, it's probably still better than AJAX, Silverlight and Flash.

Who needs Silverlight?

[DrXym]

My guess is Microsoft realise that compatibility with JavaScript, HTML and other open standards is questionable in most browsers and they absolutely do not want to make it any better. After all, if the open standards were adhered to (and improved such as with ES4), who would care about Silverlight or .NET? I think that's the bottom line here. ES4 makes many fundamental improvements to JavaScript. It's not hard to think that ES4 + HTML + a strong Ajax lib might render Silverlight irrelevant. And Microsoft sure can't let that happen. Better to talk up problems in js and subvert every effort to improve. Meanwhile they'll push Silverlight as the solution to all the problems they're partly responsible for. The sad part is that Flex and venerable Java are still better solutions than Silverlight but we know how the industry loves the next best thing even if there is no need to.

Re:Forgetting that it's Microsoft for a minute...

[photon317]

I agree with you, except for the Python part. Python is an ill fit for a language that's meant to be embedded in a (X)HTML, because (X)HTML does not honor content whitespace (and neither to a lot of related tools) and Python relies on whitespace for structure.

I could see trying to standardize a subset of Ruby though. Drop some of the ambiguous (or more difficult to implement parts) and access to operating system services (like fork(), etc), just keep the very basics necessary for pure code and modular OO, give it a well-though-out built-in object model for the DOM (and perhaps some built-in libraries of functionality for things like XML/XSLT, xmlHttpRequest-like stuff, etc), and keep the language compatible back to real Ruby (that is to say, all BrowserRuby code runs on a real Ruby interpreter, but not vice-versa).

Re-reading the above, it sounds like I'm basically describing a rehash of what the Javascript guys did. The difference would be that (1) We can do a better job today now that the problem domain is better understood, (2) It will actually be compatible (javascript code does not run in a real java environment unfortunately), and (3) It will be based on a much better language (no offense, but Java sucks).

Normally I advocate Perl over Ruby, but in this context Ruby probably makes more sense (in the very broadest sense, the languages are fairly comparable anyways).