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....
Elm in Production: 25K Lines Later
21–30 of 278 posts
Re: Elm in Production: 25K Lines Later
#22Having 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?
Re: Elm in Production: 25K Lines Later
#23First: > 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,…
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
There's also Purescript, which is built for the web but has many of the goodies you'd expect from Haskell.
Re: Elm in Production: 25K Lines Later
#24After doing a couple of contracts on Elm projects for several months, and returning now back to a React-Redux stack project, I cannot emphasize enough how much better working with Elm is.
In every single aspect. I just wish that it will get mainstream as soon as possible.
His article is spot on, and agrees with what I've seen, and most others that used Elm. Just look it up.
Re: Elm in Production: 25K Lines Later
#25If 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.…
This looks really promising. Do you use it in production anywhere? Do you have any comparison of features with Elm?
Re: Elm in Production: 25K Lines Later
#26If 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.…
This is very cool. The example apps are relatively slow to load compared to the equivalent in some other frameworks (my favorite is Mithril for an idea of how small/fast these can get).
Was wondering whether it might be a slow server, but the app.js for the TodoMVC appears to be over a megabyte (1.21 MB, have a 4000 line Mithril app which is 500k uncompressed). What's up with that?
Re: Elm in Production: 25K Lines Later
#27Having 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?
Once you handle a couple of complicated cases, you're ready to solve any JSON decoding within minutes. It's just a small learning curve to go through.
Also, once you get the hang of it, you can use it as your safety layer for incoming data. To guard the app from any invalid response.
I've even used GraphQL for one of my projects, decoding worked fine as well.
Re: Elm in Production: 25K Lines Later
#28What an excellent article: from tech to business, from the human aspect to practical code examples. Worth a read, even if you're not considering Elm.
Not into Elm at all right now and also kind of not convinced about functional programming, yet. But the article was definitely worth a read. I need to slowly open up for FP, I guess.
I'll make an observation: I write C# for a living. The great thing about that is that it has a truly great debugger. But, as you rapidly discover, it's easier to debug some code than others. For one thing, you want to be able to go back to the start of the function and re-run it. That means that methods that mutate internal state are hard to debug. Also, it's even better if you can follow the chain of reasoning without rerunning the code. This means having a variable for each assignment, rather than overwriting an existing one. Finally, when processing large data lists, it's easier to debug if you have separate variables for logical steps. e.g. Get the employees of Company X (variable) that are managers (variable) and sum their salaries (variable). Trying to debug round a for loop is an exercise in frustration.
What all these things have in common is: it's easier to reason about the values in a program than the program counter, and that destroying information makes it harder too. And that, to a great extent, is why FP is useful. Even really basic FP in C# or Java.
Re: Elm in Production: 25K Lines Later
#29[deleted]
Re: Elm in Production: 25K Lines Later
#30If 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.…
Decoding json, the one most important format of the web, is hard in elm, a language supposedly designed for the web? I'm glad I didn't give it a try.