For me a big strength is Reason's intolerance of null, this has eliminated a great number of bugs for me. Reason React ultimately forces you to think about every permutation of state your component might enter, and develop logic to handle that. JS/TS will never help you with that.
Reason React 0.8
41–50 of 85 posts
Re: Reason React 0.8
#42Earlier quoted context omitted.
I think you know what I mean. 4.02.3 was released in 2015. 4.06 was released in 2017. Like I said, I know the tradeoffs between JSOO and Reason. And lack of features from the past 2~3 years of OCaml development is one of them.
Yes, if your only heuristic of 'falling behind' is 'not getting the latest OCaml features'. It turns out that even OCaml from a few years ago is perfectly usable to build an excellent JavaScript-focused compiler.
@dmit, we will have to agree to disagree there; the reality is, only a very few people are using the absolute latest OCaml features. If you look at the Opam package build matrix: http://check.ocamllabs.io/ ... most Opam packages are building against 4.02 to 4.05. And OCaml in 2020 is great but it's still not close to what we need for wider adoption in its chosen native compilation space. BuckleScript/Reason is a different strategy, which actually does seem to be working for that goal.
Re: Reason React 0.8
#43Earlier quoted context omitted.
With ReasonML and other ML languages the type system is advanced enough to make many error conditions unrepresentable in the type system, and therefore the bugs move from runtime to compile time. Typescript has slowly been making its type system more powerful and exhaustive, but ultimately the fact that it is a superset of javascript will always keep it from having the compile time safety you can get in other languag…
What's the editor support like? TypeScript has industry-leading editor integration with insanely fast response times. I'm always wary of new languages for this reason; I've been burned before by Facebook's own Flow type system.
I use the Reason Language Server and eglot in emacs on a linux system and it is very snappy. Reason-cli gives you code formatting also.
Re: Reason React 0.8
#44Earlier quoted context omitted.
1) You can see a complete list of changes here https://github.com/reasonml/reason-react/blob/a70d9e6b51ed0a... . We consider it a huge release partly because it adds some long-awaited bindings, partly because of the documentation improvements, and partly because of how community-driven the release was. 2) BuckleScript's creator works for Facebook and has both a specific focus and a long-term vision for the project, m…
To clarify, the link in 1) is where I took the number of changes from. And Re: 2) I have no doubt that Mr. Zhang knows what he's doing. I was just noting how even after the prodigious amount of work he has put into BS over the years, it is still falling behind JSOO which has the benefit of being more tightly bound to the parent OCaml project. I know about the different tradeoffs JSOO and BS have made. All I meant to…
Hi, the author of BuckleScript here.
JSOO and BuckleScript has very different goals, the former focuses on the compatibility with native, while the latter focuses on the interop and optimal perf on JS backend.
The progress of BuckleScript is actually much faster this year if you follow the development closely. OCaml as a language which has been developed for more than 20 years is quite usable without using the latest version, our top priority is to make js interop the best, it is not to catch up the lastest release (but we do have plans to sync up once every two years).
Re: Reason React 0.8
#45Earlier quoted context omitted.
> TypeScript's inherent JS-like nature can pop up subtle bugs like forgetting to type a pair of parentheses FWIW this was just fixed in TypeScript 3.9.
Interesting, can you link me? EDIT: I just tried in the TypeScript Playground (v3.9.2), it's actually rather worse than I thought, it prints not 'false' but the actual function itself as a value...
- It's Just JavaScript With Types
- It's Usable
- It Has Full Type Safety
Pick two.
I think the TypeScript is aware of the tradeoffs, have chosen the first two, and the result is a great developer/IDE experience for JavaScript programs (props!). Reason chooses the last two and creates a great experience for writing very safe web apps.
Re: Reason React 0.8
#46Earlier quoted context omitted.
To clarify, the link in 1) is where I took the number of changes from. And Re: 2) I have no doubt that Mr. Zhang knows what he's doing. I was just noting how even after the prodigious amount of work he has put into BS over the years, it is still falling behind JSOO which has the benefit of being more tightly bound to the parent OCaml project. I know about the different tradeoffs JSOO and BS have made. All I meant to…
Hi, the author of BuckleScript here. JSOO and BuckleScript has very different goals, the former focuses on the compatibility with native, while the latter focuses on the interop and optimal perf on JS backend. The progress of BuckleScript is actually much faster this year if you follow the development closely. OCaml as a language which has been developed for more than 20 years is quite usable without using the latest…
Please, you're driving me crazy. I have referred to you personally by name in two of my above comments. I know who you are! I also know about JSOO vs BS! I know! And it's super disorienting when every single prominent person from the Reason/BuckleScript ecosystem arrives in this thread just to reply directly to my comments with a canned message that has little to do with my original points.
Yes, OCaml is older! Yes, OCaml circa 2015 is a useful language! But also, yes, OCaml has gained multiple useful features since 2015! In part because its development is driver by many, many people. And no, BuckleScript doesn't have some of those features as of May 2020! And it's not an indictment of Reason, but it is also a true statement that Reason/BS are lagging behind compared to what OCaml has to offer!
Re: Reason React 0.8
#47Hey there, is there a `styled-components` library for Reason? I'm really considering ReasonML for my app, however I'm not a big fan of the styling in reason react.
The approach I've been taking is to use ReasonML to model the domain of my application as well as high level components. ReasonML code remains unaware of the styling of the "lower-level" components for the most part, which I write in typescript with styled-components or emotion.
Is there any reason to prefer styled-components over emotion? I did a deep dive on this a few months ago, and found that Emotion supports the same API as SC, while also offering benefits like the `sx` prop, not to mention SSR for "free". It also had a reputation for being faster, but I didn't bother to benchmark it.
Re: Reason React 0.8
#48Earlier quoted context omitted.
Hi, the author of BuckleScript here. JSOO and BuckleScript has very different goals, the former focuses on the compatibility with native, while the latter focuses on the interop and optimal perf on JS backend. The progress of BuckleScript is actually much faster this year if you follow the development closely. OCaml as a language which has been developed for more than 20 years is quite usable without using the latest…
Please, you're driving me crazy. I have referred to you personally by name in two of my above comments. I know who you are! I also know about JSOO vs BS! I know! And it's super disorienting when every single prominent person from the Reason/BuckleScript ecosystem arrives in this thread just to reply directly to my comments with a canned message that has little to do with my original points. Yes, OCaml is older! Yes,…
You have half of the picture, I don't believe you have the other half, which is the progress that BuckleScript is actually making in emitting clean, readable JavaScript.
Fortunately, it's rather simple to see for yourself, you just need to head over to https://reasonml.github.io/en/try.html and try out some OCaml/Reason code and see what is emitted. In fact, the playground comes with various examples built-in, if you need some sample code to try out quickly.
Re: Reason React 0.8
#49Earlier quoted context omitted.
Yes, if your only heuristic of 'falling behind' is 'not getting the latest OCaml features'. It turns out that even OCaml from a few years ago is perfectly usable to build an excellent JavaScript-focused compiler.
I think "getting OCaml features at a slower rate than OCaml itself does" counts as "falling behind", yes. 2015 OCaml was an excellent language. 2020 OCaml is exquisite.
What feature of 2020 OCaml do you think would convince JS developers to use Reason?
Re: Reason React 0.8
#50Earlier quoted context omitted.
As far as editor support, I have used reason-language-server ( https://github.com/jaredly/reason-language-server ) with Emacs (current), Vim and VSCode (provided through reason-vscode plugin). I used to use IntelliJ, and there was a solid plugin for that as well. ReasonML's compiler is way faster than Typescript's.
There's a difference between "the compiler is faster when run at the CLI" and "the language server is faster". A good language server remains responsive by doing quick, partial compilations on just the section that changed. A bad language server just wraps the standard compiler and re-runs the whole thing when a file is saved. The latter will eat up CPU/RAM and make for a frustrating dev experience, no matter how rel…
I'll take super fast compilation first ;)