And you don't have to write that bit by hand:
http://eeue56.github.io/json-to-elm/
will generate the decoder for you for straightforward cases and give you a great starting point for more complex cases.
You also get proper ADTs to manage state: not asked/loading/loaded/error something that is tedious and error prone in Javascript.
An online converter is definitely not something I would advertise for a "production-ready highly productive amazing pragmatic language to be used in a serious company"
It's introduction is: "You know how it takes so much effort to produce even the simplest of programs when JSON parsing is involved? Wouldn’t it be nice if you could breeze right on by that step and get on with writing your business logic? This is what you’ll get with The JSON Survival Kit, a short ebook on JSON decoding in Elm."
Wut
In all seriousness, ever language has boilerplate. In js it might be error handling and state management. In Elm, its decoding json.
This is not a valid analogy (and no analogy is ever valid).
> In js it might be error handling and state management. In Elm, its decoding json.
Yeah, and Go has trouble with generics.
It doesn't mean it's a feature that has to be vigorously defended. Especially if it's basically the very first thing anyone will have to do in any web application in a language that is meant for client-side web programming
I'm not sure anyone is defending it. At least, I'm not. Basically Elm's compromise is safety, and less runtime complexity then Haskell. The trade off there is boilerplate. As with most things, there is no free lunch. I've stopped using Elm precisely because of these issues, but I understand why Evan made the choices he did.