Hello, I recently have been given the opportunity to build a website for a rather large and old company that is riddled with legacy code and technical issues.
When pitching the project to the head of the tech department, he said that his problem utilizing such cross-platform compiling languages is that if the produced code is not easily readable, and also not fixable on the top level, it can be very difficult to do bug fixes.
Personally, I have rarely had this issue with this in Haxe; typically I use Haxe as an auxiliary tool as opposed to the core tool of any software I am building.
Can anyone speak to the viability of using Haxe as a feasible replacement for a company that uses mostly ASPX/.NET? I’m not as familiar with .NET as I am with Haxe, however with Haxe, it seems fairly straightforward to get started building the back-end portion of a web application; the VP of tech mentioned .NET’s Web API, says he would prefer this over Haxe.
I don’t know enough about both platforms to really make an argument against his -however-, I can say that Haxe’s ability to build embeddable web applications with relative ease is a very attractive feature to me as a developer, and it seemed like this was the one thing about my presentation that was a hook for the VP of tech in regards to Haxe. In fact, many of their plans involve migrating existing Desktop applications into a Browser or Mobile app, this is something I also see Haxe being a strength for.
Anyways, to the point. How suitable is Haxe as an Enterprise Solution? Is it really on par with .NET or am I just talking out of my butt?
Thanks!
EDIT: We agreed upon using Vue.js and NPM for the project’s front end. I’m not sure if this would impact your decision if you were in my shoes, but it seems like using JavaScript in .NET is a pain (then again, I am only familiar with .NET MVC web development, not the .NET Web API)
If you were using Haxe for the frontend as well, that could be a great point in Haxe’s favor, as that would then allow you to easily share code between the frontend and backend. There’s several libraries for Vue.js/Haxe-development, such as haxevx, but I can’t comment on how mature they are as I haven’t used them.
Hm, that may be possible but I prefer to keep the front end and back end as separate as possible so that for any shortcomings they can easily be swapped out in a clean manner. That way as technology evolves in the future the company wont encounter this problem again.
We can then actively adopt to changes in technology and stay at e top of the industry.
Hi,
We talked about moving haxe to an enterprise level, with @pchertok at Seattle.
Actually it’s too early but we are working on it.
Basically you can have a look on hexMachina. This framework is a Spring’s like. Also for frontend haxe-react webpack and modular are matures
If they have a .NET team already I don’t think there’s a good story for moving to Haxe on the BE - however you can propose that Haxe on front-end could align well with having some shared BE/FE logic in the form of a cross-compiled JS/C# library.
I believe Vue is appealing to entreprise, as a lighter Angular.
haxevx seem very competently done.
Haxe generated JS is very easy to debug - other languages’ code generation may be a bit “busier” but I used to do C++ debugging without too much trouble.
Yes isomorphism is cool but if they are BE heavy it’s not an easy sell because you basically have to advise going full JS (preferably with Haxe of course). But if the .Net team is motivated, having them becoming full stack using Haxe could be a good sell (no need to JS too much).
Trust me, they have little reason to value the software we currently utilize.
I actually was able to get him to approve on using Vue.js and NPM, but he wants me to use the .NET Web API as the back-end. Which I’m not entirely against, but securing a connection still seems to be a mystery in .NET (for me at least).
At this point I think at best we will be using Haxe for embedded web applications, with a .NET back end and a Vue.js front end
Haxevx is pretty well done, but I don’t think anyone can beat Vue’s single file components. I am basically building static webpages with dynamic components as opposed to generating dynamic webpages from the back-end.
I imagine I would end up setting up the Web API to handle all the data jazz, then AJAX from the front end to get JSON and XML from the underlying SQL database, which I honestly do prefer. Haxe doesn’t offer a lot of support for SQL Server (which all is the type of db the company uses) it seems, so using Haxe alone to generate the webpages seems like it’ll be tricky.
The Vue single file component looks fancy
in the samples (or small projects) but that’s imho an unmaimtainable untyped soup, especially the vuex model binding. Data flow (safely handling JSON, refactoring models) is a mess in JS and precisely a good reason to use Haxe.
On the other side .NET is competent for making web services, so if you have an experienced team here it would be safe to stick to that.
How about using GraphQL ?
On front … consuming data in a way effective manner than REST, use react (with haxe), vue is nice but … react has more power/possibilities.
On backend start with composing existing (REST) services only.
Having unified frontend consumers try the same on backend.
If team could be able to expose existing services with graphQL - OK, just remove REST layer and bind directly.
If not … I imagine that GraphQL can be used as DB connector (abstraction layer) - exposing DB by one graphQL/apollo server to be used in other service.
Having access to (many) datasources (even sql, elastic etc.) with graphQL you should be able to build new nodejs microservices using haxe, possibly sharing some code with frontend.
I’ve seen some apollo-express, graphql-related haxe externs on git (psmtec) - ask them?
Result … incrementally replacing legacy services just behind api endpoints (bindings/resolvers).
If you’re not going to use Haxe, you should at the very least strive for some of the qualities that it would give you:
Static Typing - this demonstrably eradicates a whole class of bugs. It also makes code more self-documenting and easier to navigate and what not, but if none of that matters: having ~15% less bugs to deal with should. Whether it’s TypeScript or FlowType really doesn’t matter.
Transparent communication - with haxe you could use haxe remoting or tink_web to effortlessly and safely send data between the server and the client. Outside Haxe, the next best thing is swagger, which has code generators for most platforms. If you’re making HTTP requests by hand (or even just parsing/serializing JSON/XML) in 2018, you’re doing it wrong. Shoveling data around in a distributed app should be automated on top of shared interfaces. This avoids different parts of the system going out of sync and saves you writing and maintaining a lot of tedious code, that can not even be checked by static analysis (a great place for bugs to hide).
Beyond that, the gains you’ll get from Haxe are not that easily understood without actually using it for a while, especially on a long running project, which is where Haxe really shines. Faster builds, better inlining (and thus runtime performance), dead code elimination (and thus faster load times) and tends to generate better code than most alternatives. Plus macros provide the flexibility to bend the language according to your team’s needs, as opposed to bending your team to fit the language’s limitations. In the long run, choosing Haxe will pay off, at the cost of a longer learning curve and having to do a few more things yourself (even if it’s just writing externs).
From 1st hand experience, the bigger the project grows, the biggest the difference between Haxe and TypeScript compilation is (and AFAIK Babel is a bit faster than TS, and Flow is even slower).
This isn’t obvious when you start playing with a technology and where your POC is fast to compile, but months into your project, that’s the kind of difference between compiling in 10s VS 1 minute.
Also, the only times I have been in a company working with TS and Flow (on different projects), the types were utterly wrong (some signatures not updated, 200+ warnings ignored) so that the typing was absolutely useless, and also misleading.
It was almost like using haxe with Dynamic all over the place; they might as well have been using plain javascript, at least they could have seen warnings with eslint.
Could easily use typescript though. Just saying. But I’ve become pretty well adjusted to the organizational structure of Js in general.
It’s all about keeping promises lmao. If you say redCar is a redCar and use it like a redCar, I’m trusting in you as a developer that that redCar is a red car.
You actually just brought up several reasons I need to study the manual more and learn more best practices.
Right now I just write haxe when writing the equivalent code from it’s standard library is a hassle to figure out on a given target.
For example with Python I handle regex exclusively through Haxe.
This is of course because most of what I’ve done until a few weeks ago was just me programming for fun and not for production.
But, for example, I have never used function inlining. I’ve only really recently learned of the beauty of Tinkerbell’s libraries (all of them) but have yet to actually try them out.
For now Haxe is good for my side projects and definitely a tool I want to get better at using for all projects where it makes the most sense.
Don’t mean to hijack the thread here, but I’m writing a blog post about Haxe and would love to know if there are some more first-hand stories of current Haxe usage in the enterprise. If anyone has any and could DM me a quick line with your Haxe stack and scale (and company name, if possible) I’d appreciate it. Thanks!
There’s several libraries for Vue.js/Haxe-development, such as 
Isomorphism is something relevant with haxe