The Effects of ECMAScript 4′s Abandonment on Pedagogy of Rich Media Development Languages
The Oslo meeting that determined that ECMAScript 4 will not be the next generation of JavaScript, has been blogged extensively lately. Grant Skinner, Mike Chambers, John Resig, Hank Williams, and Ryan Stewart have all weighed in on this along with Dave McAllister on the Open at Adobe team. A good lengthy description on the groups decision is here in a letter to the Es4 list. It appears the namespaces and packages features of ECMAScript 4, among others were not palatable to a few members on the board, so the more advanced spec of ECMAScript 4 is being shelved to make way for the more incremental update of ECMAScript 3.1 instead. You can get the nitty gritty details on that in this Google Spreadsheet.
While this is not a big deal for the future of Flash as a viable and valuable development platform in professional circles (Adobe has already stating they will not backpedal and cutback on AS3 or AS4′s current or future features because of this decision), this does affect academia and even ongoing professional development from a pedagogical standpoint, effectively cutting off Actionscript 3 as a natural progression/extension of client side scripting to teach students and to serve as a bridge to higher level languages and vice versa. ECMA Script 4 simply served as a better path to bring students into OOP and high-level languages. The change is subtle, no doubt. It does, however, water down the linkage between the languages in a school curriculum. This does open the door for Processing.org’s Applet Development tool, Processing, to serve as a better fit for this purpose in a development learning progression. What do other instructors out think on this? I’d like to hear it.
Furthermore, this exchange serves as yet another opening salvo in browser wars 2.0. With no clear path to HTML5, the next XHTML spec still in limbo, and no real uptake by browser developers on CSS3, it’s only fitting that the behavioral layer’s future get neutered in order to serve MS and stagnate the web again. Adobe and Mozilla already had functional VMs that would run ECMA script 4, so it seems apparent to many out there that this is a stonewalling on MS’s part to buy time to build a new engine, or block ECMAScript’s advancement in general. It looks like that the W3C may very well need to create another new task force (ala The Dreamweaver TaskForce) to get things moving before they get locked up again like in 1999.
This “Harmony”, as the compromise seems to have been called, looks to be more of a placation to me.
Posted on August 15, 2008
Harry B. Garland Aug 15
What if Mozilla and Adobe both implement Tamerin anyway? You could just tell developers that if they are willing to create a Firefox-only web application, they can use a much better language than the one used by Internet Explorer and Safari? Why should everybody suffer just because 2 companies are too big and political to innovate?
RansomWeaver Aug 15
What about a sniffer that demands flash player when it detects something other than Firefox? That’s no worse than where we’re at today…. If the flash player can load content written for Mozilla Tamarin, It puts the onus on the browser devs to bring their product up to standard or fall behind.
Douglas Crockford Aug 15
This statement, “it‚Äôs only fitting that the behavioral layer‚Äôs future get neutered in order to serve MS and stagnate the web again,” appears to be based on some misinformation. Let me set the record straight. ES4 had a very long and extensive feature list, but it did not include testicles or any other form of genitalia. It had a lot of other stuff, but somehow it didn’t have that. The features its did have would not have allowed you to do anything that you won’t be able be able to do in ES3.1. You have not lost anything substantive.
Lars Gunther Aug 16
For the record. W3C and WaSP are separate entities. W3C has no “Dreamweaver Task Force”. WaSP had. It is now renamed “Adobe Task Force”. (I am a member of the Educational task Force.)
WaSP had a DOM Scripting Task force, but is is not active anymore. Its purpose was to educate about best practices (unobtrusiveness, capability testing, progressive enhancement, etc) and was not charged with working on the specs.
WaSP is more about helping browser and tool vendors implement the specs and the general public following them when developing web sites.
Lars Gunther Aug 16
@Doug C:
I’ve heard that class-based objects are critical to speed on mobile platforms. Even if they are not off the table for Harmony, they for sure have been postponed and that is a *substantive* loss – even if they can be emulated using protype based inheritance.
Speaking from a pedagogic point of view, they are also very nice when teaching ECMAScript to serve as a bridge between languages.
Chad Aug 16
@Lars,
Thanks for the comments and the clarifications on WaSP. I appreciate being set straight!