Other language, that it is possible to do with is Scheme, but it is quite a different beast all together.
That's my little dream. I intend to do gobject-introspection bindings one day for it as my first step.
Other language, that it is possible to do with is Scheme, but it is quite a different beast all together.
That's my little dream. I intend to do gobject-introspection bindings one day for it as my first step.
I guess using Haxe means that you could also share libraries with your “real” game code that likely compiles to C++, which could be a big benefit. I just thought it was funny that LDtk could be written in JavaScript and be just as cross-platform as it is.
Other examples of Haxe-Electron apps include the Ogmo level editor and the CastleDB editor.
Writing in Haxe brings nice syntax, and some flexibility regarding target language/platform, and possible UI frameworks.
- ArmoryPaint[1] and most Haxe games don't rely on Electron for UI.
- HaxeUI[2] provide a nice list of components, rendered as composite or native on various backends[3] (html5, wxWidgets, experimental pdcurse..^^)
- MVCoconut[4] also allow to bind to various front-ends : Dom, React, React-native
There is always a degree of lock-in depending on the path you choose, but having a cross platform base for logic and glue is a nice feature.