ECMAScript 4.0 Is Dead 168
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?"
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:Let's pull a Microsoft (Score:2, Insightful)
Why? There's consensus on Harmony.
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.
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.
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.
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.
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:Harmony is a good name.... (Score:5, Insightful)
Re:Establishing de facto (open source) standard ? (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:Crockford and Standards (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: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.
Re:Why is JavaScript is so popular? Lamda Function (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 to be useful.
Re:Establishing de facto (open source) standard ? (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 understand and use them.
Unfortunately, many of the people who write Javascript these days stubbornly identify themselves as non-programmers. They resist learning anything that smacks of a "real" programming language. There could have been an ugly struggle between people trying to force these features on web developers and web developers clinging to Javascript's current free-form dynamism. On the face of it, it might seem that web developers are just lazy to avoid learning a few new language features. It also sounds quite silly for them to say, "I'm a programming idiot; I can't write code," despite slinging around complicated DHTML, CSS, and Javascript. They're obviously intellectually capable of learning and using a "real" programming language for "real" programming.
I think their basic point is sound, though. The job of writing the Javascript for web pages often falls to the web designers, and they should be allowed to program in a simple and dynamic language that suits their artistic temperaments and lets them focus their minds on their creative specialties. They do have artistic design responsibilities that programmers do not, after all, so it doesn't make sense for them to invest as much time in learning about programming as programmers do.
Re:Establishing de facto (open source) standard ? (Score:1, Insightful)
I have to disagree; the summary isn't trolling. Looking behind the scenes it appears that Microsoft wanted to kill it so it wouldn't compete with Silverlight. (Notice how one of the things they said wouldn't be included 3.1 that was included in 4 was namespaces and packages. It was claimed that they weren't good for the web, but oddly they appear in Silverlight.)
Also, as far as Mozilla and Google being on board-this seems mostly due to the fact that Microsoft almost unilaterally killed 4 claiming they would never support it.
I'm disappointed. If you've played with AS3(based on an earlier draft of the ES4 spec) it allowed you to code in a more classical OOP fashion, but you still had access to dynamic language features that people love about JavaScript.
At this point, many, many people have attempted to graft a more traditional OOP framework on to JS(going so far as to abstract the prototype inheritance that exists with JS)-none of them have been completely satisfactory (which is why more keep coming out). The latest one of note was John Resig's which was somewhat decent.
I am tired of people saying "You can do anything with JS". While JS's dynamic nature makes the simulation of a wide variety of language features possible, it would be far better if some of these were standardized into the language itself instead of having everyone invent hacks for things that would be available in almost any other language. This does not lead to increased productivity or efficiency.
Re:Can I just point out (Score:1, Insightful)
The only aspect of a language that has anything to do with browser security is its security model. Are you trying to criticize Javascript's security model or are you just against browser scripting in general? If the former, please make a more specific case for how the security model could be improved, and if the latter, please make yourself clear, because it sounds like you have something against Javascript in particular.
Re:Why is JavaScript is so popular? Lamda Function (Score:2, Insightful)
Re:Crockford and Standards (Score:2, Insightful)
If you disagree with Crockford's opinions, the appropriate person to argue with is Crockford. I pulled out a quote to make a general point, one with which Crockford might not even agree, yet you don't seem to be too interested in talking to me.
Rest assured, the feeling is mutual.