As we seem to be having an eternal N+1 conversation about this…
The question I have been asking myself about Elm recently is “How can Elm be de-risked?”.
I would like to compile a list of things that are considered to be risks that organisations face when adopting Elm or not. I would also like to keep this conversation focussed entirely on that, without going off on tangents, so please try to contribute in the manner that I am asking for. I will post up the first example to give you the idea of how I would like to proceed.
The idea is to have a bit of a brainstorming session on this forum, to capture all the problems that we encounter when trying to promote Elm to our peers at work, or to recommend it to strangers on the internet. The aim is to find and focus on the risks, both real and perceived. I am happy to run this process and will proceed in 3 stages.
On this topic, collect a list of risks (and not opinions). This topic should remain open until its 10-day auto close timer kicks in, which should be plenty time to consider everything.
De-duplicatte that list by merging things that are similar enough into single items. Potentially filter out anything that is irrelevant (but even small stuff should stay in).
Solicit feedback from the community on the risks - how severe are they (say on a score of 1-5), what can be done about them, and how much work would those solutions involve (also maybe give a score). Maybe some kind of survey tool will work for this part.
The end result should be a fairly comprehensive list of the risks, and can be sorted by severity/effort to give an idea of where effort can be best spent to solve these issues.
As below, please just try and state the risk, however small, and without considering whether or not its an important risk or just some kind of misconception that exists out there on the internet. At step 2, the severity scoring will bring that out anyway.
Unclear future direction of the language and it’s features
if I would like to build my business on the language, I need to be sure that new version of the language won’t remove something I’m going to rely on (like e.g. Lazy structures, Kernel modules etc.) - without any roadmap or communication in advance we are just blind
The inability to run forked versions of core libraries (and the idea that a new version of Elm could make it even harder to get around this limitation. For all we know, such a release may be made before the relevant bug fixes are put out).
(This would be much smaller if bug fixes were released in a more timely manner)
Strict version control causes packages to be incompatible with newer elm versions even if they are compatible (unless maintainer takes action)
I’m fully aware of the benefits but if the perception is that community/maintainers are leaving - how will the ecosystem keep up with the core if even the stable packages will at some point be considered outdated?
Unclear process for raising issues. GitHub issues look like they can end up never getting responses, and it’s common to hear that you should submit experience reports, but it’s not clear where they are best submitted.
Perceived difficulty in implementing unsupported API-s (some common some more exotic)
Will I be able to easily support WebSocket (ports)
Will I be able to easily support WebRTC (ports + custom elements)
(these are the two that come to mind first)
The perceived risk is not whether this can be done but more how will it work and what are the long - term consequences as opposed to using technologies that have an established best practice and library support.
Missing transparent roadmap. I don’t care if it will take a year or two or even if half of the features will be dropped, but most users would like to know what is happening. I imagine that this is the main reason people from outside think Elm is dead. The last roadmap was not clear enough what was the potencial explorations. Including that last site blog post was on 21 Oct 2019.
To expand on the lack of a FFI, yes, it means that it’s difficult to call existing, pure Javascript code. But it goes the other way too:
Only Elm code can call other Elm code, so if you buy into writing Elm code and end up regretting, it’s hard to move away again. You’ll have to try and break your Elm code into isolated islands, that can be migrated one by one.
I think the community has an image problem, that also adds to the risk. When 0.19 was released and native code access was removed, there was very little empathy for the people who got burnt in that transition. It was common to hear a phrase ala “Your goals don’t align with Elm, have you considered another language?”, regardless of how much Elm code somebody now had to migrate.
I think that transition was damaging, because it created an image of a project that might change direction, and if your project doesn’t work with the new direction, you’re shit out of luck. Taken with the closed nature of Elm’s development, and your inability to influence its direction, I think this is perceived as a risk.
Whether that image is accurate or not is out of scope here, but it was an impression I got back then, and I doubt I’m the only one.
I think for managers/companies the most important thing is: can I found the skills in the market?
They are used to quickly changing technology, but if they think they can’t hire people to work on a project after you’re gone, it’s usually a non-starter.
If I make a great game with Elm, I can’t release it on e.g. iPhone or Nintendo Switch (app store). I can make it somewhat usable on a mobile browser, but then it’s a compromised experience. I would have to re-write the game in Rust or some other language that cross-compiles into native code and supports multiple graphic layers (Vulkan, Metal and so on).
Counter: Elm can be a good prototyping platform for games, and the “Rust rewrite” can be a good chance to review decisions made in the prototype.
