Comment by larsiusprime | Hacker News Reader

Comment by larsiusprime | Hacker News Reader

Quick note: this is NOT a flash player reimplementation. It's an API implementation. Thanks to Haxe, OpenFL apps can compile out to C++, HTML5, Flash, etc.

I should also note that people might also be interested in the programming language that OpenFL is built on, Haxe, which has been around for ~10 years, is criminally underrated, and has many, many uses besides OpenFL's Flash API implementation (probably the most popular Haxe library).

For instance, here are some other uses :

  - Isomorphic client/server web apps (http://ufront.net/)
  - Cross platform UI (http://haxeui.org/)
  - Other game frameworks
    - (snowkit: http://snowkit.org/)
    - (kha: https://github.com/KTXSoftware/Kha)
    - (nme: https://github.com/haxenme/nme)

Course I'm a big fan of OpenFL!

Also, for those who don't like the Flash API, OpenFL has a lower-level foundation called LIME that is just the cross-platform abstraction layer, so you can just use that if you hate all things remotely Flash-like.

Hear, hear.

Haxe is very much underrated. You can write mobile, web, server, system, embedded, game code with the same programming language and deploy on almost whatever you want. Guess Erlang is the one target missing.

It's a nice language and it's mature as is it's toolset. It's very trivial to integrate native libraries.

I believe it's underrated (what people most often say) because of the libraries which are kind of a mix of quality and a lot of them outdated and unsupported. HaxeFlixel/OpenFL are very nice and stable, but that's for a limited audience. Myself and others using Haxe, I believe (but I have nothing but experience to back this up), just integrate what they need themselves because it's easy. And never release it because it's not good enough or release it half-baked (to the point they need it).

I never wrote anything in Flash and so I don't really see OpenFL as anything Flash (while it obviously is); it's just a nice, well documented API for me.

Edit (bit offtopic):

Another underrated language that manages quite a bit of targets quite well is Monkey-x; it's also targeted at games. I wrote a few production games in them and it's nice to work with.

And yet another one, which I really like, is https://mercurylang.org/about/backends.html ; the implementation is very nice but really complex. That makes working with it harder because there are not many people to support it. With Haxe / Monkey I can fix things myself, with Mercury that's just really too much work.

Almost the opposite of that one is Shen which, again, has many languages it compiles to / runs on for which building targets is rather trivial. It's actually the only language of all the above for which implementing a new backend is trivial.

In my opinion part of the reason why Haxe still hasn't got much support outside of game development is an easy, cross-platform way to do native UI. It's definitely something that's needed for it to be a good solution for building most non-game applications.

Quaxe looks like exactly that: http://www.glazman.org/weblog/dotclear/index.php?post/Announ...

There was a big talk about it at WWX 2015 just a few days ago. Looks very promising.

that looks amazing! really excited to see where it goes.

I build apps with it; Haxe => C# on Xamarin...

Edit: Example of hackery I didn't release because it's hackery. But it's stable and it works. I would like to find the time to clean it and release it.

Native UI has always been the Achilles heel of any framework.

Basis https://github.com/Randonee/Basis offers a start on many native mobile UI, and non UI bindings for Haxe.

Haxe is awesome but it's not popular because it has a discoverability problem. It's difficult to find what you need. This is getting better though. Bet on Haxe this year.

I realize this is not a reimplementation, but given the similarities of Haxe and ActionScript, and the fact that you can work with both in IDEs such as FlashDevelop - would you say that OpenFL could be a good path for porting legacy Flash application to HTML5 or mobile?

Yes, it definitely is a good path for that, especially if you were using Actionscript 3.0. OpenFL does not support the AIR API on native targets (you can still make AIR games via Haxe, just only on flash target), but on native you'll gain access to anything AIR could do and more through the Haxe standard library's native system stuff.

Tons of people have used OpenFL for exactly this purpose (porting legacy flash games) -- I'm doing it for Defender's Quest (previously a flash game), Cursed Treasure 2 is a good example as well of making the jump from Flash -> Haxe/OpenFL (Cursed Treasure 1 was flash.)

Thanks for the clarification.

At first I thought the games in the showcase were flash apps that OpenFL were able to run, but they're actually created with Haxe and OpenFL then.

How does Haxe manage impedance mismatches between it and so many target languages? I've never heard of anything pulling that off successfully. Maybe Eiffel? But then, who uses Eiffel?

Assumably it compiles down to a subset that is easy to port—basically take the VM approach except make it AOT-oriented instead of JIT-oriented, like LLVM.

Another thing is the Haxe standard library, which guarantees certain features across all targets, including features that aren't normally available (like, say, Reflection in C++, if I understand correctly). If the feature is natively available, it falls through to the native implementation, if not, on that target the standard library provides enough code to enable the feature.

The haxe target languages aren't very different, other than some superficial syntactical and their standard libraries being somewhat different. Working around those aren't "difficult" (which isn't to say it isn't a lot of work to implement of course).

I'd be surprised if haxe could get a target language such as haskell (unless if they created a specific lib in haskell to emulate an imperative program and mutable state).

> (unless if they created a specific lib in haskell to emulate an imperative program and mutable state)

Writing a vm in haskell is hardly out of the question.

i would expect it to perform poorly (but then again, i m only guessing here).

Nothing about haskell prevents poor mutable state performance. If anything they could basically compile it down to unsafe haskell that's c-like.

Reply on news.ycombinator.com