Hi everyone,
I want to use Haxe for optimized, multiplatform, large-scale applications on desktop, mobile, and web with a single codebase.
Can Haxe be used for this kind of project?
Which frameworks and libraries would you recommend?
1 Like
That depends on what exactly you mean by each and every one of those words.
While it may sound silly, it’s fair to say that Haxe can be used for everything. But you do need to set very clear goals and then tailor the way you use Haxe and the available tools accordingly.
You could, for example:
- use one of the cross platform UI libraries and write a fully cross platform application, that runs on desktop, mobile and the web, using either of these:
- Feathers: https://feathersui.com/ (built on OpenFl, so no native UI - but like Qt it’s themeable, so you can probably approximate it, if you want)
- HaxeUI: https://haxeui.org/ (has various different native backends as well as one for web, but AFAIK no native iOS support)
- Use haxe/js to target React Native or NativeScript
- write your application core in portable Haxe (e.g. any business logic, API integration, data crunching etc.) and then use target specific Haxe code to create the UI layer.
Optimal performance and full portability are two irreconcileable extremes of a spectrum, and you’ll have to pick your own sweet spot. It depends a lot on the nature of your project.
If it’s a game, then yes, I would definitely recommend looking at any of the cross platform engines Haxe has. If it’s an application that would strongly benefit from using native components, then I guess you’ll have to pick your poison. If it’s an application with a lot of custom UI (e.g. let’s imagine you’re building something like Figma), then I would also recommend Haxe, and perhaps start with something like Kha (you can use GitHub - haxeui/haxeui-kha: The Kha backend of the HaxeUI framework - if you also want a component library for conventional parts of the UI).
Best,
Juraj
Hello!
In this direction haxe tooling is fragmented and often not completed.
If you want to write such kind of applications painless I advice you using node.js infrastructure. Of course you can do it with haxe.
Frontend: react.js for browser and react native for mobiles.
There is an awesome instrument for generating haxe externs for npm libs.
You can find react js externs here GitHub - kLabz/haxe-react: Haxe-React #next: preparing for 2.0.0 .
There remarkable video about using haxe with react https://youtu.be/sUlIgZ1hHR4
There is also amazing ui lib for building web and mobile interfaces with react.js/react native layers beneath
@alex_dja @back2dos Thank you for your quick response
I want to design a cross-platform UI for my applications in a way that the overall structure remains consistent across all platforms, while layouts and details are optimized for each platform and screen size. As an example, I have considered a chat application like WhatsApp or Telegram, but my goal is not limited to chat apps; this example is only to illustrate and clarify my idea and requirements.
For the web version, I do not want to work directly with tools like React or similar frameworks; however, it is acceptable if the UI can be automatically translated to JavaScript/React so that I don’t have to deal with React directly. I also do not intend to use low-level technologies like Kha.
I understand that this is a high-level goal and may not be fully achievable at the moment, but I would like to explore what approaches could bring us closer to this level of cross-platform UI design.
I plan to structure the UI into two main layers:
1. Layer 1 – Core Components:
This layer contains the fundamental UI elements, such as buttons, inputs, animations, themes, color schemes, and the basic layout rules. This layer is completely platform-independent and can be thought of as Lego blocks that will later be assembled in Layer 2 for each platform.
2. Layer 2 – Platform- and Screen-Specific Adjustments:
In this layer, platform-specific and screen-size-specific features are added:
Desktop: large windows, navigation sidebar, resizable layouts
Mobile: bottom tabs, gesture support, compact layouts
Web: responsive layouts and browser-specific tweaks
In this layer, the core components from Layer 1 are used and optimized to ensure the best user experience for each platform.
openfl
1 Like
Based on your additional detail, it seems like you will need to choose between FeathersUI and HaxeUI. I think HaxeUI will give you the maximum versatility and target options. I think the only drawback would be it’s a little more complex than FeathersUI. It has the advantage that you aren’t tightly coupled to OpenFL. I’m a happy user of FeathersUI, given my background using Flash and OpenFL. So that’s a pretty good option too.
2 Likes
Supergun - I’m actually attemping to do something similar at the moment. I’m curious what you mean by single-codebase, because that may mean different things to many different devs. The way I’m approaching my “large-scale” application is by using Haxe to write microservices that communicate over localhost sockets. As for UI for this large-scale multi-service application, I’m going to try to use Haxe wherever possible/feasible (OpenFL, and am planning on trying both FeathersUI and HaxeUI as Allan mentioned), but if I’m not absolutely loving where its going GUI-wise, I’ll be dropping down to native “wrapping” applications (Kotlin + Swift, or Dart+Flutter if the integration friction isn’t too bad) that kick off my services as local sidecars. For any desktop platform (Windows, Mac, Linux), there should be plenty of trivial ways to launch sidecar services, and for Android and iOS, it gets a little trickier (as far as I know they don’t allow the launching of separate services from a primary app, could be wrong) but should still be possible (by bundling it into the primary binary and launching it with a function invocation).
1 Like
Can Haxe be used for this kind of project?
Yes, cross-platform multimedia applications (usually games) is probably the best use case for Haxe these days. Lime/OpenFL are battle tested and fully free software.
1 Like
that’s what i was looking for. Thanks 
Why is not being tightly coupled to OpenFL considered an advantage? I want to understand what practical benefits this gives in real projects.
What I mean is this: I divide the code into two layers.
The first layer is the shared, platform-agnostic part — things that should be written once and work everywhere. For example: drawing a line, rendering UI components, handling high-level input, general logic, data models, and all the behavior that doesn’t depend on the target system. This layer should simply compile to each platform, and the backend or framework should take care of translating it into the appropriate drawing/interaction method for each target.
The second layer is the platform-specific part — things that naturally differ across targets, like screen sizes and density on mobile, desktop window behavior, mobile gestures such as swipe or pinch, web limitations, and other OS-level differences. These are the pieces I expect to adjust individually for each platform.
For me, a true single codebase means having the ability to clearly define the responsibilities and behaviors of each layer, and to express those distinctions easily and explicitly within the code itself. That’s the structure that keeps everything clean, predictable, and scalable.
So for me, the goal of a single codebase is to write the majority of the application once, and only implement or tweak the small platform-specific layer where necessary.
Wishing you good luck with your multi-service setup — it sounds like a solid and flexible approach.
1 Like
To me, OpenFL and Lime is an amazing tool chest and does pretty much everything I ever want. I know it quite well and I intend to keep using it. At the same time I recognize that not everybody might want to go down that road. Using HaxeUI, you can use html5, wxWidgets, OpenFL, Heaps, or Kha and you have the freedom to change between them down the road while keeping HaxeUI. Using FeathersUI, you will have all the OpenFL targets but don’t have the option of changing the low-level engine. So please don’t view my comment as a knock against OpenFL—I’m simply saying that people may wish to endure a bigger learning curve so they can have maximum flexibility. Or they may already have good knowledge of wxWidgets and want to build on that knowledge. The beauty of moving to Haxe is that you can often integrate whatever skills and tools you had before.