5 ms·
If you're interested in ReasonML, you may also be interested in Elm http://elm-lang.org/ http://elm-lang.org/. Coming from JavaScript / React / Redux / Flow, R
by osteele 9y ago
If you're interested in ReasonML, you may also be interested in Elm http://elm-lang.org/ 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.
- bjz_ 9y agoReason 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.
- enalicho 9y agoCan 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 agoVery 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 agoI've never noticed runtime issues with Elm.
- ch4s3 9y agoMy 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 agoI 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 agoYeah, 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 agoI'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 agoI 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.
- myth_drannon 9y agoFacebook 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.
- yawaramin 9y agoOne 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.
- m0meni 9y agoThe 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.
- anthonybullard 9y agoI'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.
- rtfeldman 9y agoI'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!
- weavie 9y agoConversely, if you are interesting in both Elm and ReasonML there is Bucklescript-Tea - https://github.com/OvermindDL1/bucklescript-tea/ https://github.com/OvermindDL1/bucklescript-tea/. The Elm architecture ported to Bucklescript.
- splintercell 9y agoIs it as fast as Elm?
- weavie 9y agoI haven't tested the performance, but I see no reason why it shouldn't be.
- zem 9y agothere'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 https://github.com/LexiFi/ocaml-vdom [1] https://github.com/LexiFi/gen_js_api https://github.com/LexiFi/gen_js_api
- sridca 9y agoAnd 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/ http://purescript-pux.org/ https://haskell-miso.org/ https://haskell-miso.org/ http://docs.reflex-frp.org/en/latest/ http://docs.reflex-frp.org/en/latest/
- splintercell 9y agoI 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-development-performance-compare-603dyh83m https://www.codementor.io/rudolfolah/elm-vs-react-developmen...
- hazza1 9y agoFramework 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.
- aaron-lebo 9y agoIt'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.
- continuational 9y agoIf 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.
- deleted 9y ago[deleted]
- 9y ago