4 ms·

Why not put all efforts on good integration into VS Code for example? I ask also because FlashDevelop was a poor IDE, seems like it's based off it.

by speps 9y ago

anifow 9y ago
As a Mac user, I have to agree whole-heartedly! I was a pretty heavy OpenFL devotee for a couple of years. It's an amazing project, although PixiJS is a very competent competitor when it comes to building HTML5 games. Pixi has a much smaller baseline footprint (~300kb unminified compared to 1300kb unminified). Lately we've been working with Pixi with a webpack / TypeScript workflow. It's starting to feel a lot like HaXe / OpenFL again. We are winning big in terms of flexibility and good support of workflow. We are using VS Code as the IDE and we have a very smooth integration smoothly with an Angular-based asset and config management tool. The big thing we lost however is HaXe's ability to compile directly to C++. Even when we compiled to Adobe AIR, we got much better performance than something like Cordova or Ionic.
johnhattan 9y ago
HaxeDevelop is a rebranded version of FlashDevelop. While it's built in .NET, apparently enough of it was built with Windows-only code that porting wasn't in the cards. HaxeDevelop's best (IMHO) feature was that it could switch targets easily and integrated seamlessly with the Flash runtime's debugger. So you could build and debug quickly using the Flash runtime and then compile your project to native code for production. But yeah, in a perfect world VSCode integration would be the way to go forward.
- jdonaldson 9y ago
  The Haxe community is made up of a lot of folks interested in general cross-platform dev, but there's also a ton of folks from the Flash diaspora. Accordingly, many tools and frameworks are evolutions of the "Flash way" (HaxeDevelop, OpenFL), while other tools and frameworks are starting from scratch, or adapting to other ecosystems (vscode-haxe, Kha). There's always been calls to "unify" the frameworks, tooling, etc., but I don't think that's a healthy environment for Haxe. Haxe exists as a way to avoid ecosystem lock-in. It's a bit antithetical if the community imposed restrictions on how to develop with Haxe.
  - camus2 9y ago
    HaxeDevelop isn't going to run on Linux or Mac, that's the point. Programming communities should focus on writing language servers and let developers use their favorite IDE instead of forcing people to use a specific IDE.
    - markknol 9y ago
      There is a language server build by the Haxe team. https://github.com/vshaxe/haxe-languageserver https://github.com/vshaxe/haxe-languageserver HaxeDevelop consumes that. If you want a cross-OS IDE, or something that works on mac/linux, then use vscode + vshaxe.

Why not put all efforts on good integration into VS Code for example? I ask also because FlashDevelop was a poor IDE, seems like it's based off it.

by speps 9y ago

Why not put all efforts on good integration into VS Code for example? I ask also because FlashDevelop was a poor IDE, seems like it's based off it.

anifow 9y ago

As a Mac user, I have to agree whole-heartedly! I was a pretty heavy OpenFL devotee for a couple of years. It's an amazing project, although PixiJS is a very competent competitor when it comes to building HTML5 games. Pixi has a much smaller baseline footprint (~300kb unminified compared to 1300kb unminified). Lately we've been working with Pixi with a webpack / TypeScript workflow. It's starting to feel a lot like HaXe / OpenFL again. We are winning big in terms of flexibility and good support of workflow. We are using VS Code as the IDE and we have a very smooth integration smoothly with an Angular-based asset and config management tool. The big thing we lost however is HaXe's ability to compile directly to C++. Even when we compiled to Adobe AIR, we got much better performance than something like Cordova or Ionic.

johnhattan 9y ago

HaxeDevelop is a rebranded version of FlashDevelop. While it's built in .NET, apparently enough of it was built with Windows-only code that porting wasn't in the cards. HaxeDevelop's best (IMHO) feature was that it could switch targets easily and integrated seamlessly with the Flash runtime's debugger. So you could build and debug quickly using the Flash runtime and then compile your project to native code for production. But yeah, in a perfect world VSCode integration would be the way to go forward.

jdonaldson 9y ago
The Haxe community is made up of a lot of folks interested in general cross-platform dev, but there's also a ton of folks from the Flash diaspora. Accordingly, many tools and frameworks are evolutions of the "Flash way" (HaxeDevelop, OpenFL), while other tools and frameworks are starting from scratch, or adapting to other ecosystems (vscode-haxe, Kha). There's always been calls to "unify" the frameworks, tooling, etc., but I don't think that's a healthy environment for Haxe. Haxe exists as a way to avoid ecosystem lock-in. It's a bit antithetical if the community imposed restrictions on how to develop with Haxe.
- camus2 9y ago
  HaxeDevelop isn't going to run on Linux or Mac, that's the point. Programming communities should focus on writing language servers and let developers use their favorite IDE instead of forcing people to use a specific IDE.
  - markknol 9y ago
    There is a language server build by the Haxe team. https://github.com/vshaxe/haxe-languageserver https://github.com/vshaxe/haxe-languageserver HaxeDevelop consumes that. If you want a cross-OS IDE, or something that works on mac/linux, then use vscode + vshaxe.