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

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.

Opera is the Ron Paul of browsers

[athloi]

Avoid the two big warring parties that are too big to get anything right, strip down your runtime and spend more time being less concerned with government or browsers. Opera is the Ron Paul of browsers in that it seems a lot of us use it online, but you never see mention of it in the "real world," and this article is part of that trend. Why?

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 <script type="javascript"> tags or not. One side says yes, other says we should keep that for older JS and put the new stuff inside <script type="ecmascript4"> 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?

brand new language

[l3v1]

Wanting to create a new language instead of supporting an upgraded JavaScript shows one thing, how bad the IE codebase for JavaScript handling might be. This majorly smells like those situations where after a long update and extension period a code becomes so hard to handle that it's better to drop the whole thing and start a rewrite from scratch. Of course, if you argue for a new language, this probbably isn't such a big issue, since you'd need to write a new handler code for that anyway, and nobody will know what your reasons were.
Of course this is all just speculation. Wouldn't be the first time I'd be wrong, still, the smell is really strong.

Re:About Silverlight?

[LWATCDR]

I would bet big money on that.
I would love to see a good javascript replacement. I don't like javascript and find it kind of nasty to write in. I just don't want it to be under the control of Microsoft, Apple, or Adobe.

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.

Language Plugins

[Doc Ruby]

I'd prefer to see scripts specify which language interpreter they're tested under, and the browser (or other executing object) retrieve an interpreter for it, caching them (and bundling popular ones if necessary). Why should old scripts stop working because they fixed something I never used in its interpreter, and left out the things I did use?

Re:Flash-bashing equivalent

[Hal_Porter]

Did you know that in Opera you can right click on a web page, select Edit Site Preferences and disable Javascript, or just disable the features the site abuses. No extension needed! And it runs perfectly fine on older machines since it doesn't leak memory like sieve like certain competing browsers. It's also free and cross platform just like them.

And it has fewer vulnerabilities -

http://news.softpedia.com/newsImage/Internet-Explorer-vs-Firefox-vs-Safari-vs-Opera-3.png [softpedia.com]

Plus since it has a tiny market share it's very unlikely anyone will bother to target it.

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.

Re:Multithreading!

[Anonymous Coward]

Web applications themselves have a UI (expressed in HTML, SVG, etc.) and processing code (loading data from the server, sorting, formatting, calculations, whatever). If you want to avoid UI stalls, you have to break up the processing into small chunks and return control to the UI frequently. Javascript has no support for doing that in the middle of a task, let's say in a for loop. You have to finish the function call, which means you have to manually keep track of the fragments that you have processed and the fragments that still need to be processed, and often the efficiency is horrible because you have to make the fragments really small so that the UI stays responsive even on slow machines. That is much worse than back in the days of cooperative multitasking. At least then you could relinquish control and have the OS remember where you left off (and user interfaces would still stall because the programmer misjudged the time it would take to do something before he offered control to another task).

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.

Sure

[Colin Smith]

But if MS creates a new language and it's beloved of "web developers", it won't take long to be implemented within Firefox, Opera and Safari. If not beloved and not supported, it'll die.

 

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).

I agree

[Yold]

I learned to program with VB, and still think its an acceptable language, and I agree with you 100%. Newlines mark the end of statements unless you add a '_', you Dim As, or just Dim (strongly typed or not, wtf?), and thats all I really can remember.

As someone who has written a 1000+ line AJAX app in the last 6 months, I can tell you that cross-browser incompatibilies already make programming javascript a bitch. I can't remember too many specifics, but I know that mozilla javascript implements arrays slightly different than IE, and it was a pain in the arse to CONSTANTLY patch around DOM issues. The breakdown of my time was probably spent 20% design, 20% code, 60% patching for IE.

Re:Why not both?

[MrMunkey]

Mod parent up. Anyone who posts anything else should read this first. At first I was a little learly of ES4 since I'm so used to ES3. After reading the overview, it's not that bad, and I don't understand what the big fuss is.

Microsoft vs Mozilla

[eulernet]

Microsoft's dream since 10 years is to rent web applications, since it will allow them to earn more and more money.

It's impossible to program Office with the current Javascript language.
So, Microsoft is trying to push Silverlight (since it's its own baby based on C#).

The battle that will result may see Microsoft's largest defeat.

First, this is a political battle, and every opponent has to make concessions, and M$ are not good at that.
Secondly, M$ is no more in a position to dictate how the Web should work, since the users have now a large choice of Web browsers (Safari and Firefox in particular). They still behave as if the Web was IE-centric.
Thirdly, Microsoft imposed his OS by crushing its competitors one by one. Due to the progress of Apple and GoogleOS, it's not any more possible.

Frankly, I don't see how Microsoft could win this battle.
If they count on their own forces, they will fail, like they failed with Vista.
If they expect a large developers support, they are wrong, since nobody (I mean nobody important) is supporting Silverlight.
If they count on a miracle, I think they had their share.

Once a technology standard will be decided, everything will depend on large Web companies, like Google.

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.

Re:Um... hello... I know it sounds wierd, but go M

[Anonymous Coward]

Even if we throw in a tag to make legacy javascript viable, every legacy page out there would have to be updated - meaning all of those abandoned or hardly maintained web sites with tons of useful information are going to be broken

<script type="text/javascript"> // "legacy" JavaScript code </script>

<script type="application/ecmascript; version=4"> // new shiny </script>

No need to change existing pages.

How would you all be reacting if there was talk about re-implementing C

There are many [gnu.org] implementations [intel.com] of C [microsoft.com]

or heaven forbid Ruby.

Oh [ironruby.net] look, [rubini.us] Ruby [google.com] as [xruby.com] well. [atdot.net]

Albatross.

[Anonymous Coward]

The man responsible for IE is in no position to lecture anyone about compatibility and security. Wilson telling the inventor of javascript to shut up and do as M$ says reminds me of this [slashdot.org]:

Question 5) True Story? by travisd ([e-mail])

Was the story about you embarrassing a Microsoftie at a conference true? Specifically, that he was insisting that their implementation of ksh in their unix compatibility kit was true to the "real" thing and trying to argue the point with you. The argument ended when someone else finally stood up and informed the speaker who he was arguing with. Just curious ...

Korn: This story is true. It was at a USENIX Windows NT conference and Microsoft was presenting their future directions for NT. One of their speakers said that they would release a UNIX integration package for NT that would contain the Korn Shell. I knew that Microsoft had licensed a number of tools from MKS so I came to the microphone to tell the speaker that this was not the "real" Korn Shell and that MKS was not even compatible with ksh88. I had no intention of embarrassing him and thought that he would explain the compromises that Microsoft had to make in choosing MKS Korn Shell. Instead, he insisted that I was wrong and that Microsoft had indeed chosen a "real" Korn Shell. After a couple of exchanges, I shut up and let him dig himself in deeper. Finally someone in the audience stood up and told him what almost everyone in the audience knew, that I had written the 'real' Korn Shell. I think that this is symbolic about the way the company works.

We can see where that effort went. Embrace, Extend, Extinguish.

Albatross [wikipedia.org] is a fine name for a blog run by anyone at M$ [wikipedia.org]. Everyone who works there has made a deal with the devil and the entire company history hung around their necks. If Wilson wants credit for, "enough intelligence to make my own lies up," he can have it. If he wonders why the world might be hostile, instead of the hotbed of helpful, fuckable pawns his company likes [edge-op.org], we can always remind him of what his group did to Netscape.

Re:About Silverlight?

[zaydana]

Another javascript code monkey here. I think we all agree that fundamentally, javascript is quite a nice language. The point I think the GP was trying to make is that while the language itself is nice, the incompatabilities between the browsers, stupid APIs like the DOM, and other similar aspects mean that it would be easier to just start from scratch with another language where all of this goes away.

While there is nothing technically stopping us from drastically modifying javascript, the problem is that as long as we require backwards compatability (as Mozilla is proposing), we can't fix any of the real big problems. You can see this in IE7 - while it's CSS support is a whole lot better than IE6, the fact that it still needs to be able to render pages which are designed for IE6 is rather limiting.

The sad reality is you can't realistically "fix" javascript, due to how people expect backwards compatability from a language with the same name. While obviously the upgraded language would be backwards compatible, the APIs, which are what needs fixing in the first place, wouldn't be. The only way to work around that would be to completely separate the old and new languages. Which effectively, would be creating a new language.