91–100 of 103 posts
Earlier quoted context omitted.
`print_endline message` is version 2 syntax. Could you point me to the exact location so I can send a PR to fix it?
looks like you found it already. somewhere else it said also that compiled js is at lib/js. that's not true anymore (as i'm sure you know it's now at src/name.bs.js)
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…
I’d love to hear about better interop APIs. I think if there’s any way to make Bucklescript bindings easier, that would be tremendous. In my experience, the crux of the difficulty actually comes from the JS APIs themselves working in a very JS-way, to be nice. Lots of DOM APIs rely on the dynamically typed nature of JS, making it super hard (probably impossible) to make statically typed bindings to.
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.…
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.
[1] http://caml.inria.fr/pub/docs/manual-ocaml/libref/Graphics.h...
Since a lot of people are coming to OCaml for the first time through ReasonML, maybe this gotcha might be helpful: I was having a really hard time doing `npm install -g bs-platform`. I kept getting "linking" errors that I didn't understand, since I'm new to Ocaml. It turned out that I needed to get rid of my ~/.opam directory. I did `mv ~/.opam .opambk`, then `npm install -g bs-platform` suddenly worked! Sweet! Looki…
Thanks for the tip. Also, we are working on making it easier to isolate opam packages and npm packages side by side in one development environment so that problems like this are avoided. This allows you to build a project that depends on opam packages for build time tooling inside your JS projects. That project is called esy, and it’s a young addition to the ecosystem but something I’ve been using to greatly increase…
So far OCaml seems like a bit of a smoother experience.
Earlier quoted context omitted.
looks like you found it already. somewhere else it said also that compiled js is at lib/js. that's not true anymore (as i'm sure you know it's now at src/name.bs.js)
Can you point to where you got that code from, a URL please. We will fix it so that others won't get errors. Thanks for your help.
https://reasonml.github.io/docs/en/let-binding.html
lib/js was here
https://reasonml.github.io/docs/en/quickstart-javascript.htm...
but someone got that one too
Earlier quoted context omitted.
Can you point to where you got that code from, a URL please. We will fix it so that others won't get errors. Thanks for your help.
print_endline was here but someone already got it: https://reasonml.github.io/docs/en/let-binding.html lib/js was here https://reasonml.github.io/docs/en/quickstart-javascript.htm... but someone got that one too
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…
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!
Earlier quoted context omitted.
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.
Is it as fast as Elm?
Earlier quoted context omitted.
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 virtually impossivle to get shouldComponentUpdate() right when you have ideomatic react with callback props, since callbacks can’t be reliably compared for equality.