Monthly Archives: August 2008

How will ECMAScript "Harmony" affect ActionScript 3?

I’ve been contracting for Yahoo! recently and I overheard Douglas Crockford talking about the ECMAScript “Oslo meeting” with a co-worker. I only heard snippets of the conversation, but I remember wondering what the heck he was talking about because it sounded very strange. Today, the topics of that conversation became public. First, I saw a thread titled Harmony on the ES3.x mailing list, started by Crockford:

It was decided at the Oslo meeting that the project formerly known as ES4 is no more. Instead, there will be a new project, Harmony, which will be the work of a unified working group.

For a bit of background, the group working on ECMAScript 4 split in two last year. Some folks (Microsoft and Yahoo! among them) felt that ES4 wasn’t going in the right direction for the web, and they wanted to start smaller with an ES3.1. Other folks, like Mozilla and Adobe, had pretty strongly committed to ES4.

John Resig just posted a more thorough explanation of what happened at the ECMAScript Oslo meeting, and Brendan Eich wrote about it on the ES4 mailing list. I encourage you to read these posts because they’re very interesting. To summarize, though, the split working groups are coming back together. They’ve committed to completing ES3.1 first and will begin re-planning features for a new version of ES4. From what I can gather, the ES3.1 group had started making changes that weren’t fully compatible with ES4, and if the two versions were finished out of sync, there would have been major problems. Some of ES4’s existing plans will be dropped completely (packages and namespaces among them) and others will be given a stronger bond to the features in ES3.1.

Overall, I think this is a good strategy, considering the alternative. When I first heard about the conflict between the two separate developing versions, I worried if it would cause the improvement of client-side, browser programming to completely stall for a while. At least now I know that everyone seems to be moving forward again, in “harmony” (to steal their term).

This is all well and good, but it leaves us asking one important question: What happens to the existing version of ActionScript 3.0? Adobe very conservatively implemented features from the ES4 specification, knowing that changes could be made to the draft spec, but unfortunately they still ended up implementing features that will no longer appear in ES “Harmony”. As I mentioned above, packages and namespaces are out, according to Resig’s post. Will Adobe continue working on AS3 with the features it already has? Will they continue to implement more from the scrapped ES4 spec? Or, will they actually remove features to stay compatible with the latest changes to ECMAScript? One could argue that they did it once already by removing private constructors that were available in AS2.

I imagine this will be a hard problem for Adobe to solve. They’ve stated previously that they want ActionScript to be compatible with an industry-standard language. If they remove features, I know many developers will have some not-so-happy opinions to share. On the other hand, I personally like that Adobe wants to use a standardized language. Like their recent contributions to open source, it’s a sign that they “get it”. To get a little off subject, I’d love to see multiple languages able to target the bytecode used by Tamarin/AVM2, and it’s certainly possible (look at HaXe), so maybe the possibilities are more flexible than we might initially expect.

If anyone from Adobe can comment, I’d appreciate it. If not, I hope you can share something with us soon.

Update: You might want to read what Hank Williams thinks of these changes and how they will affect Adobe. Well written.

Update 2: Additionally, a couple of days after this surprising revalation, Arun Ranganathan wrote an excellent and more mellow summary of the Oslo meeting and Harmony on the Mozilla Standards blog. What’s most interesting, in my opinion, is that Arun’s position is that the upcoming Harmonized ES4 may not be that different from AS3, and any differences are minor enough to be considered Adobe extensions. Fascinating!

AdvancED Flex Application Development offers a unique perspective

Unlike other Flex books, AdvancED Flex Application Development: Building Rich Media X by R Blank, Hasan Otuome, Omar Gonzalez, and Chris Charlton (enough authors, guys?) doesn’t cover Flex with a lot of little examples that introduce the features of Flex to newbies. Instead, the authors present a bit about Flex through a look at an application they built called Rich Media X. Rather than cover all the same-old, same-old Flex basics, this book covers the process of building the application and many of the considerations they had to make during the process. I think it’s great that Flex books are starting to move into a wider variety of material, and I hope this is the first of many.

What’s most interesting in this book, in my opinion, is the section on planning. Every Java head (and probably his mother too) knows all about requirements and design documents. In the Flash world, a lot of coders don’t have any experience with this sort of traditional software engineering stuff. It was great to see the authors spend time talking about finding requirements, determining how much time they had available (and inevitably, what needed to wait until a future version), and things like wireframes and various other diagrams. I honestly wished they’d spent another chapter or two on this subject. I think the Flex development community would benefit from a more engineering-focused book that has an ActionScript twist.

One thing I didn’t like was the actual application the authors presented. Rich Media X is more of a distributed set of applications that Adobe User Groups can opt-into individually, and it’s very different than the traditional Flex app. While it’s good to show that Flex can do crazy and interesting stuff, the subject of this book is very abstract compared to most Flash and Flex books. Combine that with an app that requires a reader to wrap her head around its very purpose and you have a very confusing read. I found myself switching contexts too often. They’d slip in a chapter on how to specifically do something like styling in Flex, and suddenly everything would change as I learned about installing Drupal or what makes a good advertising platform. Not to say that learning about Drupal is a bad thing. In fact, I think the topic of technology integration with Flex made the book a little more interesting.

At the end, there was a “Special Topics” section that covered what I assume were chapters that the authors didn’t know how to integrate with the main content. A chapter on SEO was nice, especially the mention of Ted Patrick’s XSL-based Flex SEO system. On the other hand, the tip of using CSS-hidden HTML content for search engines to crawl was misleading since Google penalizes that behavior. The next chapters about how to build an audio visualizer and what’s new in Flex 3 didn’t fit in at all. The tendency for authors and publishers to say “oh, a new version came out, let’s make sure we add a chapter that covers the new features” is getting old. Either integrate it into the main book’s content, or in the case of this book, don’t include it at all because the topic of the rest of the book wasn’t an overview of the previous version.

Ultimately, while I had some gripes with AdvancED Flex Application Development: Building Rich Media X, it was a nice change of pace for me. I like when tech books experiment with the normal format because I generally hate tech books. This one looked at Flex from the perspective of how to build a big application instead of how to start using Flex. That’s awesome. Personally, I think it tried to fit in a bit too many subjects at once, and maybe some more focus would have made it better. Check it out if the regular “getting started” development book isn’t your style.