Slashdot Log In
MS, Mozilla Clashing Over JavaScript Update
Posted by
Zonk
on Fri Nov 02, 2007 02:33 PM
from the minor-frustration-of-the-titans dept.
from the minor-frustration-of-the-titans dept.
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."
Related Stories
[+]
Technology: ECMAScript 4.0 Is Dead 168 comments
TopSpin writes "Brendan Eich, creator of the JavaScript programming language, has announced that ECMA Technical Committee 39 has abandoned the proposed ECMAScript 4.0 language specification in favor of a more limited specification dubbed 'Harmony,' or ECMAScript 3.1. A split has existed among the members of this committee, including Adobe and Microsoft, regarding the future of what most of us know as JavaScript. Adobe had been promulgating their ActionScript 3 language as the next ECMAScript 4.0 proposal. As some point out, the split that has prevented this may be the result of Microsoft's interests. What does the future hold for Mozilla's Tamarin Project, based on Adobe's open source ActionScript virtual machine?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
About Silverlight? (Score:5, Insightful)
Re:About Silverlight? (Score:5, Insightful)
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.
Parent
Re:About Silverlight? (Score:5, Insightful)
JS as a language is not fundamentally broken!
Parent
Re:About Silverlight? (Score:5, Informative)
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.
Parent
Re:About Silverlight? (Score:5, Insightful)
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.
Yes, they are.
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.
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.
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.
Parent
Re:About Silverlight? (Score:5, Funny)
function addOneWeek(startDate) {
var oneWeekInMilliseconds = 1000*60*60*24*7;
return new Date(startDate.getTime() + oneWeekInMilliseconds);
}
Parent
Re:About Silverlight? (Score:5, Insightful)
Parent
Multithreading! (Score:5, Interesting)
Re:Multithreading! (Score:5, Interesting)
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.
Parent
To me, this seems vaguely pointless for browsers (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Parent
Just don't break things! (Score:4, Insightful)
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!
What's this all about? (Score:5, Interesting)
I don't see anything about closing the web or stomping on the little guy or anything like that. Where's that coming from?
MS Trying to undo the Outlook Web Access Mistake (Score:5, Interesting)
STOP OVERSTATING MICROSOFT'S CONTRIBUTION (Score:5, Insightful)
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 [yafla.com], 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.
Parent
Re:Either way... (Score:5, Interesting)
Parent
Re:Either way... (Score:5, Insightful)
Yes, a language that parses whitespace like Python does would be great for client-side scripts run from a web browser.
Parent
Re:Either way... (Score:4, Informative)
Parent
Re:Flash-bashing equivalent (Score:4, Informative)
If I trust the website enough to run javascript, then I add it to my whitelist. I don't see the need for javascript on most of the pages I go to, and would rather not have my computer running unnecessary code. Seems to my totally uneducated POV that it'd slow my computer down if I have 20 tabs each running javascript stuff, when only 2 of them ACTUALLY need it. My RAM is precious to me. =(
Parent
Ug. (Score:5, Insightful)
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.
Parent
Re:Why not both? (Score:5, Insightful)
Parent
Re:Why not both? (Score:5, Informative)
Go check it out and decide for yourself.
Parent
Re:Not sure about this... (Score:5, Insightful)
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.
Parent
Microsoft appears to be spreading FUD (Score:5, Insightful)
Your criticisms seem to be aimed at HTML and CSS, and at attempts to make up for their failings with Javascript toolkits. What Mozilla is pushing here is significant enhancement to Javascript in order to remedy many of its failings while maintaining backward compatibility. Microsoft, on the other hand, is trying to limit changes to the language. According to Eich, Microsoft is criticizing the ES4 proposal without offering concrete alternatives. Instead, he says, they are developing [burningbird.net] their own language in secret.
I think Javascript's a pretty good language. Certainly it's not perfect - few languages are. PHP, C++ and Perl spring to mind as being particularly flawed, but they have been indispensable nonetheless. Javascript has a huge installed base of runtimes and many programmers are familiar with it (so there's lots of bad code, which may be why JS has such a bad rep). We know how conservative most developers are about learning new languages (especially ones that don't look like C or BASIC), so there would be a significant cost and risk to trying to switch horses from Javascript to something else. Browser compatibility is another matter altogether - but we know who is causing the trouble there.
Javascript is practical and flexible; the main problems I have encountered are weak support for OO and larger projects - problems the ES4 effort appears to be trying to address. Microsoft's argument is for making minimal changes in favor of some unknown future language. If they really are working on that language in secret, and are able to complete it while Javascript is mired in controversy, the outcome is unlikely to be good for the rest of us.
Parent
Re:Wishes (Score:5, Insightful)
Is there a non-elitist reason to not use tables for a layout?
There are many. Let's try a few:
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 keep the layout pretty basic to get broadest browser support, and tolerate browser differences. I'd never promise pixel-for-pixel cross-browser support. HTML isn't designed to do that.
Parent