I think Armory may be such a tool.
Does Tink have that allure?
I actually think Armory looks pretty amazing. It think it could become a very impressive game engine. It’s renderer is mind-blowing. I’m trying to learn it because me and my brothers have dreamed of making an Open Source game for years.
We might need an Armory game, though, to actually show off Armory. Me and my brothers are working as hard as we can to make a game that we will Open Source as soon as we can figure out how exactly we will license it ( which should be soon ). We don’t have much other than the story so far. It will probably be a long time before we actually have a good game.
Regarding Tink, I couldn’t agree more. The “problem” with it is that it can’t be easily sold in a single package, like, say, Ruby on Rails can. It’s an amazing collection of libraries. Maybe if we had a “Tink on Rails” (for web/mobile dev in general) it would be easier.
I’ll just add some food for thought here.
When I started with Haxe back when MTASC was getting discontinued, it was out of a need for an open-source AS compiler. I personally liked the ActionScript syntax, so I was more than happy to get my hands on Haxe, which sported a similar syntax and its very own cross-target API.
- PHP introduced namespaces, but not a standard class loader. In Haxe? All standard.
importyour classes and forget.
- The remoting API, albeit not quite there in terms of maturity, offered a quite straightforward RPC workflow that worked across targets
- “Forced” single point of entry PHP applications. Building a PHP app in Haxe? Forget putting multiple entry points in multiple PHP files. You have one
index.php, deal with routing in a sensible way. Back in '06, that was not (at least not for PHP) the standard.
- Both backend developers and frontend developers could learn the same language
Now, fast forward to 2018:
- PHP libraries have evolved to a point where classloading is less of an issue
- RPC is less popular than REST these days
- PHP applications evolved in a way that multi-point of entry messes are less of an issue
I cannot speak for other use cases, but as far as Web development is concerned, the languages that Haxe targeted caught up in terms of sophistication and the value that Haxe added roughly 10 years ago is not as clear as it is today. There are a lot of tools and compilers in the wild that lets developers more efficiently write JS and PHP applications without resorting to learning a new language.
The other languages’ standard libraries and communities evolved to a point where I think it’s difficult to justify Haxe based on its cross-platform compiling prowess. It’s my personal opinion here, but I think that if Haxe is going to have high impact in the industry, it’s trough its standard lib and provided APIs. Not by the number of targets it proposes.
Two cents end here!
That brings up a good point. If Haxe is good, why is Haxe good? What actually makes Haxe a good language for anything? Why should I use Haxe?!
If we can’t come up with good answers to these questions, Haxe might not stand the test of time. I very recently found Haxe so I’m not 100% sure what the answers to these questions are, but if we can come up with good answers, these are the kinds of things that need to go on the Haxe website, the kinds of things we need to be telling people about Haxe. These are the things we need to focus on if we want to find a way to make Haxe more popular.
Maybe it isn’t true, but I feel like Haxe has some great potential. We need to find out what it is and prove it if we want to get other people involved. It seems like the difficulty in doing that is either one of two things and I can’t figure out which one it is:
- Either Haxe has so many different potential applications and uses that it is hard to nail down how to use it.
- Or Haxe really isn’t more useful than the languages that already do the jobs that you could do with Haxe.
Some thoughts on what might make Haxe valuable and what it is competing with:
The reason that I initially liked Haxe was because I knew Python, wasn’t a fan of Java, and wanted to avoid writing C++. I wanted to be able to write code that was faster than interpreted Python. I looked at Cython, which is faster than Python, but there are problems with concurrency in Cython. I also took a quick look at Go before I found Haxe.
If your reason to use Haxe is for the C++ target and you want to build native binaries, without writing C++, I think that puts Haxe in competition with Go, Rust, Nim, and another one I just found, Crystal ( is there anything else? ). That leads to the question of why you would use Haxe over any of these other languages if your target is native binaries.
You can also use Haxe to write web applications, but why use Haxe over Typescript and Node?
Maybe it is an advantage that Haxe is one of the few, or maybe the only, language than can handle all of these different use-caes, but is that enough of a reason to use it over languages that target their individual use-case?
Without marketing it does not matter how good is Haxe as tool, if nobody know about it.
One of the ways to popularize Haxe among developers is a plain advertisement. There is a lot of popular youtube channels with developers who talk about languages trends and with a lot of “how to” programmers videos. This channels has thousends of views and a lot of subscribers. If blogger who has some influence in a masses will tell a few nice words about Haxe, then this will encrease it’s popularity.
I believe, but it’s only IMO, HF should try to do something like this. And maybe community can help and organize Patreon or something for donations for marketing stuff.
Marketing is definitely important, but I think it comes in pair with an end user product which may not be Haxe itself, as mentioned earlier in this topic.
What makes it difficult with Haxe is that there are plenty of different way of using it and narrowing it down to a few polished workflows is hard.
We need excellent and unique tools that take advantage of the unique features of Haxe.
OpenFL is somehow such a tool because as far as I know, there is no other tool around that makes it possible to migrate from Flash as easily. I am sure OpenFL is the initial reason of many people giving a try to Haxe.
Armory is promising as well and I am looking forward to seeing what it will become in the future.
Heaps as an end user product looks great too and already made it to publish games in production which is a big plus, but it also has a website with written « soon » on it for more than a year and that could be seen as a red flag for a newcomer.
Haxe Foundation is working on improving Haxe itself and can probably not provide and maintain by itself full-featured products based on Haxe, but if there is any way it can support finished and well-polished software made with Haxe by other companies/people, it should because these tools are what would make Haxe shine (in pair with good marketing).
I agree with @jeremyfa that direct marketing can be useful but isn’t a solution by itself. In my experience many have already heard of Haxe organically (maybe on Hacker News, Reddit, Twitter), maybe even looked at it, but it didn’t hook them yet. They might’ve had misconceptions about what it can do or what it was for (game dev, Flash.) We should understand where we’re losing potential users and what story will bring them in to investigate more, vs. just pouring in more impressions with paid ads. Then we need to make sure that the tooling and ecosystem is competitive so that they stick around.
Anyway, I think the issues are broadly agreed upon. Haxe Foundation is actively hiring an evangelist, and I’m sure they will consider this giant wall of feedback and existential drama
I also agree with @jeremyfa about importance to marketing one strong point of Haxe.
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.
The only point we agree is that the Flash target doesn’t require much updates
Hey this caught my eye and makes me worry a little. We are using Haxe with OpenFL to port our games and plan to use HTML5 for web but Flash target to bundle everything with Air to mobile and desktop. This is a great opportunity when working with Haxe imho and it leverages cross platform quite nicely without worrying about the specifics of any native target and the differences in the render pipeline. We serve 500.000 monthly active users and the games are live now with the haxe codebase on Android, iOS and desktop while we work on the HTML5 output.
I understand that the Flash code is working well and does not require a lot of work at the moment. I only hope that means you don’t need to put much effort in keeping it fit for production, and that it does not mean you plan to give up on it completely.
Haxe is right now in this neat little spot where we can code for HTML5 and mobile (through Air) without a lot of effort. Should Air ever cease to exist we might need to invest more for native targets, but we would like to stick to Air as long as possible, and I guess we are not the only company with this strategy coming from an AS3 cross platform background.
Just my 2 cents, thanks.
There is no reason that Haxe would not continue to work with Flash/Air, given that Air is not getting updated much either and that there won’t be any significant change to Actionscript 3 as well.
Haxe is Open Source and can be fixed by anybody to keep it working with Flash if needed (but I suspect HaxeFoundation would take care of it anyway). I would worry more about Air being discontinued in the future than Haxe not supporting Flash, as Air is a closed-source black box that doesn’t seem to evolve much anymore. @rewb0rn if you are already using OpenFL, there is only one step ahead to target native iOS/Android using OpenFL without depending on Air/Flash at all.
I’m just arriving (to Haxe) and my search is for a C++ replacement for developing audio software.
I need both the lack of garbage collection (Go, Crystal, Java, and just about everyone else can leave the room now…) for deterministic timing, and seek a high-level approach as the nitty-gritty audio processing is in it’s own real-time thread as the callback registered with the systems audio driver, and I’ve meanwhile to make a LOT of features and not pull my hair out with the massive scope of projects.
Can Haxe be a higher-level less-painful alternative to C++? That’s a very elite market that not many other languages can fill, certainly not most of the trendy webby ones…
Low-latency audio has other uses beside audio content production and musical performance…
And, hooray for open source, you can peek at the VM code and/or adjust it to your liking.