follow me on twitter

Note to self: remember to use the test database when testing this site ;D


final test - hope

Flash 11 should be a switch to JavaScript

Flash 11 should be a switch to JavaScript

Let's press the reset button and drop ActionScript. It hold no relevance or advantage in todays world.

Over the past few months I've been working closely with JavaScript in different environments outside of the HTML DOM. Two of those being on the server side - Node.js and CouchDB. The other being an experimental front-end, RIA like platform. And what I've concluded over these past few months is that I really like using JavaScript - I'm genuinely surprised!

It was only a few years ago when I finally rid myself of ActionScript 2 and I was ecstatic about that. The ActionScript 3 way of doing things seemed to make a lot of sense to me and I've since written tens of thousands of lines of the strictly typed, compiler checked goddess. But is she a false idol.

At present, Adobe is recruiting people to the Flash platform via the new child, Flex. Up until people started throwing around the term RIA, the Flash user base was primarily made up of creatives & devigners who made some pretty amazing websites (lets forget about skip-intros for now) with what they had. Now the Flash base is increasing filling up with Java and C# types who expect a certain level of features, complexity and checks - Adobe continues to encourage it and the old base seems to be increasingly disillusioned.

The overwhelming message is that ActionScript 3 is necessary and better than all it's predecessors. Now a big part of me believes this, in-fact I'd say it was pretty accurate. But I can't help but feel that it's hurting the essence of the platform and the web in general. It's almost as if ActionScript (and some of it's base) has a kind of inferiority complex and must be more like its mature peers in-order to be accepted. In-fact the power of ActionScript (and some of it's base) was always in it's simplicity - "less is more" so they say. And this is exactly what I've found out over the past few months with JavaScript.

The expressive power of JavaScript is wonderful. And so is the expressive power of AS3 once you take away the strict typing, package name-spacing, verbose eventing and the classical-OO pretense because you're left with the stuff you care about, the stuff that actually gets things done. More importantly you're left with something that looks just like JavaScript, no surprises there seen as they are ECMAScript cousins. Well maybe you could say AS3 is the bastard child now that ECMAScript 4 has been abandoned (- I think this post can stand without doing into depth on this subject).

But isn't the big benefit of ActionScript 3 with strict typing the speed? - surly this is key to Flash success. This statement is utterly incorrect. First and foremost, the majority of Flash's execution lies in the rendering of the stage. If AS3 is only doing [box.x+=1] then render is doing a hell of a lot more updating pixels on the screen. It is OK if your AS3 code is convoluted because the renderer will always be your bottleneck. The other mis-conception is that strict-typing improves execution speed. The evidence is probably running right in your face: most modern browser JavaScript engines are in-fact faster than Tamerin (the AS3 virtual machine). Additionally, Joa Ebert has really thrown egg on Adobes face this past year by showing the community just how unoptimized the AS3 compiler is.

So what was good about the introduction of ActionScript 3. Well, for me I think the bigger issue was at the API level. I think people enjoy AS3 over AS1 and AS2 because of a cleaner API into the platform and the finer-grain/cleaner control you get over the display-list. If you were to put put ActionScript 3 into the browser as a JavaScript replacement, you'd still end up with the problems of having to work with the awful HTML DOM. The language in Flash was never the issue.

Adobe Flash is increasingly being squeezed by it's competitors who all want a bite from the RIA apple. Adobe can no longer afford to ship a niche language. Especially if they expect to draw in fresh blood into platform. A move to JavaScript (ECMAScript 5) would seem like the sensible option for the future of Flash. A grander alternative option would be a .NET type approach, enable many commonly used scripting languages (JS, Python, Ruby, Lua, etc) to becoming first class Flash languages, but maybe that's too over the top. Simply moving to JavaScript will bring renewed expressiveness to the platform and once again it'll be approachable by new talent, who at the end of the day, will make or break a platform.

I'll end this with an example of expressiveness. Both these snippiest do the same thing: load an external JPEG and add it to the stage once loaded. I understand that you could encapsulate the JavaScript approach in AS3 - The point is that you shouldn't have to.

EDIT: People have commented heavily about the following snippets. Please don't take them as the overriding message of this article. The main message of this article is about AS3 being a niche language with too many constraints - JS could easily take it's place.

EDIT2: I've started an open source project called $flash, hosted github, with the aim of creating a whole AS3 lib based on the JavaScript snip below.


// JavaScript

flash.load("lolcat.jpg", {
success: function(bitmap) {
gallery.addChild(bitmap);
},
error: function(msg) {
trace("no lolcats found");
}
});


// ActionScript 3

import flash.events.IOErrorEvent;
import flash.events.Event;
import flash.display.Loader;
import flash.net.URLRequest;

var url:URLRequest = new URLRequest("lolcat.jpg")
var loader:Loader = new Loader()
addListeners();
loader.load(url);

private function addListeners():void {
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, completeEvent)
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
}
private function removeListeners():void {
loader.contentLoaderInfo.removeEventListener(Event.COMPLETE, completeEvent)
loader.contentLoaderInfo.removeEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
}

private function completeEvent(event:Event):void {
removeListeners();
gallery.addChild(loader);
}
private function ioErrorHandler(event:IOErrorEvent):void {
removeListeners();
trace("no lolcats found");
}






Josh Tynjala via the old blog says ... I think multiple languages using a shared bytecode would be great for Flash Player (and the web in general). I too enjoy JavaScript, and I've done much experimentation using AS3 with strict mode off, which is as close as you can get right now without leaving Flash Player. I think it would do Adobe well to keep a separate ECMAScript-compliant language around with all the prototype goodness (yes, I said goodness) that can be more flexible and friendly to those who come from an AS2 or even JavaScript background. I also think that AS3 should not go away, but continue to evolve because I understand that not everyone wants JavaScript. I don't want to see a switch because then you alienate the people Adobe was able to bring on board with AS3 that didn't like older versions of the language. We need multiple languages side by side with the same access to Flash Player capabilities (AS2 no longer gets cool new stuff, obviously), but for the widely different audiences of developers Flash Player has and should keep.

Mitch via the old blog says ... Your Javascript/AS3 code comparison is a little disingenuous. If compact code is your goal, you could write the AS3 code as follows:

var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.COMPLETE,
function():void{
gallery.addChild(loader);
});
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR,
function(event:IOErrorEvent):void{
trace ("no lolcats found");
});
loader.load(new URLRequest("lolcats.jpg"));

Alex Bustin via the old blog says ... @Mitch that's true, but it's still ugly.

But please look past those coding examples. The main point is, why use ActionScript if you can do it just as well in JavaScript.

Teddy Matayoshi via the old blog says ... This is a very informative post. I will still use ActionScript though because what I mainly use it for is "Animation" not RIA stuff. Flash was originally intended for "Animation" which is why the Flash IDE has a "timeline" then I guess it evolved to RIA somewhere down the line (which Flex is more suitable). A lot of the animation features that ActionScript has can not be done by JavaScript. Not to mention that at the present moment JavaScript doesn't have a full blown library for 3D objects (Papervision 3D, Away 3D etc). So for RIA maybe JavaScript but for real "animation" it's still ActionScript 3.0 for me.

Alex Bustin via the old blog says ... @Teddy - ActionScript has no animation features. Animation is simply the change of a value over time.

Flash is software that's able to create and render vectors, bitmaps and text. You can then use code or the timeline to control it - this is what's called an API. Whatever animation you do on the timeline, it will eventually end up a code, even if you dont see it.

There is no reason why you couldn't have a JavaScript Papervision lib for Flash.

Ross Phillips via the old blog says ... I can't say I agree this would be great for the Flash platform or the Internet in general. The idea of one runtime/language to rule them all is not something new. I think it is great to have different platforms/languages pushing each other to be better than each other. To me diversification is far better for the developer ecology than unification under one platform/language.

Your code example is not a fair comparison of syntax. You can definitely write a less verbose version of the ActionScript and I'm sure you could make the JavaScript more verbose. I know you're trying to prove the point of "less is more". I agree with you on that but in reality when you write less there tends to be more happening under the hood.

Alex Bustin via the old blog says ... @Ross I wouldn't be making this post if ActionScript was a common language. The problem is that AS3 is a niche language that holds no benefits. Flash should be using a popular language such as JavaScript to get stuff done. I like diversity too, but it has to be justified and solve a problem.

Campbell via the old blog says ... "The main point is, why use ActionScript if you can do it just as well in JavaScript"

I think this has a lot to do with personal preference. I personally prefer AS3 over javascript. I may have become lazy, but code editor features, debugging and compile time errors has made my life easier. I really dread having to jump to Javascript for projects these days (not only for IE hassels).

AS3 has allowed the new code editors. The features that are now in the code editors come from Strict Typing. This is why you don't see a lot of great editors with intellisense, code generation etc for Javascript or other dynamic languages.

Im totally with you about the .Net approach though. At the end of the day it all becomes byte code, that the VM (Tamarin) runs. Why not have compilers that can be compile any script to bytecode. But really I would prefer to see the AS3 compiler made 10x better (more efficient) first.

Looking at the Tamarin engine, its pretty strongly linked to types with traits and closures (AKA Strict typing), So for some of the more dynamic scripts I guess to support this is would need to be made more generic. And if this were at the expense of performance I personally would find it a hard pill to swallow.

Josh Tynjala via the old blog says ... Looking over your code examples again, I have to say it's a little unfair. Your hypothetical JavaScript code looks more like what you'd get after including a library like JQuery or YUI or something. Those libraries encapsulate some pretty nasty DOM and XHR functions that can be just as ugly as what you need to do with low-level ActionScript.

With that in mind, one might conclude that the JS community is ahead of us in making things look cleaner than they really are. I'd love to see more community effort to make libraries that encapsulate and simplify common tasks in AS3, like those that are so common in the JS world. I played around with some ideas a bit myself a while back, and I had a lot of fun doing it. I always wanted to take it a step further, but it's hard to justify doing it all on my own time.

Alex Bustin via the old blog says ... The ActionScript example was a watered down version from the API docs and of course the JavaScript version is only a proposal. But like I keep saying, this post is not all about the code snips.

We could start an open source project, Josh. Like I said in my post, you could create my JavaScript example in AS3, I just wish we didn't have to. Making a library and then expecting the community to adopt it is trouble.

I did try to bring back AS2 style eventing here http://thebackbutton.com/blog/88/avm1eventproxy-as2-style-events-for-as3/ ... but maybe we need to encapsulate all the core Flash classes into a mirror namespace and simplify them *shrug*. Still seems like we'd be fixing something Adobe should be fixing though.

Randy Troppmann via the old blog says ... MVC frameworks. Ant builds. Agile. Dependency injection. Flash designers say wtf.

ECMAScript 4 abandoned. ECMAScript 5 does a right turn. Javascript executes faster. AS3 is at a crossroads. Point made.

But Javascript? Don't feel like sometimes your project reaches a point of complexity and size that you are glad that your strict, encapsulated, loosely coupled structure has your back? When I think of Javascript I think of debugging nightmare, silent failure, and prototype. I think you need to dig into Javascript a little deeper to convince me of why it would be a viable replacement of AS3, because "expressiveness" is just not a good enough reason.

Matthew Fabb via the old blog says ... When ECMAScript 4 when down in smoke, I saw many suggestions from developers on blogs and at user group meetings that if Adobe ever abandoned ActionScript to move to C#. As lot of ActionScript developers who came into Flex the past couple of years have backgrounds in Java , C# or PHP backgrounds and want ActionScript to become more a complex language towards the direction of something like Java or C#. If Adobe ever moved Flash to JavaScript, I think there would be a huge backlash from this section of the community. Certainly, many I think dislike working with the lose nature of JavaScript that they would leave Flash.

Also debugging large Flex applications would become a lot more difficult without "strict typing, package name-spacing, verbose eventing and the classical-OO pretense". Large JavaScript applications can become incredibly painful to maintain and debug, compared to doing it in ActionScript for Flash or Flex (differences in browsers aside).

However, one of the reasons this would never happen, is that Adobe frameworks like Flex, the Text Layout Framework, Open Source Media Framework would have to be ported to JavaScript. The undertaking would be huge, likely take more than one year and would halt any forward momentum in those frameworks. Adobe too invested in ActionScript to ever dump it now.

That said, many developers would love Adobe to go the .Net and support many languages. Something I could see happening perhaps with Adobe's Alchemy project opening up to support more than C/C . Originally when Alchemy was first introduced by Adobe it was discussed how it could lead into PHP, Python and other C based languages being used as well.

"First and foremost, the majority of Flashs execution lies in the rendering of the stage. If AS3 is only doing [box.x =1] then render is doing a hell of a lot more updating pixels on the screen. It is OK if your AS3 code is convoluted because the renderer will always be your bottleneck."
As someone who has seen many ActionScript bottlenecks, this is not necessary true. Perhaps in simple Flash banner ads and simple applications, but more complex applications this is not the case. Certainly with the various 3D engines like PaperVision3D, most of the bottlenecks happen on the ActionScript side of things. Just look at any of the blogs from the authors of Papervision3D about how much time has been spent on optimizing the code and how it's made the engine that much faster.

As for the benchmarks against Tamerin, it's my understanding that these test were run with Tamerin as a JavaScript engine running inside of a browser. Which I imagine would be different in testing the engine inside of the Flash Player when you have compiled ActionScript code. It's been a number of years since I've seen anyone do anything proper benchmarking of ActionScript versus Javascript. The closest thing I've seen is the GUIMark (www.craftymind.com/guimark/) but that tests a number of things especially rendering. However, lately there's been a lot of experimentation with JavaScript in reproducing things often seen with Flash. Examples I've seen of JavaScript physics engines have been painfully slow compared to similar engines in Flash. Since it's just small boxes being moves around, I doubt it's the rendering that is having problems with it. Which is why I don't think a 3D engine has been produced in JavaScript yet, as I don't think any of the engines are fast enough to handle it.

Alex Bustin via the old blog says ... @Josh I've started the project on github if you want to dive in and help http://github.com/abustin/_flash

So far I've added a load method that's just like the example from the post.

adampasz via the old blog says ... Okay. I agree with most of the comments, but I've got to put in my two cents.
1. Yes, AS3 event handling is long-winded. But you've kind of picked one of the worst aspects of AS3, and made that the whole argument.
2. Your JS example uses callbacks, not Events, which you can also do in AS3 with just a few lines of could.
3. JS, in it's basic form, is tough to use to write large-scale apps. in without additional frameworks (jQuery, et al.). AS3's more structured approach, scales a little better out of the box.
4. You can always turn off strict typing and use dynamic objects in AS3, making it much more like JS.
5. As we learned a year ago, ECMAScript is a political football. It would be very tough for Adobe adopt it while continuing to innovate with the player.
6. You might take a look at haXe, which is a compelling alternative for Flash development.

Alex Bustin via the old blog says ... @adampasz

1) Sorry you picked up on eventing. This post is not about eventing.

2) Callbacks are a form of eventing. I stated you can do the same in AS3 in my post.

3) jQuery is for HTML. The idea is that the a JavaScript Flash API would be better than jQuery.

4) See my new project on git http://github.com/abustin/_flash

5) ActionScript and the features of Flash are two different things.
Adobe would be free to innovate in the Flash by just creating new APIs.

Adobe jumped the gun on ECMAScript 4. They should of waited for the standard to be finalized. I'm proposing the finalized ECMAScript 5 spec.

6) Like I've stated, it's a shame that it's up to the community to make the right calls.

Josh Tynjala via the old blog says ... In response to Matthew Fabb, while big projects like those mentioned do focus a lot of time on code optimization because it's important, I think it's pretty well known that the software renderer is the current bottleneck for most developers who routinely push the limits of what Flash Player can do. As someone who has ported things to mobile devices, I can say very confidently that all of my optimization work has been for the renderer, not the VM.

John C via the old blog says ... Flash developers currently have the choice of AS1, AS2, AS3, haxe and C (with alchemy)

Would it not be possible for javascript to be an additional choice and run alongside these choices? That said, is it even necessary to have another option?

Unity developers have a choice of javascript, C# and boo.

If I were to add another language to command flash, it would be C#, then I could move to unity and silverlight with only an API change.

Tink via the old blog says ... I'd be absoluetely gutted to loose strict typing, package name-spacing, verbose eventing and the classical-OO pretense.

Recently I had to step back to AS 2.0 for a mobile app and it was an absolute nightmare.

Benny via the old blog says ... I would love to see support for multiple language support (like C#) in Flash that would compile to *OPTIMIZED* AVM bytecode, but I would abandon Flash development if Adobe would drop AS3 in favour of (only) JS.

By the way, maybe the Hype framework (by Branden Hall & Joshua Davis) could be of interest to you?
http://hype.joshuadavis.com/

Iain via the old blog says ... Sorry but I think this would be a terrible idea. Most developers I know are reasonably fond of ActionScript3, especially if you compare it to other languages like PHP. We had javascript syntax for years - and it suited Flash fine when we were essentially just making flashier web pages. But people are making games and applications now, and I think everyone is used to the static-typing, code auto completion etc. If you think a particular AS3 API is verbose, then make a simplified wrapper for it.

I'd definitely support the multi-language compiler though -but it's not going to happen.

Timbot via the old blog says ... I have a different point of view, based on a few things.
1. OOP code is not more difficult that JS, it's just different. Will you write more lines of code? Possibly, but so what? Typing is not hard, use your code-completion and snippets. Learn templates and macros.
Your example of loading a jpeg is incomplete, because it doesn't talk about the fact that in OOP you would write the code once, give it a simple interface, and use it forever. And that interface would then be yours, customized to your specific use how you like it.
2. OOP and AS3 are strong in team-based environments. Having done a boat-load of both JS and AS3, I can say that JS is fun when you're whipping along by yourself writing new code. Picking up someone else's project is a different story.
3. Adobe did not jump the gun on ECMA4, if you're following it you'll see that others dropped the ball.

I'm not disrespecting, I'm just saying that most of what you describe as creativity-killers (strict-typing, packages, verbose events) simply are not if you follow some basic principles of OOP. In return you get code that doesn't make you want to poke your eyes out, code that people can collaborate on together.
Unfortunately, many of us working in Flash didn't get training in the basics of OOP, so it's a lot of work to go back and re-learn solid principles. Even now that problem is not being addressed (you don't see Flash in comp-sci programs), and that is the real issue here.

Alex Bustin via the old blog says ... I would of agreed with these comments a few months ago. But my perspectives have shifted as of late. I'm a long time Flash user, I know the platform inside and out. I hated AS1, I hated AS2, AS3 is something that actually worked for me. I've been an evangelist to AS3 for many years now - but I now feel a shift in my thinking.

Something I'm suggesting here is that the language never sucked, it was the API into Flash that sucks. I'm saying that AS1 might of been quite good if Flash had a nice API design, you weren't forced to work on the timeline and had a they gave you a simple modeling system for your code (such as CommonJS).

Alex Bustin via the old blog says ... typo fix: module system*

Iestyn via the old blog says ... Totally agree with Tink and Iain here; I'd hate to lose strict typing, etc. What you're suggesting sounds fine for small and maybe medium projects, anything larger would be a nightmare.

Compiling multiple languages to SWF sounds like the best idea, as Joa outlined at FOTB: http://blog.joa-ebert.com/2009/09/28/compiling-java-and-c-to-swf/

John Dowdell via the old blog says ... Sorry, I may have missed it, but where did you establish the case for the title and first paragraph?

(The subsequent screenfuls seemed to boil down to "I prefer loose-typing and such".)

jd/adobe

Kevin Newman via the old blog says ... I think your example could be solved with future extensions to Actionscript that would provide easier ways to instantiate statically typed class instances (c# has this kind of JS object notation for static types syntax). I would love to see better compile time expressiveness. Additionally I'd love some stronger runtime support for truly dynamic JavaScript like conventions, and maybe the addition of some other runtime sugar, like duck typing and also static structural typing. I don't see the need for ActionScript to go backward.

Additionally, I'd love them to go multi-language - two modes in the IDE (and maybe their Flex compiler) - Actionscript 3 (or 4 if we need an increment), and something like a true JavaScript profile (dynamic, perhaps with a proper DOM) - call it Actionscript Harmony, to align with ECMA - but additionally, provide some hooks in the core compilers (Flash IDE as well as Flex compiler) to allow third party languages like HaXe to hook in more naturally.

The runtime (AVM2 runs bytecode - the language used to generate ABC bytecode can be just about anything) has features for dynamic languages as well as static languages - why not take advantage with better compilers, and multiple languages.

Micah via the old blog says ... As a JavaScript developer, I have to disagree.

Debugging large, complex JS software is a total nightmare -- because of both syntax and how the language works with certain low-level structures. Even something as simple as passing an object by value can turn into a hassle in JS, and woe betide the unlucky novice developer that forgets to recursively copy an Object into the prototype of their class (one property shared across many instances. Good times.)

Also, I'm not sure why you said this post wasn't "about Events". The callback pattern you used as a demo of JS's conciseness is rapidly falling out of favor with JS developers, and is being replaced by slightly more verbose but much more powerful delegated evented systems. It's a clear example of how the patterns that make JS work excellently in small projects don't fit well in larger, more complex ones.

Overall I think the answer lies somewhere in between, or in compiling multiple languages down to SWF as another poster mentioned. JavaScript in its current form would drive me nuts if I had to use it to write Flash.

Ain Tohvri via the old blog says ... Whilst I agree with the artistic sentiment of the article, I also agree with Josh Tynjala's comment above. The code comparison is unfair. A prerequisite for the JavaScript code is basically a 50 KB JS library if you want a modern one, e.g. jQuery 1.3.2.

Without even diving into discussion about strict typing, I've wondered about AS3 block-level variable scope that IMHO is loose, differently from Java for instance.

Joel Stransky via the old blog says ... Loading and image != expressiveness. Filters, Pixel Bender, timer/interval/frame based animation, audio and video as bytearrays, font embedding, reliable presentation etc. THAT'S expressiveness. Simulating != doing. Granted FP is a VM but a bottle neck is simply not a big enough complaint to ditch what flash gives. It is and always will be a medium to display creativity primarily and to compare it to other ECMA languages is only a compliment.

admin via the old blog says ... @Joel You fail to understand the difference between the language the and features of Flash. I'm only talking about the language. I'm in no way talking about getting rid of Pixel Bender, audio, video or any of the features in Flash.

Brett Walker via the old blog says ... I think you're missing the elephant in the room here. The syntactic differences of JS vs AS3 are relatively unimportant. The real struggle going forward is that there are many forces at work that are focused on trying to push Flash out in favor of open standards: WebGL, HTML5, Apple refusing to run Flash on the iPhone (and probably iSlate as well). I think Adobe's only chance of Flash surviving over the long-term is to retool it to allow publishing of projects as HTML/JS sites using open standards technologies. I'm not suggesting that Adobe take away the ability to publish as a SWF, but Adobe needs to embrace the inevitable (and provide leadership for the future) before Flash becomes marginalized. And this is coming from a 12-year Flash developer and former Director/Shockwave developer.

admin via the old blog says ... @Brett - agreed. There is no reason why a Flash project couldn't be exported to WebGL. Maybe moving Flash over to JavaScript (ECMAScript 5) would help stem the tide of those forces and ease us into a world here Flash is a tool that exports to many places/platforms/frameworks. We'd get great performance too vs the Flash software renderer.

I'm aware the AS/JS syntactic differences are slight - that goes to strengthen my augments that AS isn't needed. Why maintain two very simular languages. JavaScript has a larger base, is widely used in different areas, is "the language of the web" - it makes sense.

John Wilker via the old blog says ... Not to derail, but this topic sounds like an awesome topic for discussion on an episode of The Flex Show.

Any interest? Would love to hear from Alex as the pro JS supporter and one you commenters as the against. This post and comments are insanely great, I gotta say.

I hadn't ever thought about Flash/Flex without AS3, but the idea is interesting

Druiven via the old blog says ... it's adobe itself that wants to get rid of AS by selling flash 500 dollars a piece with an as-editor that gives coders reasons to walk away and develop AS in Notepad for fun

Des Ulbe via the old blog says ... This has already been done - http://www.jangaroo.net/home/

adampasz via the old blog says ... John Wilker, that does sound like a good episode!

Also it would be good to cover HTML5 and whether it truly spells the doom of Flash like everyone keeps saying. Your Silverlight episode from a while back was great.

cortex via the old blog says ... a programming language without typecase is bullshit!
AS3 Syntax is ok, but C# is more reduce.. you dont must type function or var, only the type is needed.

Jon Williams via the old blog says ... 1) You do not *have* to use strong typing. It is *not* required.

2) As you know, JavaScript and ActionScript are cousins. They're practically twins. There's absolutely no compelling reason for Adobe to backpedal to what would look more like AS2.

3) If you want to write your own AS3 libraries allowing you to perform common tasks requiring less boilerplate code, knock yourself out. Do it well and achieve high adoption, and there's a good chance your libs will eventually make their way into the player API.

4) Also, ditto what @Micah said re: complex JS & nightmares.

Alex Bustin via the old blog says ... @Jon Williams

1) I know ... See the EDIT and EDIT2 from the post.

2) Wait what .. you almost agreed with me then took at 180. Why reinvent the wheel. Why maintain two very similar languages? I thought you just said AS and JS were "practically twins" .. how's it a backpedal.

Also I said nothing about AS2. It would prob. be more like AS1 with modules and an elegant Flash API.

3) Knock myself out? Sounds painful. ;D. I really don't think it should be up to me. Adobe should work with the community to fix the issue.

4) It's only complex is you fail to break up your code.


@cortex

You're clearly enlightened, but we're talking about a scripting language here. The clue is in the name and the name of the spec. ;)

Jon Williams via the old blog says ... PS
I don't know how much AS1 work *you* did, but I did plenty, and no matter how much you may think AS3 or AS2 sucked, AS1 sucked way, way more. ; )

Alex Bustin via the old blog says ... @Jon - I think AS1 sucked mostly because of the environment, awful Flash API and lack of a formal module system.

More AS1 bad things from the top of my head:
- globals & _root
- timeline centric
- setProperty & with
- onClipEvent
- ...


The API with JS would be cleaner ... maybe something like this ..

var display = require("flash/display");

var box = addChild(display.createSprite({
x:100,
y:450,
alpha:0.25
}));

Banned in Boston via the old blog says ... Alex: god NO!

Please read what Randy Troppmann said (I won't repeat it here).
Then maybe read it again . . .

I'm sorry, but the world of ActionScript has moved on from the days of animations and simple games.

People are doing _serious_, complex *applications* using ActionScript these days. For example, I'm no longer surprised to hear of Flex application teams that have more than a handful of full time Flex Developers.

My guess is that you haven't had much exposure to that world. Experienced Developers in that world take things like name spaces and strict typing FOR GRANTED.

I can't speak for every Developer like that; but, for certain, if I have to go back to JavaScript for serious applications, then I'll be switching to Silverlight or, at least, GWT soon after that . . .

Alex Bustin via the old blog says ... @Banned in Boston

I've been working with Flash since Flash 3 and on a daily basis for the past 5 years. I usually build ~40kloc sized AS3 projects in Flex Builder that go on for several months. I'm toward the engineering side of the devigners scale. I work in a team that is built mostly of C/C people. I hate the timeline. I'm consumer electronics focused ...

... What I'm trying to say is that I'm no stranger to large engineering projects and I know the Flash platform better than most.


I didn't say we remove all notion of namespaceing, instead you would replace it with a module system such as the one spec'd by CommonJS.


I've recently built a large scale UI project in JavaScript for an experimental platform that uses simple Flash like display APIs. It's some of the best work I've ever done. I've also built a sizable projects using Node.js too - super fun.

"ActionScript has moved on" - not sure I get that. It still drives Flash like it's always done. Flash has "moved on", not the language.

Luis Alejandro Masanti via the old blog says ... quote:
"The main point is, why use ActionScript if you can do it just as well in JavaScript."

Why not use just JavaScript, HTML5, SVG in place of Flash?
Just web open standards.
What it is needed are the tools to build.
And for Flash backward compatibility...
http://paulirish.com/work/gordon/demos/

Alex Bustin via the old blog says ... @Luis Alejandro Masanti

Because Flash has a solid ubiquitous runtime and it's features will always progress faster than web standards - thought there are only so many features a person needs to move media across a screen :D.

I see bright things in the future for WebGL. But hardware and compatibility are going to take time.

m1m1k via the old blog says ... http://ajaxian.com/archives/gordon-flash-runtime-implemented-in-javascript

oberhamsi via the old blog says ... why do most comments believe big projects can only be handled with static typing? that seems to be your biggest concern.

i spent the last 10 years porting ugly java code to readable, mantainable javascript (code that did financial database transactions in parallel on multiple servers).

the less features a language has, the easier not to fuck up.

> that your strict, encapsulated, loosely coupled structure

what hinders you to write strict, encapsulated, loosely coupled code in javascript?

------------

i beg you to learn javascript before you write if off as not worthy.

(
or at least read those primers
http://javascript.crockford.com/javascript.html
http://javascript.crockford.com/survey.html
)

Mihai Corlan via the old blog says ... @Alex Bustin

Disclaimer: I work for Adobe.

This is an interesting idea. However, there is one thing I don't understand reading your article and comments.

How JavaScript will be better suited for large and long time running projects (eg. applications, games), projects developed by large teams?

I think the inheritance based classes vs prototyping, the strict typing helps a lot when new people came to existent big projects (you have the tool support). Most of the big JavaScript applications are created by small teams and highly skilled people. And as a matter of fact these kind of developers are a scarce resource. For any programming language.

You said you developed recently a large JavaScript project. How easy and feasible will be to bring more people into the project?

Most people I talk to are asking Adobe for more "advanced" features: multi-threading, private constructors, methods overloading just to give few examples.

Alex Bustin via the old blog says ... @Mihai Corlan

I'm not proposing JavaScript would be any better (or any worse) for large and long time running projects. I'm simply asking the question, why ActionScript is necessary? AS3 is based off JavaScript spec, so why not simply use JavaScript?

I think any project is manageable as long as it's broken up into smaller chunks, such as modules, and you prohibit globals and overly abusing prototype on built-ins. Our large scale JS project was worked on by a team. I found code integration to be quite simple. I think we'd be able to add more people quite quickly. There are also ways to mimic classical OOP if you want to play well with people not familiar with JS, ex: http://ejohn.org/blog/simple-javascript-inheritance.

I think people who request multi-threading, private constructors, methods overloading must have nothing better to do. I'd love to hear why people really need multi-threading (and all the others) .. what do they intend to *solve* by using it? Methods overloading is only needed in a typed lang. Private constructors can currently be faked. ... Why bloat up things even more? Are we trying to scare people away? ...

.... I'll let Phillip highlight my point ... http://www.youtube.com/watch?v=LYIFoDgd7ho

Mihai Corlan via the old blog says ... Phillip is talking about API (Flex and Flash) and not about the language.

I'm sure that the API of many JavaScript frameworks doesn't fit on a movie ticket :)

Alex Bustin via the old blog says ... @Mihai Corlan

I know what Phillip is talking about and it is relative to your post. As a result of adding method overloading to the language, the API would bloat even more! You'd need API for managing threads, etc.

If people want Java, then they should move to Java. I'll ask again - why do people need these features? How will it improve Flash?

The Flash API size could be more than halved in size and still maintain functionality. The experimental platform I mentioned has an API that could fit on a sheet of paper and it can do most of the things Flash can (minus vector gfx).

The Flash language and APIs are way too bloated for what Flash actually does.

pyrrhon via the old blog says ... Javascript is not strongly typed! I have yet to see a compiler that can give good completion.

Franck Chionna via the old blog says ... why so many hate for AS2 ? I hated it months, but now as I know it very well I start to enjoy.... Javascript for me is a big past nightmare, especially when browsers fighted with different functions for the same results. fortunatly it's better now, but personaly I don't like the verbose of JS, PERL, PHP or AS2/AS3 is far more beautiful.

Sharedtut via the old blog says ... get real flash is powerful in comparison to javascript , and i do not see it
switching to javascript , maybe c or lighter version.

Alex Bustin via the old blog says ... @Franck & @Sharedtut

You guys need to learn the difference between language, API and rendering platform.

"flash is powerful in comparison to javascript" - flash is not a language

"browsers fighted with different functions" - that's API

oberhamsi via the old blog says ... AS2/AS3 = ECMAScript additional features
JavaScript in Firefox = ECMAScript additional features
JavaScript in IE = ECMAScript add freatures
...

ian pretorius via this site says ... I have a issue with strict mode and compile time errors , IF i have a class eg.. ComponentDTO which is used to set up and further act as a event object for a Component Controller class via the contructor (I do this to practice the DRY software development principle) and then extend ComponentDTO to say ControlPointDTO to use in a class named ControlPoint that extends ComponentController , I cant dataType a class member variable named "componentDTO" in ComponentController which stores the passed in DTO to the base implementation (ComponentDTO) Every sub class on ComponentController relies on its constructor call to super to handle boilerplate code initialisation for the DTO to be used as the event object in context(I have a custom event system) , this all works fine , but further referencing to the DTO within the other class members will all throw the "a call to a possibly undefined method or property .. blah blah.." So I have these choice left to fix it:

1. change dataType on class member "conponentDTO" to "*" or "Object"

2. turn off scrict mode

3. repeat all boilerplate set up code in every sub class of ComponentController just so i can up cast the DTO

4.. wish for a more intelligent compiler.

Firstly, the contructor attribute for the DTO in the sub classed ComponentController is data typed to the Class (ControlPointDTO).. secondly , the class member "componentDTO" is data typed to "ComponentDTO" and (ControlPointDTO) meets all requirments for the currently typed instance. I cant see why the compiler can not have the ability to up cast automatically under these conditions.

I would love to hear what all the dogmatic strict typing folks have to say concerning the current "target" member of the default AS3 event class which is typed to object.. the reason they do this is to get a more dynamic API working with the same one class , and then strict mode adds the burden upon the user of that event system to recast again to make the compiler happy. SO even adobe is using a generic data type to get superiour flexibilty and re-usability within the AS3 API they are offering to you.

PattersonSasha31 via this site says ... This is not really simple to buy dissertation online referring to this good post! Foremost some students have to see perfect <a href="http://www.primedissertations.com">thesis</a> or <a href="http://www.primedissertations.com">dissertation writing</a>, after that it will be doable to purchase publish dissertation online.

WillyR via this site says ... What if you want to handle the on success with multiple functions? What if you want to re-dispatch the onsuccess event to the stage so you can capture it elsewhere. Don't get me wrong I love JS but I ended up writing my own JS EventDispatcher to make my life a little easier.







Coming Soon