[Albert_Camus]

Author here. As I posted in a different reply:

JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object.

In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or to custom types defined in your program), there may also be a bit of a learning curve.

As I stated in the post, there is a benefit in doing all of this: your Elm application will effectively type-check your JSON and reject it if it is malformed.

[dmitriid]

Yeah, it will typecheck it if you're not bored out of your mind writing all the boilerplate and don't introduce subtle bugs https://medium.com/@eeue56/json-decoding-in-elm-is-still-dif...

[maxiepoo]

Can you not do the same thing as JSON.parse() in Elm by parsing into an unstructured JSON type?

[mjaniczek]

Parsing into Json.Encode.Value gives you that Value but no way to work with it except, at later time, using Json.Decode.decodeValue on it. And you're back to specifying decoders...

[maxiepoo]

Seems like you could easily make a library that just parses into some Union type that represents JSON values.

It's likely a design decision to force people that otherwise wouldn't to represent their data in a more structured way.