61–70 of 103 posts
How well does Reason interop with OCaml libraries? Also, how will it work with upcoming changes in the OCaml language that require changes to the runtime (like the multicore runtime, possibly modular implicits)?
Earlier quoted context omitted.
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 bring…
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.
Earlier quoted context omitted.
But that's just syntax. As you say, it doesn't mean an arbitrary library written in OCaml will actually run in the browser due to dependencies. It doesn't matter if you can link the code if it won't actually work. I'm reminded of GWT where there is client-only Java, server-only Java, and portable (shared) Java. It's all Java but you definitely have to keep your desired platform's constraints in mind when looking for…
You can try Doppio and JavaPoly. Its a full JVM running on JS, and works with most Java libraries that don't do things which would go against what the JS sandbox is allowed to do.
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.…
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…
I've been following ReasonML pretty closely because, to me, it looks like the most promising compile-to-js language (functional, static types, but practical), and moreover, it can really bring a whole new set of people to the OCaml ecosystem, improving the tooling there. Idealistically, Reason is the language that lets you target any platform by either compiling to JS or native code. That said, I recently tried rewri…
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.…
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/
Earlier quoted context omitted.
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/
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...
I looked at ReasonML couple weeks back intrigued by Jared's post (referenced in this thread as well) I noticed mentions about OCaml not supporting Unicode. I was wondering what does that actually mean? If you target native you have to find good external libraries for Unicode string manipulation? Or that text handling in OCaml (and thus Reason) is harder compared to facilities in, say, JavaScript and Python? Other tha…
What that means is that the language itself has no built-in constructs to distinguish Unicode, or any other encoding by default. OCaml's string type is more akin to an array of chars in C, in that it just represents a series of bytes. There's nothing about the string type that describes the contents of the bytes. So while you could put ascii in there, when you to print the contents, it's up to the terminal emulator t…
I've been following ReasonML pretty closely because, to me, it looks like the most promising compile-to-js language (functional, static types, but practical), and moreover, it can really bring a whole new set of people to the OCaml ecosystem, improving the tooling there. Idealistically, Reason is the language that lets you target any platform by either compiling to JS or native code. That said, I recently tried rewri…
JS favors arrays, OCaml lists, so you either write dsls with [| |] (ugly), or you import a module and convert from lists to arrays and your bundle size goes up 80 KB (don't recall if minified or not).
I was surprised to see Reason continue with this syntax. The idiomatic approach for either side is suboptimal unless I'm missing something.
Thanks, this was helpful as someone who's interested in this set of tools but hasn't been following closely enough to understand how they all fit together (e.g. why there's both js_of_ocaml and Bucklescript, and how ReasonML fits into this). For my own needs, it still seems unclear which way I should go though. The attractive thing about the tools to me is that you can write code that compiles to native and web, in a…