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?
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.
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..
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.
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 ;)
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.
So, I know this is a late reply to this but.. My reaction to the announcement post was "YES!", but I see a few choices in current "Moons" that are part of the same problem the project proposes to fix. Dapper is performant and good for what it is, but entity framework is an amazing ORM IMHO. Simple.Migrations does not have a CLI or support SQL generation?... These are too low level and don't really provide that flash OOTB experience IMHO; same critique(valid) made of Suave and Giraffe. To compete with rails and phoenix in velocity and user experience those technologies are going to have to be swapped out with more feature rich and ambitious libraries..
Ionide could just use some extra help I mean; it appears to be the work of just one guy. Hopefully with the increased interested in F# web development it will get some extra love more ala omnisharp.
I like F# and believe the author has done an amazing job evolving a functional language on the dot net platform but there are simply too many design choices in F# geared around C# compatibility and limitations of CLR being an object oriented language that when you switch to a different compilation target, these language aspects begin to look like bizarre warts.
Things like limitations on statically resolved type parameters being supported only for inline functions, etc. don't make sense for a language targeting javascript.
It is interesting to note that F# took a lot of concepts from OCaml but stripped out functors, structural typing support etc. to adapt to dotnet. These adaptations are largely required because Microsoft does not treat F# as a first class citizen (at the same level as C#) and CLR is very explicitly geared towards object oriented languages. An occasional endorsement from Microsoft does not magically obliviate these deeply ingrained design decisions in F#.
When targeting javascript these adaptions become really pointless. As demonstrated by Microsoft's own TypeScript language, Structural typing can be quite useful for interop.
It would be really nice if F# was a first class citizen in dotnet world and javascript was a first class compilation target maintained by the F# core team adapting the language to javascript target in the same way it currently adapts to dotnet. However that is not the present day reality. However typescript, despite being a javascript superset (and inheriting all its warts) has a really flexible type system and lends itself well to functional programming (as demonstrated by Giulio Canti's fp-ts [1] project).
Unlike ReasonML, however, typescript's type system is not sound. I have written a more detailed comparision [2] of TS and ReasonML. I do actively use TypeScript for my day job and mostly love it, but I am much more optimistic about ReasonML once the ecosystem matures.
tl;dr: The 80% best practices parity between ReasonML and modern functional javascript which the "What & Why" page of official documentation [3] talks about, does not exactly hold true for F#. So, while it is not that F# is not a great language, or that you can't build great apps with F#, however, as it currently stands, I don't see any compelling advantages of preferring F# over ReasonML, unless your backend is also F# and you want to (and can) share code between frontend and backend.
My familiarity with both F# and ReasonML is quite early stage (a few weeks each) and so would welcome any corrections.
If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml?
Also, to just jump in what your comment was actually about, I think the prospect of writing f# is generally a more friendly experience for those using it for the web. Or especially those using azure. Getting started with f# with ionide and vscode is literally the most pleasant onboarding I've experienced since ruby. It just goes! Amazing.
But yeah, I think reason is great too. I really like that ocaml has a centralized, external package management story. Using paket+fake isn't like a bad experience, and I mean, I wrote scala for a couple years, I can always find gratitude for a build tool of its NOT sbt, but it's awkward at times and feels like a bit more work than it should be. Of course from Microsoft's perspective, being able to jump around dotnet libs is a major boon.
You do web development primarily? I've been eyeballing TS lately, you think that's probsbly a better choice for more professional work until reasonml gets bigger pants to wear?
> If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml?
I do think that upcoming multicore support in OCaml is very exciting. I am more optimistic that it will attract people from Golang and C++. F# developers coming from outside dotnet is just too small a cohort.
> Getting started with f# with ionide and vscode is literally the most pleasant onboarding I've experienced since ruby.
Yeah, Ionide is really amazing. However merlin has also worked pretty well for me so far, and the emacs integration is a big plus for me. YMMV.
Also my comment was more around frontend use cases (compile to JS). I wouldn't be surprised if F# shines wrt Azure integration and within the dotnet ecosystem.
> You do web development primarily? I've been eyeballing TS lately, you think that's probsbly a better choice for more professional work until reasonml gets bigger pants to wear?
Yes, mostly node and frontend. In my area, professional work in reasonml is almost non-existent, but I do expect this to change in future.
As an developer coming from Ruby myself, glad to see more people from dynamic languages finding FP and type systems interesting.
I'm absolutely fascinated with type system theory. I also really like logic programming stuff too, some of what's happening in the relational logic world is very interesting stuff.
I think we'd disagree about the relevance of this, but that IS exciting news! I'm very impressed overall with node progress, especially considering how unstable the ground seems to be, or have been, in jsverse.
> tl;dr: The 80% best practices parity between ReasonML and modern functional javascript which the "What & Why" page of official documentation [3] talks about, does not exactly hold true for F#.
The bulk of F# is functions acting on values modeled by types. This maps directly to JS. In the F# and .NET compatibility document[0], you'll note that all "core F#" components map directly to JS. And of course, you can consume JS libraries, TS definition files, etc. For example:
"The following F# semantic and syntactic features are also available:
* Records and Unions
* Structural Equality/Comparison
* Comprehensions (seq, array, list)
* Computation Expressions
* Pattern Matching
* Active Patterns
* Object Expressions
* Units of measure"
Do you have specific examples where F# semantics cannot map to JS such that the "80% rule" also does not hold?
I am not at all contesting the value in the good parts of F#. It was my first foray into a functional language, and I was left seriously impressed.
> Do you have specific examples where F# semantics cannot map to JS such that the "80% rule" also does not hold?
Yes, my comment was around some of the C# compatibility things, which don't make sense when compiling to other targets.
> Tuples vs struct tuples distinction.
> Having both modules and namespaces
> Explicit interfaces
> The strange coupling of SRTP and inlining
I find OCaml's support for structural typing in classes and polymorphism to be more flexible than the above.
In typed FP, runtime reflection is seldom used, and I believe reflection support (and associated overhead) should have to be explicitly opted in.
I also faced weird issues when tracing the source of an exception in an async workflow, and some incomprehensible errors around automatic generalization. But this was a long time back and I no longer have the full context. These may have since been addressed.
My intent was certainly not to criticise F#. It has been developed and is used by people far smarter than me. It is just that after a preliminary evaluation I have not found a strong reason to prefer Fable over bucklescript in the absence of a more deeper commitment to dotnet stack.
I am also really fond of many modern JS features like Module <-> Filepath 1:1 correlation, explicit imports, ES6 proxies, tagged template literals (placeholders etc.) which TypeScript elegantly inherits from JS. Support for intersection types in typescrpt is also very handy.
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.
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.
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.
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?