Adobe Flash API ported to Dart | Hacker News Reader

Adobe Flash API ported to Dart

github.com

62 pointscnp36 comments

AS3 -> Dart -> JS, a bit much don't you think? I'm not sure who is trying to use a web stack three levels deep and dart based no less. I'm skeptical of how long dart is going to last at google, but this is definitely an impressive piece of work regardless. If it was AS3 -> JS and worked as well as it does now, i feel the web would collectively lose its shit. Unfortunately though this is tied to google, and i don't think many people want to be stuck being supported solely by google anymore.

agreed. Dart even though it has some awesome features, is still a technology preview, so I also wonder when it will be "stable" (some apis aren't "finished" yet) and it's a Google only thing. On the project's github page, you can read "The problem with JavaScript is that it sucks." ... JavaScript sucks if you don't know how it works, just like another language ... and what's the point of writting this when Dart itself compiles to JavaScript (who the fuck uses Dartium as their primary browser), finally the demo throws 18 errors ... fail.

> so I also wonder when it will be "stable"

It should be out of technology preview later this year.

> JavaScript sucks if you don't know how it works

It's possible to understand JS and want better. I think the people behind V8 and Dart know how JS works.

> what's the point of writting this when Dart itself compiles to JavaScript

What's the point of writing anything in any language? The Dart VM will be included with Chrome and other browsers are free to include one, too; Dart->JS is for browsers that don't and the goal is that it'll perform similar to hand-written JS.

> who the fuck uses Dartium as their primary browser

Nobody. It's for development until the Dart VM is included with Chrome.

Exactly -- that's why this is exciting, particularly the Flash / interactive part. The authors have done a very good job with what they have to work with, with the assumption that they're only working with a preview and that the primary medium will be a VM with a JS fallback. The performance, all said, is very, very good.

"finally the demo throws 18 errors ... fail."

I just runned it on FireFox and Chrome, and it didn't have a single error, you running the demo on what browser ? Did you even run the demo ?

This is a good start for anyone wanting to learn what Dartium is: http://arstechnica.com/business/2012/02/google-has-released-...

Stay happy.

Agreed. I would be inclined to invest my energy in a new platform that was built for HTML5 from the get go.

This might be useful as stop-gap. But I would hate to bug-test anything built using this method.

think of all the AS3 developers starting to feel left out in the cold now that Adobe's walking away from Flash.

while i'd agree that now's probably the time to jump into JS and HTML5, some people think Dart has a future, and I guess this opens up its potential market.

Adobe is walking away from the mobile player but still has Air out in the wild wich produces a lot of good chart topping titles on the Android and iOS app stores.

In my opinion, it is better to pick up Haxe if someone is coming from AS3. You can use javascript for the HTML5 compile target, you get extended Mr. Doob three.js support provided by the author himself, node.js through the Noxe Lib extends, and much more. And that is just for the HTML5 target.

It even target compiles to Android and iOS through the Haxe NME framework.

They are adding Java support to the thing and it has been doing c++ and php for some years. There are no silly ";" fights and honestly it is good to be able to use the same code source to run on multiple plats.

Though Dart may well pick up and Easel is already becoming a thing.

>AS3 -> Dart -> JS, a bit much don't you think?

That's not what this is. The API has been ported, they haven't written a AS3 -> Dart compiler.

Still, it's an indirection because AS3 primitives are not Dart primitives.

I've never used it, but jangaroo seems promising

http://www.jangaroo.net/home/

Example:

http://www.jangaroo.net/files/examples/flash/open-flash-char...

Thanks for sharing the link! I'm the author of the library and the demos. It's great to see some positive feedback. You can also check out some samples (i like the mask sample most):

Samples: http://www.dartflash.com

Source: https://github.com/bp74/dartflash/tree/master/samples

Some words about the Dart language. It's great to work with this new langauge and much more fun compared to javascript which is a pain when you come from the ActionScript/Java/C# world. In Dart you feel at home right from the start. Google is very much committed to the project and we will see pretty amazing things in the future. Of course the Chrome browser (Desktop and Android) will support the Dart VM in the future. The dart2js compiler allready works great and has improved a lot over the last weeks.

Makes sense; Dart is a closer heir to Flash/AS3 and Java than it is to JavaScript, and there's still a lot of people out there with Flash skills who're experienced building RIAs. It's a fairly natural place for them to go.

Easeljs does this pretty well, but in pure js:

http://easeljs.com/

Haxe (www.haxe.org) also has ported a decent subset of the API, and can simultaneously target Flash, JS and C++ (native). Not sure about who has better coverage of the full API.

Just to add; and through the Haxe NME framework it compiles to Android and iOS targets.

Haxe itself is pretty solid and is gaining steam almost every day now.

NME is not as easily recommended. It has very high coverage, and it's shipped a few products as demonstrated in the showcase, but the build process still shows immaturity; the Flash target is wonderfully consistent, but other targets remain pretty fragile. The general trend is "better with time" though.

Haxe is nice, but it is still not as transparent as one could hope. The differences in the way its various targets work make this understandable. Still, it still isn't "code once, run everywhere".

The main problem seems to be flash is really directed to pixel/bitmap manipulation. While on cpp/OpenGL that is extremely slow, and you have to use something like a Vertex Buffer Object.

The end result is that you probably will still have to keep two (at least) separate rendering paths if you want to support all targets.

That being said, the fact that the mobile platforms (android and iOS) are the same target (cpp), together with desktop (osx, linux and windows) makes it a very nice platform for developing a game. IMO the html5 target is the weakest link at this point.

The example game keeps crashing for me after playing a bit in Firefox.

if you want to code html5 flash, I hear another alternative is jangaroo

This is a nice project, but I think it's a stretch to call it a port of the Flash API. At this point, HaXe+Jeash is a much more complete framework for bringing AS3 code to JS, and makes it pretty easy to port relatively simple projects. The framerate here is impressive and it seems this could be a good alternative to Jeash down the road. Still there's a lot more work to be done here (not least, flash.net.*) and having to rewrite core code in Dart is more labor intensive than porting into HaXe...

I'm not a big fan of Dart. From what I've seen, Dart code is far more ugly than JS or AS3, and it produces absolutely massive JS output.

Agreed, JavaScript can have its quirks, but at least you don't need to read tons of generated code underneath, when trying to debug code.

Yeah. Thing with Dart is that its goals seem misleading. Google's complaints don't seem to be anything to do with faults of JavaScript, more the fact it isn't like languages they know. They want it to be C or Java, essentially.

JS has flaws, of course, but reacting by trying to make a completely different paradigm language that compiles to it seems a bit of an overreaction.

Well, you should see it from another point of view. You write and debug(!) your application in Dart, later you compile it to JavaScript. The dart2js team tries very hard to generate code that runs just like the Dart code does in the VM. Look at the JS-code like the binary code you get from a c++ compiler. There are hardly any people debuging the generated machine code in c++ right?

I have allready written tons of Dart code, and i have to admit there were a few issues with the JS-code regarding cross browser compatibilty (btw. it is easy to read the generated js-code). Those issues were problems in the dart2js compiler because it's a alpha-version right now. The dart2js team fixed all those bugs. As soon as the compiler will finally ship we will rely on the generated output - no need to debug "assembly language".

That's not my gripe with Dart's JS output. It's just that Dart is so different from JavaScript and has so many thick layers of abstraction that tiny programs can have thousands of lines of JS outputted, a lot coming from having to include Dart's own standard libraries.

You are right that small programs compile to pretty big JS-files, but noone should really care. I can do my "hello world" apps in javascript without a problem, the point of Dart is to write big apps! For those apps the footprint of the compiled JS-code doesn't matter at all. And you can work with nice structured source code.

Well, personally I don't want to use a language that compiles to a representation around 50 times larger than the source code.

hahaha, i totally agree - if it is 50x larger i would use a different tool too :) But as i said, if your source is 100KB it's not 50x larger, maybe it's 20% larger than hand written JS. Currently the footprint of the js-code is around 150KB. While dart2js is evolving this number is declining constantly. In the end when you add js-minification you will have a footprint of maybe 20-30KB i guess.

The JS output that gets generated from a Dart program isn't just "dart_size * multiplier", it's "dart_size * multiplier + constant". So, when you see a tiny Dart program being compiled to a large amount of JS, that doesn't mean a large Dart program will compile to a huge amount of JS, it just means that the constant is dwarfing the multiplier.

The constant is coming from the runtime library (or, more accurately, the portions of the runtime library that your program uses). That's relatively fixed so as your Dart program gets larger, the overhead of that becomes relatively smaller. The actual code-size multiplier when going from Dart -> JavaScript is actually fairly small and getting smaller over time.

In some cases, we may actually compile Dart code to less JavaScript code because of things like dead code elimination and constant folding.

JavaScript code size is something that we consider a core metric for dart2js and we're constantly working to reduce it.

Of course. I'm just a little concerned about how easy it is to inflate a program's size in Dart by including another core library.

That's true of every language, though, isn't it? If you use libraries, your app gets bigger.

I suppose so, I guess I'm too used to dynamic, interpreted languages that don't need to include the standard library in the output.

Just what we need, a way for Flash developers to be even more lazy.

What's lazy about Flash development?

Yeah, please elaborate?

If only they were all a bit more like you, so productive with your dead on zing commentary. And by "on" I meant "beat". We can only dream.

Reply on news.ycombinator.com