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

31–40 of 278 posts

Re: Elm in Production: 25K Lines Later

#31

Post by StreamBright »

aaron-lebo wrote: post #26
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.…

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?

Can you give exact numbers and a testing method of how you tested and determined it is slow?

Re: Elm in Production: 25K Lines Later

#32

Post by delegate »

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 ?

Re: Elm in Production: 25K Lines Later

#33

Post by willtim »

endgame wrote: post #20
ryanplant-au wrote: post #16

Earlier quoted context omitted.

Can you elaborate on what you mean when you say that (==) : a -> a -> Bool is a lie? I don't have enough experience with more powerful type systems to know what the more accurate claim would be. Do you mean that it should really be Eq a => a -> a -> Bool, because not all types can be checked for equality?

That's exactly what I mean: A type like a -> a -> Bool says that it will work for _any_ a, but we can easily find counter examples. We could pass in functions (say) and write something like (\x -> x * 2) == (\x -> x + 1). The type signature for (==) as written says it _should_ work, but it doesn't because there's no general way to compute function equality. Instead, there's this temporary hack[0]: > Note: Equality (i…

It we would be easy to add simple built-in constraints for things like equality, without jumping all the way to full-blown type classes. This would be a very minimal change to the type checker and should not require a rewrite.

Re: Elm in Production: 25K Lines Later

#34

Post by justinw2 »

ToJans wrote: post #8

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,…

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

Re: Elm in Production: 25K Lines Later

#37

Post by dmitriid »

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…

Can't for the life of me figure out why people equate FP with the abomination that Haskell is.

Erlang is FP. Javascript is FP. Ocaml is FP.

Type classes, or anything else that has "types" in them such as dependent, or liquid, are not FP, they are types. Types that found their way into a couple of FP languages.

Re: Elm in Production: 25K Lines Later

#38

Post by dmitriid »

> 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 pragmatic language

Re: Elm in Production: 25K Lines Later

#39

Post by aaron-lebo »

StreamBright wrote: post #31
aaron-lebo wrote: post #26

Earlier quoted context omitted.

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?

Can you give exact numbers and a testing method of how you tested and determined it is slow?

The router example on Github loads ~1.5 MB of JS files. Mithril's entire framework is 8kb gzipped (including a router).

Re: Elm in Production: 25K Lines Later

#40

Post by Albert_Camus »

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?

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

Post reply on HN