[ToJans]

First:

> Elm has an incredibly powerful type system

Near the end of the article:

>Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application.

IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e.

  {-# LANGUAGE DeriveGeneric #-}
  
  import GHC.Generics
  
  data Person = Person {
        name :: Text
      , age  :: Int
      } deriving (Generic, Show)
  
  instance ToJSON Person
  instance FromJSON Person

While I understand Evan's aversion against complexity, it makes me a bit wary about using ElmLang in production. I am currently using TypeScript, but if I would need a more powerful type system, I would probably switch to Haskell/PureScript or OCaml/BuckleScript instead.

[_gi12]

I really wish people would stop spreading the meme that decoding JSON in Elm is "hard". Yes, Haskell allows you to automatically decode/encode datatypes, but this only works in the simplest of cases. For example, if your backend returns a JSON object with snake-cased fields, but your model has camel-cased fields, `instance ToJSON Person` won't work; you'll have to write a custom decoder. The automatic decoders/encoders in Haskell only work if the shape of your JSON perfectly matches your record definition.

Writing decoders in Elm is not hard. It's manual. It's explicit. It forces you to specify what should happen if the JSON object has missing fields, incorrect types, or is otherwise malformed. There's a slight learning curve and it can be time consuming at first, but it guarantees that your application won't blow up at runtime because of some bad data. Because of this, JSON decoding is frankly one of my favorite parts about Elm.

Typescript, on the other hand, offers no such guarantee. If you write a function that takes an Int and you accidentally pass it a String from a JSON response, your app will blow up and there's the nothing the compiler can do to help you. Personally, I'd rather write JSON decoders than have my app blow up because of a silly mistake.

[charukiewicz]

Author here. I agree with your points, and in my article I specifically mention that there are benefits to some of the "hardness" of certain tasks in Elm (type-safety in the case of JSON decoding).

But to claim that JSON decoding in Elm is not significantly more difficult than it is in JavaScript would be misleading. A front end developer that has only written JS will be surprised when he/she cannot just drop in the equivalent of JSON.parse() and get an Elm value out of it. I call it "hard" because there is a bit of a learning curve, and it does require some thought, and quite frankly it takes quite a bit of time if you have a large application like we do.

Moreover, I am not complaining. And I do not think people should be. As I said in the article, the tradeoff is worth it.

[somenewacc]

You don't need to write the decoder boilerplate manually to get all those benefits.

For example, here's how you rename a JSON field while serializing/deserializing a data type in Rust:

https://play.rust-lang.org/?gist=1b382bc1572858841d5e392435d...

You just annotate the field with #[serde(rename = "..")]. Here is a list of such annotations

https://serde.rs/field-attrs.html

Serde is also generic in the serialization format; the example I linked uses serde_json, and was adapted from its README here https://github.com/serde-rs/json

[MaxGabriel]

Same for Haskell. This package provides common translations like snake_case to CamelCase:

https://www.stackage.org/haddock/lts-9.0/aeson-casing-0.1.0....

Giving you automatic encoders/decoders like so:

instance ToJSON Person where toJSON = genericToJSON $ aesonPrefix snakeCase instance FromJSON Person where parseJSON = genericParseJSON $ aesonPrefix snakeCase

And the implementation of that package is like 4 simple lines for snake case; it's totally doable on your own for whatever you need https://github.com/AndrewRademacher/aeson-casing/blob/260d18...

I haven't had to do snake_case to CamelCase with Aeson before, but I have dropped a prefix before, like "userName" -> "name", "userAge" -> "age", and it was pretty easy and well supported.

Also I would note that this isn't as big of a deal for Haskell and Rust, because they're primarily backend languages, so they're more often sending out JSON in whatever form they please, rather than consuming it. In my experience the main consumers (Javascript on the web, Objective-C on iOS and Java on Android) use CamelCase anyway, so there's a natural compatibility.

[empath75]

> Writing decoders in Elm is not hard.

At some point, after enough people tell you that they can't figure out how to do something, one should admit that it is difficult.

[Skinney]

Or that the documentation can be improved, or the API could be improved, or a number of other things. But really, JSON encoding/decoding in Elm boils down to specifying what the type of an object's field is. If that is difficult, interfaces and classes must be a nightmare.

[empath75]

Here is what people are comparing it to, in terms of difficulty:

json.loads('foo.json')

I spent 3 days about 6 months ago, off and on, trying to figure out json decoding in elm, and gave up on the language entirely. It wasn't a matter of simply specifying types. The syntax is confusing the compiler isn't any help. I had very little difficulty working with anything else in Elm, so I think there is a lot of work to be done there.

If there were a more painless way to do it, there are a lot of api's I'd love to write front ends for in elm.

[fbonetti]

Elm's primary selling point is "no runtime exceptions". The subheader on Elm's homepage even says this[1]:

    Generate JavaScript with great performance and no runtime exceptions.

Type safety doesn't come for free. If you want to build an application that doesn't have runtime exceptions, you have to specify what external data should look like, how to translate that data into a native datatype, and what to do if that expectation fails. With this in mind, you can't just write `JSON.parse(data)` and expect everything to work. What if your data has a different shape? What if it's missing fields? What if field "foo" is a String instead of an Int?

Here's a short example in Typescript:

    import fetch from "node-fetch"

    interface Post {
      user_id: number,
      id: number,
      title: string,
      body: string
    }

    const postUrl = 'https://jsonplaceholder.typicode.com/posts/1'

    const show = function(post: Post) {
      console.log(post.user_id)
      console.log(post.id)
      console.log(post.title)
      console.log(post.body)
    }

    function getJSON(): Promise<Post> {
      return fetch(postUrl).then(x => x.json())
    }

    getJSON().then(show)

Do you see the bug? `user_id` is supposed to be `userId`, yet this example will compile without an issue. When you run it, `post.user_id` will be undefined, even though our interface clearly states that a Post most have a `user_id` field of type `number`. The compiler won't catch this even with `--strictNullChecks` enabled.

Everything in programming is about tradeoffs. If you don't care about strong type correctness, use something like Typescript. If you do care, Elm is a great choice.

[1]: http://elm-lang.org/

[hudon]

Elm's type system will not catch this bug at compile time, it will still be a runtime exception, unless you're saying Elm's compiler does an HTTP call to that endpoint to verify that the interface matches the response object??

The only difference in your example probably is that Elm will force you to handle the case where your interface doesn't match the response object (missing field, in this case). But nothing in Elm forces you to handle it well, so if the programmer forgot to handle it well in TypeScript, they will do the same in Elm, and the end result will be the exact same: a runtime failure.

[Skinney]

json.loads('foo.json') (what is that? python?) requires that the json matches your types exactelly. This, at least for me, is rarely the case.

And yes, it is. Here is code from my own project:

    Json.map3 HintTemplate
        (Json.field "ID" Json.int)
        (Json.field "Text" Json.string)
        (Json.field "Image" Json.string)

Where HintTemplate is a record type containing an integer id, a string text and a image url. What about this is difficult?

[Tarean]

That's reasonably similar to handwritten haskell json parsing:

    instance FromJson HintTemplate where
        parseJson = withObject $ \o ->
           HintTemplate
             <$> o .: "ID"
             <*> o .: "Text"
             <*> o .:  "Image"

I wrote <$> and <> out but there is a definition like map3:

    liftA3 f a b = f <$> a <*> b

This works for all applicatives, though. Is it normal for elm libraries to copy paste code like the map3 definition?

[wraithm112]

With respect to the snake-cased fields issue, it's actually not that hard to do that with Generic in Haskell.

  data Person = Person
       { personFirstName :: Text
       , personLastName  :: Text
       } deriving (Generic)

  instance ToJSON Person where
     toJSON = genericToJSON $ aesonPrefix snakeCase
  instance FromJSON Person where
     parseJSON = genericParseJSON $ aesonPrefix snakeCase

Which produces messages like:

  {
   "first_name": "John",
   "last_name": "Doe"
  }

[neerajdotname2]

I found it hard. I have been learning Elm for a few weeks. I have a background in Ruby and in JavaScript. I have a repo where I am trying difference cases. https://github.com/bigbinary/road-to-elm

[KirinDave]

It's not so much that writing decoders is hard it's that writing robust parsers without applicative is quite laborious, once you're used to having them.

[justinw2]

It seems like there's no solutions for generic JSON encoding for OCaml/BuckleScript/Reason either though.

I've worked on various ways to do JSON encoding in Purescript through datatype generics, but the recent RowToList machinery lets us use record types directly. I have a post and some links collected if anyone is interested:

https://www.reddit.com/r/purescript/comments/6mss5o/new_in_p...

http://qiita.com/kimagure/items/d8a0681ae05b605c5abe

[shakna]

Yojson [0] provides a generic way to read JSON in OCaml. Mostly by pre-defining a type that contains any valid json value.

[0] https://github.com/mjambon/yojson

[justinw2]

Right, there are some various approaches but I've had a few OCaml users tell me there were some reasons why they weren't/couldn't be used on the front end, sadly. Would really like to see some demos otherwise though

[3pt14159]

The only JSON encoder / decoder / manipulator that I've seen that is typed and reasonably flexible is Nim's, but even there it's still 5 times more complicated than say Ruby.

[dmjio]

If you want a powerful type system (i.e. Haskell), but the benefits of Elm, Miso is a project that implements the Elm Architecture in Haskell. It obviously has typeclasses, and can encode / decode JSON on the frontend using GHC.Generics quite well. https://github.com/dmjio/miso

[masklinn]

There's also Purescript, which is built for the web but has many of the goodies you'd expect from Haskell.

[kahnpro]

I tried out Purescript for a project and didn't think it's ready for production... Generic encoding/decoding was painful, the lack of good dependency management was painful, too many things were either missing or immature. I hope in a year or two the story will be better.

[KirinDave]

PureScript is a rapidly moving target. When did you try?

[reitanqild]

Eh, I don't know PureScript but IMO you just added another reason why it isn't production ready.

Unless they are really really good at keeping backwards compability in both language and build tools.

[KirinDave]

Nope, they break things all the time. Or at least, they did one major break earlier this year. "Production ready" is different from "should I use this ever at all though."

Doesn't really answer the question I posed though.

[agentultra]

And GHCJS is quite good these days as well.

[Rotareti]

Whenever something about elm pops up, I see people complaining about this. Reminds me of people complaining about Golang missing feature X. Still both languages raising in popularity. I haven't used Elm or Golang, but I'm almost convinced that simplicity is a driving factor for their success.

[BoiledCabbage]

This is exactly it. I can't speak for Golang, but why Elm wins is its simplicity.

You can go through the tutorial and know the language in two days. Seriously if you ever want a weekend project, try learning elm.

Even if you don't want to use it, but just to be exposed to the ideas.

You csn be writing productive code in a week. If anyone tell you Haskell (or Purescript) is less than months to be productive is not being honest about what production level productivity entails. You can learn the fundamentals in less time, but the prized significantly more complex abstractions makes ramping up significantly slower. And this is coming from someone who likes haskell and is enjoying learning the language.

As someone who has used a lot of languages over the years, I really do say spend a weekend trying it out. The language has great ideas and a great philosophy.

https://www.elm-tutorial.org/en/

[Rotareti]

I'm playing with the idea of starting a project in Elm for a while now. I already built my own crippled version of Elm using TypeScript, React, ImmutableJS, Recompose and Ramda... The only thing holding me back is the ecosystem around JS, say ReactNative, d3, etc.

[kccqzy]

That doesn't handle custom JSON schemas at all. I don't know much about Elm but at work in Haskell we mostly write FromJSON instances manually. It's probably the same amount of code as the data type definition.

[ToJans]

For custom JSON schemas nothing tops F#'s type providers [0] IMO.

[0] https://github.com/jet/JsonSchemaProvider

[jlouis]

This is the way to go, if you are tied to JSON for some reason. A far better solution is to get rid of JSON if most of your stack is a typed stack and then convert to JSON as late as possible.

Custom JSON which people invent as they go along is just going to present your system with pain over time.

[pyrale]

Do you have examples of things that don't fit the vanilla FromJSON ? From the top of my head, there's lensed things (which can easily be done once with a LensJSON typeclass), and things which use a different serialization (e.g. no "tag" field, etc) for which there is little you can do, if each of your data types has its own standard. If they do, though, you could easily define a typeclass for each source (e.g. StackoverflowJSON, HackernewsJSON, etc).

[kccqzy]

We don't do type classes for this purpose. If you have to interface with some JSON with predefined schema, we just write the instances manually. It's not that hard at all—usually it's just calling withObject with a series of lifted function applications `Constructor <$> (o .: "field1") <*> (o .: "field2")`. Remember the Parser type is a Functor/Applicative/Monad/Alternative/MonadPlus so there's a whole host of utilities for these classes that make writing such instances both simple and concise. Of course if you are doing simple things like removing the leading underscore on lenses data typed, just use TH to derive the instance, passing slightly modified `Options`.

If you need to manually handle tags, here's a snippet that can help you:

    -- | Safely accesses a JSON object where the value at a key is text. It takes an
    -- object, a key, and a continuation of what to do when this key is present.
    --
    -- Example:
    --
    -- @
    --     data D = A | B | C Int
    --     instance FromJSON D where
    --       parseJSON = withObject "D" $ \o ->
    --         o .:=> "tag" $ \case
    --           "A" -> pure A
    --           "B" -> pure B
    --           "C" -> C <$> (o .: "theInt")
    --           t -> fail $ "Unrecognized tag in type D: " ++ unpack t
    -- @
    (.:=>) :: Object -> Text -> (Text -> Parser a) -> Parser a
    o .:=> k = \m -> o .: k >>= withText ("Object with mandatory key " <> unpack k) m

[danidiaz]

One could use a generics library to emulate something like Go's struct field tags, which decouple "external" fields names from the actual field names. Something like this is explained from 48:50 in this talk: https://skillsmatter.com/skillscasts/10181-fun-with-sum-and-...

But perhaps it wouldn't save much code compared to custom-made parsers.

[vim_wannabe]

In Rust you can also just make your struct deserializable, use a JSON lib to deserialize a string and get the corresponding object in a Result type.

The amount of work you need to do in Elm instead is huge.

[askAwayMan]

Purescript's Argonaut lib has major performance issues that are incurred for the "powerful type system."

When you only have thousands of items in an array, you end up with performance discrepancies between older browsers like IE 11 and Chrome that are unacceptable outside of a toy application.

[KirinDave]

> Purescript's Argonaut lib has major performance issues that are incurred for the "powerful type system."

Can you explain what you mean here? Your explanation below suggests a runtime cost for the type system, which just isn't true.

I'm aware Argonaut's approach generates slower code. The nice part of any such happenstance in PureScript is that if you do find an issue it's easy to bang out some Javascript in a foreign call to do what you need.

I find outside of Slamdata, folks are keen to do this. PureScript is a very new language and is still finding ways to generate code efficiently in it's target environment.

[Ar-Curunir]

On the other hand, something like Rust has similar typeclasses, and runs blazingly fast. Serde JSON is super quick and efficient.