I think the easiest way to raise awareness of the community about what’s going on in Haxe and around is to help Skial to collect data for roundups: Issues · skial/haxe.io · GitHub
3 Likes
I always wondering why some of the tech giant not support Haxe.
Is it because wrong selling point or not reach the right people ?
From my view, at example Microsoft have Xamarin - which compile to iOs, Android and Win apps.
Google are trying to escape java with announcing of Kotlin support , but Haxe should be more appropriate because can target iOs and HTML5 and already have inteljiIdeas plugin ( Android studio is based on Intellij Idea ) .
Apple are only iOs oriented , but Amazon looking for different angle ( have android market and Amazon Lumberyard ) .
So why not try to contact someone from Google or Amazon ( Mike Hines - https://twitter.com/MikeFHines ) even from Mcirosoft ( tremendes shift under Satya Nadella )
If you know what exactly looking for - more developer, more money, big exposure , etc I think this is a logical step. You can loose only part of your time, but at least is a try.
I know how much everyone is doing for haxe, so I don’t want to be rude or something else. My apologies if sound that way or just ignore me.
That’s a very good point.
2 Likes
From my point of view:
now all the popular languages have the ability to compile into other languages, I also wondered where haxe is better than them. so compiling one source code to multiple targets is not very appealing.
anyway the hashlink seems great.
By “other languages” you probably mean JS (which is just one of Haxe targets). Anyway, the devil is in the details, e.g. emscripten-based js output is much more heavyweight than haxe/js, stuff like bridge.net for C# also adds quite a lot of run-time code to make js comply with .net spec. This might be acceptable or not, depending on the situation. Haxe OTOH is designed to be cross-target and tries not to impose too much requirements that would require generating a lot of wrapper code. This, again can be good or bad thing, depending on the specific requirements, but the point is - Haxe is a bit different in this aspect and there’s not a lot of tools that follow the same idea.
And let’s not forget the power of Haxe type system and compile-time meta-programming features, which is also important when choosing the language for a problem.
@flashultra the truth is that multi-target languages don’t have much value for large companies - they just have big enough engineering to not need the efficiency it can bring.
And if the big co’s have the appetite for something new, they will rather invent their language (TypeScript, Dart, Swift, Reason, JetBrain’s Kotlin) so they can control it and use it to gain mindshare.
Finally, multi-target is becoming synonymous with betting on “everything JS”, as in using nodejs and React-native for all platforms where marginal improvements over vanilla JS (ES6, Flow, TypeScript) are good enough and don’t alienate their big dev teams.
Interestingly, ML languages are appealing to a category of elite programmers, but they prefer pure ML (Scala.js, PureScript, Elm, Reason) to Haxe’s ML-ish features. Understandably, not offering things like proper constants and nullability makes Haxe a weak language to their eyes.
tl-dr: multi-target isn’t such a killer feature for most devs, Haxe language features aren’t spectacular enough to appeal to elite developers, and Haxe is neither JS enough or ML enough 
4 Likes
An outsider’s perspective:
Updating the roadmap and providing a greater sense your mission and how that will guide Haxe in the future would probably give you the most bang for your buck as you try to grow the Haxe community.
If there is a plan that goes beyond “wherever contributors take us” then updating the roadmap has to be a lot easier and less time-consuming to do than adding a new feature.
Certainly no-one owes me a roadmap, the gift of Haxe is already massive. But if you want to grow, I think that would help you.
Why do I think that? (Okay, the rest of this post is just way too long, but it might be of interest to a few of you.)
I’m looking for something to replace AS3/Air (using FlashDevelop) for developing interactive applications for kiosks in visitor centers (Windows PCs). Maybe Adobe will continue supporting Air, maybe not. They are certainly not actively promoting it and it seems they are somewhat non-responsive about their Air roadmap.
I also need to re-write a web-delivered Flash application to get a customer beyond 2020 (Flash timeline and AS2 unfortunately). And last week a customer asked me to convert an AS3/Air desktop application to web.
Haxe & OpenFL look like a great option for me. I have seen Haxe mentioned quite a bit on the web. I started researching. Then discovering that OpenFL exists nearly sealed the deal. But finding the outdated and very limited roadmap caused me to hit the brakes. That’s a red flag. Despite all the great effort being donated to the community, the outdated roadmap gives the appearance of a dormant project.
I was about ready to email clients about the new solution that I was going to be testing for the long term. Glad I didn’t do that yet. Haxe seemed bigger to me.
I’m not very web/cross-compiling/cross-platform knowledgeable. So that means I have a lot of research and learning to do. But; what about Haxe support of WebAssembly? That sounds important to me as a I look for a long-term solution. I need great performance for converting a desktop application to the web. At first I could only find a related tweet from 2015. (I have since found an OpenFL discussion of people kicking out WebAssembly.)
On paper, Haxe & OpenFL look fantastic for me. I am super appreciative of the FlashDevelop Open Source contributors (I have been using it a couple of years). I also appreciate that Haxe and OpenFL contributors and supporters have created a solution that I could start using today free of charge. Amazing good fortune.
I will probably try converting a small AS3 project to Haxe/OpenFL because in theory that should be quick and could work well for the short term. But I really don’t look forward to the pitfalls of figuring out what does and doesn’t work. I am not willing to go through too much headache trying out a solution that doesn’t have clear long-term viability (not trying to offend, just offering one outsider’s thoughts on a business decision) when I can still do most of what I want with AS3/Air. In theory all other solutions I’m considering will have a steeper learning curve, but they have their strengths too.
In an ideal world, Adobe would get behind Haxe & OpenFL as a way of making Animate more valuable (and appeasing disgruntled developers who now refuse to buy into their subscription pricing). It seems to make sense. Flash dominated the web. Developers were committed and loyal. Even Microsoft couldn’t compete (remember Silverlight). Animate feeding into Haxe/OpenFL spitting out WebAssembly for high performance games and interactivity in a web browsers sounds like a possible path back to former glory—or least some additional Adobe revenue.
2 Likes
@BBartonW thanks for your POV; you’re right that showing up to date roadmap and plans is critical. Aside from that, it would be great if you’d start a new thread to describe your requirements for the migration so people can give you advices. Maybe OpenFl seem like an obvious approach, but Haxe is much more than that indeed.
@elsassph multi-target is still a strong and exciting feature for my main project (fontstruct.com) and is not necessarily synonymous with “everything JS”. We use the JS target in key areas of the front end and the Java target for performance intensive parts of the backend – the latter, running as a servlet, is extremely stable and performant and, for our purposes, node would not be an option. I find it very cool to be able to use a single codebase to draw onto an HTML5 canvas and in Java2D.
1 Like
I’m being the devil’s advocate: I didn’t mean that multi-target isn’t a strong (and beautiful) feature for some people - it just is underrated for a majority of developers who are looking for simple copy&paste solutions for doing their job.
Also I personally haven’t been able to leverage this aspect in my use of Haxe - though I experiented in cross compiling business logic between JS, Java and C++, but Haxe lacks a standardized way to expose an API to host languages. Maybe that’s be something to work and document as a great use case of Haxe, but it should come with documentation, samples and possibly a scaffolding tool.
2 Likes
+1 from me
2 Likes
As I see, Haxe is a wonderful language/toolkit for multimedia. You can write impressive applications, that work with graphics. Probably applications for mobile platforms too.
As the “Toolkit for everything and everywhere” - it’s talking about creating multimedia applications, and not actionable for all cases of life.
I’m playing with Haxe about 2 years, and for this time Haxe has not been able to become something more than just for fun.
No matter how hard I try to start using it in everyday life, maintaining the code base in one project C/C++/C# under Windows/Linux will cost cheaper and faster (for desktop applications) 
Many of the simplest functions risk turning into a big waste of time in search of a workaround.
Several examples:
-
if you want to make a desktop application (full integrated) - everything is very bad
I thinks that integration with the desktop for Haxe is simply not necessary (native dialogs, system tray, etc.), an attempt to quickly sketch an easy application resulted in the beginning of writing a my own library (haxity) and 5 minutes turned into N (and catch a bug of sys.io.Process on Windows) -
API for working with TCP: the attempt to make the client-server application quickly resulted in the beginning of writing a my own library (easyNet) and 5 minutes (in C#, Delphi, C++ it would not take more) resulted in N.
-
there is no API for direct calling SO/DLL modules without creating an intermediate “adapter” in C ++ (is it "the philosophy of maintaining a single code base?). There is a project GitHub - TomBebbington/hx-ffi: Haxe 3 FFI library, but rather dead than live (so and works only under neko).
I also did not find a method for exporting functions to SO/DLL (I’ve idea to try to do this via C# Target → NativeExport). -
haxe.io.Path in practice isn’t cross-plaform and always uses unix-like path separator, for example. developer must process format of path for each target platform by itself
-
classes (root elements of OOP, that I think) have a bad limitations (overloading, fields visiblity on inheritance and etc.). Solving the problem through abstractions from classes and/or macroses to extend the functional sometimes looks more like a workaround than good-practice
-
there is no debugger for native targets, who can work “out of box”. hxcpp-debugger and vscode-hxcpp-debugger have last updates about 1 year ago, and still doesn’t work (I haven’t success with it)
Fortunately, with HaxeUI v2 there is a chance to make a really cross-platform modern GUI application, at least not to study 100500 libraries and frameworks for each task and a separate platform (to draw UI elements via OpenGL/DirectX, for example, using OpenFL and Kha, is little bit strange and too expensive, no?).
So, I haven’t a good results with Haxe for really complicated serious applications, yet. Sometimes this technology shows unstable and a shortage of instruments, but have a very big potential. Hope, in the future it really can to make a native high-perfomance modern Application, who can be really stable, cross-platform, native, high perfomance and still be to easy and lightweight for application developers.
As I see, Haxe is good for gem-dev, perhaps the web. But the developers of application software are still be left behind.
4 Likes
vscode-hxcpp-debugger have last updates about 1 year ago
Hey, I made the list of unresponsive community devs! 
I’m honored to be in good company!
Yeah, it’s hard. I really enjoy Haxe, I like to play with lots of facets, but ultimately I can only spend serious time on the parts that I use in my day job. We use haxe->js, so my hxcpp projects are sadly falling out of date.
But I experienced some of the same problems as @r3d9u11 when developing hxScout - I spent a lot of time on integrations with the native systems – like System dialogs and “launching a splash screen separate from the main app.” Though I think my experience with networking / sockets went fairly smoothly, if I recall.
@elsassph - I think you’re right about big companies don’t need cross-platform. Because they can afford to hire teams for each platform, which reduces their biggest concern – uncertainty. It’s the small team and the swiss-army-knife dev that wants to code once and reuse everywhere.
Right now, my day job uses haxe->js. My thinking is: let the JS community bring us Node.js and Electron and libraries galore. I’ll whip up some externs and happily keep using Haxe, thanks. Because the compiler and features are awesome. And when the my next project (for work or play) comes along, be it a website or game or desktop app or whatever, I know I can pivot my experience and (some of) the codebase to almost any workflow.
We naturally settle into specific use cases. @ncannasse has a successful project on Heaps+HL. @larsiusprime uses hxcpp + OpenFL/HaxeFlixel (I think). We have labors of love like Kha and NME and snowkit and so many others. This unfortunately fragments us a bit, spreading a small community even thinner… but it also is a testament to the versatility of our tool. And that’s the whole appeal.
@BBartonW - hey, hit me up with any questions, your story sounds a bit like ours. 
6 Likes
Hi everybody,
I found Haxe about a week ago and I thought that it was amazing. Maybe I couldn’t even give solid proof that it was as great as I thought it was, but I thought that it was cool right off the bat. I even created a forum topic on another forum just because I wanted to tell people about it, even though I haven’t written a single program in Haxe! 
Seriously though, I think that Haxe has some amazing potential and I really want to see it grow into something that people will appreciate.
I can see that a lot of people here have issues with Haxe and the lack of documentation and communication. @Fiene, I think you are completely right about this. Open Source is about community. It is about helping others and working towards a common goal for the mutual benefit of everybody involved. We are all different people; we all have our own interests, views, and opinions, but in an Open Source community we should all be here to help each other. Maybe sometimes we feel like the community or the core dev team isn’t helping us like they should, but aren’t we all here because we want Haxe to be great. Don’t we all want the same thing?
The issues that people are having are real. Undoubtedly these are things that need to be addressed, but we need to remember that we are all part of the team. Maybe most of us can’t contribute a lot or even at all, but each of us who wants to make Haxe better is a member of the team. If we don’t want to make Haxe better, why are we here?
We all have our concerns and our tendency is to want to place blame. Yes, there are problems, but it’s not because someone is causing problems, it’s because problems are an in inherent part of having a project. This thread has done well to point out the fact that Haxe needs help, but it hasn’t done much to actually help it. What I think we should focus on here is not the problems that exist, but on how we can organize and pull together to start becoming effective at fixing the problems.
The issue with Haxe is not that it has issues. The issue is that we don’t have a good way to go about fixing the issues. We need to think about how we can best help each other. We need a way to coordinate everybody and communicate with each other.
I think that it might be a good idea to create a Taiga project for Haxe. Taiga is an Open Source project management tool that is hosted for free for Open Source projects. It is based on Scrum and/or Kanban and allows you to collaborate and prioritize work that needs to be done for the project. If the Haxe dev team would work off of Taiga, the community could get insight into what the dev team is working on and could collaborate with them on what work there is to do. The community would also be able to see what items have been prioritized and help out wherever they can. This is similar to using GitHub issues, but it is more powerful and I think it would aid communication.
I’m not saying that this would fix all of our problems. No one thing will do that. I know we all don’t have a whole lot of time to work on Haxe, and none of us are getting paid for this, but that is all the more reason to focus on how we can more efficiently solve problems, instead of focusing on how bad all of the problems that we do have are. This is a community, lets all be as friendly as we can possibly be and work together to solve the problems.
That doesn’t mean don’t have opinions or don’t make complaints. We just need to figure out the best way to handle fixing them. We’re all working towards the same goal. 
3 Likes
Hi,
I’m jumping on that subject again (unfortunately). I am glad to see that @ncannasse and @Fiene acknowledge the problem.
At first, I want to say, one more time, that the technical work on Haxe is really impressive and I can’t stress that enough.
In my opinion, as a technology, Haxe is now technically mature enough that the technical side should now take some requests from PR.
As someone stated, there are many many use cases for Haxe and it does lead to the community being split and getting thinner somehow (at least in terms of communication on specific topic). In my opinion we now need to understand what use cases would bring more people to Haxe.
Bringing more people to Haxe is needed because that means having more work-power to make the ecosystem stronger and the community wider and more supporting and communicating.
We also need to “invade” the usual communication channels : we need to be at conferences (not the Haxe ones obviously), present a tool/framework/whatever made with Haxe that is great and solves an actual issue for devs, including larger companies.
We all have such problems, we simply need to identify them. @Fiene maybe there would be a way to gather data/knowledge about that?
Also @Fiene, what would you suggest for “invading” those communication channels? I think something as simple as a standard “Made with Haxe” title screen for games would be great. Such a standard message could also be provided, maybe in less intrusive ways, for different kind of softwares (such as productivity tools, web apps, ….) A bit like the usual “Made with Wordpress” (or whatever that is).
Also, a tool that would be greatly used by devs and that would allow extending it through Haxe code (via CPPIA?) would probably be a great driver.
5 Likes
I have a ton of ideas flying around somewhere. Like most people, I have trouble putting in enough time and focus to clearly document them, prioritize them or get them into a format that I can hand over to ther people “to do”.
Most of my Haxe energy and time at the moment go into the Haxe Summit, but yes, there are things we can do.
I think the most useful thing would be to come up with templates/frameworks for certain things to make it easier for people to participate. The “made with Haxe” screen would be such a thing. Others might be:
- A running list of questions that can easily be asked about use-cases
- A template (headlines) for articles about use cases (so you don’t have to re-invent the wheel)
- Standard assets that can be used to say “made with Haxe”
- How to’s for things like “I want to organize a meetup/talk to my managers/etc”
I could go on but they are just ideas in my head right now, nothing specific.
I also think that a community manager or moderator would be helpful. Not someone who tells people what to say but someone who keeps tabs on all the different things going on and who can connect people with each other so that efforts can be more aligned with the vision that also needs to be written down ^-^.
Sure, some of that can be automated eventuallyby using a project management tool but I think we would all need to learn how to go about this better, first. In the learning phase, it would be better to have someone “directing” the efforts.
So yes, it goes back to the clarity in what we are asking for and how we are asking, connection.
Incidentally, that is why there is always an energy increase after a conference/summit/meetup. People feel connected, they have more clarity so more stuff happens. Sure, not everything that is talked about over drinks at a Haxe event will happen. But some of it will.
P.S. Yes, the HF is looking for a Marketing and Communication strategist to do just that. Most people, I think, have the same issue as I do. Working on a defined project and chipping in there is easier than looking at the whole big picture and coming up with some sort of coherent plan. That takes more focus and time. At least it would for me. It’s not that I don’t have it in my head somewhere, it is that I really can not go on a two week Haxe retreat right now (although I suspect those should be a thing).
1 Like
Also, the best way to let people know about Haxe is to talk to them. We have a ton of people in this community who have a ton of connections. I think that those relationships are valuable and should be used just as much as traditional marketing materials.
1 Like
How about we create a “task force”? I think because we all have so little time we need to formalise things so that we can all be coordinated correctly and feel like “we have to” deliver by deadlines for example. I’m not saying let’s be patronising but as you said a coordinated team. When you’re in a team you feel more in charge.
Should we organise a quick chat?
1 Like
Sure, just message me with what you want to use for chats and let’s see where it goes.
This probably doesn’t really help, because we don’t have the time, but it would be cool if there was some Open Source project that we could create that was written in Haxe that could get popular and generate more interest in Haxe as a language. OpenFL is great and it looks like a lot of people get into Haxe because of OpenFL and because they have a background in Flash, but OpenFL is only a small portion of the potential of Haxe. Lots of people use Haxe for games, but most people don’t make Open Source games so that doesn’t necessarily get more people using Haxe. If there was some kind of app or tool that we could make, it might also help reveal what in the Haxe language needs more work, based on the needs of that project.
Like I said, this is probably unrealistic as there isn’t anybody with the time to work on such a project right now, but it might not be a bad idea to brainstorm what we might be able to make in Haxe to gain some ground in getting it noticed.