10 ms·

I really want to use ReasonML in one of my next projects but I always come back to two main questions. How much is it easy to use JS components like the Calend

by nazka 8y ago

I really want to use ReasonML in one of my next projects but I always come back to two main questions. How much is it easy to use JS components like the Calendar of Airbnb for instance? And is it really easy to use BuckleScript? The "[%bs.raw ..." and others look hard to read/use. Is it the case or just a feeling? Is there someone who already tried it enough to know the answers?

rase- 8y ago
Very easy to use components between JS react and ReasonML react. Docs describe this process well. As for the bucklescript macros, the most frequent ones are easy to get used to. bs.raw is a very last resort macro that is almost never used. Highly recommend giving ReasonML a try.
girvo 8y ago
If you’re willing to give up type safety it’s easy, it’s moderately harder if you want to stay in the type box
thardus 8y ago
ppx (like `[%bs.raw ...`) are indeed tricky. They mostly seem to be used around the FFI. My experience has been that if you're going to use JS components from within Reason, you just type the portions of the JS interface that you'll actually use, and that's pretty much always a subset. When you're outside the FFI, the language really shines in build speed and output. Support of ES Modules out of the box is nice too.
qop 8y ago
It's not any less convenient than React appears to be. Disclaimer: I've only used it for small Todo project, I'm not a front end guy. Disdisclaimer: I've not used React at all. However, if you need really strong JS interop, consider something like F#'s Fable. F# is gaining a lot of momentum and now that SAFE stack is apparently Microsoft-blessed, I expect it to continue growing even more.
- Rapzid 8y ago
  1k upvotes. I check in on Fable and F# semi frequently but SAFE has somehow slipped under my radar. I wonder if the ionide project will get some extra support.. Suave though... Nothing against Suave, but it's not the Phoenix competitor the ecosystem is in dire need of. I was under the impression some newer frameworks like Giraffe were going to fill that void..
  - grayrest 8y ago
    It's in an early stage but the Saturn [1] project is aiming to compete with Phoenix more directly. The owner is a fairly prolific F# open source contributor and presented it at NYC F# last month but that's about all I know about it. [1] https://github.com/SaturnFramework/Saturn https://github.com/SaturnFramework/Saturn
    - Rapzid 8y ago
      That's fantastic! I gave F# a look right after MS announced dotnet was being open source and have been excited for it's "arrival" ever since. The pieces seem to be coming together, albeit very slowly.. * "Official" Cross platform support -> dotnet core FTW! * Cross-IDE intellisense support -> Ionide, Check! * Dotnet core support -> Check, finally(and make sure to set Ionide to use core)! * F# to javascript cross compilation project with some traction -> Fable, check(Fable needs serious documentation help though)! * A great framework competing head on with Phoenix -> Hopefully soon :) The potential just seems sooo massive. Hopefully it blows up quicker than Haskell ;)
      - sasmithjr 8y ago
        I started looking at F# because of .NET Core, and I'm really liking it. I currently use Giraffe in a project, but I'll be switching it to Saturn soon (which uses Giraffe under the hood). And I've identified a potential use case for using Fable on some already written server-side code. Ionide is great, Neptune (F# debugger for VSCode) works well, and they both are maintained by the same person as Saturn. Rider also works pretty well with F#, which is nice if you prefer the JetBrains IDEs.
simplify 8y ago
bs.raw is actually really easy to use, but it's not encouraged since it's mostly a stepping stone to "real" bindings. There is definitely a learning curve to JS bindings, but it pays off as you only have to learn them once.
weavie 8y ago
The reason I found JS interop confusing in Bucklescript is there are multiple ways to do it, so it wasn't obvious which was the right way. I think a lot of that is due to the fact that Js is ultimately a very different language from OCaml, and so to get the two to work together there were quite a large number of different scenarios to cater for. Once I got over that hump, it was all fairly simple.

by nazka 8y ago

rase- 8y ago

Very easy to use components between JS react and ReasonML react. Docs describe this process well. As for the bucklescript macros, the most frequent ones are easy to get used to. bs.raw is a very last resort macro that is almost never used. Highly recommend giving ReasonML a try.

girvo 8y ago

If you’re willing to give up type safety it’s easy, it’s moderately harder if you want to stay in the type box

thardus 8y ago

ppx (like `[%bs.raw ...`) are indeed tricky. They mostly seem to be used around the FFI. My experience has been that if you're going to use JS components from within Reason, you just type the portions of the JS interface that you'll actually use, and that's pretty much always a subset. When you're outside the FFI, the language really shines in build speed and output. Support of ES Modules out of the box is nice too.

qop 8y ago

It's not any less convenient than React appears to be. Disclaimer: I've only used it for small Todo project, I'm not a front end guy. Disdisclaimer: I've not used React at all. However, if you need really strong JS interop, consider something like F#'s Fable. F# is gaining a lot of momentum and now that SAFE stack is apparently Microsoft-blessed, I expect it to continue growing even more.

Rapzid 8y ago
1k upvotes. I check in on Fable and F# semi frequently but SAFE has somehow slipped under my radar. I wonder if the ionide project will get some extra support.. Suave though... Nothing against Suave, but it's not the Phoenix competitor the ecosystem is in dire need of. I was under the impression some newer frameworks like Giraffe were going to fill that void..
- grayrest 8y ago
  It's in an early stage but the Saturn [1] project is aiming to compete with Phoenix more directly. The owner is a fairly prolific F# open source contributor and presented it at NYC F# last month but that's about all I know about it. [1] https://github.com/SaturnFramework/Saturn https://github.com/SaturnFramework/Saturn
  - Rapzid 8y ago
    That's fantastic! I gave F# a look right after MS announced dotnet was being open source and have been excited for it's "arrival" ever since. The pieces seem to be coming together, albeit very slowly.. * "Official" Cross platform support -> dotnet core FTW! * Cross-IDE intellisense support -> Ionide, Check! * Dotnet core support -> Check, finally(and make sure to set Ionide to use core)! * F# to javascript cross compilation project with some traction -> Fable, check(Fable needs serious documentation help though)! * A great framework competing head on with Phoenix -> Hopefully soon :) The potential just seems sooo massive. Hopefully it blows up quicker than Haskell ;)
    - sasmithjr 8y ago
      I started looking at F# because of .NET Core, and I'm really liking it. I currently use Giraffe in a project, but I'll be switching it to Saturn soon (which uses Giraffe under the hood). And I've identified a potential use case for using Fable on some already written server-side code. Ionide is great, Neptune (F# debugger for VSCode) works well, and they both are maintained by the same person as Saturn. Rider also works pretty well with F#, which is nice if you prefer the JetBrains IDEs.

simplify 8y ago

bs.raw is actually really easy to use, but it's not encouraged since it's mostly a stepping stone to "real" bindings. There is definitely a learning curve to JS bindings, but it pays off as you only have to learn them once.

weavie 8y ago

The reason I found JS interop confusing in Bucklescript is there are multiple ways to do it, so it wasn't obvious which was the right way. I think a lot of that is due to the fact that Js is ultimately a very different language from OCaml, and so to get the two to work together there were quite a large number of different scenarios to cater for. Once I got over that hump, it was all fairly simple.