MS, Mozilla Clashing Over JavaScript Update 521
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."
Why not both? (Score:1, Insightful)
Re:Why not both? (Score:2, Insightful)
About Silverlight? (Score:5, Insightful)
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:Either way... (Score:3, Insightful)
There needs to be a third pary arbitrator here.
And hopefully that arbitrator tells them all to just STFU up and use python
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!
Not sure about this... (Score:3, Insightful)
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:Either way... (Score:2, Insightful)
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.
Re:Why not both? (Score:4, Insightful)
Unfortunately, Microsoft has a point (Score:3, Insightful)
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:Multithreading! (Score:4, Insightful)
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:About Silverlight? (Score:1, Insightful)
Insightful? Come on, that's rubbish. It is a simple minded microsoft bash with no basis in fact or reasoning, and yet it gets moderated insightful.
Silverlight is not about competing with Javascript at all. It's about bringing robustness to web apps. It's about being slightly compatible with desktop apps in code. Those are things that current web technologies, even with AJAX, can not do. 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? Never mind, we know the answer.
Mozilla, opera and other pushing to extend open web technologies? Please
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.
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.
How about starting over from scratch? (Score:3, Insightful)
Re:Why not both? (Score:5, Insightful)
Seriously? (Score:3, Insightful)
Considering the amount of havok that is caused using javascript, a language that can't even actually write to a file, I can't even imagine the chaos that would be caused by perl, with all of it's methods for reading system states, and manipulating files and output devices.
Re:About Silverlight? (Score:3, Insightful)
By "you," are you referring to me, the person who summarized something that I thought was an interesting take on the issue, or to Haarvard, the person who actually made the assertion and discussed it in detail?
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.
Python in HTML = BAD (Score:1, Insightful)
Seriously, Python would be the WORST language to use for scripting in HTML.
Javascript is actually pretty good, the only reason it has a bad name is from the different browser implementations and different DOM accessing methods. Fix that, and add some more convenience libraries / functions and you are set.
Re:How about starting over from scratch? (Score:4, Insightful)
- have know been widely field tested, their strenght and shortcomings are known, there are hundreds of implementation of them that have been heavily tested and debugged, this is extremely precious
- it is widely adopted, switching represents a huge cost for the whole industry (not only it pro but all the people in the world who live by selling html developpement)
While starting from scratch looks pleasant, for big things (and html is *big*) gradual changes are more appropriate.
You just have to love Microsoft. (Score:2, Insightful)
I expect a Dilbert strip about this any day now.
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.
Re:Why not both? (Score:4, Insightful)
Re:Either way... (Score:3, Insightful)
Also "Tacking on updates to existing standards only creates ugly security loopholes, and all sort of weird hacks."?
Yeah, that explains why Python 2.x is so much worse than Python 1.x and Perl 5 is so much worse than 4 and why the new versions of C, C++, C# and Java never caught on... Oh, wait.
Re:Sure (Score:2, Insightful)
Re:Sure (Score:1, Insightful)
oh, and one more thing... please, please, please, can we do something about the insane code necessary to make JavaScript work on the two major browsers? It's ridiculous the amount of garbage you have to throw in just to cover yourself for the last two versions of the two big browsers. Can we just make browser upgrades mandatory or patch old versions or something? (I know that'll still leave me with the Mozilla / IE differences but then I only have to worry about two browsers instead of four.)
Re:Sure (Score:2, Insightful)
But seriously folks if one way or another it's gonna be a different language, just call it "Javascript+ ver.1" instead of "Javascript ver.N+1" as long as you keep the ability to run "Javascript ver.N" in the browsers I don't see whats to bitch about in making it a different language.
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.
MOD PARENT UP (Score:4, Insightful)
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.
Re:Ug. (Score:4, Insightful)
Re:About Silverlight? (Score:4, Insightful)
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.
Re:Either way... (Score:3, Insightful)
Your examples actually strengthen the point you are trying to argue against. C++ is indeed lots of new stuff tacked on to an existing language (C), with a result that is far from elegant and full of gotchas, as any newbie to C++ will know. C# and Java are both completely new languages, they can be called successors to C/C++ but neither even tries to be backwards-compatible and neither builds on the C++ standard. I don't know about Python and Perl
Re:About Silverlight? (Score:5, Insightful)
JS as a language is not fundamentally broken!
Re:Sure (Score:3, Insightful)
You know the same way Apple and Microsoft force you to get new computers if you want to run the "New And Improved With 25% Fewer(?) Gaping Security Holes Operating System"
But that would require organizing developers into some form of union.
Re:Microsoft appears to be spreading FUD (Score:4, Insightful)
How come IE uses "innerText" and Firefox uses "textContent"? Right there is a little compatibility function nearly every single Javascript in the world needs to write to work correctly.
Why is there no "GetElementsByClassName?" Another function nearly every Javascript needs.
How come the various "geometry"-returning functions have some baffling results? How come it's so hard to answer basic questions like, "did the user scroll to the bottom of the webpage?" What the hell is a "userAgent" anyway? Does the measure of it include toolbars? Status bar? How come the screen functions return different results for IE and Firefox on multiple-monitor systems? How come the screen functions don't even *support* multiple-monitor systems?
Why does Firefox insert blank text nodes into the DOM while IE doesn't?
How come my Javascript can't tell if a TextArea has text selected or not?
How come the internationalization features suck so much?
Why does "XMLHttpRequest" have such a strange name? Are acronyms supposed to be in all-caps or not, because that function shows it both ways.
There are a hundred problems, not necessarily with Javascript, but with Javascript's interaction with the DOM and browser. I think it's clear that both IE and Mozilla are right in that *something* needs to be done. Whether it's a new language or a new direction for JS, I dunno. (I like the language itself, for the record.)
Actually design by commitee does work.. (Score:1, Insightful)
C++ is an example of horrible design by committee, with ever shifting basic functionality and over complexity. But the updates to C (by committee) have been very reasonable and useful. Germany's design by committee of power plugs has been great for Europe, and has even taken over Britain's mishmash of plugs that has been a plague and a bane to the folks of the island. The metric system has worked out pretty well for everyone.
When the problem is old and simple, committees do a great job of explicitly laying out the pre-existing consensus. When the problem is new and interesting, with no clear solution, committees produce a self-conflicting hodge-podge solution that is always behind the times.
It's not necessarily post-facto, but just not innovative. They're not the same thing. I'm not sure how much "innovation" is really needed for the next generation of js. I'd hope that the problems and their technical solutions are pretty clear by now, and just implementation and standardization are needed. If that's the case, design-by-committee is probably the best thing that could happen.
Seriously, MS has it right (Score:3, Insightful)
As I view it, casual web browsing and using a large-scale web application are fundamentally two different things, and demand two different approaches to development. Let ECMAScript/JScript/etc. stick around; it's sufficient for small-scale or casual needs. But if we're really talking about delivering large-scale, complex applications over the web, Javascript costs countless hours of productivity, and does limit the potential for what web applications might be able to deliver to users.
I'm completely in favor of creating a new language to meet the needs of tomorrow's web applications, provided that Microsoft and open source vendors work together in an open and honest fashion. This will only become a reality if all parties cooperate and make it a true standard. But on principle, yeah, Microsoft has the right idea on this one. (In my dream world, I would love to be able to deliver bytecode via HTTP, execute it in a tightly controlled sandbox, but still use the DOM as the UI delivery mechanism, but somehow I doubt that'll happen!!)
Re:Why not both? (Score:3, Insightful)
Or they could create a very basic, low level bytecode interface to a browser and the DOM and then have any scripting language JIT compiled to that low level representation... at the script-standard bytecode-native compilation stage you can use program transformations to move towards your browser's native structure
Go one step further and provide some helpful jit compilation operations and somebody could just say <script language="{http://www.me.com}myscript}"< and the browser could download a jit compiler. Hey presto, browser-independent scripting.
I leave the implementation as an exercise to the reader
Re:About Silverlight? (Score:5, Insightful)
.NET for client-side script (Score:3, Insightful)
Microsoft wants a new language for client-side scripts. Just-so-coincidentally, Microsoft has this new "language" ready to go for us. It's called
C#, VB.NET, J#. Whatever. Microsoft wants a
See Silverlight? That's the tip of the iceberg.
Open your eyes, people. This is Microsoft.
Re:I agree with MS (Score:1, Insightful)
It gets better if you start using the language features supported by Firefox, but not IE. Things like E4X, for example, make dealing with XML data trivial.
There are basically three problems with JavaScript as-is.
First, people (you included, apparently) seem to think of JavaScript in the way it was used back in '98 or so - basically no better than BASIC with C-style syntax.
Second, Internet Explorer's DOM. It's inconsistent, buggy, and makes things unnecessarily difficult.
Finally, Internet Explorer's implementation of JScript. Which is a pile of junk, almost impossible to debug, and has an irritating tendancy to crash the entire browser if you use complex scripts.
Obviously, upgrading IE's support for JavaScript would fix the latter, but there's no chance of fixing the second, and the former is simply a matter of perception (helped by IE, which fights you if you try to do anything useful with JavaScript).
Besides, Microsoft don't care about breaking the web - they care about breaking all the poorly written intranet apps (including their own, such as OWA) which rely on bugs in IE to work.
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.
Re:About Silverlight? (Score:1, Insightful)
Re:Either way... (Score:3, Insightful)
If you wanted to include an external *.py script, then yes it would be easy to control the whitespace and indenting as you would have the entire file created ahead of time.
But a lot of times your client scripting code is generated dynamically as a result of code running on the server (through Java, PHP, ASP, etc.). Often, these languages (especially tag-based languages like PHP or JSP) insert whitespace between different tags and it gets difficult to control their output precisely without doing works around the language. If that happens, your server script could put more or less whitespace than you intend into the dynamically generated *.py that would then execute incorrectly in the browser.
This gets even worse if your server code is not all generated in one block, but is assembled by a number of small blocks (like Struts/Tiles) as the small template that you are modifying may be included by another block (which is included by another) and if the indenting changes at the top level, you'll need to know and go find it in all the child levels to modify it.
Ever look at the source HTML to a lot of dynamically generated sites and wonder why there are odd patches of whitespace? Since it isn't (for the most part) significant in HTML, existing web server-scripting technologies have been built without necessarily caring about what it outputs. To suddenly need to care would mean re-working a whole lot of other tech just to make it work.
I'm not knocking Python or even its whitespace significance, but it definitely would introduce a huge problem for browser read scripts that weren't statically generated.