Slashdot Mirror
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."
Opera's Haarvard suggests that it's about Silverlight, 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...
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.
Gentoo Sucks
There needs to be a third pary arbitrator here.
And hopefully that arbitrator tells them all to just STFU up and use python
NewslilySocial News. No lolcats allowed.
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!
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.
more of the same on Twitter.
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.
Star Pirates
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.
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?
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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.
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?
Because HTML and javascript
- 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.
\u262D = \u5350
And hopefully that arbitrator tells them all to just STFU up and use python :).
Yes, a language that parses whitespace like Python does would be great for client-side scripts run from a web browser.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
Purely for syntactical reasons. At the risk of ticking somebody off, I really dislike VB's syntax.
Javascript is in no way comparable to XUL. XUL is an XML layout dialect, JS is a programming language.
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.
Climate Progress - Hell and High Water
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 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.
That's exactly it. Some people are fond of saying "You know, it was actually Microsoft who invented AJAX because they had XmlHttpRequest() first" but if Microsoft had known that they'd be enabling a general-purpose platform for application delivery -- one that doesn't require Win32, or even a full desktop computer at all -- they'd have found another way or not done it at all.
Tired of FB/Google censorship? Visit UNCENSORED!
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, 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.
Yes you can make browser updates mandatory, by simply refusing to support the old ones. ( all hail Cthulhu )
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.
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.