6 ms·

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 s

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.

hansjorg 11y ago
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.
tluyben2 11y ago
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 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.
- SunShiranui 11y ago
  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.
  - larsiusprime 11y ago
    Quaxe looks like exactly that: http://www.glazman.org/weblog/dotclear/index.php?post/AnnouncingQuaxe 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.
    - zem 11y ago
      that looks amazing! really excited to see where it goes.
  - tluyben2 11y ago
    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.
  - Aldo_MX 11y ago
    Native UI has always been the Achilles heel of any framework.
  - ncr100 11y ago
    Basis https://github.com/Randonee/Basis https://github.com/Randonee/Basis offers a start on many native mobile UI, and non UI bindings for Haxe.
- explorigin 11y ago
  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.
m0th87 11y ago
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?
- duaneb 11y ago
  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.
- larsiusprime 11y ago
  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.
- chii 11y ago
  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).
  - duaneb 11y ago
    > (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.
    - chii 11y ago
      i would expect it to perform poorly (but then again, i m only guessing here).
disease 11y ago
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?
- larsiusprime 11y ago
  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.)

hansjorg 11y ago

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.

tluyben2 11y ago

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 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.

SunShiranui 11y ago
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.
- larsiusprime 11y ago
  Quaxe looks like exactly that: http://www.glazman.org/weblog/dotclear/index.php?post/AnnouncingQuaxe 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.
  - zem 11y ago
    that looks amazing! really excited to see where it goes.
- tluyben2 11y ago
  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.
- Aldo_MX 11y ago
  Native UI has always been the Achilles heel of any framework.
- ncr100 11y ago
  Basis https://github.com/Randonee/Basis https://github.com/Randonee/Basis offers a start on many native mobile UI, and non UI bindings for Haxe.
explorigin 11y ago
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.

m0th87 11y ago

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?

duaneb 11y ago
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.
larsiusprime 11y ago
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.
chii 11y ago
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).
- duaneb 11y ago
  > (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.
  - chii 11y ago
    i would expect it to perform poorly (but then again, i m only guessing here).

disease 11y ago

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?

larsiusprime 11y ago
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.)