Elm - What are the risks?

I am not trying to draw up a list of things that I think Evan should fix, nor do I have any expectation that he would, or would appreciate being given such a list. The things that interest me most, are the things that we can try and solve independantly.

I am working on my private package server, but have written a spec for it that describes the full extent of what it will be in its first incarnation. I want to understand more fully the problem that Elm has in interfacing into the world of professional work more widely and see if that informs my thinking around what direction I can push in towards that end. Also, the results may help inform others thinking around what they can do.

I find the N+1 conversation about this, where people pitch in with their ideas but nothing comes of it a little pointless, a distraction at best. Hence the reason for the risk based approach, which is analytical, and not just based on feelings, opinions or sounding off. Gather information - Analyze - Act.

My guess is this will confirm that some of the hardest issues to solve will remain unresolved - are they the most important issues though? And at the levels below that, there is some interesting stuff, that is fixable.


Thats wonderful, it gives me a warm fuzzy feeling all over.


I personally look forward to many years of working with Elm and to its future evolution. It has certainly changed my programming life for the better and enabled me to be far more productive.

I got started in software development with Angular and Ruby, and learned a lot with them. But among the positive lessons was another one: how difficult it can be to grow and maintain a large codebase: hours or days spent tracing runtime bugs back to the source, then fixing the source without breaking something else, etc. In Elm, runtime errors basically don’t exist, and the type system and compiler make refactoring it a pleasure, not an anxiety-producing ordeal.

I believe that the economic benefit of making easy code changes and refactoring in Elm is underappreciated. These tasks take time, and for business, time is money.

Good for you, and good for Evan!


I think a very good response to compiler closed, can’t call JavaScript directly, is that nobody has forked the compiler and created an alternative. It feels that won’t be much work (16 hours??) and can be used as plugin, and probably fairly easily maintained when incorporating new features.

Given that this hasn’t happened, it seems to me this indicates these features are not pressingly needed in the community. It’s more the it would be nice scenario.


I think it has happened, but the successes of these forks vary. The most popular fork I know of is this one:

1 Like

I knew about that one, but I thought it was proof of concept, not really in use, marketed or working.

Well, you can’t call synchronous JS directly. Sending a message to JS and back is possible. For myself, I use code like my SimpleJS or someone else had a similar idea before, elm-eval. For small code I am thinking of creating a string with JS-code on Elm, send it trough port, use eval() on JS, and send the result back.

I really wish to have all “pure” JS-functions (without side-effects) available in Elm, especially for internationalization, but I have no idea, how to match JS-Objects to Elm without a type for it, like Json.Encode.Value, but with the guarantee, that functions keep intact, when stored in Elm.

For date and time formatting, see here: Custom Elements · An Introduction to Elm

For translations I recommend ChristophP/elm-i18next, using this right now for a site that requires Arabic, French and English.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.