4 ms·

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?

bjz_ 9y ago
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 https://reasonml.github.io/en/try.html (check out the factorial example, for instance)
- eweise 9y ago
  I've never noticed runtime issues with Elm.
ch4s3 9y ago
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.
- anthonybullard 9y ago
  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.
  - ch4s3 9y ago
    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.
    - anthonybullard 9y ago
      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.
      - ch4s3 9y ago
        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.
        anthonybullard 9y ago
        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
- frou_dh 9y ago
  As I understand it, the upcoming Elm 0.19 compiler will do dead code elimination for the output bundle.
  - bjz_ 9y ago
    Ah, that's great to hear!

bjz_ 9y ago

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 https://reasonml.github.io/en/try.html (check out the factorial example, for instance)

eweise 9y ago
I've never noticed runtime issues with Elm.

ch4s3 9y ago

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.

anthonybullard 9y ago
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.
- ch4s3 9y ago
  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.
  - anthonybullard 9y ago
    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.
    - ch4s3 9y ago
      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.
      - anthonybullard 9y ago
        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
frou_dh 9y ago
As I understand it, the upcoming Elm 0.19 compiler will do dead code elimination for the output bundle.
- bjz_ 9y ago
  Ah, that's great to hear!