On the other hand, people need to learn to take no for an answer and move on. Instead, egos get involved and a new essay of the week appears on how Elm is doom

On the other hand, people need to learn to take no for an answer and move on. Instead, egos get involved and a new essay of the week appears on how Elm is doomed because it doesn't have <pet feature>. That nobody can take Elm seriously if it doesn't have type-classes, synchronous FFI, derivable JSON codecs, component state, or whatever the pyre was built on that day. If you didn't know better, you'd think they were disgruntled paying customers. Elm's simplicity, lack of abstraction, and resulting boilerplate have more to offer than helping beginners learn. Nothing demonstrates this better than coming back to an old Elm application and immediately making meaningful changes to the code despite a long hiatus from using Elm at all. There are a lot of languages that continually add features in this space like PureScript, ReasonML, and even TypeScript. Why not see where Elm ends up with its aggressive devotion to a minimal API instead of trying to turn it into a language we already have? Some of the best aspects of Elm come from its restrictive nature. Like how every Elm application uses the same "TEA" abstraction which is a breath of fresh air for anyone who never felt particularly empowered by the paralyzing abundance of options in the JS ecosystem nor the task of webpack-plumbing them together.