4 ms·

I'm building a project in ReasonML right now with reason-react. The Reason-only parts are actually a joy. The problem is interop with the wider ecosystem, and

I'm building a project in ReasonML right now with reason-react. The Reason-only parts are actually a joy. The problem is interop with the wider ecosystem, and bucklescript. They are serious problems. You end up writing a ton of [@bs.... ] annotations to get things to work together that ultimately result in runtime errors. I hate battling a compiler (with sometimes quite cryptic errors, particularly identifying syntax errors) only to find that I can't actually free myself from the same type of errors I'd see with regular old JavaScript. I can dig through my discord history and give more specifics. But given the massive learning curve and poor tooling that exists these days it's a step backwards from mainstream production JS development. That said, the community has really got some wonderful folks out there, and is very helpful. I hope they can figure out interop with basic JS like promises. And tooling. And let me use async/await. And make bundle splitting easier to implement.

deathtrader666 7y ago
You could write your app using the Elm-inspired Bucklescript-TEA [0] framework in OCaml, and use js_of_ocaml to transpile OCaml into JavaScript. [0] - https://github.com/OvermindDL1/bucklescript-tea https://github.com/OvermindDL1/bucklescript-tea
- pkilgore 7y ago
  In what ways does it fix my major issues with bucklescript (simple interop with JS libraries / object / output, promises, async/await being highest on the list).
  - deathtrader666 7y ago
    With js_of_ocaml, you need not use Bucklescript at all. Both are transpilers for OCaml -> JavaScript.
- wtetzner 7y ago
  Is Bucklescript-TEA available through OPAM, or only through NPM? EDIT: Nevermind [1] https://github.com/OvermindDL1/bucklescript-tea/issues/45 https://github.com/OvermindDL1/bucklescript-tea/issues/45
  - wtetzner 7y ago
    I have to say though, the ELM architecture actually lends itself better to OCaml than ELM, because functors give you a really nice way to compose components.
jasim 7y ago
My recommendation for using Reason in production is to go for it -- but only if someone in the team has previously shipped production software in a typed functional programming language. If not, use it in a non-critical project, have a pair of programmers build up expertise over around six months of full-time work, and then make the jump for the entire team. Regarding bindings -- which external libraries were you using? Component libraries written for React could be a fair amount of work to write bindings for, but I anyway prefer hand-rolling components with Tailwind, so that hasn't been a problem personally. Bindings were indeed difficult when I started out - Javascript can invoke functions in a myriad ways: new xyz(), object.key, object.key(), module defaults, Math.abs etc. We have to map them to OCaml's semantics (easy), and figure out the BuckleScript macros for them (easy with practice). I recently wrote a bunch of bindings for Adobe XD, and it was surprisingly fun.
dpwm 7y ago
I've been using of BuckleScript and OCaml for a couple of years now. I'd been using OCaml for a long time before then. I tried ReasonReact, and found that I preferred the OCaml + vdom library way. I first used my own minimal bindings to Mithril, but then later moved to an Elm Architecture implementation for bucklescript: bucklescript-tea. After being on a deadline and either completely misunderstanding or finding significant show-stopping bugs in bucklescript-tea's virtual dom implementation, I reimplemented the parts of the API I'd used from bucklescript-tea with a minimal alternative that called out to snabbdom for the vdom stuff. This was mainly as a learning exercise, which took all of about two afternoons of fairly relaxed work. The only places I have needed to use annotations with this approach is in my modules that call out to JavaScript. This is really unavoidable, and you'd surely find the equivalent information would have to be provided if you used F# or PureScript, or your compiler simply won't know the types. I'm sure my approach, with layers on layers of functions to build virtual dom nodes, is certainly not going to win any benchmarks, and it's certainly not novel – but it's good enough, and my productivity is up. I can leave a project for months and be relatively unsurprised by what I find when I return – because there's usually only one sensible way to do things. Everyone's different, though, and I fully respect it may not work for all. The key lesson I've learnt is that interop is painful because the some of the bucklescript types do not neatly map how you would necessarily imagine to javascript types. But if you do this at the edges, and write sufficient wrappers, you won't have any problems. The biggest pain point for a while has been that bucklescript is based on an old version of OCaml – and there have been some very nice additions to the OCaml standard library since then. That said, I think it's excellent that we've got two OCaml -> JS pathways in the OCaml world now.
- yawaramin 7y ago
  Just fyi– bs-platform 6 and above are based on OCaml 4.06. So, still not the latest, but a bit more recent! In particular, it supports record types directly embedded in variant constructors without having to declare them first.
_hardwaregeek 7y ago
For real. It's hard to get support for browser APIs, let alone libraries. Getting Reason to work with File objects is just an utter pain.

deathtrader666 7y ago

You could write your app using the Elm-inspired Bucklescript-TEA [0] framework in OCaml, and use js_of_ocaml to transpile OCaml into JavaScript. [0] - https://github.com/OvermindDL1/bucklescript-tea https://github.com/OvermindDL1/bucklescript-tea

pkilgore 7y ago
In what ways does it fix my major issues with bucklescript (simple interop with JS libraries / object / output, promises, async/await being highest on the list).
- deathtrader666 7y ago
  With js_of_ocaml, you need not use Bucklescript at all. Both are transpilers for OCaml -> JavaScript.
wtetzner 7y ago
Is Bucklescript-TEA available through OPAM, or only through NPM? EDIT: Nevermind [1] https://github.com/OvermindDL1/bucklescript-tea/issues/45 https://github.com/OvermindDL1/bucklescript-tea/issues/45
- wtetzner 7y ago
  I have to say though, the ELM architecture actually lends itself better to OCaml than ELM, because functors give you a really nice way to compose components.

jasim 7y ago

My recommendation for using Reason in production is to go for it -- but only if someone in the team has previously shipped production software in a typed functional programming language. If not, use it in a non-critical project, have a pair of programmers build up expertise over around six months of full-time work, and then make the jump for the entire team. Regarding bindings -- which external libraries were you using? Component libraries written for React could be a fair amount of work to write bindings for, but I anyway prefer hand-rolling components with Tailwind, so that hasn't been a problem personally. Bindings were indeed difficult when I started out - Javascript can invoke functions in a myriad ways: new xyz(), object.key, object.key(), module defaults, Math.abs etc. We have to map them to OCaml's semantics (easy), and figure out the BuckleScript macros for them (easy with practice). I recently wrote a bunch of bindings for Adobe XD, and it was surprisingly fun.

dpwm 7y ago

I've been using of BuckleScript and OCaml for a couple of years now. I'd been using OCaml for a long time before then. I tried ReasonReact, and found that I preferred the OCaml + vdom library way. I first used my own minimal bindings to Mithril, but then later moved to an Elm Architecture implementation for bucklescript: bucklescript-tea. After being on a deadline and either completely misunderstanding or finding significant show-stopping bugs in bucklescript-tea's virtual dom implementation, I reimplemented the parts of the API I'd used from bucklescript-tea with a minimal alternative that called out to snabbdom for the vdom stuff. This was mainly as a learning exercise, which took all of about two afternoons of fairly relaxed work. The only places I have needed to use annotations with this approach is in my modules that call out to JavaScript. This is really unavoidable, and you'd surely find the equivalent information would have to be provided if you used F# or PureScript, or your compiler simply won't know the types. I'm sure my approach, with layers on layers of functions to build virtual dom nodes, is certainly not going to win any benchmarks, and it's certainly not novel – but it's good enough, and my productivity is up. I can leave a project for months and be relatively unsurprised by what I find when I return – because there's usually only one sensible way to do things. Everyone's different, though, and I fully respect it may not work for all. The key lesson I've learnt is that interop is painful because the some of the bucklescript types do not neatly map how you would necessarily imagine to javascript types. But if you do this at the edges, and write sufficient wrappers, you won't have any problems. The biggest pain point for a while has been that bucklescript is based on an old version of OCaml – and there have been some very nice additions to the OCaml standard library since then. That said, I think it's excellent that we've got two OCaml -> JS pathways in the OCaml world now.

yawaramin 7y ago
Just fyi– bs-platform 6 and above are based on OCaml 4.06. So, still not the latest, but a bit more recent! In particular, it supports record types directly embedded in variant constructors without having to declare them first.

_hardwaregeek 7y ago

For real. It's hard to get support for browser APIs, let alone libraries. Getting Reason to work with File objects is just an utter pain.