9 ms·

Reason React 0.8

186 points by thegreatpeter 6y ago

thegreatpeter 6y ago
The long awaited 0.8.0 release from Reason React is out of beta! This includes a lot of the niceties of writing React but in a very fast, type safe language. If this is your first time hearing about Reason, watch a video from its creator (Jordan Walke, creator of React) to learn more: https://www.youtube.com/watch?v=5fG_lyNuEAw&t=11s https://www.youtube.com/watch?v=5fG_lyNuEAw&t=11s Fun facts about Reason: - exports TypeScript! If you have a TS project and looking for some extra speed & stability, you don't have to sacrifice type safety interop - It powers all of Messenger.com. The team put out a case study where they went from ~10 bugs a week to less than 10 a quarter by switching to Reason - It uses the npm / yarn ecosystem so you can use your favorite / current packages without looking for something new.
- parhamn 6y ago
  Awesome! Question, say you use TypeScript already, what are the biggest tangible gains in terms of safety (measured by fewer bugs in production) you think can be achieved by using Reason?
  - bgorman 6y ago
    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 languages. ReasonML (OCaml) natively supports pattern matching, variants (Sum types), polymorphic variants, smart constructors, abstract data types, recursive types, and modules. When you know how to use all of these features, you can prevent a remarkably large surface of bugs from ever compiling. As a new user, the first feature that will probably bring a smile to your face is pattern matching with variants. If you are interested I highly recommend the book "Learn Type-Driven Development"
    - _bxg1 6y ago
      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.
      - dmit 6y ago
        Reason support in VSCode is very solid.
        davesnx 6y ago
        That's not even true. It's still very early days for Reason VSCode tooling, since you might find a few extensions that support most of the cases but lacks a few key features that you might be used to while writing JS/TS.
      - bgorman 6y ago
        As far as editor support, I have used reason-language-server (https://github.com/jaredly/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.
        _bxg1 6y ago
        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 relatively-fast the base compilation time is.
        yawaramin 6y ago
  - deleted 6y ago
    [deleted]
  - yawaramin 6y ago
    - Full-fledged support for pattern-matching exhaustiveness check, not something you have to bake together using a 'tag' field. This means if you match on i.e. integers, the compiler will warn you if you don't include a catch-all default case. - Simple module system where you don't need to deal with named vs default imports and all the weird bugs getting them mixed up can bring - TypeScript's inherent JS-like nature can pop up subtle bugs like forgetting to type a pair of parentheses: function isSupported(): boolean { return false; } function test() { console.log(true && isSupported); // true } Or doing object/array indexing and forgetting to handle the case of 'undefined' because TypeScript doesn't enforce that. Or how any typings from before version 2 are suspect because they were written with the assumption that every type can be implicitly nullable. There are lots of these little footguns all over the place. - Higher-quality bindings: more stuff captured at the type level, you're not left to deal with bindings full of 'any', 'object', and 'function' It's not even just about safety though. One of the biggest productivity drivers in Reason is its iteration speed–the compiler is so fast that you can try out changes basically as fast as you can save the file. And there are other things, like how all modules are implicitly available in scope, so you don't need to manage a 'wall of imports' at the top of every file before you can actually get to the code itself.
    - Kaze404 6y ago
      > 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.
      - yawaramin 6y ago
        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...
        jordwalke 6y ago
        - 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.
  - thegreatpeter 6y ago
    1. Pattern Matching Pattern matching has been by far my most favorite feature as someone coming from TypeScript: https://gist.github.com/peterpme/10840585ddced15a7f4ecd05394e6091 https://gist.github.com/peterpme/10840585ddced15a7f4ecd05394... The ability to use "constants" that are inherently typed mean less mistakes and a better path forward for handling your application state. Refactoring with this in mind, becomes a lot safer. For example, if I had a reducer that needed a new action, I would add that action to the `type`. The compiler would then tell me every place I needed to handle that case. 2."Implicit" Types (types that don't get in the way) I don't need to type everything like I would in TypeScript. ReasonML already figures all of that out for me. I _can_ add the type if I want (for readability purposes). There is no such thing a `any` or any type of escape hatch for that (this can be frustrating at first) but once you get it, you write code more confidently. 3. React & Refactoring Say I've got a bunch of React components I need to refactor. Reason types both the prop key and value. If I remove a prop or change that prop's data structure, I'll immediately know all the places I need to make that change. I know some folks may roll their eyes when they read this, but after using both Reason and TypeScript at Draftbit, I strongly believe it's a competitive advantage. The stuff we ship in Reason just doesn't break.
    - machiaweliczny 6y ago
      Is it possible to compile in presence of errors? I love TS that it's gradual and for prototyping I can use "transpileOnly" and after I'm done I can verify everything. I have bad memories from typing json interfeces for Elm while prototyping (maybe could be disabled).
      - pkilgore 6y ago
        No, but you can slowly Reason-ify a javascript (or typescript!) app at the interfaces using gentype[1], which emits javascript/typescript/flow interfaces for the reason side. It works perfectly well to ship a slowly-becoming-reason frontend app. But you do have to have the compiler give the thumbs up before it will compile the reason side of the project. You can also checkout the tutorial for slowly converting a single file here, although I find myself doing this sort of thing very rarely: https://reasonml.github.io/docs/en/converting-from-js https://reasonml.github.io/docs/en/converting-from-js [1] https://github.com/cristianoc/genType https://github.com/cristianoc/genType
  - davesnx 6y ago
    There are a few differences between both, a lot of people mention the fast compilation and the type inference. I would add that the types from Reason are much "smaller" and concise, Option type or Result type and the immutability of Records/Objects creates an environment of safety that I don't have it in TypeScript.
  - cies 6y ago
    All good arguments in this thread. One I miss: TS fixes some of JSs issues, but many it cannot fix by still being a super set of JS. Reason is similar (enough) to JS syntax-wise, while not having to deal with it's quirks. This is huge for me.
- Matthias247 6y ago
  > - It powers all of Messenger.com. The team put out a case study where they went from ~10 bugs a week to less than 10 a quarter by switching to Reason Did they move from Typescript or Javascript?
  - yawaramin 6y ago
    More details here: https://reasonml.org/blog/messenger-50-reason https://reasonml.org/blog/messenger-50-reason
- dmit 6y ago
  Congratulations on the release! I have a couple questions for you (and any other contributors!) about the project, but I don't know how to phrase them without coming off as combative. Please accept the following as genuine curiosity rather than malice. 1) You called the 0.8 release "huge" in the release notes, even though it adds 11 new functions, removes 2, and updates 2 compared to 0.7, released a year prior. Is there something else about 0.8 that makes it larger than the sum of the API changes? 2) BuckleScript has seemingly been a one-man show for ~3 years. It is lagging noticeably behind the progress of the main OCaml project (including jsoo). ReasonML has a couple prominent contributors, but the overall (public) activity is dwarfed by Hongbo Zhang's work on BS. Is this because the ReasonML project is considered to be in a stable state, sufficient for production work?
  - yawaramin 6y ago
    1) You can see a complete list of changes here https://github.com/reasonml/reason-react/blob/a70d9e6b51ed0ab27a895fa13807436d20db5620/HISTORY.md#080-042020 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, more details here: https://www.youtube.com/watch?v=iWEQjvGGiTA https://www.youtube.com/watch?v=iWEQjvGGiTA . He also regularly blogs about ongoing improvements: https://reasonml.org/blog https://reasonml.org/blog . Facebook Web Messenger and other products are heavily reliant on BuckleScript. I would consider that to be production-ready.
    - dmit 6y ago
      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 say is that one super-productive person is apparently (and understandably) not able to keep up with upstream (i.e. Inria + Jane Street + many others) in this case. And then we have the ReasonML project that has seen even less activity recently. If ReasonML in its current state is considered a finished product that requires minimal maintenance, I couldn't think of a better endorsement, to be honest.
- dmitriid 6y ago
  > It powers all of Messenger.com. The team put out a case study where they went from ~10 bugs a week to less than 10 a quarter by switching to Reason When they did that, I was running into numerous behaviour bugs on Messenger.com. Anything from weird image uploads to link previews not showing up in one chat but working in another etc. Reduction in pure code bugs is nice and all, but a very synthetic and useless metric overall IMO.
- Scarbutt 6y ago
  If the language has proved to be worthy, why messenger.com only though?
  - fulafel 6y ago
    This meritocratic model is unfortunately not really how language popularity plays out in the real world. At least not on career-length timescales.
    - Scarbutt 6y ago
      Was referring to Facebook usage only, like in, why isn't it used more at FB?
      - jordwalke 6y ago
        It is.
      - vosper 6y ago
        I asked a similar question recently, one of the maintainers was nice enough to reply with some info. Perhaps this sheds some light: https://news.ycombinator.com/item?id=23116754 https://news.ycombinator.com/item?id=23116754
      - fulafel 6y ago
        I think the point stands doubly strong in case of Facebook. They're a PHP shop after all.
        Scarbutt 6y ago
        PHP doesn't run in the browser...
        fulafel 6y ago
        Sure, but using it in the backend tells us that there is no language meritocracy at FB.
- namelosw 6y ago
  Congratulations! I hope Reason and Reason React could get more tractions. I'm wondering, will there be more marketing for Reason or Reason React after it reaching 1.0? I found when introducing this kind of technology for day jobs, people either get confused or concerned usually, even though it really looks like React now. It seems to be very hard to have programming languages taking off without marketing nowadays because the adoption usually comes from other people's adoption. It's the "threshold of immortality" of programming languages according to Simon Peyton Jones.
bgorman 6y ago
ReasonML is awesome! I personally preferred the "reducer" state modeling mechanism from ReasonReact 0.6, but you can still use it as a library with https://github.com/bloodyowl/reason-react-update https://github.com/bloodyowl/reason-react-update
- wwewe 6y ago
  I ended up just using redux with react-redux. I just wrote my own bindings (does not cover the entire api surface but the essentials): https://gist.github.com/melbourne2991/b3093187505f2ee9e517bbcaa6d52580 https://gist.github.com/melbourne2991/b3093187505f2ee9e517bb... You get a lot of optimizations for free with react-redux. Given reason-react now supports hooks you can also just use `useReducer` but this lacks some optimizations.
cosmosocean 6y ago
Hey 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.
- thegreatpeter 6y ago
  styled-ppx by @davesnx is a great option https://github.com/davesnx/styled-ppx https://github.com/davesnx/styled-ppx At Draftbit we've been using https://tailwindcss.com https://tailwindcss.com with @dylanirlbeck's https://github.com/dylanirlbeck/tailwind-ppx https://github.com/dylanirlbeck/tailwind-ppx with great success! We also use `bs-emotion` (which on the styled-components vs. emotion api side is the same)
- tsnobip 6y ago
  I guess this lib would be the closest alternative in a safe statically typed way : https://github.com/davesnx/styled-ppx https://github.com/davesnx/styled-ppx There's also a nice lib for tailwind : https://github.com/dylanirlbeck/tailwind-ppx https://github.com/dylanirlbeck/tailwind-ppx
  - davesnx 6y ago
    Thanks, let me know if you are using it!
- wwewe 6y ago
  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.
  - chrisweekly 6y ago
    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.
deleted 6y ago
[deleted]
shermanmccoy 6y ago
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.
- s-km 6y ago
  What do you mean? Typescript by default assumes non-null, and if you specify that something can be null it'll force you to check that it isn't before attempting to access it.
  - Vinnl 6y ago
    Note that "by default" here means "when strict mode is on, which is explicitly turned on when you run tsc --init". If you don't specify a config value for strict mode, it will be off. (At least last time I checked.)
  - shermanmccoy 6y ago
    Sure. However the any type lets the nulls in. And the any type is very convenient, perhaps even necessary to use in some situations. So then you are back to plain old js check blocks and ternaries littered everywhere. If you miss one, well, I don't need to remind anyone of the ubiquitous js console error which every js developer has burned into the back of her/his brain.
    - osdiab 6y ago
      I use the no-explicit-any Typescript ESLint check and tsconfig no-implicit-any, never turn them off unless absolutely necessary, making this is a non-issue. Not that I’m not interested in Reason for other reasons though!
      - shermanmccoy 6y ago
        That's fine if you can control this configuration I suppose. But the escape hatch is there, so in my opinion TS doesn't go far enough.
iddan 6y ago
I am very pleased to see the revitalized efforts on ReasonML. I hope soon it will be widespread enough I could use it professionally. Also, I love the new website design!
zaphirplane 6y ago
Assuming most serious projects will depend on a lot of npm modules. Do the reason folk think that projects will add custom wrappers/typings Just like with TS (mind share chicken and egg problem) or is there a way for the compiler with its powerful type system to - handwave - deduce types in JavaScript npm modules Edit The gap between https://redex.github.io/ https://redex.github.io/ and type.d seems like a challenge
- pkilgore 6y ago
  There is no way, currently, to deduce vanilla javascript types. You'll have to write your own bindings (types) or as you pointed out, use community bindings on redex. Now? Writing a binding is barely a speed bump, but when I first started writing Reason code it definitely tripped me up a few times. I tried to make the road behind me a bit smoother [1], but that gap you observed is real. But as someone who writes/reviews both Typescript and Reason, pretty much every day, there is space for both projects, so I don't see that gap as being relevant to the survival of Reason--rather, its something that with hard word will be improved over time.
cpursley 6y ago
ReasonReact & ReasonML seem like a much more practice Elm. Can anyone recommend some up to date ReasonReact & ReasonML tutorials & books? Also, what is the recommended architecture - are there any good starter projects?
- davesnx 6y ago
  Sure, I worked with Elm before and I feel like they share the basics like immutability and types. Which makes a lot of sense, since Elm got very inspired by Haskell and Reason it's a syntax and a few beauties of OCaml. A good intro (at least for me, since I'm into videotutorials) is https://egghead.io/courses/get-started-with-reason https://egghead.io/courses/get-started-with-reason. https://egghead.io/courses/get-started-with-reason https://egghead.io/courses/get-started-with-reason

186 points by thegreatpeter 6y ago

The long awaited 0.8.0 release from Reason React is out of beta! This includes a lot of the niceties of writing React but in a very fast, type safe language. If this is your first time hearing about Reason, watch a video from its creator (Jordan Walke, creator of React) to learn more: https://www.youtube.com/watch?v=5fG_lyNuEAw&t=11s https://www.youtube.com/watch?v=5fG_lyNuEAw&t=11s Fun facts about Reason: - exports TypeScript! If you have a TS project and looking for some extra speed & stability, you don't have to sacrifice type safety interop - It powers all of Messenger.com. The team put out a case study where they went from ~10 bugs a week to less than 10 a quarter by switching to Reason - It uses the npm / yarn ecosystem so you can use your favorite / current packages without looking for something new.

parhamn 6y ago
Awesome! Question, say you use TypeScript already, what are the biggest tangible gains in terms of safety (measured by fewer bugs in production) you think can be achieved by using Reason?
- bgorman 6y ago
  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 languages. ReasonML (OCaml) natively supports pattern matching, variants (Sum types), polymorphic variants, smart constructors, abstract data types, recursive types, and modules. When you know how to use all of these features, you can prevent a remarkably large surface of bugs from ever compiling. As a new user, the first feature that will probably bring a smile to your face is pattern matching with variants. If you are interested I highly recommend the book "Learn Type-Driven Development"
  - _bxg1 6y ago
    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.
    - dmit 6y ago
      Reason support in VSCode is very solid.
      - davesnx 6y ago
        That's not even true. It's still very early days for Reason VSCode tooling, since you might find a few extensions that support most of the cases but lacks a few key features that you might be used to while writing JS/TS.
    - bgorman 6y ago
      As far as editor support, I have used reason-language-server (https://github.com/jaredly/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.
      - _bxg1 6y ago
        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 relatively-fast the base compilation time is.
        yawaramin 6y ago
- deleted 6y ago
  [deleted]
- yawaramin 6y ago
  - Full-fledged support for pattern-matching exhaustiveness check, not something you have to bake together using a 'tag' field. This means if you match on i.e. integers, the compiler will warn you if you don't include a catch-all default case. - Simple module system where you don't need to deal with named vs default imports and all the weird bugs getting them mixed up can bring - TypeScript's inherent JS-like nature can pop up subtle bugs like forgetting to type a pair of parentheses: function isSupported(): boolean { return false; } function test() { console.log(true && isSupported); // true } Or doing object/array indexing and forgetting to handle the case of 'undefined' because TypeScript doesn't enforce that. Or how any typings from before version 2 are suspect because they were written with the assumption that every type can be implicitly nullable. There are lots of these little footguns all over the place. - Higher-quality bindings: more stuff captured at the type level, you're not left to deal with bindings full of 'any', 'object', and 'function' It's not even just about safety though. One of the biggest productivity drivers in Reason is its iteration speed–the compiler is so fast that you can try out changes basically as fast as you can save the file. And there are other things, like how all modules are implicitly available in scope, so you don't need to manage a 'wall of imports' at the top of every file before you can actually get to the code itself.
  - Kaze404 6y ago
    > 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.
    - yawaramin 6y ago
      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...
      - jordwalke 6y ago
        - 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.
- thegreatpeter 6y ago
  1. Pattern Matching Pattern matching has been by far my most favorite feature as someone coming from TypeScript: https://gist.github.com/peterpme/10840585ddced15a7f4ecd05394e6091 https://gist.github.com/peterpme/10840585ddced15a7f4ecd05394... The ability to use "constants" that are inherently typed mean less mistakes and a better path forward for handling your application state. Refactoring with this in mind, becomes a lot safer. For example, if I had a reducer that needed a new action, I would add that action to the `type`. The compiler would then tell me every place I needed to handle that case. 2."Implicit" Types (types that don't get in the way) I don't need to type everything like I would in TypeScript. ReasonML already figures all of that out for me. I _can_ add the type if I want (for readability purposes). There is no such thing a `any` or any type of escape hatch for that (this can be frustrating at first) but once you get it, you write code more confidently. 3. React & Refactoring Say I've got a bunch of React components I need to refactor. Reason types both the prop key and value. If I remove a prop or change that prop's data structure, I'll immediately know all the places I need to make that change. I know some folks may roll their eyes when they read this, but after using both Reason and TypeScript at Draftbit, I strongly believe it's a competitive advantage. The stuff we ship in Reason just doesn't break.
  - machiaweliczny 6y ago
    Is it possible to compile in presence of errors? I love TS that it's gradual and for prototyping I can use "transpileOnly" and after I'm done I can verify everything. I have bad memories from typing json interfeces for Elm while prototyping (maybe could be disabled).
    - pkilgore 6y ago
      No, but you can slowly Reason-ify a javascript (or typescript!) app at the interfaces using gentype[1], which emits javascript/typescript/flow interfaces for the reason side. It works perfectly well to ship a slowly-becoming-reason frontend app. But you do have to have the compiler give the thumbs up before it will compile the reason side of the project. You can also checkout the tutorial for slowly converting a single file here, although I find myself doing this sort of thing very rarely: https://reasonml.github.io/docs/en/converting-from-js https://reasonml.github.io/docs/en/converting-from-js [1] https://github.com/cristianoc/genType https://github.com/cristianoc/genType
- davesnx 6y ago
  There are a few differences between both, a lot of people mention the fast compilation and the type inference. I would add that the types from Reason are much "smaller" and concise, Option type or Result type and the immutability of Records/Objects creates an environment of safety that I don't have it in TypeScript.
- cies 6y ago
  All good arguments in this thread. One I miss: TS fixes some of JSs issues, but many it cannot fix by still being a super set of JS. Reason is similar (enough) to JS syntax-wise, while not having to deal with it's quirks. This is huge for me.
Matthias247 6y ago
> - It powers all of Messenger.com. The team put out a case study where they went from ~10 bugs a week to less than 10 a quarter by switching to Reason Did they move from Typescript or Javascript?
- yawaramin 6y ago
  More details here: https://reasonml.org/blog/messenger-50-reason https://reasonml.org/blog/messenger-50-reason
dmit 6y ago
Congratulations on the release! I have a couple questions for you (and any other contributors!) about the project, but I don't know how to phrase them without coming off as combative. Please accept the following as genuine curiosity rather than malice. 1) You called the 0.8 release "huge" in the release notes, even though it adds 11 new functions, removes 2, and updates 2 compared to 0.7, released a year prior. Is there something else about 0.8 that makes it larger than the sum of the API changes? 2) BuckleScript has seemingly been a one-man show for ~3 years. It is lagging noticeably behind the progress of the main OCaml project (including jsoo). ReasonML has a couple prominent contributors, but the overall (public) activity is dwarfed by Hongbo Zhang's work on BS. Is this because the ReasonML project is considered to be in a stable state, sufficient for production work?
- yawaramin 6y ago
  1) You can see a complete list of changes here https://github.com/reasonml/reason-react/blob/a70d9e6b51ed0ab27a895fa13807436d20db5620/HISTORY.md#080-042020 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, more details here: https://www.youtube.com/watch?v=iWEQjvGGiTA https://www.youtube.com/watch?v=iWEQjvGGiTA . He also regularly blogs about ongoing improvements: https://reasonml.org/blog https://reasonml.org/blog . Facebook Web Messenger and other products are heavily reliant on BuckleScript. I would consider that to be production-ready.
  - dmit 6y ago
    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 say is that one super-productive person is apparently (and understandably) not able to keep up with upstream (i.e. Inria + Jane Street + many others) in this case. And then we have the ReasonML project that has seen even less activity recently. If ReasonML in its current state is considered a finished product that requires minimal maintenance, I couldn't think of a better endorsement, to be honest.
dmitriid 6y ago
> It powers all of Messenger.com. The team put out a case study where they went from ~10 bugs a week to less than 10 a quarter by switching to Reason When they did that, I was running into numerous behaviour bugs on Messenger.com. Anything from weird image uploads to link previews not showing up in one chat but working in another etc. Reduction in pure code bugs is nice and all, but a very synthetic and useless metric overall IMO.
Scarbutt 6y ago
If the language has proved to be worthy, why messenger.com only though?
- fulafel 6y ago
  This meritocratic model is unfortunately not really how language popularity plays out in the real world. At least not on career-length timescales.
  - Scarbutt 6y ago
    Was referring to Facebook usage only, like in, why isn't it used more at FB?
    - jordwalke 6y ago
      It is.
    - vosper 6y ago
      I asked a similar question recently, one of the maintainers was nice enough to reply with some info. Perhaps this sheds some light: https://news.ycombinator.com/item?id=23116754 https://news.ycombinator.com/item?id=23116754
    - fulafel 6y ago
      I think the point stands doubly strong in case of Facebook. They're a PHP shop after all.
      - Scarbutt 6y ago
        PHP doesn't run in the browser...
        fulafel 6y ago
        Sure, but using it in the backend tells us that there is no language meritocracy at FB.
namelosw 6y ago
Congratulations! I hope Reason and Reason React could get more tractions. I'm wondering, will there be more marketing for Reason or Reason React after it reaching 1.0? I found when introducing this kind of technology for day jobs, people either get confused or concerned usually, even though it really looks like React now. It seems to be very hard to have programming languages taking off without marketing nowadays because the adoption usually comes from other people's adoption. It's the "threshold of immortality" of programming languages according to Simon Peyton Jones.

bgorman 6y ago

ReasonML is awesome! I personally preferred the "reducer" state modeling mechanism from ReasonReact 0.6, but you can still use it as a library with https://github.com/bloodyowl/reason-react-update https://github.com/bloodyowl/reason-react-update

wwewe 6y ago
I ended up just using redux with react-redux. I just wrote my own bindings (does not cover the entire api surface but the essentials): https://gist.github.com/melbourne2991/b3093187505f2ee9e517bbcaa6d52580 https://gist.github.com/melbourne2991/b3093187505f2ee9e517bb... You get a lot of optimizations for free with react-redux. Given reason-react now supports hooks you can also just use `useReducer` but this lacks some optimizations.

cosmosocean 6y ago

Hey 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.

thegreatpeter 6y ago
styled-ppx by @davesnx is a great option https://github.com/davesnx/styled-ppx https://github.com/davesnx/styled-ppx At Draftbit we've been using https://tailwindcss.com https://tailwindcss.com with @dylanirlbeck's https://github.com/dylanirlbeck/tailwind-ppx https://github.com/dylanirlbeck/tailwind-ppx with great success! We also use `bs-emotion` (which on the styled-components vs. emotion api side is the same)
tsnobip 6y ago
I guess this lib would be the closest alternative in a safe statically typed way : https://github.com/davesnx/styled-ppx https://github.com/davesnx/styled-ppx There's also a nice lib for tailwind : https://github.com/dylanirlbeck/tailwind-ppx https://github.com/dylanirlbeck/tailwind-ppx
- davesnx 6y ago
  Thanks, let me know if you are using it!
wwewe 6y ago
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.
- chrisweekly 6y ago
  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.

deleted 6y ago

[deleted]

shermanmccoy 6y ago

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.

s-km 6y ago
What do you mean? Typescript by default assumes non-null, and if you specify that something can be null it'll force you to check that it isn't before attempting to access it.
- Vinnl 6y ago
  Note that "by default" here means "when strict mode is on, which is explicitly turned on when you run tsc --init". If you don't specify a config value for strict mode, it will be off. (At least last time I checked.)
- shermanmccoy 6y ago
  Sure. However the any type lets the nulls in. And the any type is very convenient, perhaps even necessary to use in some situations. So then you are back to plain old js check blocks and ternaries littered everywhere. If you miss one, well, I don't need to remind anyone of the ubiquitous js console error which every js developer has burned into the back of her/his brain.
  - osdiab 6y ago
    I use the no-explicit-any Typescript ESLint check and tsconfig no-implicit-any, never turn them off unless absolutely necessary, making this is a non-issue. Not that I’m not interested in Reason for other reasons though!
    - shermanmccoy 6y ago
      That's fine if you can control this configuration I suppose. But the escape hatch is there, so in my opinion TS doesn't go far enough.

iddan 6y ago

I am very pleased to see the revitalized efforts on ReasonML. I hope soon it will be widespread enough I could use it professionally. Also, I love the new website design!

zaphirplane 6y ago

Assuming most serious projects will depend on a lot of npm modules. Do the reason folk think that projects will add custom wrappers/typings Just like with TS (mind share chicken and egg problem) or is there a way for the compiler with its powerful type system to - handwave - deduce types in JavaScript npm modules Edit The gap between https://redex.github.io/ https://redex.github.io/ and type.d seems like a challenge

pkilgore 6y ago
There is no way, currently, to deduce vanilla javascript types. You'll have to write your own bindings (types) or as you pointed out, use community bindings on redex. Now? Writing a binding is barely a speed bump, but when I first started writing Reason code it definitely tripped me up a few times. I tried to make the road behind me a bit smoother [1], but that gap you observed is real. But as someone who writes/reviews both Typescript and Reason, pretty much every day, there is space for both projects, so I don't see that gap as being relevant to the survival of Reason--rather, its something that with hard word will be improved over time.

cpursley 6y ago

ReasonReact & ReasonML seem like a much more practice Elm. Can anyone recommend some up to date ReasonReact & ReasonML tutorials & books? Also, what is the recommended architecture - are there any good starter projects?

davesnx 6y ago
Sure, I worked with Elm before and I feel like they share the basics like immutability and types. Which makes a lot of sense, since Elm got very inspired by Haskell and Reason it's a syntax and a few beauties of OCaml. A good intro (at least for me, since I'm into videotutorials) is https://egghead.io/courses/get-started-with-reason https://egghead.io/courses/get-started-with-reason. https://egghead.io/courses/get-started-with-reason https://egghead.io/courses/get-started-with-reason