Home >
In parts of the Flash community, ActionScript 3.0 seems to have gained a reputation for being "hard"—particularly among those who have not yet tried the new language. Is the reputation warranted? Not in my opinion.
When ActionScript 3.0 was first released, the sheer number of new features it offered was a little intimidating. On first impression, many developers were understandably concerned that the language was going to be hard to use. A year and a half later, that initial concern seems to have developed into a widespread misunderstanding, perhaps even prejudice, that ActionScript 3.0 is harder than ActionScript 2.0 or ActionScript 1.0.
The most common laments I hear about ActionScript 3.0 are, "It’s too complicated," "It’s harder to learn/understand," and "It takes a lot more code to do things." Yet, rarely have I seen these complaints backed up by more than one or two examples. So let’s do some thorough investigation to see if ActionScript 3.0 really is as hard as people seem to think it is.
It’s Too Complicated!
I think the intuitive feeling that ActionScript 3.0 is complicated stems from the sheer number of features in the language, many of which are new. ActionScript 3.0 is certainly "bigger" than ActionScript 2.0 or ActionScript 1.0. But as developers, do we actually need to learn every detail of every feature in ActionScript 3.0? Of course not. Instead we simply learn what’s needed to get the job done. Sure, if you’re creating a sophisticated desktop application for Adobe AIR, you’re going to need a good knowledge of object-oriented programming and AIR’s application framework. But if you just want to control an animation’s timeline in the Flash authoring tool, you don’t need to know anything about the AIR framework, nor even object-oriented programming. You just need a little knowledge of timeline control functions, such as play() and stop().
There seems to be a common misconception that ActionScript 1.0 means "programming on the timeline" while ActionScript 2.0 and ActionScript 3.0 mean "object-oriented programming in externalized class files." That distinction is completely false. All versions of ActionScript have supported both timeline-scripting and object-oriented programming, and will continue to do so.
For example, suppose you’re working in the Flash authoring tool, and you want to move the playhead of the current timeline to frame 5. In ActionScript 1.0, you would add the following code to a frame script:
gotoAndStop(5);
In ActionScript 2.0, the code looks like this:
gotoAndStop(5);
In ActionScript 3.0, the code looks like this:
gotoAndStop(5);
That’s right: timeline control code in ActionScript 3.0 is the same as it was in ActionScript 2.0 and ActionScript 1.0. And there’s no reason for that to change. When you issue the command gotoAndStop(5), you’re writing valid, uncomplicated ActionScript 3.0 code.
I regularly hear people claim, incorrectly, that to use ActionScript 3.0, you have to know object-oriented programming, or every variable’s datatype must be declared, or everything has to be in packages and classes. In practice, none of those assertions are true. ActionScript 3.0 code can be placed on timelines, exactly as it was in ActionScript 2.0 and ActionScript 1.0. The code doesn’t have to reside in classes. Variable datatypes don’t have to be declared, even in the strict compilation mode. The language is designed to provide as much or as little structure and flexibility as the task at hand requires. If you prefer to program procedurally with functions and variables declared in frame scripts, you can continue to do so in ActionScript 3.0.
It’s Hard to Learn!
Surprisingly, I have actually heard university-level instructors say that they’ll be teaching ActionScript 1.0 and ActionScript 2.0 instead of ActionScript 3.0 because ActionScript 3.0 is too hard for students to learn. Once again, I think this misconception is based on the false notion that ActionScript 1.0 means programming on the timeline, while ActionScript 3.0 means Java-style object-oriented programming. ActionScript 3.0 certainly can create complex object-oriented programs. But you can also use it for all of the simpler scripts that people have been producing since Flash 4.
To determine whether ActionScript 3.0 is harder to learn than ActionScript 1.0, let’s look at a series of comparative examples showing typical code that a new programmer might have to learn. In each example, we’ll look first at the ActionScript 1.0 version, and then the ActionScript 3.0 version.
Here’s a short ActionScript 1 .0 script that waits for a .swf file to fully load before playing:
// Code on Frame 4
if (_framesloaded == _totalframes) {
gotoAndPlay(6)
}
// Code on Frame 5
gotoAndPlay(4);
And here’s the same script in ActionScript 3.0:
// Code on Frame 4
if (framesLoaded == totalFrames) {
gotoAndPlay(6);
}
// Code on Frame 5
gotoAndPlay(4);
With the exception of the missing underscores and capitalization in the variables "framesLoaded" and "totalFrames", the ActionScript 3.0 code is identical to the ActionScript 1.0 code, and certainly no harder to learn.
Next, let’s look at a very simple programmatic motion example. The following ActionScript 1.0 code animates a movie clip horizontally. It assumes that a movie clip instance named "ball" is placed manually on frame 1 in the Flash authoring tool.
// Code on frame 1
setInterval(moveBall, 20);
function moveBall () {
ball._x += 10;
}
Here’s the same script in ActionScript 3.0:
// Code on frame 1
setInterval(moveBall, 20);
function moveBall () {
ball.x += 10;
}
Again, the only difference between the preceding ActionScript 1.0 code and the ActionScript 3.0 version is the removal of the leading underscore in the variable name "_x". In ActionScript 3.0, named movie clip instances placed manually on stage can still be referenced by their instance names. Likewise, ActionScript 3.0 still supports the setInterval() function. However, the Timer class is now preferred over setInterval() because it provides better tools for starting and stopping the repeated execution of a function.
Now let’s look at a slightly more complex programmatic motion example, first in ActionScript 1.0. The code rotates a movie clip around a circle. As before, the code assumes that a movie clip instance named "ball" is placed manually on frame 1 in the Flash authoring tool.
var rpm = 30;
var radius = 150;
var centerX = 230;
var centerY = 200;
var theta = 0;
var degreesPerSecond = rpm * 360 / 60;
var now = getTimer();
var intervalID = setInterval(moveClipAroundCircle, 20, ball);
function moveClipAroundCircle (theClip) {
var then = now;
now = getTimer();
var elapsed = now - then;
var numSeconds = elapsed / 1000;
var degreeIncrement = degreesPerSecond * numSeconds;
theta += degreeIncrement;
theta %= 360;
var radians = degreesToRadians(theta);
theClip._x = centerX + Math.cos(radians) * radius;
theClip._y = centerY - Math.sin(radians) * radius;
}
function degreesToRadians(degrees) {
return (degrees/180) * Math.PI;
}
Here’s the same script in ActionScript 3.0:
// Code on frame 1
var rpm = 30;
var radius = 150;
var centerX = 230;
var centerY = 200;
var theta = 0;
var degreesPerSecond = rpm * 360 / 60;
var now = getTimer();
var intervalID = setInterval(moveClipAroundCircle, 20, ball);
function moveClipAroundCircle (theClip) {
var then = now;
now = getTimer();
var elapsed = now - then;
var numSeconds = elapsed / 1000;
var degreeIncrement = degreesPerSecond * numSeconds;
theta += degreeIncrement;
theta %= 360;
var radians = degreesToRadians(theta);
theClip.x = centerX + Math.cos(radians) * radius;
theClip.y = centerY - Math.sin(radians) * radius;
}
function degreesToRadians(degrees) {
return (degrees/180) * Math.PI;
}
Once again, except for the removal of the leading underscore in variable names, the ActionScript 3.0 code is identical to the ActionScript 1.0 code, and, therefore, no harder to learn. I’m not making this stuff up.
Moving on to another example, suppose you want to programmatically create an instance of a movie clip symbol at runtime. Here’s the ActionScript 1.0 approach:
- Right-click the movie clip symbol in the Library, and select Linkage.
- Check "Export for ActionScript"
- For Identifier, specify a name, such as "BallSymbol", then click OK.
- On the timeline, add the following code:
someParentClip.attachMovie("BallSymbol", "ball1", 0);
Here’s the ActionScript 3.0 approach:
- Right-click the symbol in the library, and select Linkage.
- Check "Export for ActionScript"
- For Class, specify a name, such as "BallClass", then click OK.
- On the ActionScript Class Warning dialog, click OK.
- On the timeline, add the following code:
someParentClip.addChild(new Ball());
The only substantial difference between the ActionScript 1.0 and ActionScript 3.0 approaches is the code used to programmatically create the movie clip instance and add it to the stage:
// ActionScript 1.0 code:
someParentClip.attachMovie("BallSymbol", "ball1", 0);
// ActionScript 3.0 code:
someParentClip.addChild(new Ball());
For new programmers learning how to "make a new instance of a symbol," I think the ActionScript 3.0 phrasing, "new Ball" is more intuitive than the ActionScript 1.0 phrasing, "attachMovie(‘BallSymbol’...)." The syntax "new Ball" expresses the concept of "making a new thing" more directly. The ActionScript 3.0 phrasing "addChild()" also nicely reinforces the concept of the display hierarchy where a "parent" movie clip contains "child" movie clips. Beyond phrasing, the ActionScript 3.0 approach offers another benefit: its class-based terminology helps new developers seamlessly transition to more complex object-oriented programming if they so choose. In ActionScript 3.0, the knowledge used to write "new Ball()" is directly applicable to all other kinds of objects, displayable or not. Once the developer has learned to say "new Ball()", then "new TextField()", "new Date()", "new MovieClip()", and "new ColorPicker()" are right around the corner. ActionScript 3.0’s consistent "new-based" display-object instantiation is less complicated than the previous collection of instantiation techniques, which included attachMovie() for Library movie clip symbols, createEmptyMovieClip() for generic movie clips, createTextField() for a new empty text field, and "new SomeClassName()" for non-visual objects. ActionScript 2.0 and ActionScript 1.0’s object-instantiation techniques were difficult for beginners to remember, and helped give Flash its reputation as a "quirky" development environment.
In general, I also find ActionScript 3.0’s new display system easier to learn than its predecessor because it has fewer limitations. In the past, new programmers learning Flash’s display system would inevitably encounter confusing limitations whose workarounds were undocumented, and existed only as Flash community lore. For example, ActionScript 2.0 provided no direct way to insert a new graphic between two existing graphics. Instead, programmers were expected to write custom depth management code that used swapDepths() to rearrange existing graphics on the display list. Likewise, ActionScript 2.0 provided no direct way to attach one .swf’s symbols to another .swf’s display list. Instead, programmers would typically place a "child" .swf inside the desired "parent" .swf and attach child symbols only within the child.
The workarounds for ActionScript 2.0 and ActionScript 1.0’s limitations have become familiar territory to Flash developers, but have been serious learning impediments for new ActionScript programmers. By contrast, in ActionScript 3.0, the display system pretty much just works, so new programmers spend less time researching awkward workarounds, and more time learning worthwhile programming techniques. In ActionScript 3.0, you can use addChildAt() to insert a graphic between existing graphics. You can also take a whole container of graphics offscreen and put it back onscreen somewhere else. And you can easily add instances of symbols from one .swf to another .swf’s display list. These things not only save time and reduce the amount of workaround code in every ActionScript program, they make good sense, which makes them easier to learn.
Let’s look at one final example comparing the learning difficulty of ActionScript 1.0 with that of ActionScript 3.0: submitting simple login data to a server. The ActionScript 1.0 code follows; note that it uses LoadVars, not loadVariables(), to send and load the data. The code assumes that there are two text fields on stage: usernameField (the login name) and responseField (the server’s response).
// Code on frame 1
var dataSender = new LoadVars();
var dataReceiver = new LoadVars();
dataReceiver.onLoad = function () {
responseField.text = this.serverResponse;
}
function submitForm () {
dataSender.username = usernameField.text;
dataSender.sendAndLoad("http://www.example.com/cgi-bin/login.pl",
dataReceiver,
"GET");
}
// Code on submit button
on (release) {
submitForm();
}
Here is the ActionScript 3.0 version.
// Code on frame 1
var variables = new URLVariables();
var request = new URLRequest();
request.url = "http://www.example.com/cgi-bin/login.pl";
request.data = variables;
var loader = new URLLoader();
loader.dataFormat = URLLoaderDataFormat.VARIABLES;
loader.addEventListener(Event.COMPLETE, completeListener);
submitButton.addEventListener(MouseEvent.CLICK, clickListener);
function completeListener (e:Event) {
responseField.text = loader.data.serverResponse;
}
function clickListener (e:MouseEvent) {
variables.username = inputField.text;
loader.load(request);
}
Frankly, I think that both the preceding examples would be hard for beginner programmers to follow. In both cases, to understand the code, the programmer must have a decent prior understanding of creating objects from classes, assigning values to variables, and registering for events. However, the ActionScript 3.0 version of the code offers several long-term benefits:
- In ActionScript 3.0, once you’ve learned to use URLLoader, you can load any kind of data, including binary, text, variables, and XML. In ActionScript 2.0 and older, by contrast, a separate class was required for loading XML (see XML.load()), and a competing mechanism existed for loading variables (loadVariables()). In ActionScript 3.0, the knowledge of URLLoader is portable to all types of data.
- In ActionScript 3.0, once you’ve learned to use URLLoader, you can directly apply your knowledge to the companion Loader class, which loads graphical assets such as .jpg files and .swf files. In ActionScript 2.0 and older, competing systems were used to load graphical assets (like loadMovie(), loadMovieNum(), MovieClipLoader). Furthermore, the ActionScript 2.0 APIs used to load graphics were unlike those used to load textual data. The lack of uniformity in ActionScript 2.0 and ActionScript 1.0 would lead new ActionScript developers to doubt their own code. I have often heard programmers ask, "Should I really use loadMovie() to load a .jpg file?" or "I want to load a raw text file, should I really use loadVariables()? That sounds like it’s designed for variables." or "When should I use LoadVars instead of loadVariables()?" By contrast, the ActionScript 3.0 loading APIs are simple and consistent: Loader is for loading graphical assets and URLLoader is for loading binary or textual data. Both Loader and URLLoader use a load() method for loading, and both emit the same load-status events (in the case of Loader, through a LoaderInfo instance). This uniformity makes the loading system in general easier to learn than it was in previous versions of ActionScript.
- In ActionScript 3.0, knowledge of addEventListener() and the built-in event architecture applies to everything in the language, from components, to network operations, to input events. Once you have learned to handle an event from one object, you have the knowledge required to handle any event from any object. In ActionScript 2.0 and older, the developer was required to learn up to four different ways to handle events, including event properties, event listeners, on() events, and onClipEvent() events.
- While we’re talking about events relative to the learning process, I think it’s important to compare Flash’s older on()/onClipEvent() system with the newer addEventListener() system. The former system provides a convenient way to attach a behavior to a visual object in the Flash authoring environment. The latter system provides a way to keep code centralized and manageable. Conceptually, the on()/onClipEvent() system was a useful development metaphor, but it never gained the full tool support it required to succeed. Too often, source code placed on visual objects became repetitive and unmanageable, leading to time-consuming bugs and difficult multi-developer workflow.
- Accordingly, the on()/onClipEvent() system has been removed from Flash CS3. I hope that in the future, Adobe will enhance the visual-development toolset enough to allow for a revival of the on()/onClipEvent() ethic. For example, perhaps code placed on a visual object should also be editable in an auto-generated class from a centralized location. Backed by the proper tool support, attaching event listeners to visual objects could be a healthy part of a productive workflow. Adobe’s new tool, Thermo seems to be moving in that direction.
It Takes A Lot More Code To Do Things!
One final ActionScript 3.0 misconception I have heard repeated online and in conversations is: "ActionScript 3.0 might be cool and all, but I just wish it weren’t so wordy! It takes so much code to do things that used to be easy!" Here are the only two examples I regularly see put forward as evidence of ActionScript’s verbosity:
1) To access a URL in ActionScript 1.0 and ActionScript 2.0, you use this code:
getURL("http://www.moock.org");
In ActionScript 3.0, you use this code:
navigateToURL(new URLRequest("http://www.moock.org"));
2) To load a .swf file into a movie clip in ActionScript 1.0 and ActionScript 2.0, you could use this code:
someClip.loadMovie("foo.swf");
In ActionScript 3.0, you use this code:
var loader:Loader = new Loader();
loader.load(new URLRequest("foo.swf"));
someClip.addChild(loader);
In the preceding two examples, the ActionScript 3.0 code is longer than the older code. But those two isolated examples don’t represent the general trend. In my own programming, I find that ActionScript 3.0 is not, on the whole, a more verbose language than ActionScript 2.0 or ActionScript 1.0. For example, in ActionScript 3.0, the code required to make a text field, a button, or a movie clip is about the same length as it was in ActionScript 2.0 and ActionScript 1.0. Here’s one example that gives the general flavor of the difference between ActionScript 3.0 code and older code:
// ActionScript 1.0 and ActionScript 2.0
someClip.createTextField("t", 1, 0, 0, 0, 0);
t.border = true;
t.text = "hello world";
// ActionScript 3.0
var t:TextField = new TextField();
t.border = true;
t.text = "hello world";
someClip.addChild(t);
Admittedly, there are 16 more keystrokes in the ActionScript 3.0 code. But I find that the new ActionScript 3.0 structures more than make up for those little differences. For example, if you want to move a text field to another movie clip in ActionScript 3.0, you do this:
someOtherClip.addChild(t);
In ActionScript 1.0/2.0, you can’t move the text field directly, so you have to write a function that makes a new text field in the destination movie clip, and then copies the original text field’s characteristics to the new text field. That’s a lot of extra code (and complexity) that you don’t have to write in ActionScript 3.0.
Likewise, things like regular expressions and events are a native part of ActionScript 3.0, but in ActionScript 1.0 and ActionScript 2.0, you have to write your own implementations or research third party implementations, at the expense of extra time and extra code.
Furthermore, there are numerous cases where ActionScript 3.0 is actually much less verbose than its predecessors. Consider E4X, the ActionScript 3.0 system for working with XML. Suppose you want to retrieve information from an XML document such as this:
<STAFF>
<EMPLOYEE>
<NAME>Marco</NAME>
<MANAGER>James</MANAGER>
</EMPLOYEE>
<EMPLOYEE>
<NAME>Graham</NAME>
<MANAGER>James</MANAGER>
<EMPLOYEE>
<EMPLOYEE>
<NAME>James</NAME>
<MANAGER>Dorian</MANAGER>
</EMPLOYEE>
</STAFF>
If you want to retrieve the second employee’s name in ActionScript 2.0 or ActionScript 1.0, you do this:
staff.firstChild.childNodes[1].firstChild.firstChild
In ActionScript 3.0 you do this:
staff.EMPLOYEE[1].NAME
var managedByJames = new Array();
for (var i = 0; i < staff.firstChild.childNodes.length; i++) {
if (staff.firstChild.childNodes[i].childNodes[1].firstChild.nodeValue
== "James Porter") {
managedByJames.push(staff.firstChild.childNodes[i]);
}
}
In ActionScript 3.0 you do this:
staff.*.(MANAGER == "James Porter")
The ActionScript 3.0 code is much shorter, and much more intuitive.
In isolated side-by-side code-length comparisons, ActionScript 3.0 sometimes wins, and sometimes loses. But in my own code I find that ActionScript 3.0’s cleaner structures produce generally shorter programs because my system logic can be expressed more succinctly, and with fewer workarounds.
I Want to Believe
By now I hope you’re getting my point: As a developer who’s been using Flash since it was known as FutureSplash, I simply can’t find any good reason to avoid ActionScript 3.0. I can still use it on the timeline for simple scripts, I still find the basics pretty easy to learn, and I don’t find it demonstrably more verbose than ActionScript 2.0 or ActionScript 1.0.
On the contrary, once I started learning ActionScript 3.0, I found programs faster to create and easier to maintain because of the cleanliness of the API and the coding assistance available in Flex Builder. Other things I appreciate in the new language (not already mentioned in this article) include:
- Much faster speed than ActionScript 2.0
- Binary sockets and binary data access
- Improved text metrics
- Programmatic access to sound spectrums
- Good integration with assets authored in Flash CS3 (see http://moock.org/lectures/ActionScriptAndFlashCS3/)
- Free compiler and development framework
- And here are 50 more: Reasons ActionScript 3.0 Kicks Ass, enumerated by Grant Skinner.
My advice? If you haven’t tried ActionScript 3.0 yet because you worry that it’s too complicated, don’t believe the hype. Do yourself a favor and try ActionScript 3.0 sincerely for a month of daily work. Then decide for yourself whether you like it. I highly doubt you’ll be disappointed.
- Early Flex 4.5 SDK released on Adobe Open Source
- FITC Day 3 - Afternoon: Ralph Hauwert (take 2), Theo Watson and Emily Gobeille, Brendan Dawes and Yugo Nakamura
- FITC Day 3 - Morning: Kristin Henry, Grant Skinner and Jeremy Thorpe
- FITC Day 2 - Afternoon / Evening: Jared Ficklin, Eric Natzke and Robert Hodgin
- FITC 2 - Morning: Ralph Hauwert, Jim Corbett and Joa Ebert
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
With Colin as teacher, AS3 is very NOT so hard.
--
A Colin's reader since AS1
I appreciate this article, and while I agree with many points I can't help point out my disagreement on few things.
I do think AS3 tends to produce more code for simple to moderately advanced projects. On balance, I think the formality can help you... but I still think you'll have more code for small cases. Some of your examples are cherry-picked to support your case. Sure, E4X is just the opposite (it'll be less code).
But... say you have students who are familiar with AS1 and your goal is to teach "programming"... not so much ActionScript. I don't see the point in covering AS3.
Your examples of code in the timeline definitely proves your points--but if you're going to code like that (not typing your variables for example) why bother with AS3? You're not going to get any speed improvement, right?
Finally, the biggest concern I have as I embark on projects and have to choose between AS2 and AS3 the reason why I still don't feel 100% confident in my time estimates with AS3 is simply the runtime error exception handling. I suppose it's partially a non-issue as such errors fail silently in the regular Flash player--but the debug player displays such runtime errors. I'd like to think I could make a project that NEVER has those pop up--but from the looks of many (not all) AS3 and Flex developers it isn't so easy to catch all those errors. While this is not a great reason to avoid AS3 (and it's not what I'm saying), I do think runtime error exceptions make it a much more difficult decision than simply "it's the new version, might as well use it".
For me, I'll stick to AS2 in the cases where the project is not super complex and when there's no specific benefit in AS3 that justifies the "investment". In a larger project or one where I need some new feature of AS3/FP9, then sure I'll go for it. I do think if you're learning right now, AS3 is the best choice--if for no other reason than the fact they've gotten rid of the funk (say, the countless event models and attachMovie).
If you want to go further in discovering AS3, there are a few nice and free screencast tutorials posted by Lee Brimelow on gotoAndLearn().
Hi Colin,
I totally love AS3 and I can't think of any reason for me to do AS2 again. I'm always suggesting an AS3 rewrite to all my clients that have an AS2 code base. This always pays off in terms of easier maintenance, better structured code and the lack of messy FLA files.
While I agree with your article in general, I don't agree with your conclusion. To any programmer, AS3 will be awesome over AS2. If they take the one or two days required to readjust, they'll never go back to AS2. The problem is really not this group of users, but rather the designers and lightweight developers ("deviners"?). To them AS3 really IS harder. I'll give you a couple examples:
1. AS2 was intuitive since they could easily grasp the concept of "onPress", "onRelease" and so on.
is really not intuitive at all. In addition, the AS3 Events don't match the old ones and building good button behavior in AS3 requires a bunch of code. I use a couple button-behavior classes that are easily reusable, but hard to grasp for non-coders (60+ lines of code in a class).
2. Timeline navigation is MUCH more difficult. I know designers that can do amazing things with Flash by just controlling MovieClips, but they have no chance understanding the display hierarchy in AS3. To tell the movie on the timeline above to play, they need timeline code like this:
If this casting fails for some reason, it could potentially halt the progress of the entire movie. This is a simple example. The designers I know use much more complicated timeline scripts to achieve the desired effects. They could of course try to get their head around the DisplayList and "Object.getChildByName" but that's an error prone approach. The DisplayList has some bugs where in some occasions, you'll only be able to see the objects beneath the layer your code resides in. I've not been able to reproduce this, I just now that it hits at random. Designers really can't use that...
3. The error messages thrown by the Flash IDE suck. I think it's less than 5 of them that actually could help someone learning AS3 where to look for errors, what could be missing and so on. There's next to no "intelligence" involved, just dumb messages that tell you little or nothing.
That said, I do find it much easier to teach AS3 to beginners than it was teach AS2 to beginners. The problem here is really explaining AS3 to designers and "deviners" that already know AS2. AS3 is really not easier for them at all.
J
"Surprisingly, I have actually heard university-level instructors say that they’ll be teaching ActionScript 1.0 and ActionScript 2.0 instead of ActionScript 3.0 because ActionScript 3.0 is too hard for students to learn."
And what about Pascal or C in a first year of University without any previous programming experience? I think that AS3 is far less complicated and is more exciting to start...and as you said and I tottaly agree you dont need to know everything. You should go step by step and try to search the web, get some good books and try to find some good practices.
Only an opinion.
Paulo Moreira
http://interactividades.blogspot.com
I am currently working on my first AS3 project and I find myself using a lot of time figuring out how to do relatively simple stuff. The display list, events and the way code and movieClips communicate and interact in CS3 IDE are among the things that are causing me most problems. My old AS2 ways are seldom working and I have to figure out new ways to do things. This takes time, especially since I think the documentation could have been a lot better when it comes to explaining how to migrate outdated AS2 functionality to AS3.
My general impression so far is that as long as I work more or less entirely in AS3 the process is fairly smooth. If I, however, try to combine AS3 with movieClips in the Flash IDE like I used to do in AS2 I seem to run into trouble on every corner...
Hi Colin ....
After Reading your book , i find AS 3.0 much easier and pwerful and thanks for such great article .
Thanks for the great introduction into OOP Colin. Like many others, I have learned all around Flash authoring--actionscript, interaction, best practices, etc...from your previous work (books, website, etc...). (Phillips book--ActionScripting in Flash MX was good too).
Colin Moock's books are very thorough. A great teacher, he guides you from the beginning, and prepares you well for advanced topics.
Colin's "encouragement" inspired me to write an AS3 FPlayer 9 application that utilizes the new lightweight components. It has a Flash GUI, a PHP backend, and MySQL storage for handling data input and retrieval. It came out pretty nice (even if I say so myself). The new components are simply nice, handle thousands of records with ease, and are easily skinnable. And to top it off, I still used a lot of what I learned in previous versions of Flash--since 5--I didn't have to create the whole App by creating my own classes either. When you work in the authoring environment (i.e. drag and drop MovieClips etc.) the Flash compiler automatically creates the classes for you. The new AS3 OOP Class structure offers much more control for programmers/developers/"Software Engineers" (as some prefer to be called). However, learning the built-in classes does take some serious time for us "un-classy" people. Just open up the documentation and you see 40 million Classes/Packages in multiple frames. Ok, a slight exaggeration--but there are a lot. I imagine that, for beginners of actionscript programming, there will be some intimidated by the sheer number of classes and the steep learning curve. I am encouraged by people who aren't afraid to "make it simple" so that others like myself can learn the basics first, then apply them in more advanced situations. Having been a teacher myself, I appreciate the efforts of anyone who strives to do this.
As Colin says, the new display API, URLLoader, XML, and Event handling was not all that bad, although I had his help and the documentation to assist.
I do have one complaint though, why doesn't Adobe give us the Tree component...come on...the Tree...they took away my Tree man...other than that, the new components are Flexy.
Oh yeah, one other complaint, Flex Builder 3 goes from 250 Meg to 400 Meg when I do multiple compile/degug sessions--might as well get a workhorse computer with 4 Gigs of RAM.
Procedural or Classes....that is the question.
hey phillip,
responses below:
PK: I do think AS3 tends to produce more code for simple to moderately advanced projects. Some of your examples are cherry-picked to support your case. Sure, E4X is just the opposite (it'll be less code).
--
i tried to select a cross-section of typical examples in the article. i'm just interested in the facts; i don't really have a "case" to make, other than dispelling misconceptions about ActionScript 3.0. if you have a list of examples showing ActionScript 3.0's verbosity, please post them here.
PK: But... say you have students who are familiar with AS1 and your goal is to teach "programming"... not so much ActionScript. I don't see the point in covering AS3.
--
two responses:
1) most core ActionScript 1.0 code is valid in ActionScript 3.0. if you're teaching fundamentals like variables, functions, loops, and conditionals, the code will be the same in both versions of the language. what exact content are you referring to when you say "I don't see the point in covering AS3"?
2) i think ActionScript 3.0 is a much better language than ActionScript 1.0 for teaching general purpose programming because it's cleaner and uses idioms that are more easily transferable to other languages.
PK: Your examples of code in the timeline definitely proves your points--but if you're going to code like that (not typing your variables for example) why bother with AS3? You're not going to get any speed improvement, right?
--
ActionScript 3.0 is a scaling language. it is as simple or as complex as you need it to be. if you're just using timeline control functions, the version is actually moot. ActionScript 3.0 includes the simple timeline control that was introduced back in Flash 4 and formalized in ActionScript 1.0 (Flash 5). "gotoAndStop(5)" is valid code in all versions of the language.
PK: Finally, the biggest concern I have as I embark on projects and have to choose between AS2 and AS3 the reason why I still don't feel 100% confident in my time estimates with AS3 is simply the runtime error exception handling. I suppose it's partially a non-issue as such errors fail silently in the regular Flash player--but the debug player displays such runtime errors.
--
don't be afraid of runtime errors. learn to love them. they dutifully lead you directly to the line of code in your program where a problem has occurred. runtime errors help you fix your code, which should save you time, not cost you time. the old silent failure system in flash player 8 and older cost much more time because it required you to hunt down your own bugs (even simple ones like method name typos).
jensa:
in response to this article, I have had many private and public discussions about upgrading ActionScript 2.0 skills to ActionScript 3.0. you have identified the two most common, and most serious issues:
1) on()/onClipEvent() are gone
2) parent.gotoAndPlay() requires a cast
i failed to mention issue #2 in my article, but it is extremely important. i think both issues need to be solved by adobe at the tool level. specifically:
1) the on()/onClipEvent() style should be revived with new and improved tool support.
2) parent.gotoAndPlay() should be made legal with automated tool behaviour. for example, flash could add the following compile-time assistance:
-if a symbol's timeline code uses methods of the MovieClip class on a parent, and all author-time instances of that symbol have a MovieClip parent, then auto-cast to MovieClip
-if a symbol's timeline code uses methods of the MovieClip class on a parent, and any author-time instance of that symbol has a Button parent, then generate a compiler error
-if the programmer casts manually, honour that cast
i think that the major authoring-tool impediments to using ActionScript 3.0 are fixable. hopefully Adobe agrees and will do something about the above issues. ActionScript 3.0 itself isn't fundamentally "harder" than ActionScript 2.0, the IDE just needs some important tweaks to make ActionScript 3.0 more approachable to Flash authoring-tool users.
as for better error messages, i have to agree. many Flash and Flex compiler errors are arcane, and could be made much more friendly. i love clear, helpful error messages, and i hope Adobe improves their messages over time.
thanks for raising the casting issue!
colin
hi wodger,
you wrote:
"If I, however, try to combine AS3 with movieClips in the Flash IDE like I used to do in AS2 I seem to run into trouble on every corner..."
please feel free to post specific examples here so we can all evaluate the issues you are facing. undoubtedly, you are not alone, and we might all be able to provide some guidance for others facing similar circumstances.
thanks!
colin
For those of you who is till thinking about jumping on the bandwagon of AS 3 - I recommend to wait until Actionscript 5 is released.
I think AS3 is harder (much harder) than AS1 if you do it right. And of course much much better. But, if you don't do it right (treat it like AS1) then I really don't see the point. It becomes extra typing for no bug reduction, extra structure without gaining scalability, and extra errors with no improvement in code.
As for teaching though, I would go AS3 (done right) regardless. The hard part of programming is never the loops or variables, it is the organization and breaking down of your intentions in a structured clear way. This is where oop, events, the display list, etc really pressure you to do it right. Even for eventual non-programmers, the ability cleanly deal with complexity is a very valuable skill...
5 cents.
I have to agree with Colin. Although I was somewhat frustrated and maybe intimidates by the fact that some stuff (mostly event(types)s and displaylist stuff) was very much different, it is something you simply do memorize when coding AS3 for a while.
You can't expect everything to remain the same but call for improvement at the same time. And apart from that, you don't _need_ to use all the (I admit, somewhat abstract) OOP features if you don't want to. Just stick to the timeline at first if that's you comfortzone. Hey, you can even stick to AS2, I just wouldn't try to mix it to much.
And if to some extend you (rightfully ;) ) _do_ see it as an improvement, why complain about some (really: some) extra typing now and then.
Anyways, the advantages (maybe off a bit here and there since I'm not at full steam yet) I see at the moment:
* the displayList stucture (eg. no more awkward getNextHighestDepth() etc)
* easily created objects like TextField, Sprite etc.)
* closed methods (no need for Delegate anymore)
* speed
Not to mention the new features like:
* Timer
* Easier Text(Field) control
* Less messy coding (I hate each time I have to use the MovieExplorer to find someone's code)
* framelabel access
* easier drawing of shapes
And yes, the helpfiles seem somewhat exploded in fragments at first glance, but that to is just different, not that much more complicated
...
Which is probably more or less my point: different is not more compicated.
Much as I admire Colin's work, and bearing in mind how useful and authoritative I find his books, I'm afraid on this occasion I disagree with this article.
My issue with ActionScript 3 is that it lacks a middle ground. Because of this it has forced a division between designers and programmers that did not exist previously. Basic timeline control is, as Colin suggest, pretty much the same as before. However, Incorporating relatively basic interaction (even something as simple as matching AS 2's behaviours) demands a understanding of programming that was not previously required.
As someone who has grown up with programming, I can see the advantages that AS3 offers, but it needs a programmer mentality - the conceptual ability of abstracting and decomposing a task that others have described here. I love ent propagation and the display list is great when you use it. Day to day, I work mainly with artists and designers. They don't want to create complex applications but they do want to deploy basic interactions and visual transformations, and they often want to incorporate sound. A lot of Flash development falls into this category of wanting to use relatively simple programming to create emotionally or visualy sophisticated results.
Frankly, AS3 has made the step up to this level of interactive creativity harder. It demands abstract conceptual thinking rather that does not always fit easily with affective visual thinking, and I find that people with a visual arts or graphic design background are deterred by this because Flash no longer feels like a visual tool. Of course, if the step if taken the rewards are greater; but the apparent difficulty of getting there is deterring artists and designers from trying. Colin is right that AS3 is a great language for beginner programmers; it's just not so great for experienced designers. Wierdly, when these two disciplines should ideally be getting closer, AS3 is currently driving them apart.
I don't think AS3 is harder to learn than AS2 when you know nothing about it.
AS3 is a big change from AS2 and people usually complain at first when there is change. But let me tell you this, I am now working on two projects, one in AS3 and one in AS2 and I can't wait to be just coding in AS3. What you can do is so much more. The speed gain gives you a bigger margin for a lot of stuff.
I do agree that making a simple button is now harder than before, but it's really worth it.
Coming from someone who is lucky to be an abstract thinker as well as a logical thinker, I don't see a problem with AS3, but I am guilty of coding in a more familiar language. AS3 is clearly more robust, flexible and faster but it is also more complex and different enough from AS2 that I still don't feel comfortable coding strictly in AS3. Perhaps I'm just reluctant to accept the fact that every new version of Flash comes with steeper learning curves when it comes to building logic into an app, presentation or game. Having said that, I am eager to learn about and take advantage of the features introduced in AS3. By the way, thank you for writing an excellent book.
I agree with Phillip, I too am not 100% confident of estimating the time needed to create a full-blown AS3 application/ microsite. The fact is that I'm still getting my feet wet on AS3, hence I code slower than I do in AS2. Transition to AS3 in my workplace is also not as fast, given the short datelines... I'm still looking for a project that will allow me enough time to transit to it. Mean while, I'll continue my read on the excellent EAS3.
Great topic, and timely in my case.
I have been with flash sine version 3 and been doing flash development since actionscript 2.0.
I was also under the misconception that AS3 was "harder" to learn, etc. This caused a little procastination on my part in getting involved with AS3.
About 6 months ago, I had started regularly using AS3 on most new projects given to me.
There is absolutely one thing above all that stands out in AS3 compared to AS1/2: Debugging is Beautiful
Things don't fail silently, you get both compile time and run time errors, which can be cumbersome. but only to your benefit.
End result? More stable, solid applications. With the right editor (I use FlashDevelop), you actually can buld thing MUCH MUCH faster, solely based on the error reporting features in AS3.
Now, my only problem is -- I don't want to go back to AS2, AS3 is just too awesome.
I have just transferred all of my code from AS2 to AS3 since last Xmas, I can say that AS3 is easier than AS2 to learn, it just took me a few weeks to learn and transfer all codes plus great help from Colin's great AS3 book:)
I didn't have a good first experience with 3.0. I found it much more cumbersome. I can agree with some of your points about standardized ways to call files and such, but it does not seem very intuitive at all. I will need to take more of a "recipe" approach to writing it, at least for a while. That is, I won't be writing much from memory, but rather referring to a recipe for how to do certain things. Check out my blog post on the subject:
http://www.personal.psu.edu/pzb4/blogs/besong/2007/12/actionscript-30-first-impressi.html
hi ian,
you wrote:
"However, Incorporating relatively basic interaction (even something as simple as matching AS 2's behaviours) demands a understanding of programming that was not previously required."
it sounds like you're referring to the removal of on()/onClipEvent() here. i think we all agree that that's a step backward for ease of use, especially from a designer's perspective.
hopefully the on()/onClipEvent() issue can be fixed by adobe. can you identify any other specific areas that cause problems for creating simple interactive content?
colin
hi qbix,
you wrote:
"Perhaps I'm just reluctant to accept the fact that every new version of Flash comes with steeper learning curves when it comes to building logic into an app, presentation or game."
i agree, the transition from ActionScript 1.0 to 2.0 to 3.0 has required a lot of retraining. each version of Flash has also included new components, which adds to the upgrade workload. that said, I think that the language has finally stabilized, and we can expect to see more comfortable, incremental improvements from here on out. the ECMAScript 4 standard is a good indication: most of the changes from ActionScript 3.0 to ECMAScript 4 are pretty minor. generally speaking, the fundamentals of the language still look like ActionScript 3.0.
Thanks for the insight! I'm really interested in moving over to AS3, this article has re-sparked my interest in it. Your AS2 book really helped me get into code, and I've already got a copy of your AS3 book, so I don't know what I'm waiting for really... Hoping that any new projects I get involved in I can use AS3. I am sure there are more benefits than you have listed as well! Thanks again.
hi robin! nice to see you here.
some responses...
RD: I think AS3 is harder (much harder) than AS1 if you do it right. And of course much much better. But, if you don't do it right (treat it like AS1) then I really don't see the point.
--
Using ActionScript 1.0-style timeline scripting does not equate to "doing it wrong". As I mentioned earlier, "ActionScript 3.0 is a scaling language. it is as simple or as complex as you need it to be." Even if you only use a few lines of code in ActionScript 3.0, you still get lots of benefits over ActionScript 2.0, including speed, a clean display API, and much better error reporting.
The ECMAScript 4 working group has put a lot of effort into providing a simple set of language tools for use in simple situations. Their work in making the language flexible applies equally to ActionScript 3.0 and the future JavaScript 2.0. For example, not everyone uses JavaScript to build Google Maps. Often, all that is required is 10 simple lines of code in the header of a web page. Simple, ad hoc scripts are not "wrong". They are a healthy, intentional part of the language.
RD: It becomes extra typing for no bug reduction,
--
By "extra typing" do you mean "declaring datatypes" or "more keystrokes". If you mean "declaring datatypes" remember that ActionScript 3.0 does not require datatype declarations. If you mean "more keystrokes", in my examination I have not been able to substantiate that claim (counter-examples welcome).
RD: extra structure without gaining scalability
--
ActionScript 3.0 does not force extra structure on you. "Using ActionScript 3.0" does not mean "using object-oriented design patterns." You can use simple timeline scripts, with no formal object-oriented programming structure. Do you have specific examples of what you mean by "extra structure"?
RD: and extra errors with no improvement in code.
--
Those "extra errors" help developers fix problems and reduce bugs, which by definition means improved code. ActionScript 2.0, by contrast, failed silently, leading to lengthy, time-wasting bug hunts and broken code. There's one big exception here: the parent.gotoAndPlay() casting issue that's already been discussed (and which I believe needs fixing).
>I simply can’t find any good reason to avoid ActionScript 3.0
I found one: the absence of removeMovieclip() equivalent.
It is not enough to argue that the job is done with removing the mc from the display list + checklisting page 807 of your (btw excellent) book "Essential AS3".
This page 807 is really painful ;-).
This "problem" was pointed by Grant Skinner in his episode 2 of his series about memory management:
http://www.gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html
It's really a big issue when working with dynamic content, or for example when flash is used as a level editor and is not possible to predict what a mc (or a 3d part SWF file) will contain and when you precisely want to use flash as a flexible tool.
Ok, it's certainly possible to "fix" these problems with specific code managing "the possibility of being removed" (!!), but I don't know if someone finally found a simple way to do that.
Any info?
Colin, first I just want to say thank for your all your work and books. Admittedly I don't read near as much as I should, but your AS 2.0 book really helped me break into programming in AS. So thank you. Since reading your book I've become a freelance/contract AS software engineer and currently on contract as MSN. We are strictly an AS3 shop here and for a lot of reasons. When I got here the whole team was transitioning from 2 to 3. I'll be the first to admit it was intimidating. It's different. Once you get over that initial hump you realize it's a thing of beauty. Memorizing, or at least becoming accustomed to what library to import for what class was one of my frustrations and that passed in time. For each of us here, once we made the transition, none of us have any desire to look back. The event model, delegates, and having all the API conform to better OOP standards are reasons alone for me to support 3 over 2. It simply allows you to write OOP correct code easier. Sometimes more code is easier to read and maintain if you've designed and developed it well. Now sure, my perspective is from that of a Software Engineer and I write 1000s of lines of code, so I can't much speak for designers or animators. 1 line vs. more capable 3 is quite fine with me. I will say, that anyone who learns AS3 for any application is setting themselves up to have a much easier time making the transition to better written code and bigger projects not to mention become competent programmers if your learning or career take you there. So do I think it's harder than AS2? No. I find it easier to code in. Do I think it's harder to learn? Hesitant yes, but only once you really get into it because there's more to it and when you get real deep it starts to require you to have some OOP understanding. As Colin pointed out, a lot of the very basics are the same or just have minor differences. I think the biggest hang up for people is the intimidation of it. Get over that and just start to dig in and you'll be golden. Anyway, I've rambled enough and will shut up now :) Cheers to all.
Hi Colin,
I have not made the move to actionscript 3.0 yet, and I want to say from the start that your books have helped me, and thanks.
I found the examples in this article too simple to help me decide if I should move. I have been programming for 28 years now, and and have always sought out development environments for my off hours pursuits that allow me to get in and do something quickly with a minimum amount of set up and ensuing fuss - leave that for work. Actionscript has been fantastic in this respect, and I am happy to read that AS3 doesn't require having to type variables, but what about declaring classes?
Do we still have freedom to declare classes as in this example? :
function ball( color ){
this.color = color
}
ball.prototype.traceColor = function(){
trace( this.color );
}
var myBall = new Ball( "red" );
myBall.traceColor();
////******************************
And, can we still just as simply embed the above class declaration within a movieClip library instance, and associate with with the movieClip class? ( using the RegisterClass method? )
If this type of easy class creation is still available, I will jump to AS3. But if I will have to use AS 2/3 Class declaration protocols and syntax, or have to start putting everything external files, it's no longer going to be as quick and easy.
Sometimes you want have fun while to getting things done!
thanks,
Gordon
I'm new to AS3 (or any version of AS) and although I'm struggling quite a bit trying to grasp the different graphical aspects of flash, I'm liking AS3 very much.
I am still somewhat overwhelmed, but I suspect it'll get easier as the days go on. I am learning AS3 largely on my own and I've had one year of classroom experience with Java. The game design class at the college I'm enrolled in is offering this course where I work with art students and I incorporate their art into a simple game.
From a beginner's aspect, (only a week old here), AS3 may have a lot of content to digest, it is somewhat intuitive (from a Java point of view) and not all that difficult to learn or implement.
Well, it looks like I answered part of my own question, and that is no, you cannot sub class a movieClip directly inside of a library object - please correct me if I am wrong - you have to do it in an external .as file.
But this is a step toward what I consider making AS3 more difficult than its predecessors. We now have to abstract out the subclass into yet another artifice ( the separate .as file ) which is less compact and less convenient. (For this reason I never used AS2's external class file structure either.)
When we allow the class definition inside the library object, there is a concrete correspondence between object and behavior that is easy to relate to. It's like being able to create a robot that you can pop open, rewire, and then send on its way - it's something tangible. I don't really even have to know the (linkage) name of the robot to get this to work.
With AS3, I am now forced to keep a separate file to control my robot. This means now two separate entities to control - the as file and library object, and a link between them. And I'm not sure, but can I even view these at the same time in the IDE? (note that .as files are edited in a window that is separate from other scripts - also making the IDE even more complicated)
Certainly Adobe could have given us the option of creating classes in both ways, as AS2 did, without the kinds of underlying performance penalties Colin is referring to. After all, isn't that part of what a compiler is supposed to do? Make it easier on us mortals?
Again, the reason I started with AS is that, in my experience working with 68000 Assembly, Pascal, C, C++ and JAVA, Flash AS it was the most convenient environment since Hypercard for doing something exciting without having to manage linking, libraries, multiple files, and class paths, and a complex IDE. With Flash you could just start coding and go. Advanced features were there for those who needed to take advantage of them, but we weren't forced into it.
After futzing around with this for a couple of days now, I can't see how one can make the claim that AS3 is moving anywhere near the direction of "Easier to work with" in any sense of the word. Is AS3 harder? I'm not sure, but the IDE has certainly forced me to use features that I didn't want to use before.
Cheers!
ActionScript 1 and 2 was horrific for large scale projects especially if you are using the timeline. Sure it works great for all the one-off projects everyone is doing.
I don't see why anyone would teach 1 or 2. Just read Colin's book. I did and was off and running in a matter of a week.
ActionScript 3 allowed me to design and architect a very intelligent system that can scale and allowed me to graduate to working outside of the Flash IDE by using the Flex SDK to compile and document my project.
Remember, nothing worthwhile comes easy. Study and practice is my only advice. It definitely pay$ off.
Thanks for the book Colin.
hi gordon,
you asked:
"Do we still have freedom to declare classes [using prototypes]?"
--
yes, no problem. that agile style of coding is still supported. in fact, ECMAScript 4 currently has a proposal to include even more support for quickly declaring (structural) types:
type Point = { x: int, y: int };
new Point(3, 4);
as for registerClass(), its symbol-related functionality is gone. (for object-encoding, use the flash.utils.registerClassAlias() function.)
i think the new symbol linkage system is much easier to use than registerClass(): just enter the name of a class in the linkage dialog, and you're done. however, the removal of registerClass() means that you cannot dynamically reassign a symbol's class at runtime. i think that's too bad, and will advocate for dynamic reassignment at adobe.
externalizing the class might seem like a hassle, but it does make the code easier to manage, and reuse across multiple .fla files.
colin
hi again gordon:
you wrote:
"When we allow the class definition inside the library object, there is a concrete correspondence between object and behavior that is easy to relate to. It's like being able to create a robot that you can pop open, rewire, and then send on its way - it's something tangible. I don't really even have to know the (linkage) name of the robot to get this to work."
--
i agree, there's something nice to that style, but i don't think ActionScript 3.0 itself precludes similar functionality from being re-introduced in the future. i think this example is not a case of an ActionScript 3.0 limitation, but a Flash authoring tool limitation.
note that with the registerClass() approach, your robot metaphor breaks down when you want to apply the same class code to multiple symbols. the ActionScript 3.0 approach lets you reuse the same class with any number of symbols. that said, i think a good tool should offer the best of both worlds: click an "edit class" button in the library to edit a symbol's class. Flash still has lots of room to grow into a better visual development environment.
as for simultaneous symbol and class editing, you can un-dock the file windows and tile your ActionScript editor with the .fla editing window. (I personally use Flex Builder to edit code, so for me, the code is already open in a tiled window.)
colin
hi gludion,
you make a great point: in ActionScript 3.0, the programmer is responsible for deactivating display assets that are no longer in use. in ActionScript 2.0 and older, Flash Player took care of that burden automatically when removeMovieClip() was called.
this is one case where i think ActionScript 3.0 actually is harder than ActionScript 2.0. unfortunately, i also think the additional work is going to be a permanent fact of life in Flash programming. ActionScript 3.0 lets you take a display asset off the display list, hold a reference to it, and then later put it back on the display list. this new functionality comes with a new cost: Flash Player can't know when you're "done" with an asset, so you have to deactivate it yourself. hopefully in time Flash programmers will get used to putting away their proverbial toys when they're done playing with them.
summary of ActionScript 3.0 issues so far:
1) on()/onClipEvent() are gone
2) parent.gotoAndPlay() requires a cast
3) can't dynamically change a symbol's class at runtime (as previously possible via Object.registerClass())
4) deactivating display assets that are no longer in use takes more work.
happily, i think 1-3 are fixable, and i'll do what i can to bring them to Adobe's attention. for now, 4 is a fact of life.
colin
I'd say I fall quite clearly into the designer turned super lightweight developer, more of a flash butcher than a developer really and I'm finding to quite difficult to get into AS3, this more of a personal shortcoming and lack of time than "the fault of flash" and AS3.
I think comments by Ian earlier are spot on. AS3 to someone who is from a programming background is a good logical step forward but for a lot of people I’ve spoke to who are from a design background now feel it's time to become one or the other, going back to a sole designer or investing their time into becoming a developer, where as previously there was this middle ground of existence where you could be both. This, arguably, to some is a better way of working both skill sets set firmly in their respective camps but for many of us in this middle ground and who quite enjoy the middle ground feel it's a bit of a loss.
While I have only become involved in anything Flash-related recently (and all with AS3), I will say that it seems like, with few exceptions, that the "middle ground" developer is not required to learn anything really complex from a programmatic standpoint. The biggest challenge is where things are done differently than in previous versions of the language, but that challenge is easily conquered through some familiarization with the APIs.
Someone mentioned that the addEventListener method is harder to grasp than onclick, etc. While I would agree that the method name (and the use of static constants to indicate the desired event to be captured) is at first a little less direct than the old way, I can not agree that it is harder to grasp. It's still pretty straightforward English, and, most importantly, it doesn't require any deeper programming knowledge than was required by the old way of doing things. It just requires that the designer/programmer memorize a different instruction. Surely no person could attach any significance to a function like goToAndPlay() prior to learning about it and what it does, but most veteran Flash builders know exactly what it means and how to use it, because they once took several minutes to acquaint themselves with it.
Yes, in quite a few areas, AS3 requires you to memorize different ways of doing things that you've done before, but I firmly believe that it is for the better--both for the language and for the way Flash programs are designed. AS3 is flexible enough to allow "lite" programmers to keep working as they have (if they learn a few new things) while opening up the door for well-structured, large-scale *applications* built collaboratively by designers and programmers.
First, thank you very much for Essential Actionscript 3.0, it was worth every penny of the $71.99 Canadian dollars I paid. I read the book from cover to cover. I would be more than happy to divulge my full thoughts on the book if that is so welcome.
Nowhere can I find if you can access a variable or function of a parent in AS3 like we could in AS2. I loved being able to do in AS2:
this.parent.parentFunction(); or
this.parent.parentVariable=value;
and access any variable or function within AS2 child/parent hierarchies either up or down the hierarchy at will with dot syntax.
This to me is an example of how AS2 could be used to achieve quick and intuitive results for all.
My first impression of AS3 was that it was a real **tch but now am starting to grow into it.
Recently I asked myself whether I would have continued to learn Actionscript 3.0 if I didn't already know AS1.0/2.0. AS3 has a fairly steep learning curve compared to it's predecessor though I feel once you reach a certain understanding your skills tend to plateau and things just start to "click".
I use flash for work and now shudder when I have to revert back to AS2.0 when building banner ads. Overall I feel AS3 does have some fairly daunting elements though once you get a solid grasp of the key concepts it becomes much simpler.
thx for responding, but..you said:
>4) deactivating display assets that are no longer in use takes more work.
It seems besides taking more work, some very useful possibilities of Flash are just becoming... impossibilities.
For example, "a flash site loading external SWF developped and submitted by various contributors" seems no more possible.
I mean, it was previously possible to load any SWF in a flash "site framework" (for example: game site, flash experiments site, educational site, flash-youtube, ... etc..) and unload these SWF. "Any SWF" here means SWF that can be submitted by anyone (studios, indies, amateurs, flash-gurus, etc..).
I did'nt check all the implications of the page 807 of your book, but if the loaded SWF has started a Sound for example, the SWF may not be garbage-collectible. Even if removed from the display list, those SWF would still be present and take more and more memory.
Even if the programmers of the loaded SWF afforded "more work" and explicitly managed the possibility of being removed, it's unlikely (because quite tedious, specially when human interaction is involved) that they would check/test the removal for any state of the loaded SWF.
Aside from asking more work from all SWF developers of the world, a better approach might be to do that job from the flash framework. But... It also seems that programming a super-function recursively walking a SWF and properly "terminating what has to be terminated" is quite difficult, or perhaps impossible. I didn't tried yet.
Has anyone any info about this?
why people are so frustrated about parent.gotoAndPlay() requiring cast?
Way I see it, using parent.gotoAndPlay completely breaks idea about loose coupling between components as you are expecting certain behavior to occur inside ui element.
Behavior code should almost always be coded on separate handlers that are aware of their context, and UI elements should just pass events that are catched on top level of the user interface.
If you are a visual designer and you have been following (and trying to keep up with) actionscript for the past 4 years you KNOW that the tool is now in the hands of engineers. Objects,Classes, Listeners, Dispatchers, Private, Public, Protected, Scope? This is just non-sense to your average designer who wants to add animation to their work. goToAndStop, LoadMovieClip, CreateEmptyMovieClip, now this is the language of a VISUAL thinker. I have spent hundreds of dollars and hours trying to keep up. I spend more time looking at code than I do tweaking my design. Trying to abstract the nature of a button and build a class around it is way less fun than just drawing it on the stage, calling it a movieclip, and writing a few functions to point it at. Seriously, it's sad to see a tool that let the average designer create some basic interaction be stollen by programmers who would rather program a square than just draw one. I have to say I have been forced to become a programmer and I think my visual creativity is getting rusty. Flash used to inspire designers to do cool stuff, now it just says, "stick with photoshop dummy"
I am on a new path. I am learning AS3. I am enjoying it. I have to learn this because this is how I pay the bills. But God help the guy who has been dabbling with a bit of HTML and CSS who wants to make a simple slide show for his client. He'd have an easier time with JQUERY than flash. which is exactly where designers are turning now that flash has forgotten who made it all happen.
IMHO there should have been a code fork about two years ago. FlashDev and FlashDesigner.
Josh,
You can still draw buttons in Photoshop, Illustrator, or the Flash Authoring tool and use them as buttons. You simply add an event listener that handles the click. It doesn't require any extra programming know-how; it just requires that you, like me, have to refer to or memorize a piece of knowledge. This isn't too much to ask--you had to refer to or memorize a piece of knowledge when you first started working with Actionscript in any of its versions.
You can create your button in a few easy steps:
1) Draw it.
2) Give it an instance name
3) Write the following Actionscript:
instanceName.addEventListener( MouseEvent.CLICK, functionToExecute )
If you want the button to have different states (up, down, over), all you have to do is make it a descendant of the simple button class (which isn't very hard at all) and set 4 instance variables, upState, overState, downState, hitTestState (that last one being the area of interaction, which you can set as larger or smaller than the actual button). These are new concepts to users of AS1 and AS2, but they aren't difficult concepts to tackle. Step 3 above is still pretty close to sensible English, and you can't get much easier than upState, overState, and downState. And you can still do all of it outside of a class definition. If your button is a subclass of SimpleButton (or just a SimpleButton itself), you can set those states as follows:
instanceName.upState = upState;
It's really that easy.
Granted, many designers complaining about AS3 have legitimate concerns, but it seems like a good deal of you are upset because there have been some language changes that require you to use a different instruction to accomplish something that you've been doing.This isn't something to get upset about. Just learn the new code. No one is asking you to become a more sophisticated programmer (not that it would be a bad thing...).
The reason AS3 is becoming more programmer-friendly in the first place is because people are using the Flash platform for more sophisticated applications. Something like Pandora.com would be pretty hard to manage without getting into more structured, sophisticated programming, and that's just one website out of many that are treating Flash as a serious, portable applications platform.
Not sure why my other replies never posted... (I did reply specifically) whatever. I do think this thread has turned into "AS3 may or may not be 'harder' but it's 'worth it'". I think that, sure, if you want/need it, it's worth it. I do think that there's a middle-ground programmer who is left out... and is especially alienated if they think they need to learn AS3 to keep up.
Oh, pandora.com is Flash player 6!
I didn't say that Pandora was written in AS3; I was implying that it requires a more sophisticated level of programming than that which is typically employed by the timeline programmer using the Flash Authoring Tool.
I didn't read ALL the comments here, but here's a HUGE reason not to go AS3 yet. Uptake of the Flash Players. If I code OO AS2 code I can still do most of what I need (ok big thing is no filters for effects - it just makes you more creative for the design side of things) and ensure that coded tweened, animation and integration with back end systems is no problem.
The thing is even if 1% of users only have FP6 and your corp is turning over a billion $ in online sales a year, then 1% of a billion$ is SIGNIFICANT. Hence AS2 (proper cleanly OO coded) will be need for a long time for us for any site that impacts income. For other (unnecessary) apps/websites, sure we might go AS3 so we can use the full gamut of toys (like papervision of FP8's filters). But until more of the masses uptake the player that supports it (yes I know it's over 90%) - then it's not viable for publishing where every user counts.
:p
Show me a corporation that's doing a billion in online sales that makes a significant portion of its profits from Flash. You aren't going to lose 1% of your profits because some of your customers aren't current.
I don't agree with the author. This language is way too hard and their ARE no good teachers out there. There seems to be an assumption in all of the books and vids I've purchased that the reader has a baseline knowledge that stops authors from defining terms. I hate the language and decided on going with VB.
AS3 only hard if you have been brainwashed into learning older versions of ActionScript with all the inconsistencies and work-arounds, adn their often akward entanglement with the timeline and the Flash IDE. Once you make the leap the clean-ness and beauty of AS3 becomes apparent.
I am so switched over that I do not even to touch Flash Lite anymore, until they have come over to the 21st century :-)
It seems hard to folks who have been indoctrinated into the AS2 workflow.
I migrated to AS3 as soon as it was avaiable, and I always use a standard FLA and Main.as file which I copy for different compiles, different projects.
The Flash IDE should probably make that initial step easier.
They should probably explain that your main document class (which seems to work best extending Sprite) is basically what you use as the "stage" - and how to use a static variable, i.e. an instance() function to access it.
If Main.instance() gives me my top level sprite, then I can always have another more specific class like if I create a Drawingboard.instance() which links to that. This is equivalent to the AS2 "_root".
AS3
var s:Sprite = new Sprite();
Drawingboard.instance().addChild(s);
AS2
_root.createEmptyMovieClip("s", ......
Whatever the case may be you are going to need access to your top level Sprite object at one point or another (an in some cases, the .stage property if you want to size and position something before you add it to the display list.)
Again, I think they could make this more intuitive to the AS2 folks.
Hi
Does anybody have sample codes for webservice in FlashCS3 using actionscript3. Icannot find one. help appreciated.
Thanks
Hari
most certain AS3 is an improvement. No doubt about that. But I must admit that it is irritating that my wellproven techniques doesnt work or at the best take me hours to understand how to implement in this new framework. After ten years or so in the industry I am lazy and prefer to focus on making great games for small kids. The programming is just a tool for me, and I pretty much have used the same technical concept /framework since AS2 arrived (I started with Lingo back in 96 and moved on to AS when it was mature : )
I have just spent (waisted) a workday with trying to figure out how to create movieclips from my arrays.
I often organize my stuff in arrays and keep references to my clips as Strings.
In As2 it is simple to construct and combine strings as references to library assets. attachMovie accepts strings. But in As3 I just can't find a way to make the machine interpret my string as a 'name of a movieClip'
the 'new MovieClipName()' doesnt give me a way to use a string. I have tried all the trix I knew from AS2 but nope. At last I found some very strange: getDefinitionByName and it seems to get the job done. I dont know If there are any cons???
anyway this is an example where aFrameClip could be a stringvalue stored in a complex array describing state, name of clips, etc.
private function attachTheFrames (aFrameClip:String)
{
for (var prop in grid_mc) {
grid_mc[prop].removeMovieClip ();
}
delete clipList;
var noc = 5;
var nor = 3;
var c = 0;
clipList = new Array ();
for (var i = 0; i for (var ii = 0; ii var clip:String = 'c' + i + 'r' + ii + '_b_mc';
grid_mc.attachMovie (aFrameClip, clip, grid_mc.getNextHighestDepth (), {col:i, row:ii, state:"front"});
clipList.push (clip);
grid_mc[clip]._visible = false;
grid_mc[clip].gotoAndStop ('init');
grid_mc[clip]._x = (grid_mc[clip]._width + 3) * i;
grid_mc[clip]._y = (grid_mc[clip]._height + 11) * ii;
}
}
}
cheers to Colin - I ' ve been with you since your first AS-book. Keep up the good work.
/ Lasse
Very timely and interesting article. On the whole I like AS3 but I agree wholeheartedly with the point Colin makes about half way down that the two AS2 structures that should be re-introduced in some form are ...
1) on()/onClipEvent() are gone
2) parent.gotoAndPlay() requires a cast
In general, object orientated programming only really has significant advantages over other structuring for larger projects where there are many moving pieces and you want to isolate code. OO is not some magical higher evolution of programming structure. For smaller projects, from a practical point of view, setting up a full object communication structure is a big fat waste of effort.
Adobe is pushing AS as a Rich Media Application development language and so I can understand and appreciate the new rigor in AS3 - but I think in their rush forward they need to remember that most Flash projects are fairly small.
In particular, the joy of flash was being able to quickly put together fun projects without having to worry about an unnecessarily rigorous structure. It was also great for prototyping and playing around with ideas. This is why it flourished.
Adobe denies this heritage of Flash at its peril. I'm a fairly hardcore programmer but there are many times when I've cursed Adobe for removing elements of AS2. And the ones I've cursed most are:
1) on()/onClipEvent() are gone
2) parent.gotoAndPlay() requires a cast
They are the bedrock of small fun AS projects prior to AS3. 1) allowed the quick addition of interactivity to graphical, drawn elements. 2) allowed easy controlled animation of those elements.
If I'm putting together a quick button-driven interactive animation (a big part of Flash output) why on earth would I want to deal with higher OOP structures just to add a button that starts an animation in the containing movie? I wouldn't - and no reasonable person would.
I'm all for moving AS forward but the removal of 1) and 2) was a bad mistake that I urge Adobe to remedy as soon as possible.
Oh! and point 4):
4) deactivating display assets that are no longer in use takes more work.
I believe this could be AS3's Achilles heal ... if you thought Flash devs wrote memory hungry, inefficient Flash code when there was automatic garbage collection, I'm not looking forward to see what happens when people forget they're now responsible for it themselves.
But - one thing I don't understand:
Colin, you say:
this new functionality comes with a new cost: Flash Player can't know when you're "done" with an asset, so you have to deactivate it yourself.
Why couldn't Adobe just re-introduce a removeMovieclip()-like method that TELLS Flash that you are 'done' with an asset?
Come on people. Just by reading the comments, most of you are experienced developers......you should be used to it by now. Adobe wouldn't be Adobe if they didn't periodically do something with Actionscript to screw with our heads. I could do things with AS2 that I am finding nearly, if not entirely impossible with AS3. I just accept it and move on to learning all new ways to fool Flash into doing what I want it to do.
AS3 is very hard. I have used Flash since its first version Future Splash. But I am more of a designer not a coder. The last thing I want to do is type out code. In AS2 I used the Script Assist whenever possible then modified anything else. The script assist in AS3 us completely useless! I view Flash as a design animation product & they are making it harder not easier to use.
Um, Colin...I think it's a bit tough, but
THANK GOD FOR ESSENTIAL ACTIONSCRIPT 3.0!
It's been a lifesaver!
Hi All,
Colin, first off amazing book man. I took the leap late in the game, but so far I'm happy with it. Just getting over the AS2 stuff is hard at the moment.
I've been searching for days and I can't seem to figure this little snag out.
Basically the problem lies in ability to target a TextField within a MovieClip.
This used to be as simple as MovieClip_mc.TextField_txt.text = "whatever"
This is no longer the case and I can't help but rip my hair out.
Here is a snip of code from the "popupHolder_mc" class file (which I use to declare all of the things that I need to control after "attaching" it to the stage).
package {
import flash.display.MovieClip;
import flash.text.TextField;
public class popupHolder_mc extends MovieClip {
public var header_txt:TextField;
public var dialog_txt:TextField;
public var popupBG_mc:MovieClip;
public var closeButton_mc:MovieClip;
public var okButton_mc:MovieClip;
public var cancelButton_mc:MovieClip;
public function popupHolder_mc (dialogType:String, dialogText:String=null):void {
//check the dialog type and move it to where it needs to go
gotoAndStop(dialogType);
//if the dialogText has something in it, then set the dialog_txt box
if(dialogText != null){
setDialog(dialogText);
}
}
private function setDialog(dialogText:String):void {
trace("DT: "+dialogText); //shows the dialogText fine
dialog_txt.htmlText = dialogText; //TypeError: Error #1009: Cannot access a property or method of a null object reference.
}
}
}
I'm dying here.
One thing that puts me off is the fact you can't display dynamic text on screen by just giving it a variable name in the preference box. I use this method quite a lot to show the status of variables while I'm writing or debugging something.
Having to create code to make a text box display a value is a real pain. It means you've then got to seek these bits of code out when you've finished debugging, instead of just deleting the text box. Sorry, that's a backward step for me.
I'm sure it's easy to learn, but there's just too many unknown unknowns (to quote somebody) that kind of puts me off the transition process at the moment. Especially as I make my living doing flash animations.
I was wondering if there were any invites left? If there are, I would love to have one. My email is alexbttf(at)gmail(dot)com
March 29, 2008 11:38 AM
Gustav said:
Amazing ! . Any invites left?
April 19, 2008 9:56 AM
Joaqo said:
This online applications suite is incredible, it is going to revolutionize the web forever! :)
Could I please have an invite (if one is available) to be part of that revolution?
joaqo ankara nakliyat
I'm one of those instructors who will state that teaching AS3 to people who have never programmed before is harder than teaching AS2 - particularly when your curriculum is based on examples which date from the AS2 era. To be balanced, you should include the kind of example that people like me tend to bring up.
The reason I think it's harder is that when I converted the sample AS2 projects I used in my class to AS3, I had to drop a number of features employed in those movies, because they involved introducing too many complex topics at the same time, when converted to AS3.
One of the first things I used to teach to newbies is how to make a simple play button. I notice that most of your examples do not include simple clickable actions.
The following code, which can be attached to the button itself, in AS2, cannot be duplicated in AS3:
on(press)
{
play();
}
The equivalent code in AS3, involves introducing a lot of unfamilliar concepts to the student (including naming the button, objects, and inline functions), whereas the AS2 version only requires that I introduce the concept of button event handlers.
You mentioned all the good reasons why this alternate method of event handling was dropped. They were good reasons, but nonetheless they had the unfortunate side effect of making it harder to teach newbies (who nothing about objects, embedded functions, etc.) how to make simple buttons.
In addition, a button with that simple code attached to it, can be cut & pasted, and the code that goes with it comes with the button. This is an incredibly useful feature for people who are first learning a programming environment. They take a long time to get the script working, and then they can copy the working script, simply by cutting and pasting the button from one project to another.
I agree that once one gets into more advanced programming, AS3 is easier in many respects. The problem is that simple playback control buttons should be a fairly simple basic concept. In AS2, they are. In AS3, they are not.
* * *
The second problem I have with AS3 is the lack of support for globals. I realize this globals are a popular bugaboo and I am likely a minority voice: It is my opinion that the revisers of languages should not enforce their personal style on us by eliminating potentially useful features that they deem to be in poor taste. For a very small hobbyist project, such as a simple adventure game, a few harmless global variables can mean the difference between 100 lines of code and 50 lines of code.
Not everyone who takes a class to learn a little programming is destined to work on large professional projects - most of my students are graphic designers with very little real inclination to program professionally. If one of my students does go in that direciton, he'll eventually learn good style (there are certainly enough people clamoring about it). But if he doesn't, he shouldn't be forced to code a little tiny project using techniques more appropriate for professionals.
Colin Says:
each version of Flash has also included new components
I don't think they added new ones, In As3 Adobe removed the DateField component they just dropped it to flex, wich i think is a way to force all of us to leave flash...
Yet another example that shows that even university profs are too stupid and lazy to learn a few simple changes to a language that in many cases uses LESS code.
People are lazy and this is what is being taught....hey here's a thought...lets all go back and learn BASIC, hell it did the job for me in 1983 with my good old TSR80 from Radio Shack...(which was considered a hell of a machine back then...wow,, 8hz).
Thank you very much for taking so much time to prove that people are lazy.
As for me, I love this language and what it finally enables action script programmers to do....code with real code.
Thanks for the comments everyone. Great discussion. It prompted a followup article, which you can read here:
http://www.insideria.com/2008/07/the-charges-against-actionscri.html
Collin great article. I have pointed everyone that visits my site looking for resolution to their ActionScript 3 Errors to these two articles. These are invaluable to helping people overcome the fear of AS3 and really drop the mental barriers so that they can focus on learning and being productive.
I did noticed that in your XML example that you are missing the end slash (/) on the employee named Graham which will give ActionScript Syntax Error #1100
Thanks,
Curtis J. Morley
P.S. It was great to hear you say FutureSplash.
Collin,
Excellent article I have sent everyone this way and also to your follow-up article from my site that helps people understand and solve their Flash and Flex Errors. After reading these articles Flashers around the world will be less prone to the chronic issues that Flash CS3 brings to the table.
Thanks again,
Curtis J. Morley
P.S. In the XML example above the employee Graham is missing the closing slash (/) which will produce AS3 Error 1100 Never fear you can find a detailed explanation on my site with code. :)
Its not the really the language. Its like Adobe took my paper work that might look messy to you and cleaned it up so i don't know where anything is.
onPress", "onRelease"?? i never used those anyway. I always used functions and listeners on the time line.
Qwerky AS2? no AS3 is qwerky. Packed with new features? Ha more liked packed with the same features just diffrent words.
So Tell me how do i point to dynamically created clips?
// ActionScript 2.0 code:
someParentClip.attachMovie("BallSymbol", "ball1", 0);
// ActionScript 3.0 code:
someParentClip.addChild(new Ball());
"ball1" was the old way i had my paper work not to mention its now totally a diffrent name. Loadmovie is gone swapdepths gone all the basic things have been renamed or removed.
You see what I'm getting at? I spend more time in reference manuals than i do developing. OOP who needs OOP for flash anyway? If your designing say a XML widget say a RSS reader do you really need to put all your action script in 20 diffrent files wrapped in classes? 99 percent of flash users don't build RIAs that need constant updating or editing. The other 1 percent well nobody visits their sites. We seen how major players switch back from flash to html/php/ajax in a heart beat. Would you design a site in pure javascript?
Flash is good for video, animations, ads, widgets, and that's about it. It's eye candy.and if you over do it you will piss off the end user.. So like i said most of the new features are pointless and the average web developer don't t work with just flash all the time (even though some clients enjoy those pure flash sites that everyone hates) so moving basic things around tend to piss them off. and flex and adobe air haha forget it.......
on the plus side I do like the bitmap and audio features and its good to know flash player 10 will have a new text engine something to look forward too,.
And to scott up top you have to point to the text not the other way around good luck with your flash OOP app.
@thawootah
"OOP who needs OOP for flash anyway?" - apparently you're not concerned with saving money on repurposing similar flash items you create for mulitple clients?
ActionScript 3 is a complete waste of time. There doesn't appear to be anything you can visually create in version three that you cannot create in version 1. It seems like the video compression got better and the file system reading stuff may have some new features but after using ActionScript3 for almost a year I find not having quick access to things or being able to duplicate movieclips or load external .swfs and target it's children movieclips and deploys them to the new movie a huge waste of time. I know I could setup linkage to create a custom class then create an instance of that class but what a huge wast of time and maintenance is a nightmare. I'm thinking of just using ActionScript 2 again sorry I haven't' found any features worth of upgrading I don't understand why people say it's better maybe get text extent is less buggy but dividing everything into little little sub classes of sub classes to save overhead of the powerful pig movie clip who cares why waste a day doing what takes minutes in ActionScript 2 everyone do yourselves a favor ditch ActionScript 2 version two is easier faster and you will not be missina any features.
im goingback to my old flash
Not all card-carrying programmers like to organize everything within classes, etc. I also use global variables quite regularly in projects...
But things have become way to cumbersome for anyone with a shred of sanity and good sense. Everything that was intuitive about Flash is now gone! Having many solutions and paths to solve any given problem is what makes a dev. platform/software *rich*. Cutting down on those options for the sake of novelty or runtime optimization is plain irresponsible.
Better stick with AS2 for the time being.
I have to agree with Jensa's first post. I am what she defines as a "Deviner". I am a web designer/graphic designer heavily into the design side of things (unfortunately, not much demand for people like me now a days). I also hold my own when developing simple to moderate Flash projects from banners to simple games to multimedia presentations. I use Director, Flash, 3ds Max, CouldFusion, and all Graphic Design/web design software. I do alittle of all aspects by myself. Don't have the time to learn and code a lot, just simple tasks to give projects a "WOW" factor. My experience as a Deviner is as Jensa suggests. It took awhile to get the hang of AS2, but made since coming from AS1. AS2 to AS3, however is way to difficult to learn in a weekend and remember and switch over.
I've been teaching multimedia programming for 12 years. WIth an emphasis on Flash/ActionScript since Flash MX.
I also strongly agree with Jensa's comments. I think Colin has gone for 'low hanging fruit' in this article (which by the way is a very useful piece for those who seek to 'upgrade' their skills).
True, simple timeline control and such is same old same old.
Even so, Colin was disingenuous in overlooking Jensa's two main issues, which are far from trivial. These are a major headache in introducing ActionScript 3.0 to 'deviners'. (Nice coinage!)
Having taught AS 3.0 to both upgraders and new users, I dare say that asking visual people to make and use non-visual objects (i.e. events and event listeners) to achieve visual results is where the cognitive break happens. Adobe needs to offer a simpler model for hooking up events so the designers can get back on board. I've seen dozens of Flash users shy away from ActionScript because of a labyrinthine event model which requires a lot of non-obvious theoretical understanding.
I also think the popup warnings function as barriers to learning. They should be off by default. New programmers need a lot of encouragement and a lot of reassurance. Warnings have the opposite effect.
The 'parent' casting issue is more of a speed bump for upgraders who are familiar with the easier old way of targeting, than new users, who know no better. Even so, it is an irritation, and seems unnecessarily complicated.
As a programmer, I think AS.3 is really great, but for a teacher of multimedia, it is a bit of a nightmare. The students just don't get it as easily as AS 2. I've heard similar things from many other multimedia teachers. Consequently, we've decided to drop most of our ActionScript sessions from the first semester curriculum in favour of JavaScript (which is a more approachable beginners language, and lays the foundation for AJAX).
It's a shame. I hope Adobe gives this matter plenty of attention for CS4
hi brennan,
you wrote:
"Even so, Colin was disingenuous in overlooking Jensa's two main issues, which are far from trivial. These are a major headache in introducing ActionScript 3.0 to 'deviners'. (Nice coinage!)"
Just to be clear, i didn't overlook Jensa's issues at all. Quite the opposite, i believe they are very important, and said so clearly in my original response to jensa, which was:
"jensa:
you have identified the two most common, and most serious issues:
1) on()/onClipEvent() are gone
2) parent.gotoAndPlay() requires a cast
i failed to mention issue #2 in my article, but it is extremely important. i think both issues need to be solved by adobe at the tool level. specifically:
1) the on()/onClipEvent() style should be revived with new and improved tool support.
2) parent.gotoAndPlay() should be made legal with automated tool behaviour."
the original article text also directly addresses jensa's "issue 1", as follows:
"the on()/onClipEvent() system has been removed from Flash CS3. I hope that in the future, Adobe will enhance the visual-development toolset enough to allow for a revival of the on()/onClipEvent() ethic."
for more direct discussion of both issues, please see this followup article:
http://www.insideria.com/2008/07/the-charges-against-actionscri.html
Hi Colin.
Your article is cool and I agree with it and all, but as a flash game developer who favors AS2, I believe your examples are only touching the tip of the iceberg. Not that I disregard the power of AS3. Actually I like what AS3 can do too, but then I have my own reasons and opinions on why AS2 is still easier to learn and use for people who are not really programming experts/geeks but want to develop something more than a few-hundred-KB-cool-AS3-effect movie.
Please read my thoughts here in this article if you wish to:
http://tamugaia.com/actionscript-2-is-still-good
Colin, I actually read your book while trying to learn Actionscript 3... and was left completely lost.
I respect your desire to teach "pure" actionscript- and it's surely more portable-- but there is an absolute dearth of resources or tutorial that teach Actionscript 3 the way I (and I suspect a lot of other people) want to use it.
I'm working in the IDE. I'm not pre-exporting SWF classes, I'm using the 'export for Actionscript' checkbox. I'm testing code on the timeline where I don't have to beat my head against a rock with includes before I migrate it out to .as files.
A lot of people /aren't/ developing rich multimedia applications. We're developing lightweight standalone crap that still needs the power of classes. I would have KILLED for a tutorial explaining the sort of headaches using a timeline-baseclass is going to cause, or how to creates a Global static class to hold data--- while still working in the IDE.
Instead I get a solid chapter on PACKAGE MANAGEMENT. Every package I use, at my level of complexity, is "Package {." And a cheery "Remember to include the bits you need!" without any clues about how to know what they are, what they're named, where the find the right addressing for the includes...
I don't know AS2. I was learning 3 right off. I've done a LOT of object-oriented programming in the past, so that's not the problem. I had Essential Actionscript, Learning AS3 and Foundation AS3 Animation (an absolutely stupid number of books to learn a language from) and NONE of them were taught in a way that was REMOTELY useful to me. Instead I was picking apart example files for 3 weeks solid before I actually "got" enough of how the basic architecture works-- all the unwritten assumptions-- to be able to USE any of those books for anything useful.
Essential AS3 was BY FAR the most useful reference work once I had that underpinning... but the opening chapters, which purported to be a tutorial? Not useful. (I know, your mandate was pure Actionscript. I can respect that. By NO ONE ELSE I can find teaches proper AS3 FOR the IDE either, so I'm crabbing at you.)
All I want a book that opens with the /apology/ "Actionscript 3.0 is kinda retarded. It's in transition from being a light scripting language to a robust object-oriented language, and 3.0 is a silly little in-between step that requires you to explicitly declare every variable, but doesn't require terminating semi-colons on lines."
Teaching AS3 like it's an internally consistent logical easy to use/learn language isn't USEFUL. Because it's not. Accept that it's hard and TEACH IT LIKE IT'S HARD, don't just keep telling everyone it's easy.
(Again, not /you/ so much since your mandate is pure Actionscript... but when people tell you AS3 is hard to learn and you retort "No it isn't!" I think it's this /gaping/ hole in the educational landscape-- POWER+IDE --that they're referring to.)
Also, I agree with whoever posted that your AS2/AS3 code-length samples were disingenuous.
Hello,
I would disagree of your opinion that AS3.0 isn't harder than AS2.0. It IS harder, but it also have its own advantages.
1. It is more organized, like programming languages, backtracking, error-finding, and stuffs would be easier. -- this also means you can divide tasks easier when doing a large project.
2. It can make vast more applications.
3. It is faster (I read a discussion that it won't be such faster if you use all bitmap images).
I'm currently new to Flash, less than a month ago I start by learning a bit of AS2.0 until I put into dilemma: AS2.0 or AS3.0. I dig around the internet to find basic tutorial for AS3.0 that easy to understand but it is scarce. At last I find a site that have simple tutorials ( http://foundation-flash.com ), and even more: the admins willing to answer questions (for free) and available everyday.
Now after like a week, I understand slightly around AS3.0 and able to combine functions from the tutorial and various sources on the web. But as more and more I venture to AS3.0 world, seems there is many things to learn, interesting things.
My direction is into game making though I'm not closed to know everything about AS3.0. Mr. Collin, if you had suggestions and advices for me, like step by step I need to do to properly learn AS3.0, please email me. :)
thank you
www.ankaraevdenevee.net
Yeah I'm reeeealllly excited about AS3. So are my clients, they're always asking me if there is some way I can charge them 5 times my normal price to make a simple game or some other basic animation with a bit of code in it. Now I can tell them YES! we can achieve this goal, because it will take me all day to do what used to take me an hour. Adobe has found a way to bolster this economy. Think of all the hours of extra work AS3 is giving us all!
I'm glad all the "real coders" are happy though. They can make all those "Rich Internet Applications" I keep hearing about. I've never had a single client ask for a RIA but there must be some out there. My clients want one-off projects: take their new product, make it spin, and play some music. Or maybe just make a simple quiz game.
Sure, I'll bite the bullet and learn AS3, I'll suffer through the extra time it will take to do the most basic things. It's either that or starve right? I wonder though, if the next generation of developers will just skip flash because it's such a pain to get into now. I feel like flash is being dictated by the small but vocal 'hardcore' developers. I think the majority of flash users never frequent these sites or attend flash conferences. Their voice isn't heard. Perhaps soon it will be, when none of these developers are buying CS4...
I feel the need to comment on this, though I have stated my case on Mike Chambers' blog previously.
1. @colin: I find the error reporting in AS3 to be VERY DIFFICULT to understand. I use the Flash IDE, and every runtime error directs me to a list of functions inside of classes that I then need to open up to run down where the problem is stemming from, and often the problem is simply being triggered there, while the source of the problem is elsewhere. Albeit, compiler errors give me a line to go to, though various bugs sometimes point me to the wrong line.
2. I have posted this example on Mike Chambers' blog as well, but I feel it fits here. People have told me that my AS2 code is incorrect, but it is not, and I feel that it emphasizes the extra code necessary to code simple things in AS3. It is a practicle example of navigating to a different url based on which button you press. The urls are stored in an Array that is defined outside of the scope of the function.
AS2 code:
obj1.onPress = obj2.onPress = obj3.onPress = function(){
var whichURL:Number = Number(this._name.split(”obj”)[1]);
getURL(URLArray[whichURL]);
}
That same thing in AS3 is:
obj1.addEventLIstener(MouseEvent.CLICK,doPress);
obj2.addEventListener(MouseEvent.CLICK,doPress);
obj3.addEventLIstener(MouseEvent.CLICK,doPress);
function doPress(evt:MouseEvent):void {
var whichURL:Number = Number(evt.currentTarget.name.split("obj")[1]);
NavigateToURL(new URLRequest(URLArray[whichURL]);
}
As you can see, the AS3 code is a bit longer. 308 characters as opposed to 144.
My other big qualm with AS3 coding is inside of that as well:
NavigateToURL(new URLRequest("http://website.com"));
Why is it that a URLRequest object must be passed into the NavigateToURL function? In AS2 it was much simpler to say: getURL("http://website.com");
This is not only more complex, and more code, but it is also more confusing, and requires the addition of another included class, just to open a website? It would be a simple matter to update the NavigateToURL function to allow the passing of either a URLRequest OR a String, and convert the String if passed.
thanks
msn nickleri
Excellent..
I agree for the most part, and I love AS3 now that I've learned it. There's just one thing I don't agree with. The event listener system in AS3 is certainly better once you get used to it, but (especially for beginners) the code can get tedious. For example:
// Instead of using a simple on() function, we have to use:
someMC.addEventListener(MouseEvent.CLICK,listenerrFunc)
function listenerFunc(e:MouseEvent){
//Code
}
Now, that's just one. But new programmers might end up thinking they have to add another listener for each MC! In truth, they can use this:
someMC.addEventListener(MouseEvent.CLICK,listenerrFunc)
someOtherMC.addEventListener(MouseEvent.CLICK,listenerrFunc)
function listenerFunc(e:MouseEvent){
if(e.target.name == "someMC"){
//Code
} else if(e.target.name == "someOtherMC"){
//code
}
}
Also, one thing you don't mention is the removal of MC and button scripts, all code has to be done on the timeline now. Now, timeline coding is better, but you don't mention it.
Otherwise, I agree with you!
What I am finding, as someone attempting to teach AS3.0 to folks who don't know AS at all is that, their are conceptual challenges with it that are more challenging than previous AS.
Attaching script to buttons in AS2 is less of a conceptual link than having to write everything in another "place".
I feel like if I could get my students over this "hump", the challenges would be the same as with AS2.0.
Unfortunately, we have only 18 hours to a complete intro to all that Flash has to offer including AS3.0.
I probably could have taught them AS2.0 but I didn't think that was fair to them. However, the challenges are intense and really no one is "getting" it. I know if we were doing AS2.0 at least a few of them would get it.
Ah well.
Wow!!!!! Lots of good info. Just my 2 cents..........From my personal opinion AS3 is better to learn considering it is close to a many other languages. It makes it easy to jump and learn another language. AS2 is easier in the sense that flash has a bunch of presets and AS3 does not. So for taking the easy way out............gone. I took AS2 and AS3 in school and found that AS3 to be better in the long run....sure I no longer have the ability to use presets like behaviors but that's not programming anyway. If I wanted the easy way I would go download it from fl@shden............lol
I think there are 3 major factors to AS3 being seen as being more difficult:
(I code using both AS2 and AS3)
1- If you've spent a lot of time and effort learning AS2 and then have to learn AS3 it can feel like quite a pain. Especially if you're projects require that you go back and forth between the two. I still experience this myself.
2- The advent of AS3 and it's advanced features has brought over a lot of developers from other, more complex languages. These developers are not only using their skills to create great work but have also brought over many of the standards and practices used in the software development world. So your average AS2 developer might see this new work and the techniques used to create them and feel very intimidated.
3- I would say that a majority of books, tutorials, articles, postings, etc. display the code using some level of OOP style programming. Anyone using these resources to learn AS3 would easily get the impression that this is how AS3 works. And even if they knew that one could just throw there code into the timeline the message sent is very clear, "OOP programming is the right way to do it". And who doesn't want to do the right way?
As ActionScript grows and matures it is being taken more seriously by developers across diverse platforms. Who knows, maybe one day we'll be writing server-side code using ActionScript.
Yeah I'm reeeealllly excited about AS3. So are my clients, they're always asking me if there is some way I can charge them 5 times my normal price to make a simple game or some other basic animation with a bit of code in it. Now I can tell them YES! we can achieve this goal, because it will take me all day to do what used to take me an hour. Adobe has found a way to bolster this economy. Think of all the hours of extra work AS3 is giving us all!
I'm glad all the "real coders" are happy though. They can make all those "Rich Internet Applications" I keep hearing about. I've never had a single client ask for a RIA but there must be some out there. My clients want one-off projects: take their new product, make it spin, and play some music. Or maybe just make a simple quiz game.
Sure, I'll bite the bullet and learn AS3, I'll suffer through the extra time it will take to do the most basic things. It's either that or starve right? I wonder though, if the next generation of developers will just skip flash because it's such a pain to get into now. I feel like flash is being dictated by the small but vocal 'hardcore' developers. I think the majority of flash users never frequent these sites or attend flash conferences. Their voice isn't heard. Perhaps soon it will be, when none of these developers are buying CS4...
Hey Colin. i came into the game as an artist/animator at Flash 4, and slowly became a strong coder.
i very much disagree with you. i think the proof is in the Moock pudding: take two novices. One of them gets to read your own AS2 book, and the other gets to read your AS3 book. AS2 guy will be up and running reasonably quickly, but i'll be flabberghasted if AS3 guy even makes it halfway through your other book. i had to abandon ship the moment you started talking about bubbling events.
i think that at this point, you're so solid on all of this stuff that you're very much living inside your own head, and you can't remember what it was like to know absolutely nothing. Your AS3 book was so thoroughly bogged down in details and technical accuracy that in your quest to be completist, you lost the plot.
Here's something, from a designer's perspective, that's absolutely wrong with AS3: i used to develop a lot of games with avatar puppets. The puppet contained the head, torso, limbs, etc. The head contained the hat, eyes, nose, mouth, and so on. Each piece would contain multiple frames for various hats styles, hand styles, torso styles, yadda yadda. i'd animate all of these "piece collections" on the timeline. So i could tell a character, to gotoAndPlay("walk") or "run" or "pickUpAnObject".
So let's take that last one - "pickUpAnObject". The object container wouldn't exist on the timeline until frame 30. The character would bend down, and at frame 30 i'd remove the object from the main timeline, and the object would start existing inside the character timeline.
Have you ever tried to control nested, timeline-built movieclips like this with AS3? You just can't. It's a near-impossiblity. With FP9+, the interpreter no longer pauses to draw the clip before the rest of your code executes. So you have to dynamically build everything with code, which completely destroys the power of the timeline for me.
This one issue alone has forced me to dramatically change the way i do things in Flash, and not for the better. It's a complete concession that hampers my creativity and the speed with which i could normally build stuff.
And trying to minimize the impact of removing onClipEvents is nonsense, because interactivity is such a HUGE part of Flash. It's like saying "You still have the whole boat! The lifejackets, the captain's wheel, the decks, the sails, the rigging ... you just don't have a bottom! No problem! Let's hope they address that soon."
If AS3 was such a cinch, a 7-year veteran (at the time) should not have had to spend two solid months full-time trying to get his mind around it. If it was such a piece of cake, we wouldn't have the vast divide in the industry where so many AS2 programmers have been left in the dust.
Here's my own rant from back in the day when i was trying to learn the new language, and having a very hard time of it (remember: 7 years' full time professional experience making kids' games in Flash at the time of this writing):
http://www.untoldentertainment.com/blog/2007/10/13/kicking-as-from-actionscript-2-to-actionscript-3/
and the follow-up, lambasting OOP:
http://www.untoldentertainment.com/blog/2008/04/22/as3-and-the-scoop-on-oop/
These days, i even disagree with some of the points i made, but the articles are a snapshot of a frustrated developer who felt (and still feels) that Adobe is ignoring what made Flash such a fast, fun and functional tool to use, in favour of earning street cred with brainiacs like Moock and Skinner.
- Ryan
It really worth reading for me, I just transferred all of my code from AS2 to AS3, I think that AS3 is easier than AS2 to learn, no doubt it took me some time to learn it but it worth; It makes my job a lot easier as i have to handle a lot of my canadian web hosting client sites; ( handling bluehost promotion sites in canada).
absolutely totally absurd....flash is no longer a tool to create great interactive graphics, with AS 3, it has become one huge monster of a learning curve, with very little productivity....totally agree with comments from Mr. Creighton above! Adobe has completely alienated a HUGE portion of traditional animators by insisting they learn OOP to do the simplest thing....Flash shouldnt be about coding, it should be about fun, and creativity, and play...and simply and easily creating interactivity...I am seriously thinking about droppping Flash, going back to video, where at least a timeline is still important, and coding is best left to the geeks....and we all know what beautiful work coders do...yes, it works, but is ugly...but the people that can make something beautiful, interactive and fun, can't any more...thank you Adobe, for destroying what i used to love...and until I can professionally drop Flash, making my life a living hell.
I am a designer and had loads of fun until AS2, pushing code far and experimenting things - maths, video, dyn. drawing, etc.
The needs in Flash animations for web sites decreased over the recent years, and I have stopped using Flash for a while.
But today I have to do something quite simple : dynamic drawing of squares and play with them; I know how do to do this in AS2 in few lines; I thought I'd try with AS3, just to stick with clean OOP.
Well, that's just hell, my friends.
I spent 48hrs reading books and just can't make work things simply.
It looks like it takes 5 files, 500 lines of codes to make what you could make (and still can - but for how long?) in 50 lines in a frame;
Colin, your book is great, and probably that AS3 is well done; yet I have 2 major comments to make on AS3:
- designers won't use it: for the reasons said in previous comments - too far from them and too complicated.
- if I can write good OOP and spend 90% of my time into coding, I'd rather program in Java and forget about Flash - Flash developpers are underpaid in comparaison of what good programmers earn in the industry (at least in France where I am).
So I think Flash 's golden age is behind. This is a pity, they were the best, and almost alone, but when you develop an animation tool you develop an animation tool.
I know plenty of former Flash designers who simply 'do something else' today for their living.
I fortunately today sell more my tastes than my technical skills.
Flash's pleasure for me today has become like crossing words.
There's a great flash dev tool out there for designers. It's called Swish Max. Version 3 was just released. Supports 99% of what most flash modules do and makes all the common tasks so very easy to do. Best part is it includes AS2 support so you can code to your heart's content if you like. No, I don't work for these guys. Just love the app.
I had a question when used ActionScript 3.0 "how to send arguments to a listener function along with an event" but one of my friends gave me the solution.
We shouldn't bother listening to people like Colin on these issues - you might as well ask the Adobe developers who created AS3. They're too far gone, they'll never be able to see things from our perspective.
AS3 is absolutely slow, painful, and inefficient to learn and implement. It is costing me business (and for some of my projects, I do need to use AS3 - or I'd never choose to) and slowing down my personal/entrepreneurial projects.
I don't care if it runs faster, and I don't believe there are any programmers who will now think "Oh, Flash has grown up - their programming language is now a 'real' language!" Hardcore programmers that I know either have no respect for Flash/ActionScript at all - or they're not even aware that you can program in Flash!
"Teach it like it's hard" is great advice. AS3 is going to hurt Flash like nothing else could have.
As ActionScript grows and matures it is being taken more seriously by developers across diverse platforms. Who knows, maybe one day we'll be writing server-side code using ActionScript.
Greats from Zauberer Frankfurt
did they pay you to write this article or something?
Hi colin,
As per your comments dated
January 31, 2008 8:44 AM
>happily, i think 1-3 are fixable
Can you pls. give solution to those two issues mainly 3rd of Object.registerClass() convertion from as2 to as3?
Thanks & Regards,
Sagar S. Ranpise