3 ms·

I like the idea of Reason, but I currently do much more server coding than front end. The native compiler is currently classified as work-in-progress (https://

by joobus 9y ago

I like the idea of Reason, but I currently do much more server coding than front end. The native compiler is currently classified as work-in-progress (https://reasonml.github.io/docs/en/native.html https://reasonml.github.io/docs/en/native.html). I also wonder about how the community evolves if javascript-targeted reason libraries aren't compatible with native reason libraries. For instance, would a wrapper for a js promise library be able to work in server code? I'm interested in the language, but currently not investing time in it.

hurricaneSlider 9y ago
It's fully compatible with nodejs, so super feasible to do backend dev
- santoriv 9y ago
  Has anyone actually done this in a real app? The last time I looked for nodejs examples, I could only find small POCs. The vast majority of ReasonML material seems focused on the front-end.
  - lilactown 9y ago
    I ran all of my Advent of Code[0] solutions in Node.js - there's nothing specific really about running a ReasonML app in Node.js vs the browser. Except you don't need a module bundler for the former. :) I've also been slowly working on a small CLI app using ReasonML, ReasonReact and react-blessed. There definitely is a dearth of ReasonML server-side examples, libraries and frameworks, though - especially compared to all the front-end chatter. bs-express[1] is actually quite nice, but hasn't seen much attention from the larger community. I would highly recommend it if it's something you're interested in pursuing. [0]: https://github.com/Lokeh/advent-2017 https://github.com/Lokeh/advent-2017 [1]: https://github.com/reasonml-community/bs-express https://github.com/reasonml-community/bs-express
  - yawaramin 9y ago
    There's definitely activity on the backend, especially with GraphQL, but we don't have any large success stories to report yet. Here's a very cool native-OCaml GraphQL server you can try out today though: https://github.com/andreas/ocaml-graphql-server https://github.com/andreas/ocaml-graphql-server
lilactown 9y ago
There are definitely individuals exploring the native-compilation story, for instance bsb-native[0] allows BuckleScript to use OCaml's native compilation tools. Jared Forsyth has also been publishing a lot of material[1] about creating cross-platform project using ReasonML. The ReasonML team seem to be taking a conservative approach towards what they officially release. They want to make sure that they have a really good plan on how and where to move forward with each of these stories - async, native compilation, cross-platform project, optimizations, etc. Right now they seem to be focusing on creating a really high quality platform for building front-end web applications, but all of these things are on their mind. I'm actually reminded of the fact that Jordan Walke (initial creator of React) is currently working on a native OCaml/Reason package manager called esy[2], which in my mind is kind of the starting point of the native compilation story: unifying the package and build system of the two ecosystems. [0]: https://github.com/bsansouci/bsb-native https://github.com/bsansouci/bsb-native [1]: https://jaredforsyth.com/ https://jaredforsyth.com/ [2]: https://github.com/esy/esy https://github.com/esy/esy
yawaramin 9y ago
The standard OCaml native compile toolchain supports Reason: http://jbuilder.readthedocs.io/en/latest/overview.html?highlight=reason http://jbuilder.readthedocs.io/en/latest/overview.html?highl... You can write in Reason syntax and deploy native binaries with Docker: https://medium.com/@bobbypriambodo/lightweight-ocaml-docker-images-with-multi-stage-builds-f7a060c7fce4 https://medium.com/@bobbypriambodo/lightweight-ocaml-docker-... JS and native differences will probable be resolved just like with any other language that supports both: packages for common code, with specialised packages targeting specific platforms and having dependencies on the common packages.

by joobus 9y ago

hurricaneSlider 9y ago

It's fully compatible with nodejs, so super feasible to do backend dev

santoriv 9y ago
Has anyone actually done this in a real app? The last time I looked for nodejs examples, I could only find small POCs. The vast majority of ReasonML material seems focused on the front-end.
- lilactown 9y ago
  I ran all of my Advent of Code[0] solutions in Node.js - there's nothing specific really about running a ReasonML app in Node.js vs the browser. Except you don't need a module bundler for the former. :) I've also been slowly working on a small CLI app using ReasonML, ReasonReact and react-blessed. There definitely is a dearth of ReasonML server-side examples, libraries and frameworks, though - especially compared to all the front-end chatter. bs-express[1] is actually quite nice, but hasn't seen much attention from the larger community. I would highly recommend it if it's something you're interested in pursuing. [0]: https://github.com/Lokeh/advent-2017 https://github.com/Lokeh/advent-2017 [1]: https://github.com/reasonml-community/bs-express https://github.com/reasonml-community/bs-express
- yawaramin 9y ago
  There's definitely activity on the backend, especially with GraphQL, but we don't have any large success stories to report yet. Here's a very cool native-OCaml GraphQL server you can try out today though: https://github.com/andreas/ocaml-graphql-server https://github.com/andreas/ocaml-graphql-server

lilactown 9y ago

There are definitely individuals exploring the native-compilation story, for instance bsb-native[0] allows BuckleScript to use OCaml's native compilation tools. Jared Forsyth has also been publishing a lot of material[1] about creating cross-platform project using ReasonML. The ReasonML team seem to be taking a conservative approach towards what they officially release. They want to make sure that they have a really good plan on how and where to move forward with each of these stories - async, native compilation, cross-platform project, optimizations, etc. Right now they seem to be focusing on creating a really high quality platform for building front-end web applications, but all of these things are on their mind. I'm actually reminded of the fact that Jordan Walke (initial creator of React) is currently working on a native OCaml/Reason package manager called esy[2], which in my mind is kind of the starting point of the native compilation story: unifying the package and build system of the two ecosystems. [0]: https://github.com/bsansouci/bsb-native https://github.com/bsansouci/bsb-native [1]: https://jaredforsyth.com/ https://jaredforsyth.com/ [2]: https://github.com/esy/esy https://github.com/esy/esy

yawaramin 9y ago

The standard OCaml native compile toolchain supports Reason: http://jbuilder.readthedocs.io/en/latest/overview.html?highlight=reason http://jbuilder.readthedocs.io/en/latest/overview.html?highl... You can write in Reason syntax and deploy native binaries with Docker: https://medium.com/@bobbypriambodo/lightweight-ocaml-docker-images-with-multi-stage-builds-f7a060c7fce4 https://medium.com/@bobbypriambodo/lightweight-ocaml-docker-... JS and native differences will probable be resolved just like with any other language that supports both: packages for common code, with specialised packages targeting specific platforms and having dependencies on the common packages.