Hacker News Reader

Comment by osteele | Hacker News Reader

If you're interested in ReasonML, you may also be interested in Elm http://elm-lang.org/.

Coming from JavaScript / React / Redux / Flow, ReasonML initially looked more familiar, but I still found Elm easier to pick up. Elm has a more unified feel. ReasonML read to me as an assemblage of components — each of them high quality, and expertly integrated, but it still felt like more different pieces all to learn at once. YMMV.

OTOH, you can't (currently) use Elm to write a native mobile app.

View on HN

Facebook and Bloomberg, two large gorillas throwing their weight behind ReasonML+Bucklescript tooling. Elm is mostly Evan (with support of RedInk)working on the core/tooling with a lot of help from Richard Feldman on general ecosystem. No surprise here that ReasonML is gaining momentum fast.

One thing to remember is that Reason and BuckleScript are rather small projects, with not that many people employed to work on them. Their combined 'manpower' is not that much more than Elm's right now.

What they are cleverly leveraging is the twenty years of solid type theory (a sound type system), language design (more powerful pattern-matching, functions, syntax sugar), and engineering practice (the OPAM ecosystem) that has gone into OCaml.

This is why Reason/BuckleScript are able to punch above their weight class.

Conversely, if you are interesting in both Elm and ReasonML there is Bucklescript-Tea - https://github.com/OvermindDL1/bucklescript-tea/.

The Elm architecture ported to Bucklescript.

there's also ocaml-vdom[0] which i've been enjoying using for a side project - it's built on top of lexifi's gen_js_api[1] and while a little bare-bones right now, is pretty easy to extend with the bindings you need.

[0] https://github.com/LexiFi/ocaml-vdom

[1] https://github.com/LexiFi/gen_js_api

Is it as fast as Elm?

I haven't tested the performance, but I see no reason why it shouldn't be.

The best thing about Elm to me is how it's innovated on tooling, and has trailblazed on the super readable error messages.

At the end of the day though, I don't understand the appeal. The people who really are into functional programming will gravitate towards GHCJS and PureScript whereas the ones that aren't as into it will be drawn to TypeScript and plain JS. I really don't get where Elm fits into it all.

I can see Reason being way more mainstream.

I'm really into functional programming and I gravitate toward Elm and away from PureScript and Haskell.

Fundamentally what appeals to me about Elm is the design sensibility of "what is the minimal set of primitives necessary to achieve a great user experience?"

Over the years Elm has gotten simpler and nicer at the same time. The last three major releases removed language features.

I love that! Building software is complex enough as it is; one of the things I like most about FP is that I no longer have to spend time thinking about objects, classes, inheritance, etc.

It frees up more of my brain to focus on building things!

I'm in the former category and am very enthusiastic about Elm. Reason is great and will probably be more popular overall as it's less of a leap for most JS devs as it utilizes patterns that are already being pushed as best practice and it's relatively loose in comparison. That being said, Elm offers a built-in architecture that reduces decision anxiety.

Reason also has the benefit of Bucklescript which has very high-quality JS output - very friendly to VMs, and the rest of the JS tooling ecosystem. This is something where Elm is sadly lagging quite behind.

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?

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!

And if you are interested in Elm, but felt limited by the language, you may also be interested in PureScript or Haskell.

http://purescript-pux.org/

https://haskell-miso.org/

http://docs.reflex-frp.org/en/latest/

Initially for me Elm felt like a toy language that serious folks should ignore in favor of PureScript and similar. But then after reading code for various Elm applications I realized that I can grasp how things work just by reading the description of the state. Code was just filling details that can be ignored on the first reading. This does not happen with other functional languages when the code ended up passing various important bits of the state in lambdas of callbacks making understanding of the whole much harder.

I have the same concern, what is the performance of these frameworks in comparison to Elm? Elm is super fast compared to React and Angular [1], but what about these frameworks?

1. https://www.codementor.io/rudolfolah/elm-vs-react-developmen...

Framework performance should rarely be an issue in normal use, by super fast you're talking about milliseconds of difference to toggle hundreds of todo item.

It's worth being aware that the Haskell approach (and quite a few of these functional langs) add a lot of size to your bundle.

Hello world in that Haskell library was 1 MB last time it was posted.

If you’re building anything that shows a list of editable things in React, then you’re going to need shouldComponentUpdate() to avoid updating every list item view, every time you type a letter.

It’s virtually impossivle to get shouldComponentUpdate() right when you have ideomatic react with callback props, since callbacks can’t be reliably compared for equality.

Reply on news.ycombinator.com