Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm in Production: 25K Lines Later

charukiewi.cz

Post reply on HN
Print view View original

41–50 of 278 posts

Re: Elm in Production: 25K Lines Later

#41

Post by amimetic »

dmitriid wrote: post #38

> making very heavy use of Ajax calls to a JSON-based RESTful API and then > 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. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone). What a great p…

In exchange you get incredible validation of your JSON and precise error messages about missing fields etc.

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.

Re: Elm in Production: 25K Lines Later

#42

Post by Albert_Camus »

dmitriid wrote: post #38

> making very heavy use of Ajax calls to a JSON-based RESTful API and then > 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. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone). What a great p…

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.

Re: Elm in Production: 25K Lines Later

#43

Post by mjaniczek »

delegate wrote: post #32

Anyone familiar with both Elm and Clojurescript ? Clojurescript's 're-frame' lib implements something similar to the Elm architecture and is quite pleasant to work with. How does the Elm experience compare to the Clojurescript experience ?

Simple: writing code in Elm is compiler-driven development. As the article said:

> Just start by changing your type definition and the compiler errors will help you find everywhere that needs updating.

This is how most of Elm development gets done. I change the types and let the compiler tell me what actual code needs changing.

Clojurescript, on the other hand, doesn't have this "assistant", unless you're using Typed Clojure or Schema (it's been a year or two since I tried that, so can't speak from current experience).

The Elm Architecture is worth pursuing even in dynamically typed languages though :)

Re: Elm in Production: 25K Lines Later

#44

Post by enalicho »

dmjio wrote: post #21

If decoding json in Elm is considered hard, I'd recommend checking out miso ( https://github.com/dmjio/miso ), a Haskell re-implementation of the Elm arch. It has access to mature json libraries like aeson for that sort of thing, along with mature lens libraries for updating your model. Here's an example of decoding json with GHC.Generics using typeclasses. https://github.com/dmjio/miso/blob/master/examples/xhr/Main.…

You don't need to switch a whole language because of JSON decoding. There are many tools that exist to aid you write JSON decoders in Elm. The language is not just about the architecture -- you can implement the architecture in any language, as Redux has proven. What people like about Elm is the compiler and design philosophy that radiates through the entire community. Switching to Haskell won't give you that, as the Haskell community has different priorities.

Here are some JSON tools for Elm:

- json-to-elm http://json2elm.com

- swagger-elm https://github.com/ahultgren/swagger-elm/

- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql

- elm-export https://hackage.haskell.org/package/elm-export

Re: Elm in Production: 25K Lines Later

#45

Post by dmitriid »

amimetic wrote: post #41
dmitriid wrote: post #38

> making very heavy use of Ajax calls to a JSON-based RESTful API and then > 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. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone). What a great p…

In exchange you get incredible validation of your JSON and precise error messages about missing fields etc. 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…

Yup. There are a bazillion libraries now trying to pretend to make it look like it's easy to deal with JSON in Elm.

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"

Re: Elm in Production: 25K Lines Later

#46

Post by enalicho »

kristianp wrote: post #22
iamwil wrote: post #10

Having started using Elm for side projects over 3 years ago, the article is pretty much spot on. Programming in Elm had been a delight, especially when you let go of OOP and embrace functional concepts and practices. On one hand, you lose mental tools that you've relied on, but you gain the other tools you didn't even know existed before. Where I really disliked about Elm is when I had to encode or decode JSON. It's…

Isn't decoding JSON a big part of an SPA though? How do you deal with data from the server?

There exist multiple tools to aid you with writing decoders:

- json-to-elm http://json2elm.com

- swagger-elm https://github.com/ahultgren/swagger-elm/

- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql

- elm-export https://hackage.haskell.org/package/elm-export

Once you've got the hang of it, it's not that hard either. Just time consuming. That's where json2elm comes in :)

Re: Elm in Production: 25K Lines Later

#47

Post by enalicho »

therealmarv wrote: post #35

When JSON decoding is hard this is not a minor thing when looking at my RESTful APIs. This is a major trade off. How to deal with it ideally?

Right now, there exist multiple tools for dealing with JSON:

- json-to-elm http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export

It's worth noting that JSON decoding is not _hard_ as such, but it's harder than other parts of the language. It is more time consuming. Tools like these can help reduce the amount of time you spend hand writing decoders.

Re: Elm in Production: 25K Lines Later

#48

Post by dmitriid »

Albert_Camus wrote: post #42
dmitriid wrote: post #38

> making very heavy use of Ajax calls to a JSON-based RESTful API and then > 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. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone). What a great p…

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…

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...

Re: Elm in Production: 25K Lines Later

#49

Post by hellofunk »

endgame wrote: post #4

I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the po…

Here are some relevant discussions related:

https://news.ycombinator.com/item?id=14870642

Re: Elm in Production: 25K Lines Later

#50

Post by a-saleh »

dmjio wrote: post #21

If decoding json in Elm is considered hard, I'd recommend checking out miso ( https://github.com/dmjio/miso ), a Haskell re-implementation of the Elm arch. It has access to mature json libraries like aeson for that sort of thing, along with mature lens libraries for updating your model. Here's an example of decoding json with GHC.Generics using typeclasses. https://github.com/dmjio/miso/blob/master/examples/xhr/Main.…

I am kinda waiting for Purescript to mature a tiny bit more in this regard, because it seems that they have something special brewing there, with their polymorphic record type and interesting take on type-level programming.

Because this [1], even though it seems to be just a experiment so far, looks really good.

I.e: doing

type MyTestStrMap = { a :: Int , b :: StrMap Int }

and then just calling

let result = handleJSON """ { "a": 1, "b": {"asdf": 1, "c": 2} } """

let newResult = doSomething (result:: Either MultipleErrors MyTestStrMap))

is kinda all I ever wanted in these haskell inspired languages?

[1] https://github.com/justinwoo/purescript-simple-json/blob/mas...

Post reply on HN