25 Days of ReasonML
medium.com
25 Days of ReasonML
1–10 of 44 posts
Re: 25 Days of ReasonML
#2I'm interested in Reason/Buckle, coming myself from the ClojureScript.
The seemingly tinier minified compilation size would be a huge plus. But what are the actual sizes emitted for large scale projects (arguably the ones that matter most for static typing)? Anyone could share real-world experiences?
For reference: I know of cases where 60K lines of clojurescript (arguably equivalent to 150K lines JS) compile down to 5MB under advanced optimization mode.
(in case that scares you: well it's an actually large app. We should do route-based code splitting soon - easy/robust with clojurescript apparently)
Re: 25 Days of ReasonML
#3I'm interested in Reason/Buckle, coming myself from the ClojureScript. The seemingly tinier minified compilation size would be a huge plus. But what are the actual sizes emitted for large scale projects (arguably the ones that matter most for static typing)? Anyone could share real-world experiences? For reference: I know of cases where 60K lines of clojurescript (arguably equivalent to 150K lines JS) compile down to…
One thing bucklescript has going for it is that it plays nicely with the NPM/webpack ecosystem. If you want your bundled code to be optimized and minified like Clojurescript, just use a plugin/loader for webpack or your bundler of choice to run the Closure compiler or a similar javascript optimizer. Despite being more inflexible about tooling, clojurescript is great because of how it generates code specifically to take advantage of Closure's optimizaitons.
Re: 25 Days of ReasonML
#4How does ReasonML/Bucklescript stack up against F#/Fable.
Is the only difference that F# has the .NET environment?
Re: 25 Days of ReasonML
#5A weak point of ReasonML for me, last time I tried it, were the Promises; you have to remember to resolve them, with the compiler not providing any help. It's very easy to miss/forget to resolve them.
While it is definitely improvement over JS, it's a step back from the sense of safety you get with TS.
Re: 25 Days of ReasonML
#6I'm interested in Reason/Buckle, coming myself from the ClojureScript. The seemingly tinier minified compilation size would be a huge plus. But what are the actual sizes emitted for large scale projects (arguably the ones that matter most for static typing)? Anyone could share real-world experiences? For reference: I know of cases where 60K lines of clojurescript (arguably equivalent to 150K lines JS) compile down to…
Hey, author here!
BuckleScript itself doesn't actually do any sort of bundling or minification of the code - in fact, it prides itself in generating "human readable" code that, worst comes to worst, one could modify by hand and not be too hung out to dry.
So in that case, you are at the mercy of the general JS ecosystem when it comes to module bundling, minification, code splitting, etc.
The Google Closure compiler does a lot of the magic behind ClojureScript's advanced optimizations, so theoretically one could leverage those same optimizations with an app compiled by BuckleScript. Unfortunately, I don't have any real-world experiences with this.
However, I do have experience using ClojureScript + Google Closure compiler and can give you a heads up that you might (...probably will) run into issues using Closure compiler with NPM libraries, which the BuckleScript ecosystem relies on.
As someone who recently started working daily with ClojureScript, I'm really crossing my fingers for some of rough edges around Node.js/ES module support in the Closure compiler to be smoothed out soon!
NINJA edit: I have heard good things about rollup with regards to dead-code elimination and other optimizations, but the JS module bundling story is moving at break-neck speed these days and I'm not really keeping up with it - Parcel's a new thing? Jaredly's writing a bundler in ReasonML?? X_X
Re: 25 Days of ReasonML
#7A weak point of ReasonML for me, last time I tried it, were the Promises; you have to remember to resolve them, with the compiler not providing any help. It's very easy to miss/forget to resolve them. While it is definitely improvement over JS, it's a step back from the sense of safety you get with TS.
Hey, author here!
I definitely agree that Promises - and the whole async story in ReasonML - is pretty poor atm and ripe for improvement in the near future. I'm not sure what you mean by, "remember to resolve them," though?
I've helped Wojtek Czekalski out a bit with a small library called vow[1] that provides a more type-safe way of using Promises in BuckleScript/ReasonML - it needs a bit clean up (update to new syntax, publish to npm) that I might do in the coming weeks. Nick Cuthbert has a PR for making it completely sound[2] that might land soon as well, which might change the API but provide even more safety.
Re: 25 Days of ReasonML
#8Nice article! I was also doing Advent Of Code[0] with ReasonML but sadly due to time constraints I didn't get any far. Still learned a lot about ReasonML, even if the solutions weren't really idiosyncratic! Definitely going to dive into ReasonML later again.
Re: 25 Days of ReasonML
#9I 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). 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.
Re: 25 Days of ReasonML
#10I 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 ). 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 cod…
It's fully compatible with nodejs, so super feasible to do backend dev