First of all, there are more things than typed arrays (vectors) in AS3, the main thing being a consistent runtime. Also the way you structure an AS3 project is different since the language supports packages/classes etc while in JS you (for better or worse) don't have these concepts so you end up with many different code styles. Even though browsers implement the some of the features, there are subtle differences in the implementations. This results, in real world scenarios, that this stuff are being abstracted away, layers and layers of abstractions, libraries for everything. I have my doubts that this SWF interpreter can be efficient.
So when ActionScript is compiled to JS, do they mean it's actually pure JS, or is this getting converted into ASM.JS? Historically, a big appeal of Flash vs. JS has been performance - ActionScript is an ugly language, but it's statically typed. And JS/canvas/whatever historically haven't been too efficient at moving vectored objects around the screen.
Then again, a the factor in Flash's favour isn't the run-time, its' the development workflow.
I agree. I had to go back from AS3 to AS2 for a project and it felt like a step backwards, and AS2 is more like Javascript. Adobe has also open sourced the AS3 runtime. But of course the practicality is that we have Javascript in browsers, and there's a big get-the-job-done benefit to using a common language.
Overall AS3 with Flex felt great, and I used it for one of the funnest projects I've ever worked on (prototyping for a new GUI system).
The inbuilt widgets functionalities were great, with things like skinning functionality and the ability to place shaders on widgets right on your fingertip. States were easy to model.
I think it took Javascript years to catch up, and while now some of the modern frameworks (React, Angular, Vue) might be ahead in lots of regards, they might still be behind in others.
Actionscript itself had a pretty weak type system compared to what Typescript can do now (or could do years ago). E.g. there were no generics, apart from the some kind of semimagical vector. So this one is the smaller loss.
I totally agree. I developed a 3D rendering engine using Flash + as3, and I think it's my favourite platform I've ever developed for. AS3 is a great language - Brendan Eich referred to it briefly in his Lex Fiedman interview, apparently it was essentially a potential successor to Javascript that never made it into the browser, which I found interesting. I wish it had become a new standard.
Doesn't sound like they were devs at all. Flash's AS3 (and to a lesser extent AS2) were pretty good languages and after learning them it should be pretty easy to transition to JS. AS3 was, imho, a better ECMAScript implementation than JS was, especially because it was typed. As someone who worked in both AS3 and JS I still miss it a bit but it wasn't that much of a leap to work in other environments.
Maybe I'm missing something, but what's wrong with ActionScript? I've never used it, so I don't have much to go on besides the fact that it's based on ECMAScript/JavaScript. Being a superset of JS can hardly be considered a bad thing.
You still get the prototypes, dynamism, and functional programming of JS with AS, right?
I haven't worked with flash in at least five years, though I had worked on quite a few decent sized projects with it before then. I became quite competent with Actionscript 3 and absolutely enjoyed working with it. I'd always hoped Javascript would lean in that general direction, as was generally assumed early on (not that I dislike ES6).
I especially liked the potential for writing things dynamically and then refactoring toward strictness over time while moving a project beyond the prototype stage.
I would agree that Actionscript 3 as an implementation of ECMAscript is more of a delight than JavaScript as a language which conforms to whatever version of ECMAscript. But compiling to VMs in the browser? Never again.
Porting HaXe to AS3 wouldn't have solved the C++ part of the server component.
Even if I didn't need the C++ part, HaXe way of doing things is very different from Flex. Also, the code for SWF generation required quite a bit of linear algebra, which scared the original developers (the code had to take various properties of display objects and convert them into matrices of affine transformations, because that's how SWF format natively encodes it).
Even after all that, the code would lose a significant portion of performance gained from it being written in HaXe. HaXe made two significant improvements on MXMLC: since it was able to prove type correctness at compile time it removed type checks at run time (that's almost like removing half of the bytecode). And, on top of that, if it was able to resolve a reference during compile time, it generated a more efficient code for lookup (i.e. MXMLC generated code that stacked all contexts within function visibility and whenever a non-local variable was referenced it'd put a call to a function to look through this stack; this especially penalized the code with nested functions).
> Likewise I doubt that the parser being written in C was the problem
Doubt all you want, but it was the problem... Why did you choose to second-guess me if you were never there, never interacted with people in question, never seen the program in question? Like, on what authority do you think you know better?
> the problem was probably that (I assume?) you didnt also provide the convenient python bindings
You guessed wrong...
> Otherwise it's hard to believe that someone would throw away finished code.
You must be new here... I've seen this more times than I can count. Sometimes it's even a good thing.
> seems a bit too lazy.
Being lazy and ignorant is the name of the game. This is what people in general are made of, but when it comes to programmers, they have fewer checks that make other professionals resist being lazy and ignorant.
> don't want to deal with it.
Because, let me repeat it: ignorant and lazy.
> Also I wouldn't want to inherit Prolog code either because it's an ancient niche language, IDE and docs and everything else is probably terrible.
You are also demonstrably ignorant and lazy: you didn't bother to check, and decided to spew a bunch of nonsense.
* What difference does it make in what year was a language created? English is older than Esperanto, does this make English worse? Hebrew is older than English, is Hebrew worse?
* Prolog is alive and well. Multiple language implementations released new versions in the last year. A lot of academic research happens in Prolog because, conceptually, it's newer and more advanced than, say, Java or Python.
* Documentation is fine. Python documentation is a lot worse for example, because it's written by idiots... Python documentation writes simply don't know how to do it well, so it doesn't matter if there are many of them, or how much effort they put into it -- what comes out is garbage.
* I haven't experienced technical problems programming in Prolog. Installed SWI Prolog, wrote some code, ran it, fixed errors, ran it again... nothing out of ordinary. Editor support was not a problem, not anymore than editor's support for Python or any other more popular language.
Remember Java bytecode backward compatibility hampering language evolution, in the generics (erasure) debate and result. Then they broke bytecode compat anyway.
Flash has two language implementations in it, one for AS2 and the other (Tamarin) for AS3. Only way to be sure about AS2 compat!
In many ways, with JS you have one problem; add bytecode and now you have two.
AS3 is one of those things where we needed to put in a lot of work just to get basic things working, because the runtime is a hell of a lot stricter[0]. On AS1/2 we could hook up a few basic things and have basic games working. Further complicating things was that a lot of under-the-hood things about frame lifecycle are different, in ways that took a while to fully understand.
There's a bunch of work going on with Stage3D that's pretty promising.
Socket support on the other hand is probably not happening since the web doesn't allow arbitrary TCP/IP sockets. You'd need to switch to WebSockets for Ruffle clients - fortunately we support `ExternalInterface` so mixing AS3 and HTML5 code is possible.
[0] AVM1 has no runtime errors aside from infinite recursion and infinite prototypes. This leads to some absolutely ridiculous consequences even for basic operations, like prototype-less objects sorting differently from ones with prototypes.
Indeed. I was tracking a lot of these projects a few years ago because we had a Flex/AS3 RIA (remember that term?) so I was hoping we'd get a freebie port to HTML/JS.
In the end, we ended up writing our own AS3->JavaScript transpiler[1]. The Apache Flex project has since done something similar, though by the time that was done, we were done. So my skepticism stemmed from just seeing these projects come out, get some quick wins from implementing a simple subset of swf, and then just go nowhere.
But I wish them well. I hope it works out.
[1]Well, not totally ours. We used the existing Falcon compiler front-end and we wrote the emitter to transpile to TypeScript (after implementing a subset of Flash SDK that we needed).
It's weird this is would even be seen as a negative. AS3's ecmascript-based language isn't even bad. It just had some brain dead runtime decisions (untyped arrays), and a horrible editor. Most people I know would gladly work with the AS3 language over javascript. Haxe looks closely related to AS3, but trust me, it is far easier to work with.
Also just wanted to mention that Haxe3 is just around the corner...
not really, if you're writing flash apps, there's a huge chance that you're actually writing as3 code, which gets compiled into DoABC tags (actionscript bytecode) and I don't think DoABC tags will ever be supported unless they implement a stack-based virtual machine in javascript.
It gives the appearance that it got cheaper to re-target, but really it will be a ton more work when you realize what will never be supported. Even if they managed to implement a virtual machine in javascript, they'd still need to implement all the library code that normally doesn't ship with every swf file.
reply