Introducing AS3JS

It’s been quite awhile since my last post, so I figured it was time for something big. Today I’d like to introduce to you AS3JS!


This is a little project I’ve been developing on the side in an attempt to make HTML5 development a little easier. It’s a command-line tool built with Node.js (and leveraging my previous library- ImportJS) that can convert AS3 code files into valid JavaScript. While it’s not perfect (hence why I’m calling it “dumb” for the time being), it’s definitely something I’ve found extremely powerful in some some large JavaScript apps I’m working on right now. This article will go over some of it’s features, as well as why I created it. (You’ll have to excuse me if I rant a bit, I wanted to spare the Github documentation all the TL;DR )

Example AS3JS Project

In case you don’t feel like reading all of this, let me start off by linking you to a cool little project I built in AS3 that runs in pure JavaScript. I even exported a Flash version as well just for kicks.

I certainly hope the demo convinces you to read this rest of this article 😉

Why ActionScript?

To be frank, I’ve grown quite tired of two things:

Why can’t we make JavaScript easier without adding so much baggage to the language? I say let’s take a step back from ES6 for a second and examine another overlooked language with a ton of potential on the web. For those of you already familiar with ActionScript, I’m sure you’re already well aware of some of its awesome features:

  • Typed variables
  • Classes
  • Package import system
  • Encapsulation
  • Much less “this” everywhere

Why not use these same exact features on the web? I don’t mean to put down ES6 and some of it’s strong points, but ES6 is still evolving as we speak while ActionScript has been a stable development language for years. It’s only recently that we started seeing attempts to convert AS3 to JS, and I think at the very least we could learn from such a language. TypeScript is a prime example of positive AS3 influence on the JavaScript language, although it itself is starting to conform to ES6 standards.

But ActionScript is Flash right? Flash is evil/stupid/dead/obsolete!

Now calm down for a second and listen to yourself. ActionScript is not Flash, it’s a coding language. The language happens to be a superset of ECMAScript, and as such valid JavaScript syntax is valid in ActionScript. AS3JS is not about Flash, it’s about ActionScript. If you don’t want to assign types to all your variables you don’t have to! But the fact of the matter is that you can, and in doing so you can get some pretty powerful features from your IDE like code hints, auto-completion, and automated refactoring. Not to mention how easy ActionScript’s package system is to use.

Do you have a problem with JS/ES6 or something?

The short answer is yes. But for me it’s all about redundant code. The number one thing that bothers me about JavaScript is how often you have to write out the word “this”, when inside class-like structures there is technically enough information to infer where “this” needs to be used. In ActionScript the “this” is implicit (i.e. optional) in class files, and there are very few situations where you actually need it. As such, AS3JS will automatically take care of prepending “this” where it’s needed in its JS output.

Now don’t get me wrong, JavaScript is my favorite language next to ActionScript. My favorite part about JS is its simplicity, and the fact that it does very little for you out of the box. It pains me to see new constructs are being added to the next generation of JS (ES6) that, while admittedly save keystrokes, slowly eat away at the simplicity of such a dynamic and expressive language. I would rather encourage developers to get comfortable with vanilla JavaScript and not rely so much on fancy new symbols and keywords that require keeping up with a constantly evolving documentation.

But what about TypeScript / CoffeeScript / ES6 / FlexJS / Jangaroo / Dart etc.?

Well since you asked, I’ll gladly comment on each of them:

  • TypeScript – To be honest, if I didn’t have the ability to write AS3JS (or if I didn’t know what AS3 was) I probably would get into TypeScript. But I’ve been developing in ActionScript for a decade and TypeScript looks eerily similar, so I thought “wouldn’t it be cool to use the language I have a preference for on the web?”. Also, TypeScript seems to be adopting many concepts from the ES6 spec, and it’s gotten the point where the two look virtually identical (minus the type safety). If that’s the case, I’d choose ES6 over TypeScript if presented with no other options.
  • ES6 – ECMAScript 6 is the latest version in the JavaScript spec. While it attempts to solve many “problems” in the JavaScript language, to me a lot of it just doesn’t look like JavaScript to me anymore and it feels like a lot of concepts from other languages being crammed into one. In other words, it’s as if everyone wants to satisfy audiences that come from completely different programming backgrounds. Things such as arrow functions, generators, destructuring (ugh, yes it’s less code but boy is it confusing), and the like, are great features for experienced developers but can become a serious obstacle for newbies. In addition, a lot of these constructs that were added can already be built without ES6, so why not standardize some JS libraries instead of building these things into the language just to save a few characters of text?
  • CoffeeScript – Let me just say that I think the syntax of CoffeeScript is the main turn off for many people, and as with TypeScript it has adopted many concepts from ES6. I personally find the code takes longer to comprehend at a glance without the curly braces, and the symbols it uses to save a few bytes of text just isn’t worth it to me. You could argue it just takes some getting used to, but you can say that just about any language. In a higher level coding language like JS I would prefer to code in a format that resembles its output form a little more.
  • Dart – Since Dart is newer than most of the other languages I listed above, the only argument that comes to mind for me is that this is just yet another language to learn. I think developers could benefit from mastering existing languages before adopting new languages that they are based on.
  • FlexJS – While it’s technically an AS3->JS converter there are several issues with FlexJS, the biggest of which is that it’s designed around the Flex SDK and is still in alpha. Flex also implies the Flash Player, and I think this is a turn off to many JavaScript developers. Why not let the AS3 language work independently from the Flash/Flex platform?
  • Jangaroo – This one is another AS3->JS compiler. Not only have most people not even heard of this, but I personally think the compilation process is overly complex since it relies on Java. The project also does not seem to be maintained all that well. I think Node.js is a much more suitable platform for converting any language to JavaScript since JS devs can jump right into it, and the JS community can even chip in themselves.

Final Thoughts

So in conclusion, I think it’s important we consider the potential of ActionScript as a native web development language. Even if my AS3JS tool doesn’t become widely used, I would find comfort if members of the JavaScript community (and Adobe) would take ActionScript seriously as a language for the web. As we slowly move away from browser plugins, let’s make sure the alternative moves us forward instead of backward.

Introducing My New GitHub

In preparation for my upcoming tutorials for Flash (and other similar posts I have planned) I have just created a GitHub account! 🙂

GitHub seems to be all the rage for open source fans out there, so I’ve decided it will be the best place to host my various creations for anyone to use.


I will be uploading not just Flash, but coding examples in other languages as well such as C, C++, Java, JavaScript, PHP and potentially many more.


For starters, here’s an AS3 class for easy keyboard input management in Flash:

Source Code:

I have created the above class to simplify keyboard input management in Flash. Back in the days of ActionScript 2.0, you used to only have to call one function to get the state of a key press. In AS3 it’s become a pain – you have to set up multiple events just to be sure of whether or not a key is currently held down. With my Key class, you simply initialize it and you’re done! Anywhere in your program you can type the simple words Key.isDown(keyCode) just like in AS2, and you’ll be able to get the state of any key without having to create a bunch of extra event mess. This is definitely one of the most useful pieces of code in all of my games (especially SSF2), since it completely centralizes key press management.

I will be adding many more utilities like this, so stay tuned for more updates!

FlashDevelop: A Must-Have for Flash Developers

FlashDevelop Logo

And now for another programming related article, I’d like to recommend an essential tool to all Flash Developers out there called FlashDevelop. It is an open source code editor available for free at

The best part about this software in my opinion, is that it allows you to code Flash apps and games without needing to pay for the Flash IDE. Currently I do still use Flash CS5 but only for graphics and exporting executables – lately I’ve started to use solely FlashDevelop for everything else. Keep in mind that I’ve been using Flash since MX 2004, and as much as I like Flash you learn to hate the IDE after years of bugs, crashing, and lost work…

Anyway, I will list the features I find most attractive as a Flash developer:

  • It’s Free
  • Code auto-completion as you type (far above the Flash IDE capability)
  • Very customizable (Tons of options and plug-ins)
  • Fast exporting (none of the overhead of Flash IDE)
  • Simplicity (Make a project file, write code, done)

I could go into more detail but if you code ActionScript and haven’t heard of this program I want you to download it and see for yourself. Even if you don’t use its more advanced features it’s still a great code editor for AS2/AS3. When you install, just make sure at least these 3 boxes are checked:

FlashDevelop Install Screen(Click to enlarge)

The Flex SDK is what allows you to export SWF files without needing the Flash IDE. The AIR SDK allows you to alternatively export your Flash project in the Adobe AIR format, a growing platform for desktop-based Flash games. Lastly, the Flash Player included with Flash Develop is what allows you to debug your projects if you are not testing through the classic Flash IDE.

It’s important to understand that the Flash platform itself is no longer something that is only accessible via Adobe’s latest Creative Suite products. The Flex SDK itself contains all of the resources needed to make a Flash game, and I feel that a lot of newcomers to Flash may not realize this which is the main reason for this article. Though I have to admit, the Flash IDE makes it a whole lot easier to handle graphics and animations….

A Quick “Hello World” App

To conclude this article I will write a simple HelloWorld application so you can at least know how to get started. I’ll be posting up things like code samples and tutorials at a different time. Assuming you installed FlashDevelop as described above, you should be able to start a new project right away. Simply go to Project->New Project in the menu bar, and fill out the form as follows:

FlashDevelop New Project Window(Click to enlarge)

I have chosen “AS3 Project”, named it “HelloWorld”, and chose a folder for it on my computer. The “Package” part can be left blank. Then click OK.

Next, you should have a Project panel on the right. If you don’t see it, on the menu bar click View->Project Manager:

Flash Develop Project Window(Click to enlarge)

Several files and folders have been generated for you, but we are only concerned with which is set to your Document Class by default. This is where your Flash application begins when you test it. If you open up there will be some pre-generated code inside. We can modify it to add a “Hello World” text box to the screen as follows:

	import flash.display.Sprite;
	import flash.text.TextField;

	public class Main extends Sprite 
		public function Main():void 
			if (stage) init();
			else addEventListener(Event.ADDED_TO_STAGE, init);
		private function init(e:Event = null):void 
			removeEventListener(Event.ADDED_TO_STAGE, init);
			// entry point

			//At this point, your code is guaranteed to be ready to go

			//Make the text box
			var textBox:TextField = new TextField();
			textBox.text = "Hello World!";

			//Move the text box to a decent spot
			textBox.x = 150;
			textBox.y = 150;

			//Add to stage

And that’s it! You can click the Test Movie button and you should see the following:

FlashDevelop Test Movie(Click to Enlarge)

All done. If you happened to hand-type the code, you might notice that while typing out “Textfield” FlashDevelop auto-generates the “import flash.text.TextField;” at the top of the file. This is one of the things I love about FlashDevelop since you never have to worry about missing references which can cause you serious headaches.

Anyway, hopefully this article gets you interested in FlashDevelop. I’m not going to go any further into actual coding since I only want to demonstrate how simple it is to set up. As I said above, actual programming tutorials will appear in future articles.

Mac Projectors Not Working When Compiled on Windows

For my first technical post I’d like to offer a workaround to a common problem that I’ve found when publishing Mac Projectors (.app format) on Windows in Adobe Flash CS3 all the way up to CS5.5 (possibly CS6 as well). I’m hoping Google indexes this as soon as possible since there seems to be a lack of information on this issue…

Those of you who are familiar with compiling Mac projectors on Windows may know that the file appears as a folder instead of an executable. Often times this file will load on some Mac computers but not others, or none at all. Well it turns out that this may be due to you using a NTFS file formatted hard drive. I suppose some files aren’t written properly to NTFS due to this folder formatting of the .app on Windows, so you need to compile straight to a FAT32 formatted drive if you want to maximize Mac usability.


Step 1) Find a USB drive somewhere that’s formatted to FAT32 (or format one yourself, and always remember to first back up your files from the drive before formatting)

Step 2) Set up your Flash IDE to publish the Mac projector straight to the USB drive.

Step 3) Use a archiving program such as WinRAR (confirmed to work with WinRAR) and zip up the .app directly on the USB drive.

Step 4) You can now move the zipped archive from the USB drive anywhere else and distribute to your Mac users!

It’s a silly workaround but works, and I hope that Adobe addresses this eventually. I recommend always having a drive somewhere that’s formatted FAT32 (or has a small partition for FAT32) since the Mac environment tends to favor FAT over NTFS.

Hope I’m able to help someone with this issue!