There’s been some turmoil in the world of ECMAScript.
While many are – even, at least, vaguely – familiar with the development of ECMAScript 4 the devil is in the details. I’ve blogged about ES4 extensively in the past – and even did a speaking tour last fall educating developers about its details and implementations, however, a lot has happened since that time.
The ECMAScript 4 specification development was very ad-hoc in nature (primarily tackled by Adobe, Mozilla, Opera, and Google): Implementors agreed upon a set of features that they wished to implement and a specification was molded out of the remaining consensus. Building a specification tailored by implementation is a very pragmatic means of reaching a reasonable result.
However there was a fundamental split related to how much of the specification should be implemented. Enter ECMAScript 3.1. This working group (lead by Microsoft and Yahoo) set out to implement some minor changes and bug fixes to ECMAScript 3 while remaining as a subset of full ECMAScript 4 functionality.
These two groups continued to work side-by-side but a struggle was inevitable. The ECMAScript 3.1 group wanted to add changes to the language that would affect the result of ECMAScript 4. This struggle over the past year finally came to a head this past month at the meeting of TC39 (the committee responsible for both ECMAScript 4 and ECMAScript 3.1). Dubbed “the Oslo meeting” this discussion between the two groups saw an ultimate conclusion: The two efforts had to be merged, otherwise neither one would succeed.
The result was a set of concessions and a re-focus on simplicity and pragmatic language additions. Brendan Eich detailed the result in a lengthy email to the ECMAScript 3.1 and ECMAScript 4 lists.
The important part is the new set of goals for this, now dubbed, ECMAScript Harmony project:
- Focus work on ECMAScript 3.1 with full collaboration of all parties, and target two interoperable implementations by early next year.
- Collaborate on the next step beyond ECMAScript 3.1, which will include syntactic extensions but which will be more modest than ECMAScript 4 in both semantic and syntactic innovation.
- Some ECMAScript 4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.
- Other goals and ideas from ECMAScript 4 are being rephrased to keep consensus in the committee; these include a notion of classes based on existing ES3 concepts combined with proposed ECMAScript 3.1 extensions.
This means a couple things: First, you can forget a lot of what you learned about ECMAScript 4, previously. Many of the complicated concepts contained in the language have been tossed. Instead there is a considerable amount of effort going in to making sure that new features will be easily duplicable through other means.
For example, ECMAScript 3.1 provides a new method – called Object.freeze() – which allows you to pass in an object and “freeze” it, preventing it from being modified any further. This is a subset of the functionality that is needed to implement classes in ECMAScript 4 (classes are immutable).
This means that classes will be a part of the new language but they will be defined as simply being syntactic sugar for a series of plain methods or conventions (such as using closures and Object.freeze to create a Class-like experience). Making sure that complex concepts break down into a simplified form will serve users well – giving them a considerable amount of leverage in using the language.
There is still some debate surrounding the remaining features of ECMAScript 4 – such as type annotations or if classes should support inheritance (and if they do, should the utilize the existing prototypal form of inheritance). A lot of this will become apparent over time.
The process that’s gone into developing ECMAScript 4 is being adapted to suit ECMAScript 3.1 development as well. This means that there will be a runnable reference implementation for the language (with as much of the language written in the language itself, as possible – self-hosting code is quite cool).
Probably the most important development within all this is the codification of existing de-facto standards. For example, the concept of JavaScript getters and setters (implemented by Mozilla, Apple, and Opera) are going to be quickly fast-tracked into the specification (in the case of getters and setters they already have been). Seeing real-world code quickly make a bee-line for standardization is truly heartwarming. We’ll probably see more of this for topics like ‘let’ and ‘expression closures’ – but which will arrive post-ECMAScript 3.1 (since they require new syntax).
There is still a significant amount of work left to do (both in the realm of specification and implementation) but there has been some important progress made here. Seeing an agreement between all of the largest players in the ECMAScript space (Mozilla, Microsoft, Apple, Opera, Google, Yahoo) is quite historic and will stand to serve users well.
—
I will be doing another Open Web Podcast tomorrow with Dion Almaer, Alex Russell, Brendan Eich, and Arun Ranganathan where we will be discussing ECMAScript Harmony.
Richard D. Worth (August 13, 2008 at 7:28 pm)
Considering the alternative, this is quite a positive outcome. How very refreshing. And we have two big versions to look forward to :)
One of my favorite parts learning about ES4 last year was the self-hosting bit. Glad the goal is to do that with 3.1 as well. Thanks for the info.
David Brewer (August 13, 2008 at 8:03 pm)
Isn’t ActionScript 3 largely based on the ECMAScript 4.0 draft? Wonder what Adobe’s plans are for bringing the world of Flash back in line with where the standard is headed.
John Resig (August 13, 2008 at 8:09 pm)
@David Brewer: That’s definitely not clear. ActionScript 3 is based on a very different ECMAScript 4 draft, though – one from 1999. The current ECMAScript 4 work is an extension of that (supported by Adobe) and would’ve become ActionScript 4. However, the new ECMAScript 3.1 and Harmony proposals are not compatible with ActionScript 3/4, at all. The committee acknowledges this and it’s unclear as to what will happen because of it.
Question (August 13, 2008 at 9:12 pm)
Then, what’s relation between Mozilla and Adobe on the EMCAScript side in the future? TamarinTracing will be replaced by TraceMonkey? If adobe based on es4 or what ever, how could we collabarate on the VM?
—-
There is a lot of work took place in the last year, would it be wasted?
John Resig (August 13, 2008 at 9:33 pm)
@Question: I don’t think the relationship is changing, at all. Work is still being done on tracing technology, compiler work, and on Tamarin. Obviously the language will be changing but that doesn’t really affect what’s already done (ActionScript may just become a different language, divorced from ECMAScript – I’m not sure). Collaboration on the VM still takes place, where appropriate (especially in relation to the tracing jit) – we’ll have to see what else occurs.
Brendan Eich (August 13, 2008 at 9:37 pm)
@John: ES3.1 is not *incompatible* with AS3, in the sense that it does not redefine class, package, namespace, type annotations, etc. incompatibly — ES3.1 doesn’t add any of those things, of course. It adds little new syntax (new only to IE, really), and it adds library methods (Object.freeze, etc.). These could be added to an AS4.
As you say, the future is not clear. However, whatever harmonized successor edition TC39 does produce, which might be called ES4 in time, it will probably be tracked by ActionScript. The Adobe guys want to keep up with the standard, so long as it doesn’t actually conflict. Stuff like namespaces will remain ActionScript extensions.
@Question: there’s a lot going on, again crystal balls are cloudy. But lots of folks at Intel, UCI, Adobe, and Mozilla (and elsewhere) are collaborating on Tamarin Tracing. Its nanojit is in TraceMonkey.
/be
Brendan Eich (August 13, 2008 at 9:40 pm)
@Question: forgot to respond to your last line: I’ve said that the successor work will not start from a clean slate, and others in TC39 at Oslo said positive things about many ES4 (JS1.7/1.8) additions, including let, rest/spread (…), destructuring, expression closures, and generators.
So don’t worry, not everything is wasted and much will be conserved with appropriate adjustments, in my opinion (crystal ball, partly, but also Harmony principles including de-facto standardization of what’s in JS1.7/1.8).
However, as I noted in my message to the lists, namespaces, packages, and early binding are definitely gone.
/be
Justin Meyer (August 13, 2008 at 10:04 pm)
This is very exciting. This is the type of attainable progression I think many developers were looking for.
Ben Dalton (August 13, 2008 at 11:34 pm)
John, thanks for the informative post. Brendan, your clarifications regarding Harmony’s impact on ActionScript were very helpful.
I’m glad to see Harmony’s continued focus on what’s suitable for the web. Hopefully we’ll see 3.1 sooner with this renewed focus.
It is hard to recognize a need for a change in direction and harder yet to actually make a change. Kudos to TC39 for coming together to work in a unified fashion.
Question (August 14, 2008 at 12:45 am)
@John: It’s great to see JS and AS will merge to one script with different script host. But it seems that this is NOT available in a long term. Really disappoint. Collaboration on the VM may only stay at nanojit.
@Brendan: I just think JS2/ES4 with js-ctypes is a great opporunity to make it as a first class programming language just as perl/python do. Well, I think it’s also needed for Moz2 as it’s the glue of the whole platform. Any performance or what ever inprovements will do good to the whole mozilla community. So what about enable the kick-ass es4 for chrome developer? I think M$ just don’t care about the future of ES, they focus on C# and Silverwhat. As the next generation browser, moz2 must be strong enough in multimedia (script, SVG and …).
Tobie Langel (August 14, 2008 at 1:09 am)
That’s great news. Thanks for sharing, John.
simon j (August 14, 2008 at 1:30 am)
Packages and namespaces are out. But how about a module system like Python’s. Which can also simulate a package/namespace via directory structures. And possibly zip up a directory structure for easy transport across the web.
Behrang (August 14, 2008 at 2:10 am)
In my opinion not only packages, but also being able to use multiple versions of a JavaScript library is a must-have for today’s Web projects.
Poral Servers, for example, aggregate different portlets developed probably by different vendors into one cohesive Web application. A portlet might use jQuery, another portlet might use Prototype. Also one portlet might use version x of jQuery while another might use version y. even in small Web applications one might want to use two different JavaScript libraries simultaneously
Currently lack of “module” support, as in OSGi, makes aggregation of different portlets a nightmare.
I don’t get it why packages are not suitable for Web. So why Flex, Silverlight, and JavaFX all support packages?
Also variable definitions should be lexically scoped.
Well, that’s my 4 cent s ;)
Andrew Wooldridge (August 14, 2008 at 9:12 am)
This is very encouraging news. It seemed like the spec was becomming unwieldy. I look forward to this more practical approach.
Jason C (August 14, 2008 at 11:09 am)
Should I throw out my ActionScript 3.0 Cookbook?
Zach (August 14, 2008 at 11:56 am)
*sigh of relief*
Now, is there a way to define non-enumerable properties?
John Resig (August 14, 2008 at 12:25 pm)
@Jason C: I don’t think you should worry that much. Due to the changes it’s very likely that ActionScript will simply become a superset of the ECMAScript language (in which they continue to add features like packages, classes, etc.). I think you – and the many other ActionScript developers – will be safe.
@Zach: Yep – there’s a way to toggle the enumerability of properties in ECMAScript 3.1.
Jean-Philippe Martin (August 14, 2008 at 12:46 pm)
@to Brendan and John : I’m a Javascript newbie but I find it a much better solution for the longterm than Adobe AIR or Microsoft SilverLight (or even Java/JavaFX). Based on your differents discussions and meetings, do you think that Microsoft will implement the lastest ECMAScript in the next version of their browser : Internet Explorer 9 ? Could MS block the next Javascript to promote their Silverlight platform ?
Thank you in advance for your advice.
Kevin (August 14, 2008 at 1:55 pm)
I’m still sad that E4X won’t be in ECMAScript vNext.
Brendan Eich (August 14, 2008 at 2:50 pm)
@Question: Mozilla will continue to evolve JS toward JS2, which may even correspond to a 4th Edition. ES4 is a bit of a scare-word for some, and definitely overloaded or ambiguous, so we’re using the ES-Harmony name for now. Whatever the Edition number and the future standards that emerge, we’ll keep advancing JS in Mozilla’s platform.
@Behrang: see @simonj’s comment. A module system is important, and we will work on one for Harmony. But packages were never a module system, they were a kind of super-namespace notion (two namespaces, public and internal) with extra syntactic features (and misfeatures, like mx.foo in AS3 being a package name that can shadow a local variable mx with property foo).
JS in the web browser has the script tag for some of its module system needs, and standards bodies are loathe to mix the URL-naming and the synchronous vs. asynchronous issues up between Ecma and w3c. My opinion is that the core language should provide something close to PLT-Scheme’s module system, with provide/require and simple module naming that fits into ES3.1 and Harmony (no namespaces), and that we should leave the filesystem- or URL-addressing and loading to the host environment.
@Jean-Philippe: I have no idea about Microsoft’s product plans, you’d have to ask them. Since 3.1 is not done, they haven’t implemented it in IE8, although I understand that JSON.stringify/parse are coming in beta 2.
Harmony means everyone on the committee is on the hook to work on not only 3.1, but a major successor (major meaning new syntax at least, probably stuff from JS1.7/1.8). In the best case this means vendors will compete to show prompt and faithful implementations of finished standards, as well as previews for testing draft-spec features.
/be
Hannes Wallnoefer (August 14, 2008 at 5:20 pm)
@simonj, @Brendan: It is quite easy to implement a perfect python-like module system with JS 1.x, provided you are able to load scripts and manipulate the prototype and parent scope of objects. In fact this is what we are doing with Helma NG, a server-side web application framework, using the Mozilla Rhino JavaScript engine. The trick is to simply load each script into a new, dedicated scope object which has its parent scope set to null and its prototype set to the actual global scope.
That way, scripts are perfectly isolated from each other and confined to their own private scopes, interacting with other scripts only through the modules they explicitly import.
Now imagine if this became standard and supported by all browsers. Finding mechanisms to set up namespaces and avoid name collisions would suddenly stop being an significant part of writing a JavaScript library or application.
Since this feature requires no significant change to the JS engine, wouldn’t this be a candidate for ES 3.1? All ES 3.1 had to do was define a set of import* statements (or even just functions like Helma NG does, if adding keywords is a concern) and I bet browser developers could implement this within hours or days.
Dan Smith (August 14, 2008 at 6:51 pm)
I’m glad to see the level of interest about ActionScript!
Brendan’s comment pretty much nails where we’re headed with ActionScript — it’s too early to know what will be in Harmony, but Adobe will track the specifications and likely implement what doesn’t conflict. But no promises until we know what’s coming. And we’ll absolutely not be pulling classes, packages, etc out of ActionScript.
@Question: Harmony doesn’t change our working relationship on Tamarin at all. Tamarin can support multiple language variants — it was already going to support SpiderMonkey(JavaScript) and Flash Player (ActionScript).
@Jason C: Don’t throw out the AS 3.0 Cookbook! Today’s announcement doesn’t affect the current definition of ActionScript at all. Innnovation typically leads standards and AS has done so for years — conditional compilation, vectors, classes, etc are available today.
Dan Smith
Adobe, Tamarin Module Owner, AS Engineering
pd (August 14, 2008 at 8:45 pm)
Wouldn’t it be nice to see version numbers align as well?
Is there any reason the next version of ActionScript can’t fall into line with ECMAscript 3.1 both in naming and spec?
davey (August 14, 2008 at 10:11 pm)
Any news of Object.noSuchMethod support?
William J. Edney (August 14, 2008 at 11:18 pm)
As the original requestor back in in 2003 for what became ‘__noSuchMethod__’ in Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=196097
and as an extensive user of said function (polymorphism rocks ;-) ), I’ve been curious as to whether it was going to make it into ES3.1. Obviously, if it becomes part of the standard, renaming to just ‘noSuchMethod’ (without the underscores) would be appropriate.
For those who are curious, my rationale for needing such functionality is as relevant today as it was 5 years ago and can be found at the top of that bug.
In fact, now that the dust has settled for a bit, my business partner Scott and I would like to know if there’s a formal mechanism by which we can suggest it to the ES committee for inclusion into 3.1. We stand by to help with writing tests (there’s a good testcase attached to the end of that bug) or specification bits, if necessary.
Any takers here to help? Brendan? Crock? John R.?
Respectfully,
– Bill
Dennis Bell (August 14, 2008 at 11:52 pm)
I must confess I’m very dissapointed at this turn of events. Yes, it’s great that two groups have come together to form a concensus and are all “buddy-buddy”. How heart-warming – we now all get along. Too bad we have had to lower our goals.
The point of this new version was to enable programmer to treat JS like a *real* language, because it has been sorely lacking in many aspects up til now. ECMAScript 4 was going to free us to do great things. Steve Yegge even hinted at it being the Next Big Language: http://steve-yegge.blogspot.com/2007/02/next-big-language.html — that’s unlikely now with its committee-induced castration
Sorry if I sound bitter, but I’ve been waiting for a while for this, like many people. While I admit that I’m not fully versed in what had been comprimised, I am utterly shocked at what I have heard. For example, determining that packages and namespaces are “deemed unsound” for the web!!?? That is so — words fail me — but stupid is close to what I want to say! Every modern language of note supports ways to isolate libraries, and libraries for programs running inside a browser have the same needs of not colliding. Why do you think all the systems that cropped up because javascript failed at addressing the full needs of web programming (Flash, Flex, Silverlight) have namespaces??!!
And don’t tell me its because it’s running in a browser. That is a lame excuse. When windowed operating systems came out and the programs had to share runtime and screenspace, did we create a dumbed-down language to run in these windows. No, we still used C and added powerful libraries to enable use to do what we needed. (Well, actually we did — VB, and it allowed millions to write really bad, slow programs – sound famiar?)
That being said, I love JavaScript and have been a long time proponent of using it, in its limitted abilities, instead of the above mentioned alternatives because of its ability to run without plugins and near universal, if not interoperable, inclusion on all browsers. But this might be the last straw to push me to Flash/Flex — at least Adobe knows what coders need. I know this rant hasn’t been stated with the greatest elegance, and probably contains spelling errors, but I’m just too pissed off to care…
Question (August 15, 2008 at 1:37 am)
@Dennis Bell
I fully understand your feeling.
Lower our goals == hello, silverwhat
M$ never wanna see a powerful JS, indeed.
Maksim Lin (August 15, 2008 at 1:37 am)
@Dennis: Did you even bother to read the other comments?
Hannes comment clearly shows how you can have library code/module isolation without having to resort to introducing explicit packages or namespace features.
As he said, he’s implemented it quite easily (though the idea itself I think is really clever!) with Rhino for Helma NG and I’ve personally found it works really well.
@Brendan: Could you comment on the chances of getting the “private scope” module loading technique into ES3.1?
As a previously out spoken critic of ES4 I think its great that the committee has come to a compromise to move forward with the ES-Harmony. But I’ve also myself changed my opinion somewhat and realised that some features are worth adding to make js coding a more pleasant and productive experience, despite the added complexity to the language.
Question (August 15, 2008 at 1:40 am)
@Brendan
“We’ll keep advancing JS in Mozilla’s platform.”
——
Thanks for your promise!
Dennis Bell (August 15, 2008 at 2:33 am)
@Maksim Lin: The point I take with Hannes’ comments is that there is a certain amount of ‘trickery’ needed to get things done in JS that would be considered core functionality in other languages.
“Finding mechanisms to set up namespaces and avoid name collisions would suddenly stop being an significant part of writing a JavaScript library or application.”
When the simple act of loading a library is a “significant part of writing” an application in your language, where in most languages its a single line, you know your language is broken.
You talk about adding complexity to the language as a negative, but I think adding complexity to your code to overcome the simplicity of the language is far worse.
Maksim Lin (August 15, 2008 at 3:06 am)
@Dennis: No my point is that with a simple *implementation* change to the language in the current JS you can get the functionality you want without introducing alot more new features and complexity language.
Its not trickery in terms of *your* code – what Hannes has implemented DOES require a change in the language implementation and semantics, just like other new features in JS 1.5/6/7/8 like getters/setters.
Please have a look more closely at Hannes comment and work. Basically you achieve it all with just a simple:
importModule(“foo”);
in *your* code.
Now isn’t the above much easier to “get” then all the new namespace stuff that was being put up for the ES4 spec?
Graphex (August 15, 2008 at 3:13 am)
@Dennis: Absolutely. I can’t see how the compromises are anything but political, and I hope that I’m never forced to trick a class into being ‘self contained’ simply because these ‘leaders’ failed at their task of defining innovations which are useful to us all.
To me this represents a significant opportunity for Adobe et al to clarify their leadership role in promoting standards which are better for the majority of programmers who are actually using the language. Mr. Smith’s comments to that effect are heartening and demonstrate that Adobe’s vision is one which I, as a programmer, appreciate better than those who want to so severely limit the capabilities of the language.
simon j (August 15, 2008 at 5:30 am)
Well said Dennis. Brendan has made the same point repeatedly.
importModule(“foo”); looks good. But it, or something similar, needs to be standardized so every js runtime includes it and it does not have quirky gotchas or complexity leakage which confuse developers. es-harmony != crockscript.
javascript is powerful and interesting – much more so than java. But in someways it’s the equivalent of ‘c’ for the web. Powerful and dangerous. Can es harmony satisfy both ‘standard developers’ and hackers who appreciate the functional goodness that lay looking at javascript?
hlsantos (August 15, 2008 at 6:27 am)
Thanks for the summary John. As with all new directions, eventually the industry comes together to stabilize it – that includes open (source) technology as well.
Money (August 15, 2008 at 8:08 am)
I hope there would be more developer kits for js, also i think no one would like to do too many imports or have lots of references since they just need a loop for their htmls.
Thanks for the great job, good luck.
John Resig (August 15, 2008 at 3:40 pm)
@William J. Edney: There’s been a lot of talk concerning catch-all getters and setters. It’s looking likely that they might get in – but your participation in the discussion would surely help. Feel free to post a point over on the ECMAScript 3.1 mailing list.
Brendan Eich (August 16, 2008 at 12:44 pm)
@William (John too): catch-alls are not going into 3.1, which is trying to get its spec debugged so implementations can proceed. So this topic and others for post-3.1 standards should go to the newly-renamed [email protected] list (renamed from es4-discuss).
/be
Brendan Eich (August 16, 2008 at 1:04 pm)
Dennis wrote “You talk about adding complexity to the language as a negative, but I think adding complexity to your code to overcome the simplicity of the language is far worse.” As others here note, I’ve said this often too. Guy Steele had a great OOPSLA ’98 talk on this topic, called “Growing a Language”. Google video here.
What Dennis and others have missed is that we, the ES4 “side”, cut packages this past April, for technical reasons. We could not make them desugar to namespaces, they required extra magic that we had no time or convincing ability to invent extra spec to make work in ES4.
Namespaces too require some kind of module system to prioritize the namespaces that are opened (by ‘use namespace N’) when a particular module is compiled. This doesn’t fit the Web’s late-bound model, and grafting early binding on must be done optionally, in ways that do not lead to different name-binding decisions between compile time and runtime.
A similar problem exists outside global code, in subclassing. These problems led us, the ES4 folks, to conclude that namespaces don’t fit in ES4 as proposed. Effort to make them work would be a bridge too far.
But the module system problem remains. It’s not solvable only by name binding elaborations. Hannes points out how to solve it in-language, but that wheel is (a) a leaky abstraction, which could be abused; (b) something no one should have to re-invent.
Another point: simon j is right on to assert that ES-Harmony != Crockscript. For the longest time, the “3.1” position (there was no spec at all) was “nothing”. Like Michael Corleone to that Senator in “The Godfather, Part II”, Doug’s answer was “nothing” and sometimes less than nothing: make the language smaller, make incompatible changes to remove things. That’s not going to happen.
The idea that it’s better to do nothing than the wrong thing is really no excuse, since the opportunity to do the right thing (instead of just nothing) was before us all on the committee, for the last two years. That we only heard of 3.1 details beyond fixing errata until 2008 says to me that ES4 was a necessary antithesis to the “nothing” thesis.
Users are free to subset, even to use subsetting tools like Caja. But the language must grow, as Guy Steele’s talk makes clear is the case for all living languages.
/be
xho (August 16, 2008 at 10:10 pm)
Very disappointed,
i lead a large dev group in Italy: my group spent a lot of training time on ES4 and Actionscript 3.
I must say that we have always been on the “open standards” side and that’s why we went so much into a proprietary technology like AS3: the existence of Tamarin, ECMAScript and Adobe’s efforts towards “open-nes” and standards furnished the necessary credibility.
But now it seems to me that this is only a political decision supporting Microsoft strategies: I want to point out the fact that Microsoft had also recently relased Silverlight (vs Flash/Flex/Actionscript) and XPS technology (vs PDF), built into Vista/Office 2007.
Microsoft is pushing towards XPS adoption and Silverlight endorsement (i.e. NBC Web live coverage on Olympic Games).
What’s going on?
And what should we do now: should we abandon AS3 and its powerfullness in order to stay aligned with open standards?
And if so, what should we do with all the knowledge and software engineered with packages/namespaces/typing in mind?
Michael O'Brien (August 17, 2008 at 2:02 am)
Understandable given the tensions and market forces.
However, ES4 had many, many good things and the debate often clouded good work to actually implement much of ES4. Things like namespace can be implemented quite efficiently with the right implementations.
Ejscript implemented the majority of ES4 and nearly all the hard parts. We intend to push forward in the direction of ES4 as it was being defined and enhance it for use outside browses – embeded use, and server side web frameworks.
As Harmony evolves we will track it, but Ejscript like ActionScript will preserve much of the goodness in ES4 and will innovate and develop the language (e.g. modules)
Michael O’Brien
Peter Hale (August 17, 2008 at 6:38 pm)
See the official Ejscript position: http://www.embedthis.com/blog/?p=14
Breton (August 17, 2008 at 9:35 pm)
“Hannes points out how to solve it in-language, but that wheel is (a) a leaky abstraction, which could be abused; (b) something no one should have to re-invent.”
@brendan, I think you misunderstood Hannes’ solution. It is not an in-language solution, what he’s doing is he’s manipulating the scope of module code from the JAVA side of a rhino embedding, and making that clever scope manipulation indirectly available to the clientside via an “import” function, as a host object. so basically it’s still the same javascript 1.X, and there’s no implementation written in javascript- It’s just a different way of embedding a script in an application.
If it really is a leaky abstraction- then you should probably note that in the MDC wiki page where Hannes got the technique. (Under the section “shared scopes”)
Brendan Eich (August 17, 2008 at 11:33 pm)
@Breton: could you provide a link to the MDC page you mention?
Since you took this topic to [email protected], I’ll just refer interested folks there, and note that lacking more information, I do not see how setting the prototype or parent, by themselves, avoid the kinds of problems I meant by “leaky abstraction”.
/be
Brendan Eich (August 18, 2008 at 12:14 am)
@Breton: sorry, I was thinking of Maksim Lin when I wrote “Since you took this topic to [email protected]” — no worries, whoever did the deed — just want folks here to know about the thread there.
/be
Philip Bulley (August 18, 2008 at 2:30 am)
@Dennis, fully agree with you. Personally, I’m Glad I left the so-far-stagnant realm of Javascript a few years back. As for everyone doubting the future of Actionscript, I think, even though no longer officially a standard, I now trust that Adobe have their heads screwed on correctly (unlike in the days of Flash 5 and AS1) and will take Actionscript forward in a clean and innovative fashion.
As for throwing out the AS3 cookbook as Jason C mentioned earlier, if RIAs are what you’re about, this is all the more reason to go buy it if you haven’t already! (surely what Microsoft are sneakily banking on in regards to any Silverlight concoction books out there too).
Brian Ferris (August 18, 2008 at 10:57 am)
I for one, am crushed. Having played around with AS3 since its release, and JS since it was LiveScript, I was eagerly looking forward to having a similar overhaul made to JS for building more enterprise-level applications. Clearly there is a demand for classical OOP features (such as class-based inheritance) as there seem to be an unending series of libraries that have been released attempting to simulate this (your recent attempt John has been one of the better ones).
But just as clearly, none of the attempts have been completely satisfactory. The nice thing about AS3 is that you have this sort of feature set while still having access to dynamic language features that people love about JS-the best of both worlds.
Reading between the lines it seems that the MS/Yahoo group were the ones on insisting that namespaces/packaging need to be removed since they were unsuitable for the web. This seems odd since these sort of features have been successful in AS and also I believe MS even has them in Silverlight. I’m not sure why MS would make this argument unless they are concerned a much stronger JS would lessen the need for people to move to Silverlight-what MS is positioning as their enterprise level web development platform.
In any event, I’m frankly tired of people claiming “anything can be done in JavaScript”. While JavaScript’s dynamic nature lends itself to the simulation of a wide variety of language features, I can’t help but feel that it would be better if some of these features were standardized as part of the language itself instead of having everyone develop numerous hacks that all fall somewhat short of the mark. This doesn’t lead to greater programming productivity or efficiency.
Jonas Bolinder (August 18, 2008 at 1:59 pm)
From a newbie’s perspective in these circumstances it seems a bit worrying that the ambitions have been lowered in making JavaScript a truly competitive object-oriented language. Though, joint forces might help bringing a new version forward faster. I think it is important to keep JavaScript, in view of its openness, a competitive client-side scripting language.
Brendan Eich (August 18, 2008 at 5:53 pm)
@Brian: you wrote “Reading between the lines it seems that the MS/Yahoo group were the ones on insisting that namespaces/packaging need to be removed since they were unsuitable for the web.” What makes you think so?
ES4’s working group cut packages this past April. No one from Yahoo! or Microsoft was involved in that decision.
Namespaces were on the chopping block too, since as proposed they lacked the multiple global objects (one per script) or other module-like ways of priotizing that Flash supports; also the static type checker in AS3, I’m told, helps avoid ambiguities and integrity problems to do with namespaces and subclassing. These (multiple globals, static typing) were not part of ES4 as proposed.
The ES4 working group could have revived the old notion of optional static type checking, but we’d be slipping into 2010 to spec and reference-implement all of this. You can’t just wave a wand and standardize what’s in AS3, even if it has an open source implementation (the compiler is split from the runtime, but both are open now). An interoperable spec has to formalize all of the syntax and semantics.
More that time to finish was at stake. Spec complexity was already high.
And most of all, many of us working on ES4 did not believe that static type checking without a module system to hang it on was right for the Web. There’s no compile-to-SWF phase for web app and mashup JS. Type checking could be done in an advisory way, in the background, but this was researchy.
Multiple globals, one per script, might be an option if we had a proper module system. Something like this, or better (true lexical scope) may yet happen in ES-Harmony.
But again, we didn’t have such an optional module system in ES4 as proposed. So we were unable to standardize some proposals that depended on AS3’s different global object model and strict-mode type checker. That’s not to say AS3 is flawed, or any such thing. Only that it is different enough from JS as used in the web browser embedding that a unified standard seems out of reach.
In time the two worlds, AS3 and JS, may evolve together, but there will be differences as well as changes, adaptations to an evolving standard.
Anyway, it’s silly to blame Microsoft and Yahoo! for what the ES4 working group decided. You could blame Microsoft for stagnating the web for years, but with Firefox renewing browser competition, they are back at the standards table. You could argue that Doug Crockford of Yahoo! has been a nay-sayer to major changes proposed for the language, but he’s just one of many members, and anyway he never got into the detailed technical issues of namespaces or packages.
Hope this helps,
/be
Nick (August 19, 2008 at 11:45 am)
“Anyway, it’s silly to blame Microsoft and Yahoo! for what the ES4 working group decided”
Is it also silly to blame Microsoft for manipulating the ISO standards process concerning OOXML?
Ean Schuessler (August 20, 2008 at 1:32 pm)
Isn’t the Harmony name going to be easily confused with Apache Harmony? Is ES4 going to be based on a JavaVM?
John (August 21, 2008 at 7:26 am)
As everyone else I was expecting ES4 but it didn’t make it that put javascript in a position that it will continue to be the hacky scripting language for the web and not the real programming language for the web we ware waiting.
Microsoft sucks it is a disgusting company promoting always their shity products and destroy all the good things of this life but I can see this as a winning for Adobe Flas/Flex/AS.
I think now it will be the time that everybody will move to Adobe AS becuase they understand the developers what they need and they are not driven by shity companies politics. So for the guy that wants to throw away the book dont do it you will need it more than ever.
Adobe will lead the RIA from now on, Forget Silverwhat is a shity enviroment, Im a Java developer too but I dont see any value in JavaFX. So Flash/Flex/AS I think is the way to go for now on and the future in RIA.
Javascript where will be? I think as I said it will continue to be the same hacky scripting language for the web.
Thats my 8c.
Brendan Eich (August 21, 2008 at 7:42 am)
@Nick: no, but that (OOXML) is a different story, isn’t it? Blame away.
@Ean: Harmony is just a short-term name. It won’t be an open source project, or even an Ecma Edition name. The likely next major edition number is still 4.
/be
simon j (August 21, 2008 at 8:22 am)
Does firefox still intend to use tamarin – or some variant – as it’s vm. That is, will the work of getting the spidermonkey compiler to generate abc byte code – actionmonkey? – continue? A vm that could run both actionscript3 and es-harmony/es4 would be sweet – if possible. Does tamarin offer the runtime semantics to run efficiently an es-harmony which is more ‘dynamic’ ala scheme/dylan/python etc and ‘functional and structural’.
Nick (August 22, 2008 at 10:32 am)
@Brendan: Is it though? I mean we are talking about a company with vested interest manipulating a standard. For instance, if I really wanted to “stick it to the man” I could argue my head off on why adding Linq to .NET is a bad idea, but Microsoft’s going to add it anyway. It’s a methodology to make the programming easier. If ECMA4’s suggested syntax and methodology makes it easier to use, why argue that it’s not needed?
There’s definitely motives behind this decision. If Javascript could have been made easier through whatever was dropped because of this decision… then I say it is the same issue.
John (August 23, 2008 at 2:38 am)
Committee standards Sucks Big Time!!, I think for the healthy of technology and programming languages is much better the Open Source Model with a leader, look at Linux, Look at Python those are a Success.
Javascript specs and implementation should be driven with a Open Source Model and a Leader in the field as John Resig is a good candidate for the future of Javascript, Look at his framework is a Master Piece.
Open Source is the future, ECMA/ISO/ANSI sucks big time!, Committee standards are to slow for the dynamic IT/Computing world and we need a lead that it is not with a company politic agenda.
2c.
Simon the Pious (August 29, 2008 at 2:11 pm)
Well,
I know a few languages but I’m not like yourselves, I’m just a common user of scripting languages who is so sick of no base standard like C of the compiled world to work in. While this has dragged on for years we the “”Users””, have had carrots dangled in front of our faces. Ahh the hope I had when I thought yes, there might be nirvana so I’ll forget about Ruby. We all know that a standard is what we want but without a modules system Ecmascript will never reach the status of a full script and must remain an embedded web centric system.
Please Brendan consider that not all things even in embedded land need the web or operate through html. You could always allow an Ecma superset which allows some form of modules but does not support it in limited embedding environments or where security is paramount. But damn, I need the modules feature to write some nicely portable code that can be bigger than a matchbox. I need structure in files, is that so hard to see?
Umppfff, off to wait another 2 years before I get a standard scripting language…
Jonathan Fine (September 2, 2008 at 3:16 pm)
Hannes Wallnoefer has told us about his work to create a Python-like module system for server-side JavaScript, as part of Helma NG. As it happens I’ve been doing something similar, but on the client side.
The basic idea is that JavaScript
var db = jsmod('database')
is equivalent to Python
import database as db
and that to write a module ‘database’ one create a file ‘database.js’ whose content looks like
jsmod(
function(m){
// 'm' is the module object we are initialising.
m.aaa = function(){
// ...
}
// ...
});
My work on this is available at http://code.google.com/p/jspy2/
So far it’s working fine, but I’m the only user, and keep finding that I need to add new features. However, I’m now quite certain that the fundamental concept will work on browsers (although there are difficulties due to the nature of the platform).
(There’s a story behind the odd name, which isn’t worth telling. Think of it as jsmod.)
Yasar Kurt (January 9, 2009 at 1:12 am)
I hope there would be more developer kits for js, also i think no one would like to do too many imports or have lots of references since they just need a loop for their htmls.
Thanks for the great job, good luck.
dvdrtrgn (January 13, 2009 at 7:59 pm)
Two things from PHP that I’d love to see implemented in JS:
1) Ability to automatically set argument values… <code>function($var=”gracefully undefined”)</code>
2) The ability to embed tokens within strings <code>”Hi, I $feeling JavaScript.” // $feeling = ‘love’;</code>