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."
Re:Either way... (Score:3, Interesting)
Re:Either way... (Score:5, Interesting)
Multithreading! (Score:5, Interesting)
Opera is the Ron Paul of browsers (Score:1, Interesting)
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?
brand new language (Score:3, Interesting)
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? (Score:3, Interesting)
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 (Score:5, Interesting)
Language Plugins (Score:3, Interesting)
Re:Flash-bashing equivalent (Score:2, Interesting)
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! (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.
Re:Multithreading! (Score:1, Interesting)
Re: Unfortunately, Microsoft has a point (Score:4, Interesting)
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? (Score:4, Interesting)
Sure (Score:3, Interesting)
Re:Forgetting that it's Microsoft for a minute... (Score:4, Interesting)
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 (Score:3, Interesting)
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? (Score:2, Interesting)
Microsoft vs Mozilla (Score:2, Interesting)
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? (Score:4, Interesting)
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 (Score:1, Interesting)
<script type="application/ecmascript; version=4">
No need to change existing pages. There are many [gnu.org] implementations [intel.com] of C [microsoft.com] Oh [ironruby.net] look, [rubini.us] Ruby [google.com] as [xruby.com] well. [atdot.net]
Albatross. (Score:1, Interesting)
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]:
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? (Score:3, Interesting)
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.