BIT-101 [2003-2017]

The Future of MTASC


From Nicolas Cannasse (creator of MTASC) on the OSFlash list:

As announced at OFLA today MTASC will unlikely support ActionScript3.
The reason is quite simple. MTASC supporting AS3 + AVM2 will be very comparable to Macromedia Compiler provided with FlexBuilder2. And only having the “opensource” difference is not enough.

My proposal is then a new language (name still unknown) that will support several platform :

– the Flash platform of course, with in the beginning current FlashVM and later AVM2.
the new language will try to make it easy to port your existing AS2 code to it (or at least as much difficult as porting your AS2 to AS3).

– the Brower platform, by allowing Javascript code generation. So you can write all your DHTML and AJAX *strongly-typed* with this language, and interact seemlessly with Flash.

– the Server platform, since it will be able to run on the NekoVM, and then you can write *web pages* and *standalone executable* using this language.
It’s also great since you’ll be able to have to communicate with the same-language from client to server, and you can access all the NekoVM libraries (sockets, databases, file system, ….)

So it’s really one language, which syntax will be near AS2 and Java but still different and more flexible (more powerful also) and which evolution will be driven by the community. By you.

An interesting decision. One of the biggest pulls for using MTASC currently is that it is a command line compiler, which you can integrate with the IDE of your choice. You are not limited to the Flash IDE. Also, the compile times are orders of magnitude faster, and it has much stricter error checking.

With Flex Builder 2 shipping with its own command line compiler that potentially has more options than MTASC, “what becomes of MTASC?” is a valid question.

Is the fact that it is open source and free enough to justify its existence? Apparently Nicolas doesn’t think so. Actually, I’m not sure the “free” part is even a big issue. MTASC is now free, which theoretically means you don’t need to go out and spend money buying Flash 8 to create SWFs. But I bet there aren’t many (if any) MTASC users who don’t also have a copy of Flash installed.

It’s not so much about the price as the flexibility, and the fact that in many ways, MTASC is a better tool for creating Flash RIAs than the Flash IDE.

So assuming that most serious AS3 developers will likely have a copy of Flex Builder 2 with the command line compiler installed (not all, but most), what advantage would an AS3 MTASC offer? If you are one of those who believes that open source will change the world, I guess that’s enough for you, but religious issues aside, I think I kind of agree with Nicoloas that that differnce is not enough to invest the huge amount of development time into.

While I’m sad to see MTASC as we know it go, I’m not too excited about the idea of it becoming a new language tool. At this point we have AS1, AS2, AS3, MXML, Flex 2 MXML, Xamlon, NeoSwiff, Laszlo, and several other language options for creating SWFs. It’s already impossible to keep up with them. Creating this new language might be cool, and I am sure it will have some great features. But while learning this new thing might be fun, I highly doubt it’s something that I’m going to invest much time or energy in.

Most projects I do are as part of a team. A team of other Flash designers and developers working with Flash and standard ActionScript. One of the greatest things about MTASC as it exists is that it uses, for the most part, standard AS2. Actually, it’s probably “more standard” than MM’s compiler. In other words, I can use MTASC, but pass off my .as files to someone else using Flash, and they can still compile them. A new language might have some nifty features for a one-off, one-man project, or if you are lucky enough and brave enough to get your whole team using it, that’s great. But I think the majority of large development projects will continue to walk hand-in-hand with the standards defined by Macromedia.

« Previous Post
Next Post »