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."
It seems they could both radically improve javascript and add in support for additional scripting languages. It would come at the price of increasing the size of the browsers, but that seems a small price to pay for the increased flexibility for developers.
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!
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.
And the languages won't win either. Javascript will stall at its currently supported version as people strive for cross-compatibility.
[ think ]
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.
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.
Javascript, like HTML, has grown to handle tasks it was never envisioned or intended to do when it was first created, and that has tremendous implications in the security space (cross-site scripting, cross-site request forgery, etc). Why not just scrap the HTML and Javascript specs and start over with something designed with security in mind from the get-go? Swapping Javascript for Python or Ruby only means that we get to write/deal with exploits with more syntactical sugar. Let's fix the darned problem once and for all.
You want to give a website the ability to run client side perl?
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Do you really think it is a good idea to insert a whitespace meaningful scripting language (Python) into whitespace meaningless HTML? The level of indenting in HTML has no effect on the rendering, but change the indenting in Python and you've borked your script.
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.
"Embrace and Extend" not working, Microsoft goes with "Repudiate and Close".
I expect a Dilbert strip about this any day now.
668: Neighbour of the Beast
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
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
I seem to remember VBScript, it's a perfect example of MicroSoft's agenda and why JavaScript should evolve instead of fork. From a pragmatic point of view, there might have reason -- but it's clear that MicroSoft's agenda is neither technical, nor pragmatic. Image M$ advancing the same argument for forking Java into a new language when new functionality/semantics were planned? It's ridiculous.
My opinions are my own, but you may share them!
In which case we'll be right where we are now... with old JavaScript and the addition of some useless language. Microsoft always wants to make a new language. I'd absolutely vote for the improvement of JavaScript, it makes sense and all browsers can (theoretically) be relatively easily updated to support it. Additionally, developers are busy enough keeping up with the constantly changing landscape, we don't need *another* freaking language. There are plenty. Just add the features it needs and fix the bugs.
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.)
You are using English. Please learn the difference between loose and lose; they're, there, and their; your and you're.
Don't forget all the fun with JScript in Internet Exploder.
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.
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.
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.
.. but if you want another example of a language where tons of insecure and hacky cruft has accumulated over the versions, try PHP. Now there's a language that needs a complete restart if I ever saw one!
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
Quality, performance, value; you get only two, and you don't always get to pick.
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.
For fairly well-defined problems. GSM isn't a great cell phone standard, but it has allowed European cell phone manufacturers to take over the global marketplace while American cell phone companies with splintered standards have had to play catch up for more than a decade now.
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.
I have to agree with MS on this one. A radical update to Javacript has the potential to break more than I would care to think about. Major web applications can take months to simply test and years to design and implement! Major platform changes of this type are an unacceptable risk in the enterprise setting. Now, I fully agree that JScript is a horrible and broken implementation of the ECMAScript standard, but let's face it: JScript's own problems aside, Javascript as a language is not acceptable given what people are trying to do with the web. It was meant to provide limited dynamic capabilities to mostly static information delivery. That was yesterday, now let's take a serious look at today. I'm sorry if I'm offending any scripting fanboys, but weak typing, the lack of threading, the lack on non-prototypical OO features, the lack of a serious class library (including real data scructures), etc. all get in the way of delivering truly powerful client/server apps.
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!!)
-James
I can't believe that nobody's pointed this out.
.NET and the CLR.
.NET runtime in the browser. Probably a sandboxed one that can only access the DOM and browser. But you still get all the .NET benefits, like multithreading and bytecode compilation. And all the .NET drawbacks, like you can't implement it outside of IE because it's patented from here to hell and back.
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.
No, JavaScript is NOT a horrible language. It's a fairly standard dynamically typed language, with prototype-based OO, and a small set of simple, flexible datatypes. It's consistent. It's logical. As long as you're not after C++, it makes sense, especially for web site scripting.
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.
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.
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.