[vlangber]

I think there is a clear distinction between languages and frameworks.

But again, what are the clear benefits for the customer of choosing Elm compared to the more popular choices in the market, given the (IMO significant) drawbacks of a niche language?

[adamch]

The article lists several: static typing, guarantee of zero runtime errors, sane error handling using rich enums.

Other advantages: async is baked into the framework and isn't an afterthought like React. Immutability is standard and doesn't require a competing ecosystem of immutable datastructures like React. Also significantly smaller download sizes [1]

I also question that Javascript the language doesn't change: it's gone through several big language changes, and a growing number of devs wanted more changes, so stared writing in Typescript or Flow.

[1] https://elm-lang.org/news/small-assets-without-the-headache

[dorian-graph]

Elm is so small, I'd almost argue that it's easier to learn Elm and The Elm Architecture than it would be than to worry about some almost equivalent combination of TypeScript, React, Redux (which was inspired by TEA, afaik), etc.

From a business perspective, having 0 JS crashes or errors in production is nice. I say that as someone who works at a startup that switched to Elm in 2017 and have had that very experience.

[Skinney]

a) Many things that are runtime exceptions or silent errors in other languages, are compile errors in Elm.

b) Immutability, strong type system and few language constructs make local reasoning very easy. Developers spend less time chasing bugs.

c) Easy to learn. In virtual all jobs that I've had as a frontend developer, there's always been something new to learn. I spent more time learning Ember than I did spend on learning Elm.

d) Less churn. Javascript and related frameworks are, to me at least, exhausting to stay up to date on. Elm changes at a much slower pace.

[vlangber]

I would argue that Typescript and React or Vue would have been a better solution for the customer. Yes, Elm might be better in some aspects, but I could name quite a few benefits for Typescript as well.

I think the technical reasoning is okayish, but from a business perspective I don't think the customer made a good choice.

[Skinney]

We actually do have react in production as well. The header on our website is a react component, and our app is written in react-native. We also tried out flow for a while.

Elm compiles faster, has better error messages, is a simpler language (so our apps tend to stay simple, so easier to pick up again after some time) and has less churn.

We have experience with other technologies, we just find Elm better :)

[dorian-graph]

> I would argue that Typescript and React or Vue would have been a better solution for the customer. Yes, Elm might be better in some aspects, but I could name quite a few benefits for Typescript as well.

Go on then. ;)

[vlangber]

I would think most people on Hackernews are familiar with Typescript, but some of the benefits from the top of my head:

- Better tooling - Easier to work with existing javascript code - Superset of javascript - Larger community and ecosystem - More developers are familiar with it - Easy Server Side Rendering

[Lio]

I’m someone that only vaguely knows Typescript and doesn’t know Elm at all, so please forgive me if these seem obvious but would you mind expanding on some of your points?

In what way is the Typescript tooling better? i.e. what can you do with it you can’t do with Elm’s tooling?

Also I’m intrigued by the claim of “easier server side rendering” is it difficult to run Elm code on top of node.js?