- PureScript has a small but passionate community, one of the biggest players in that community laid off their whole ps team so that doesn't bode well.
- ReasonML fractured into ReScript but left half the Reason community behind, it's a confusing space to navigate now.
- GHCJS...
Most (perhaps even all) of the job postings end up on the elm slack (rather than, say, reddit or other more visible places).
There was some controversy with the release of 0.19 a couple of years ago, and general contempt (in the wider community, not inside Elm) for the way the language is developed and run which means there isn't a great deal of buzz about it outside of those already using it.
I was also wondering, does Blazor work with F#? That could also be an option. Not a front-end focused language but a front-end focused framework, so, there's that.
Now what we really need is a functional dialect which compiles to TypeScript...
Why would it be beneficial to have TS as an intermediate representation? It turns into JS anyway, and there are already statically typed functional languages that compile to JS.
Only stage 2, so whether it'll get through to next stage is up in the air, will depend on interest (compare to Temporal which started fairly slow but has gained huge momentum recently and is now at stage 3 and engine testing level) but it's encouraging.
Typescript encourages and is generally more conducive to a different style of programming. That's OK (in fact, clearly it's more than OK given its popularity) but it's not really the sort of thing I want to be writing. I think it's worse if you commit to something like fp-ts or the fantasyland stuff, personally.
I wouldn’t let that dissuade anyone. Even if support diminishes, the language is feature complete, and FFI is so stupidly easy you can freely co-opt JS libs as needed.
Using job postings isn't really that useful. If they where any indication then the two only language in existence would be Java and C#. That depends on where you live of cause. E.g. there are plenty of Python jobs around where I live, but they aren't frequently posted on the regular job sites. I'd suspect that Elm jobs are posted where Elm developers are to be found.
That said, I suspect that given how fun the language is to write, supply probably outpaces demand a bit. Which is actually good, in the sense that for many companies adopting a somewhat less mainstream language one of the main concerns is "will I be able to hire for this?", which generally the answer is "yes, especially for more senior positions".
I find it slightly funny because I also write Svelte at work and that app is public facing so it gets public attention but the Elm app is internal facing so the public will never see it. Also helps that Svelte uses its own name in the code it generates. Which is why I try to promote Elm myself. To semi-quote @SvelteSociety "@Square, a >$100 billon company, uses @elmlang."
With Elm, mutation is impossible - everything goes through the update loop. There are no escape hatches. This does mean you have to jump through a number of hoops to use FFI. It can be a pain at times, but does make for much easier refactoring.
TBH, I thought the pain of FFI in ports (the only mechanism available in Elm 0.19) was kinda overblown. Function input goes into a command, function output comes back as a message. That's just a few extra lines of standard code.
I think they become annoying if you do lots of small, synchronous, safe calls, like using a JS math library. In that case I suspect I would prefer writing a larger JS function instead of having an Elm function full of JS calls, even if I could use a more permissive unsafe FFI, because every JS invocation is still a chance at runtime errors due to type conversions (even with ports).
Needing to type stuff in elm is mostly optional too. The compiler will still check it for you anyway.
Can't speak for the community as whole, but there is at least some demand: the company I'm working for is actively hiring Elm devs for at least two teams at this moment :)