Slashdot Log In
ECMAScript 4.0 Is Dead
Posted by
Soulskill
on Sat Aug 16, 2008 12:23 PM
from the long-live-ecmascript dept.
from the long-live-ecmascript dept.
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?"
Related Stories
[+]
Developers: MS, Mozilla Clashing Over JavaScript Update 521 comments
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."
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.
I'll wait for... (Score:5, Funny)
ECMA Script 3.11 for workgroups.
The joke works this time !
Re: (Score:2)
Re: (Score:3, Funny)
Dude, that joke is so 1993!
The current version is going from 4.0 to 3.5.9
Re:Establishing de facto (open source) standard ? (Score:5, Interesting)
The Microsoft stuff in the summary is just trolling. Mozilla and Google are both on board with abandoning the current work called ES4.
Parent
Re:Establishing de facto (open source) standard ? (Score:5, Interesting)
My opinion: I need a modern virtual machine with capabilities comparable with Flash/Silverlight applets and level of integration comparable with javascript engines shipped with browsers. Compatible across browsers. Language independent (I would like to program this in Python) - maybe with some kind of intermediate representation (bytecode?). Capable to run bigger, non-trivial apps. Well designed. Open sourced and not patent encumbered.
Currently there is nothing satisfying my wishes. Pure javascript has somewhat limited capabilities (especially in multimedia area) and isn't fully compatible across browsers. Flash is proprietary and doesn't work well on some platforms and is just an applet (not well integrated with the browser itself). Silverlight is proprietary and does not work well outside windows. Java applets - along with their bad integration with browser itself and huge startup overhead - are IMO examples of bad design. Any ideas ?
Parent
Re: (Score:2, Interesting)
No, no ideas, but ES4 was only going to give you about 1/10 of what you want anyway, so you don't lose all that much here.
it's the libraries and frameworks (Score:3, Insightful)
Any ideas ?
The problem with Java and the CLR in browsers are mostly with the libraries, not the virtual machines. So, I think the thing to do would be to start with, say, the CLR and develop an open applet environment and browser integration based on it. This environment could even be emulated in Silverlight, allowing things to run without any install on Windows.
Re: (Score:3, Interesting)
This environment could even be emulated in Silverlight, allowing things to run without any install on Windows.
Doesn't the CLR (as part of the .Net Framework) ship with Windows as of Vista?
Re: (Score:3, Informative)
http://www.sproutcore.com/ [sproutcore.com]
Re: (Score:2, Interesting)
I haven't looked into SproutCore much, but isn't it just a framework built around JavaScript? If that's the case, how does that solve the multimedia part of the GP's request?
Re: (Score:2)
What does the zillionth javascript framework have to do with his (legitimate) request?
Besides sproutcore looks less than impressive, even by javascript metrics. It took ages to load, yet the few available widgets feel sluggish under linux. Oh and ofcourse the layout blows up when changing font-size...
Re: (Score:3, Interesting)
I have an idea. I'm working on it.
My initial idea I laid out here [screamingduck.com]
Since writing that I became aware of quite a few things also exploring this area. I'm currently putting together a proof-of-concept plugin using vx32 [wikipedia.org].
It should be possible to make something speedily executable on non-x86 with just a few restrictions and a bit of instruction-metadata.
Importantly. The spec is much simpler than any existing VM model so an open spec with multiple implementation methods should be quite feasible.
Re: (Score:3, Informative)
> My opinion: I need a modern virtual machine ==> Java ... check
> with capabilities comparable with Flash/Silverlight applets ==> Java ... check
> and level of integration comparable with javascript engines shipped with browsers. ==> Java ... check
> Compatible across browsers. ==> Java ... check
> maybe with some kind of intermediate representation (bytecode?). ==> Java ... check
> Capable to run bigger, non-trivial apps. ==> Java ... check
> Open sourced and not patent
Re: (Score:2)
Mozilla and Google are both on board with abandoning the current work called ES4.
In particular a very curious choice on Google's part, whose GWT implements Java on browsers.
The current decision is that we don't need ES4 as we don't need packages, namespaces, classes, early binding and types on a web language.
Makes you wonder how GWT happened then.
Re: (Score:3, Insightful)
I think their primary roles would have been for basic libraries, for generated code such as SOAP bindings, and other code that ordinary web-developers would not write. They would work quite well for that and allow better robustness and possibly better performance (less dynamism -> more JIT compiler optimizations) for core functionality like parsing XML and drawing graphics.
The only way I can imagine that those features are "unsound for the Web" is that ordinary web developers would not bother to underst
Re: (Score:3, Insightful)
>The Microsoft stuff in the summary is just trolling
That is true because MS actually voted for more security of an individual's IP rights than what ECMAScript 4.0 offered. One problem for example, under ES4, is that containers of code may also contain code that is owned by someone that never gave permission to distribute code. ES3.1 is not a solution, but it achieves that some desired advancements without a greater lack of security in a trade-off.
Re: (Score:2)
isn't that how .dlls have worked for years. Pretty much any dll can call any other one. Isn't that the basis of how things like scrip-o-licous and prototype work, allowing your pages to bind into the common javascript. Javascript is a DOCUMENT scripting language, not designed to keep the user or user agent from knowing or reusing the code.
Microsoft and Adobe are not being genuine here... the only way to implement what they want is in complied languages... like .net or Flash... gee imagine that.
Re: (Score:3, Funny)
Slashdot: News for Trolls. Memes that Matter.
ES4 not dead (Score:5, Informative)
It's not dead. There will eventually be a Fourth Edition of ECMAScript, it just isn't the focus now. The ES4 proposal wasn't ever enshrined as the actual Fourth Edition either.
I was really skeptical about the concessions made by the ES4 side before I listened to some of their rationale; it wasn't so much concessions to the 3.1 side, it was that the things they were dropping didn't adequately solve the problems they were put in to solve.
There's a great talk about it here: http://openwebpodcast.com/episode-2-brendan-eich-and-arun-ranganathan-on-ecmascript-harmony [openwebpodcast.com]
Re: (Score:2)
And it wants to go for a walk.
Re: (Score:2)
And notice that the adoption of scripting of web pages are slow in order to allow the web pages to be useful even on older browsers.
Most of the functionality in JavaScript 1.5 is sufficient for what you normally want to do.
The only problem is that JavaScript/ECMAScript from a language point of view isn't really good. A strongly statically typed script language would have been better since it would have allowed the developers to catch a lot of bugs that now occasionally blows up in the face of the users.
Re:ES4 not dead (Score:5, Insightful)
The only problem is that JavaScript/ECMAScript from a language point of view isn't really good. A strongly statically typed script language would have been better since it would have allowed the developers to catch a lot of bugs that now occasionally blows up in the face of the users.
That would be the worst possible thing to happen to Javascript. I know, I know... let's not get into a religious war over static/dynamic typing. There are valid points for each in different contexts, but a language in Javascript's problem domain is probably one of the worst contexts for static typing.
Keeping the language small, clean and simple should be the priorities. If you want Java in the browser, well... that's already available.
Parent
Harmony is a good name.... (Score:5, Insightful)
.
It is good to see the standards committee taking a breather from major new features, and instead focusing upon the alignment of behavior of functionality across the various browsers.
Hopefully, there will be a robust and rigorous compliance test suite as a deliverable of this standards process.
Re:Harmony is a good name.... (Score:5, Insightful)
I would disagree (to some degree) that more features are in fact needed. For example, E4X (and a native XML doc object) being standardized in the browsers would be a huge benefit.
That being said, I think that a lot of the feature bloat going into the proposed v4 was really not all that great. I think this is generally a step in the right direction.
Parent
Re:Harmony is a good name.... (Score:5, Insightful)
Quite so, a lack of standardization amongst the implementations has been a serious problem for years. Allowing developers to use the entire spec as is without fear of problems going between browsers would be a huge step forward for JavaScript.
Perhaps add in a few fixes for annoying parts of the language and similar, but overall if it's just made to be consistent across browsers, that would go a long ways.
Parent
Re: (Score:2)
YES! But the next revision...
1) They NEED to release a long list of test cases that can be run against implementations.
2) How about having toString() output JSON? (at least specify exactly what it should output.)
If anything new:
Access methods for Object():
Allows a function to monitor read/write/exec of an object's properties (EXTREMELY useful for client side patching of implementation bugs.)
A Console object loosely modeled after FireBug with a focus on unit testing. Implementation optional; b
Re:Harmony is a good name.... (Score:5, Insightful)
Parent
Re:Harmony is a good name.... (Score:5, Informative)
"What is needed in the JavaScript world is not more features, but more consistency of implementation across the various browsers."
With the exception of a few later-added methods (on Array for example), that's already there. The inconsistency is in the DOM, and that's not something ECMA covers.
Parent
I'm skeptical (Score:3, Funny)
Crockford and Standards (Score:5, Informative)
I invite everyone to read Douglas Crockford's latest post on the YUI blog entitled: The Only Thing We Have To Fear Is Premature Standardization [yuiblog.com]
He gives some insight into how ES4 got to where it is today and its impact on standards in general
Re: (Score:2, Insightful)
This was the sentence of Crockford's post that really leapt out at me:
That's generally true of standards committees. When they're documenting existing practices and seeking consensus and convergence between them, they're in their element. When they decide they can start inventing, rather than consolidating, they lose the plot altogether...
Re: (Score:3, Informative)
That line was about HTML5, which is absolutely ridiculous. The things that the WHATWG and W3C have added to the HTML5 proposal are one or both of the following:
- formalized semantics already informally in use as classes and ids (like the section and nav tags);
- behaviors already in use, drastically simplified (like Web Forms 2.0).
They didn't really "just make new stuff up", they're making the language and environment much more powerful, with real world use in mind. Both types of feature additions make devel
ECMAscript 4.0 is dead (Score:2)
Long live ECMAscript 5.0!
What a damn shame (Score:4, Insightful)
Such a damn shame to let ECMAScript edition 4 go in this way.
The small shame is for Adobe's efforts, who entered the ECMA standards body to contribute, donated the entire engine to Mozilla and plenty of other efforts to get this going. But AS3/Flash will not be affected in a big way from this.
The web community as a whole will be. That's where the big shame is: for all of us, web developers. I see that packages, namespaces, classes and early binding are out, likely forever.
Classes are not "sugar", we do need those paradigms when creating bigger applications, because they are more rigid, more readable, more maintainable, understandable. I love lambdas, prototypes and all that, but that's the lower level, the implementation inside a class, inside a package. Those are not interchangable paradigms.
ES4 and AS3 have managed to add those higher constructs to the language, while maintaining full compatibility with all flexible features of ES3 (the JavaScript currently used in browsers).
The reasoning behind dropping all constructs appears to be the preconceived notion that JavaScript must exist in the form of disparate text files loosely connected to each other, something that doesn't scale to bigger efforts at all (and which makes Flash much more viable for such deployment), hence packages and early binding are out. What a mistake.
Who's to say we won't see JAR-like environment where bigger libraries can be compressed together, and some preprocessing can be done to ease the load on the client CPU/bandwidth? I've been praying we get such deployment option soon as a modern web application typically has to download a ton of CSS/JS/image files to build an average GUI nowadays. Why isn't this the focus of ECMA's efforts, but instead the focus is to maintain the status quo and reject us basics that have proven themselves in time to work well in all environments out there.
If you doubt this would work, look no further than Java/Flash applets distributed over the web in this fashion (and Flash is very widely used nowadays).
What ECMA has achieved with their decision, is to basically stagnate the browser environment, and empower third-party cross-browser plugins to eat more from the advanced web application market share, because Adobe's Flash, Microsoft's Silverlight are not even thinking of dropping their mature OOP features, just because ECMA said we don't need them.
Re: (Score:2, Informative)
With a good build/deployment script you can combine all of your CSS and JS files together, giving the advantage of better compression and less HTTP requests. If you have it set up in that way, you can split your script into as many files as you want.
Images are a bit different, you can't do much outside of spriting where you can.
This is not to say a JAR equivalent wouldn't be preferred, just that there are things you can do today.
Classes are not out of the question. (Score:3, Informative)
Classes are syntatic sugar. That's what the working group found, when it discovered that most class-centric features can be boiled down to simpler APIs such as .freeze(), .defineProperty(), &c., all of which are being implemented in ES3.1. Classes, then, would only be user interface to what can already be implemented using these features.
ES-Harmony is about standardizing new features that already work in (three out of four) major browsers, without changing the syntax of the language. Brendan Eich of Moz
Re: (Score:3, Informative)
Seriously, RTFA.
This thread's title is totally misleading. In fact, the summary is wrong. ES Harmony is NOT ES3.1. And of course, there's the anti-MS slant as usual, but no mention of Yahoo, which was also against ES4. Good ol' /.
So just in case you're too lazy to read the article, here's a quick summary:
ES Harmony is just an ES4 that the ES 3.1 guys agreed to work on after ES3.1 is out the door, while the ES4 guys agreed to work together with the ES3.1 guys on ES3.1. So ES Harmony (which could be ES4 o
A real pity (Score:5, Insightful)
Oh well; Microsoft scores one here, considering that Silverlight 2.0 will be scriptable using Python and Ruby out of the box.
By the way, the whole fuss about MS being behind this is pretty stupid and unfounded. MS was actually one to jump on the ES4 bandwagon early, along with Adobe - their early implementation of it was called JScript.NET, first released in 2002 with .NET Framework 1.0, and it does in fact still ship with all versions of .NET, and is an officially supported .NET language. They certainly wouldn't have any trouble extending it to the more recent spec, should it become standard. Now, I guess it will just be quietly dropped in the next version of the framework.
Re: (Score:2)
I agree that packages are not generally useful for the web, but why not keep it as a language feature. Mandate that a parser accept it, but perhaps only mandate that core packages be supported, and that an implementation does not need to provide a means to add additional packages.
I really don't understand the AS 3.0's "namespace" feature. That looks like access specifiers to me.
The packages feature sounds more like C++'s namespaces to me. (Although C++ classes are also (effectively) namespaces, to the point
Re: (Score:3, Informative)
JS was never "lightweight" in any sense of the word - neither in terms of language features, nor it terms of performance of typical implementations. If you want a truly lightweight scripting language, designed as such, see Lua.
Why is JavaScript is so popular? Lamda Functions (Score:2)
Although JavaScript is not very good as an application language, it can do some really neat things which makes it very interesting to language nerds which is why it is so popular.
One thing is that functions are also objects which means they can be returned and taken as parameters by other functions. This is called lambda coding. Function pointers do not allow you do to quite the same thing since they can't be dynamically generated and modified. It makes certain kinds of mathematical programming very easy
Re: (Score:3, Interesting)
JavaScript is popular only because it exists in almost every browser since a long time ago. This means that if you code something for a browser in JavaScript you know that it has a reasonable chance to work for the most commonly used browsers.
The use of JavaScript outside the environment of browsers is very limited, and exists only in specialized applications where it may be useful to have a script language. But then it competes with other script languages like TCL/Tk.
Re: (Score:3, Insightful)
In my case, I really didn't START to like Javascript until I began to read up on it's functional capabilities.
I think there is more to Javascript's popularity than what you say. It is actually a fairly nice little language, and hopefully when a few annoyances are cleaned up in version 2.0 it will be used outside the browser more and more. In fact, anyone who has done some serious Mozilla application programming with XUL realizes that there is no reason Javascript must be restrained to a web browser context
Re: (Score:2, Insightful)
Why? There's consensus on Harmony.
Re:Can I just point out (Score:5, Interesting)
[Can I just point out] That Javascript as a development platform, as it seems to have become, is evil. It's just horrible from an efficiency, performance, security and architectural point of view. It seems to be the future.
You can point that out, but you'd be wrong. JavaScript hasn't recently "become" anything. The last major revision that all browsers supported was in November 2000.
It is a beautiful, expressive and quite powerful language that is just now starting to shine after years of being misunderstood by people like you.
Parent
Re: (Score:2)
Re:Can I just point out (Score:5, Interesting)
OOP !== Class based OOP
JS isn't a class based OOP language, it's prototype based OOP language - the two are _very_ different. I can understand why it's a pain in the neck. It's also a pain in the neck to force a square peg into a round hole, but is the blame on the person who made the square peg or on the person whom thinks that the square peg should indeed be able to be put in the round hole?
Parent
Re: (Score:2)
I agree that JavaScript/ECMAScript is horrible, but it's what we have.
At least it's not as horrible as VBScript.
But I sure would like to have had a language with strong static typing, which in effect would have made it very similar to Java. By doing this we would have had at least some bugs straightened out before deploying to a large number of users.
The inconsistency between browsers is also a catch, but it could have been a lot worse.
Re: (Score:2, Troll)
exactly what Microsoft is doing its best work to cause. Javascript and all the tech in AJAX which allows application-like browser-neutral pages is a massive threat to Microsoft's income.
I don't know what Microsoft had to do with this but their position on any industry committee is purely to find ways to either stall the project or make sure they have ways to dilute it on Windows. They have no other reason or purpose. IMO.
LoB
Re: (Score:2)
and this should not surprise anyone. Cross platform technologies are a threat to Windows and since over 80% of Microsofts profits come from Windows, cross platform technologies are a threat to them. So don't wonder why Microsoft keeps pushing stuff which only works on Windows or pushes for things which slow down adaption for open standards.
LoB