Hacker News Reader

Comment by enalicho | Hacker News Reader

Can you quantify this? In what sense is the JS output from Elm lagging behind? What is it about the JS output from Reason that makes it better?

View on HN

Very bloated, lots of allocations, not compatible with other JS module systems, no uncurrying optimizations, no integer optimizations, etc. Bucklescript's output is pretty damn impressive on the other hand: https://reasonml.github.io/en/try.html (check out the factorial example, for instance)

I've never noticed runtime issues with Elm.

My biggest gripes with Elm are cumbersome JS interop, and the fact that the output for a hello world when gzipped and minified is still 43kb.

I get what you're saying - as someone who is very concerned about bundle sizes currently - but if you are using something like Elm door a help world, you are already losing. Elm is for complex, highly dynamic user interfaces that need a high level of durability and maintainability. Toy projects like the one you describe are useful for learning the language and it's patterns, but for practical purposes it's like bringing in a concrete truck to patch a hole in your driveway.

Also, that bundle size is still smaller than react + react Dom. And you get the features of redux and immutable for free plus a solid, statically checked type system.

Yeah, bundle size isn't a real deal breaker, but it does make it a bit harder to roll into an existing project in small chunks. My main issue is the interop portion.

I'd like to hear about your pain points with interop. I'll more than likely be talking to Evan soon and I can discuss with him. Also, he's pretty responsive in general. The community is pretty eager to help with these sorts of pain points - join the Slack.

I think my biggest issue was the lack of any escape hatch for the development process. When you're trying to interop with JS and have to reason through the types that should be associated with the return value it can be a real slog if the JS returns a deeply nested object. I like that BuckleScript/ReasonML allows you to experiment with raw JS while figuring out the types.

One thing to remember is that you only need to decode the fields that you need access to in elm. You don't have to reason about the whole data structure of it's not used in your program. But I feel you, in JavaScript you can just kind of wing it. But I think there a lot of value in the more deliberate approach. And for your work you are awarded with zero runtime exceptions - which is a pretty amazing guarantee which I've seen be largely born out in practice

As I understand it, the upcoming Elm 0.19 compiler will do dead code elimination for the output bundle.

Ah, that's great to hear!

Reply on news.ycombinator.com