[umvi]

So if I understand the appeal of Haxe, it's basically a high level language that compiles down to other languages?

[haxiomic]

The multiple targets is certainly a big appeal, but the biggest for me is it's just a nice language to work in, so I often prefer it over whatever domain's native language I'm working with

For example, when I do web frontend work I often use it over TypeScript - I broke down why earlier https://news.ycombinator.com/item?id=26084187

Same story for say, writing blender plugins; personally I find prefer if I can use a strictly type functional language and then compile to python, rather than write in python

[suby]

You seem to caution against using vue and react when targeting the web. Is the haxe-react project you linked to in that post what you normally use for building front-end apps, or how are you approaching that if not?

[haxiomic]

Yeah, kLabz's haxe-react is the one I've used in the past because kLabz seems to be active keeping it updated and I've been very happy with it (although I think the readme doesn't do it justice)

My work at the moment is WebGL-heavy and DOM-light, so I haven't needed DOM frameworks much, however the next time I do I'm curious to try haxe 'coconut'[0] which is a react-like ui library written for haxe

I think when building a web app that involves assembling components from libraries and frameworks, TypeScript is a strong choice because there's so much material out there to work with, all designed for TS. Whereas if you're building something for the web with few dependencies and primarily in-house code, haxe starts looking more attractive

I'd love to see haxe get to a point where it can frictionlessly integrate with TS codebases so it can become an attractive choice for any frontend work but it's not there yet. Lots happening in this direction however; maybe in a few versions time.

[0] https://lib.haxe.org/p/coconut.ui

[csande17]

Yup! With its JavaScript and JVM targets, it simultaneously manages to be a better TypeScript than TypeScript and a better Kotlin than Kotlin.

[EvilEy3]

> better Kotlin than Kotlin

Kotlin has JVM, Native and JS targets. And as a language it is much better than Haxe, I would be careful about such statements.

[smrq]

Hmm. Did you just make an equal but opposite statement, while cautioning against making just such a statement in the very same sentence?

(I have no opinion on the argument, never having used either language. I just found the rhetoric funny.)

[EvilEy3]

Exactly, haha.

[pjmlp]

Kotlin/Native is a special snowflake that by being built on an incompatible memory model with the JVM, now has been forced back into the dev board as the amount of issues kept pilling up.

You cannot just pick a random Java library, even if pure logic code, one of the Kotlin FFI selling points and use it with Kotlin/Native, if it wasn't originally written with Kotlin/Native memory model in mind.

[Gama11]

I work with Kotlin at my day job but am also active in the Haxe open source community. I really like both languages, and I don't think that Kotlin is objectively better than Haxe.

In practice, there are things about Haxe I miss in Kotlin, but also things about Kotlin I miss in Haxe. Just to name a few examples:

- I'm missing Haxe's pattern matching and macros in Kotlin

- I'm missing Kotlin's level of IDE support and robust null safety (with ?: and ?. operators) in Haxe

(Haxe does have experimental opt-in null safety, but it doesn't seem production-ready yet)

[MokaAkashiya]

Yep, try-haxe itself is generated JS+PHP code from shared Haxe codebase. There is also some bytecode targets: JVM, HashLink JIT (fast in compilation Clang target alternative), neko (older Haxe VM), swf.

[uvtc]

Well, it also has its very own [Hashlink, virtual machine](https://hashlink.haxe.org/).

And it can also compile down to various bytecodes (like JVM), not just to other languages.

[amitport]

Exactly