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:Why not both?

So you think that while right now we have partial and buggy implementations of one scripting language in most browsers, when we have two new additional scripting languages we'll have two well-supported, to-the-spec implementations of the two new languages in most browsers?

Re:Why not both?

The overview of the current ES4 proposal is here: http://www.ecmascript.org/es4/spec/overview.pdf [ecmascript.org]

Go check it out and decide for yourself.

Ug.

Javascript is intentionally designed to be less functional than any of the languages you've mentioned, and with good reason...A client side language with the sort of feature set that perl or ruby or python has would be death on a plate in the context of a modern web browser; you'd go to a webpage and it wouldn't just slip you a trojan--it'd reinstall your OS.

Client side languages need to be concerned purely with the cosmetics of the interface. Any single step beyond that opens up some extremely scary security concerns.

Re:Ug.

JS has several features that e.g. Python lacks, for example prototypes, open/classless objects and closures. JS bashers usually know little about JS and largely perceive it as a web toy, something like VBA with Java syntax and without the IDE. The fact is, you can write real, reusable, object-oriented software in JS, without going crazy in the process. There are deficiencies and incompatibilities in the various browser runtimes, but those are neither JS's fault nor will they magically be avoided by inventing some new language.

Re:Why not both?

Purely for syntactical reasons. At the risk of ticking somebody off, I really dislike VB's syntax.

Re:Why not both?

Screw two languages. I'd love to have one language that actually works on all the browsers. Javascript as it's implemented by Microsoft is worlds different from any implementation outside of it. It's only by hacking together the common bits between the implementations that web pages are actually capable of working on multiple browsers.

About Silverlight?

Opera's Haarvard suggests that it's about Silverlight [opera.com], 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?

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

Re:About Silverlight?

Javascript is a beautiful ulimately flexible language, implementations of it (esp Microsoft's) may suck, but the language itself is very good. Learn to use it properly, prototypes, closures, higher order functions... and you will soon learn what a remarkable language for scripting it is.

Re:About Silverlight?

And you are precisely echoing all of the lies that Brendan discredited in his post. There is absolutely nothing about ES4 that will break ES3. Nothing. Yet you (probably quite knowingly) propagate the falsehood that it will.

Re:About Silverlight?

Silverlight is about competing with adobe flash, which by the way is way ahead of microsoft at the moment for the robust web app space, so why did you choose to bash Microsoft and not adobe?

Because the story being discussed here isn't about Adobe lobbying a standards body in an effort to hold back adding new functionality to an open standard that could provide an alternative to closed add-on technologies like Silverlight and Flash.

If it was, people would be bashing them for trying to push the dominance of their proprietary solution by holding back standard, non-proprietary technology in the exact same way that Microsoft is being criticized here.

Microsoft wasn't criticized for having Silverlight, they were criticized for the manner in which they were perceived to be promoting Silverlight.

Mozilla, opera and other pushing to extend open web technologies?

Yes, they are.

Please .... how does a fight between what version 2 of something is named have anything to do with extending open technologies?

That's not what the dispute is over. The dispute is over whether Release 4 of ECMAScript should:
1) Include major new functionality, or
2) Include only minor new functionality, with major changes outside of the scope of the standard and left for other languages (either proprietary or part of different standards efforts.)

The first position favors substantial extensions to non-proprietary, freely-implementable standards for the web. The second does not.

Microsoft is saying we have a standard, we have products that are written to that standard, and it will be expensive to supercede that standard with a replacement.

A new version of a standard doesn't impose costs; no one is obligated to support the new version. ECMAScript Releases 1-3 won't stop working when a specification for ECMAScript Release 4 is released.

OTOH, more features in the standard means more that can be done within the scope of the standard and without non-standard, proprietary alternative technology.

They have no objections to something new, just dont break the old.

New standards, even ones that aren't backward compatible, don't break old standards. ECMAScript 3 implementations don't break just because there is an ECMAScript 4 standard.

Re:About Silverlight?

It's about bringing robustness to web apps.

I stopped reading your quote here because the only person that would say that is somebody from Microsoft's marketing department.

Re:About Silverlight?

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 [mozilla.org].

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?

No Microsoft is not pushing Sliverlight and WPF here. OR saying scripting does not need to be extended. They are saying there needs something better than javascript

It's true that this is not what Microsoft is actually saying, but you can be sure that's what they mean and want.

Frankly anyone that thinks the present javascript is worthwhile keeping just has not programmed enough in it

I have done a ton of work in javascript for the last decade or so, and you are very wrong. Javascript has always had its pains, but the pains are not inherent in the language and (very importantly!) these pains are rapidly going away. Throwing JS out now back before Mozilla 1.0 might have been reasonable, but by now JS support in all browsers is to a point where throwing out JS would be *stupid*.

JS as a language is not fundamentally broken!

Multithreading!

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!

Disclosure: I am a web developer, but my use of javascript extends only as far as your "simple things like rollovers". (Well, not actually rollovers, that's done in CSS unless you're an idiot, but...) I am not a "proper" Developer. Hence, this genuine question:

To solve the problem of "the UI stalls the processing or the other way around" (which, funnily enough, I only ever really encounter right here on Slashdot), why would the script language need to provide multithreading to the script author (typical or otherwise).

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?

Re:Multithreading!

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:MOD PARENT TROLL

Have you ever, honestly, been to a website that freezes Firefox?

Yes, I have. There's a dating/forums site called plentyoffish that regularly freezes Firefox for me (at least as of 2.0.0.8). Sometimes the browser recovers quickly, sometimes it recovers slowly, sometimes I give up waiting and kill it.

To me, this seems vaguely pointless for browsers

By the time that a good chunk of all browsers actually support ECMA 4, it's going to be a "nice to have" feature that nobody's going to be too keen on.

The road forward, in true hacker fashion, is probably to write translators so that part of your PHP, Ruby, Perl, Java, or C# code magically runs on the client, treating ECMA 3 as a vague intermediate language.

ECMA 3 can be the x86 assembly language of teh intarweb. No CPU actually executes real x86 instructions anymore, they translate it into internal RISC/VLIW-ish operations. Very few programmers write much of any raw x86 instructions anymore.

Of course, this may or may not be handy for the other ECMAScript implementations like LiveScript.

Re:To me, this seems vaguely pointless for browser

Well that's what GWT, OpenLazlo et al do already anyway. The thing is you can't get all the features of the underlying language that way. The key is to making the source language so much better than Javascript that my complaint sounds like saying "the problem with C++ is that you can't get all the features of assembly." (And I mean within the source language, not with things like asm blocks.)

Personally I like Javascript as a language and think it's a shame to see roadblocks to it's development happen because of the nature of the platform it usually runs on. I'd like to see something like GWT where the source language is Javascript instead of Java - that is a Javascript to Javascript compiler where you could add whatever local features you need and have the compiler throw away the fluff and stick in cross-browser compatible shims.

Re:Opera is the Ron Paul of browsers

There's no need to pull Ron Paul's abysmal ability to properly render real world websites into the discussion.

Just don't break things!

As a user, I really couldn't care less which way it goes.

Just don't break things that work now!

As a developer, I really don't care, either.

Just don't break things that work now!

Not sure about this...

Honestly, if we're going to have a new version that's significantly different and "updated," just fork: Keep the original code that works well as one version and then rewrite it as the basis for the new one. The first thing that comes to my mind is KDE4: It's a hell of an idea, but I think they'd best keep 3.5.* around until they're done with 4.0.

In short, give people a choice: Let me choose if I want to write for the stable venerable base or the new pretty whizbang version.

Re:Not sure about this...

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.

Re:Not sure about this...

If the default were to behave exactly as ES3 or ES4 interim, and the new restrictions only applied then, it might be a justifiable change -- but that is explicitly not what the overview says.

I don't know which overview you've been reading, but mine says this:

III. Compatibility
[...]
Syntax
Some identifiers that were legal names in ES3 (let, yield, cast, is, and a few more) are keywords in ES4. Other keywords in ES4 were future reserved words in ES3, and correct ES3 programs do not use them (class, interface, public, private, and many others), though some implementations allow them to be used as names. Sometimes the new keywords are contextual and can continue to be used as names, but in general an ES4 implementation that must be able to process all ES3 programs must be told which dialect--ES3 or ES4--it is looking at, so that it knows whether to treat these identifiers as keywords or not.

The mechanism that supplies the dialect information will depend on the environment. In a web browser the information comes from the MIME type of the script or from a version parameter on the SCRIPT tag in the document. New web pages that choose to use ES4 will have to specify the dialect.

So unless you specify that some script block is actually version 4 ES4 interpreters are supposed to treat it as version 3 code.

np: Savath & Savalas - Tormenta De La Flor (Golden Pollen)

What's this all about?

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?

Re:What's this all about?

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.

Wishes

I've actually had dreams about all the major browsers coming to an agreement about consistent standards with HTML, CSS and Javascript. I have actually had dreams about designing an elaborate webpage layout for Firefox and then having it turn out perfect when it came time to load it in IE. But then I woke up and went about another busy day of using tables and NOT divs for webpage layouts...

*sigh*

Re:Wishes

Is there a non-elitist reason to not use tables for a layout?

There are many. Let's try a few:

• Semantic, linear structure of the page. When one forces a layout into a table, almost invariably the "reading order" of the page gets fouled up. Text content that probably should be readable in top-to-bottom order gets split up into left-to-right cells (in page-load order). This plays havoc with the ability to repurpose the page for mobile devices, pdfs and screen readers, and (perhaps more importantly to the folks signing the checks) makes the page harder for search engines to understand, potentially lowering your page rank. By creating a page that makes semantic sense and using <div> tags and other parts of HTML properly (parts like <h1>, <p>, <ul>, etc.) you help convey to the search engine what the page is about.
• Ease of updating. When you need to change the layout of a page created in tables, you have to reconfigure all the tabled content, moving some from cell to cell, changing colspans, etc. If instead you've made semantic sense of the content, you can move the content around the page with CSS, never having to touch the HTML. You can even do things like change lists of links from vertical nav trees to horizontal tabs without changes to HTML.
• Ease of creating printable pages. When you lay out in tables, you may be able to "hide" display of the tables in the print style sheet, but browser problems may push content around the page anyway (have been struggling with this in a poorly-designed page this week). With tableless layout, it's easy to hide the elements on the page you don't want to see in the printout, set size and margins for the elements you do, then do a window.print()
• Separation of content from presentation. When tables are in use, typically related content is plunked into adjacent cells (image slicing anyone?). When this happens, the presentation (layout) is tangled up with the content. This is difficult to maintain. The developer and the designer have to touch the same page for different reasons. When the page has to be edited for layout, the designer has to know enough about the table code to do things like remove or insert colspans, when in fact there are no columns of tabular data.
• You get to break out of the grid and use flexible (even liquid) layout. You can move things around, put 'em in front of or in back of other items, never having to worry about running out of cells or keeping colspans straight.
• When all else fails in trying to make a table layout do something it was never intended to do, designers make "pictures of type" so the layout observes their wishes. This is a huge mistake for searchability and accessibility. The search engines can't read the pictures any better than the blind can.
• Table-based layouts typically get really, really screwed up when the user resizes the fonts in her browser. Trust me: I'm doing this all the time 'cause I don't want to bother with reading glasses.
• Layout is not tabular data. It's just not. Tables work great for tabular data, and they have many features to render spreadsheet-like pages with clarity.
• It's a misuse of a feature of the language. You might think this is elitist, but would you also imply that the suggestion that someone stop using a Crescent wrench as a hammer is elitist? Or might you instead think: "there's a better tool for that job - one that's designed to do it well".
• It's the right thing to do for the disabled. Not bothering to lay out the page well so the visually impaired can read it could be interpreted as elitism on the part of the sighted.

Is that good for a starter? I'm about out of time to spend on this...

I don't think that browser support for tableless layout is perfect. It's awful in older browsers, but getting better all the time.

In any case, it's the browser's job to render the standard properly, not yours to break the code for the browser. I find the middle-ground is to k

brand new language

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.

Unfortunately, Microsoft has a point

The trouble is, Microsoft has a point. Original HTML, up to, say HTML 3.1, was limited but a reasonable design. Most of the attempts to extend past that point have been disappointing. CSS is a collection of attributes in search of an architecture. Page layout with "float" and "clear" is too limited and doesn't work well. (The "three column problem" is well known, and workarounds using layers or absolute positioning often result in text on top of other text.) Javascript is a mediocre language. (Could have been worse; see TCL.) That's the current mess.

Papering over the problem with a layer of "toolkits" just resulted in a proliferation of incompatible toolkit layers. That wasn't the solution.

But Microsoft will try to "fix" the problem with a closed, ambiguous system that requires frequent updates. That's what they do with everything else.

I don't see a good way out of this. Who can provide leadership? Adobe? They can't even make Dreamweaver work right any more.

Re: Unfortunately, Microsoft has a point

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.