I’d need more time to go through all this and point to deficiencies, but in api.haxe.org there’s one thing that often bothers me: navigating in the codebase.
I have no example to point to atm for a better navigation system, but the main things that are missing for me are :
keeping the tree separated from the content’s scroll position
some fuzzy search (like t in a github repo)
more advanced search (like being able to search for a function by name)
The content is good, I guess (except when there’s an occasional bug in the generation, but that’s pretty rare). At least I don’t remember complaining about it.
About social media: maybe facebook?
and this is not exactly what you asked but haxe have the best compiler(IMHO) and tools for JS but we haxe not vast known strong in this huge community and this is a shame.
As a beginner with Haxe the most import thing for every single programmer is one thing - IDE and debuging. So you need to start with that.
For what I saw, at the moment, the main focus for IDE is Visual studio code , so I think will be nice to add in cookbook section for how to use VSCode ( some wiki pages here Home · vshaxe/vshaxe Wiki · GitHub could be added to cookbook ) . Here just at example for my experince :
Ok, Ctrl+Shift+P and choose Haxe Initialize VS Code Project
Not working. Hm.
So my mistake was about empty directory. First I need to create one, after that open in VS and after that step 2) . So simple example in cookbook will help.
Also I will quote myself form other topic
"
For me, this will be a direct comparison between Haxe and Xamarin and marketing haxe as cross platform mobile app development tool. If we go further, I will suggest creating ‘Haxe ads’ similar to Unity ads .
Let me explain. Every mobile developer looking to monetize the game / the app and one of the things to do that is with the integration of ads in the game. So if Haxe have separate sdk, and platform/site where publisher and developers can use is a big ‘yes’ for all. For Haxe , team can get from publisher 10-20% , for developers is easy development with Haxe ( for iOs, Android, html5) and easy integration of ads ( so can make money) and why not easy integration with extensions ( mobile payment, push notification ) and so on.
Think about that . Haxe still be open source free project , but will became platform for adversiters and will help in developers in the same time. Win-win situation.
"
thanks for the suggestions, a VSCode guide is something I plan on working on very soon.
In regards to some of the other points, while useful they might be more appropriate for a specific framework. For example an OpenFL asset would probably be different from a Heaps asset. Nonetheless the comment is appreciated and I’ll gauge it vs other user feedback.
As for libraries, I’d love to see the UFront project get revitalised. The wiki pages have potential but are pretty bare bones: Home · ufront/ufront Wiki · GitHub
More documentation on Heaps would be a huge and really appreciated improvement. From a Heaps beginner point of view, here are my suggestions:
In the source code, classes like h2d.Sprite have some of their functions documented. I think more functions (with their parameters : ) could be documented that way. It makes the framework a lot easier to understand when exploring its source.
Currently there are a lot of useful samples, and maybe samples related to general game development concepts could be added to them?
I’ve been using haxe a long time and I would like to see more desktop integration, it is bombarded with game making solutions but not many ways to make native desktop UI’s or plain desktop apps. Right now people are loading up game making frameworks and making desktop apps in them, which isn’t terrible, just not ideal. - The web development side for haxe is definitely growing though! - The summit was mostly about one particular game engine which wasn’t fun for a haxe summit.
Externs are quite under-documented for some reason, they are quite powerful and a great way to contribute to haxe! Javascript externs are okayish documented but there’s no proper guides for porting native/c++ projects to haxe. Sure we might need to know some c++ but a proper “noob” friendly guide would be nice as well for the major haxe targets at the minimum.
Also for others information there are libraries which give native ui’s like:
Haxe UI Widgets
ImGui
ImGui is pretty great to have, but it would be nice to see modern additions as well which follow today’s ui design standards
I’d love to see some community help with HaxeUI documentation, tutorials, and examples.
Also, some write-ups on Haxe compiling to dll for use in other projects.
I was binge watching the Haxe US summit videos and notice you “call to action” …
I am glad the not-game-part of Haxe is also getting some focus.
What I was missing (a couple years back) was detailed information about specific targets.
The manual is doing a good job of explaining how Haxe works, but fails when it comes to specific targets.
IMO I think it should be part to the manual, and the other targets should get equal love. (I tried Python and Java but I just couldn’t get it to work for me…)
matthijskamstra, those are awesome resources - thanks so much for those! I’m definitely going to leverage them when presenting some JS based solutions.
I’ve been thinking about how to add more business app / UI options to Haxe as well and it occurs to me that HashLink might provide a nice bridge. If wxWidgets (or possibly QT?) was embedded into HashLink it would allow a HashLink bytecode file to be delivered relatively easily to desktops. HashLink has a batch of libraries already compiled into it (SDL/etc), so this would just be an additional library that would be compiled in. The hxWidgets externs could be adjusted to wire up to the HashLink JIT, and this would provide a path to have HaxeUI sit on top of HashLink+hxWidgets.
Just dreaming here, and I don’t have enough experience with the inner workings of all the pieces that would be required to make this happen, but maybe someone out there has the knowledge?
API documentation needs to be fleshed out - many pages have assumed knowledge, others are plain incomplete like typedef documentation not telling how to extend/combine typedefs:
typedef A = {...}
typedef B = {...}
typedef C = {>A, >B, } // note the last coma!
typedef D = {>A, >B, >{foo:Foo}, } // again the last coma
// etc.
Someone needs to take a step back and ask himself: is that really clear?
