

A Pragmatist's Guide to ReasonML

Marcel Cutts speaking at Reactivate London in April, 2017
Great talks, fired to your inbox 👌

About this talk

What is ReasonML, and why does it seem to keep dripping into our React ecosystem? Is this just one of those crazy hipster things? Should I learn it now, later, or never at all? These questions and more will be answered in this talk.


Marcel: Hello, everyone. I hope you're all sufficiently beered. I'm very excited because I know own my own, personal clicker, which really makes me happy because I can wander around while I talk, which is... otherwise I just get really antsy. Okay, cool, so Reason, what is it? Should you care? Are you going to be using it today, tomorrow, or any other time? Let's find out. So you're all good engineers. Over time, your Javascript has turned from looking like this, to looking like this, to looking like this. And you've amassed this sort of like menagerie [00:00:30] of tools to try and build uh higher quality... Javascript applications with confidence and stability, so you've got flow for types, and Babel so you can use features from the future and all this stuff. But you've always had a core of simply Javascript. You've never had to do Typescript because that's over there in the angular pile somewhere, and you're a React person, so you fee safe that you can stick to Javascript. Then Cheng Lou gets on stage one day and says, "Hey, we want you to write everything in Reason." [00:01:00] You put your head in your hands, and you go, "Oh, I wanted to avoid this;" and then you look a little closer, and realise there's Reason, syntax and tool chain for OCaml. Hmm. But others don't understand OCaml, so you check your phone real quick to make sure it's not April 1st; but he keeps talking, like he's serious about this. And sure enough, you may soon be writing OCaml for your Javascript. Yes, the twenty year old systems language [00:01:30] OCaml is making a return on the web front. Now you may be asking, "Okay, my browser doesn't run OCaml." And to be clear, like when we say Reason, it's a metalanguage for Ocaml, so it's the exact same thing but with slightly different syntax to make it seem less intimidating to the uh normal Javascript developer. Lots of no sugar. But this is a thing called Reason Tool which will just take regular OCaml documentation [00:02:00] and turn it into a Reason syntax so you can continue on your merry way. So the people we have to blame for this is Bloomberg, purveyor of wacky keyboards, because they made something called Bucklescript, which can turn your OCaml byte code into Javascript. So your flow will look something like this. You write OCaml/Reason here or there, it gets turned into Bucklescript, then it turns into Javascript. So you're probably thinking this is some sort of like weird joke where we just try to make things as complicated as possible, like an obfuscated C contest, [00:02:30] but for Javascript. But there are very good reasons that this can like be a good idea. So this leads you to the question, "Why should I write Javascript in a metalanguage for a 20 year old systems language that's compiled to Javascript by a fancy keyboard company," which is not a question I ever thought I'd ask, but here we are. All right, so what does Reason and the Reason tool chain give you? So all these little bits and pieces Flow, Babel, ESLint, Prettier, [00:03:00] they go away completely. They get absorbed into the language and into the tool chain. But they don't just do what they currently do. They-- Like Reason does it better. And let's run through it quickly to prove the point. So Flow adds types. Ocaml is a type language, hooray! Easy one. And Flow is written OCaml anyway. So you get all of the cool editing integration you might come to love and expect. You have your types inference and your, you know, look ups for-- for types you should be returning, the types we [inaudible 00:03:28] for your parameters. Great. [00:03:30] Babel. So... compiles something into... browsable Javascript most of the time. Bucklescript does the same, but at different metrics that we can judge the goodness that a pile is on. So Babel, often very slow. You can read me winging about it on Twitter. Bucklescript compiles ten times faster than Typescript, which is already significantly faster. And, it can producer human readable Javascript output. Now I don't know if you've ever tried to debug some production Babel compiled [00:04:00] Javascript, but that's not a happy place to be. So let's play a game. I'm going to show you two pieces of code, one written by a human, and one added by compiler. Try and guess which is which. Number one. Number two. I feel like an optician. All right, hands up for one? Speaker 2: [inaudible 00:04:21] Marcel: Sorry, not yet. Is human number one? Speaker 3: Yeah. Speaker 2: [00:04:30] No. Marcel: Is human number two? No? Okay, trick question. They were both compile outputs. But the fact that you had to think about it proves us all right. Okay, Prettier, formats our code so we don't have arguments about semicolons. Unfortunately, there's now a semicolon option in Prettier; but, you know, that's fine. So Prettier was taken from Reason format, so that's a bit of a cheat anyway. Reason has similar capabilities [00:05:00] and is just-- gives you fewer configuration options, which is a good thing because the reason you have to have configuration options in Prettier is due to like a long legacy of craft. ESLint. Well since we have Types and we have Prettier, our Reason format, we-- like there's not that much left for ESLint to do. But it's generally there to make sure that we don't hurt ourselves in our code, we don't do anything naughty. It catches our mistakes. And the compiler is extremely helpful for Reason. It gives you extremely verbose errors, it tries to guess what you did wrong, kind of [00:05:30] like [inaudible 00:05:30]. So for example here, you know, it gives you a nice print out, it tells you what [inaudible 00:05:37] expected. It doesn't give you a like a one line like, "Error on Line 7" type error... kind of stuff. It's trying to hold your hand. It's your pair buddy for programming. And something-- and beyond all-- like taking in all the bits that are already covered by these bolt ons we use for Javascript, Reason really tries to tame the metalanguage. So [00:06:00] this is kind of a long subject. Sheng Liu has like a two part talk about this, but a metalanguage is kind of the stuff around the language we use to get stuff done, the intent and ideology. So I'll just give you a quick example of one bit that gets tamed through Reason. If you want to deprecate something in your API of a library for your Javascript package, for example, at the moment, you might put in a comment, or a cheeky console log and hope someone notices, but there's no real way of like deprecating something long term. You could write a [inaudible 00:06:30] [00:06:30] comment, and then write an ID plug in, but that's not universal. You can't always count on it being there. But in OCaml, and therefore Reason, there is a deprecation functionality, so you can always count on it being there, always count on it being used. You can count on... common formats so you can automate deprecation notices and all this other kind of stuff, which isn't available in Javascript. Cool, so the other thing that's really, really interesting about Reason, and its tool chain, is that the OCaml world has an [00:07:00] insane reach. With React [inaudible 00:07:02] coming out very, very soon, we'll be able to write renderers much more easily, so we can run it through anything Javascript can touch. Anything Javascript can touch. But... OCaml can react compile to native. You can have real applications running on your computer, and your website, and your phone, and everywhere else without having to have an intermediate layer, which is really, really, really insane. And at the really crazy end, we can do unikernels. Does anyone [00:07:30] know what a unikernel is? That guy's chilling out and confident. He knows what unikernels are. I didn't know before I started getting into the OCaml world. But you know how when you have an application, you need to have an operating system because you don't have your own TCPIP stack and stuff? Well the OCaml crew have decided to write pieces of operating systems themselves, like a TCPIP stack. And if you don't need anything that they haven't already provided, you can just have a pure OCaml application/OS in the single bundle. No operating system required, you just stick it on a hypervisor and it runs. So you can have an [00:08:00] OS and application combo of like a hundred kilobyte to ten megabyte. You can boot it up a whole operating system and application twenty millisecond, which is faster than Lambda functions. It's really, really amazing shit. But that's a bit far, like a bit out there. This is a React meet up, so we should think about Reason and React. And good news, recently Reason-React was released, which is a way of binding React to Reason so you can manipulate it in [00:08:30] ways that we know and love. It's not a rewrite of React and Reason, it's just bindings, but it works well enough. This is what a regular module will look like in Reason. As you can see, it's quite similar to what we would normally-- I think there's nothing that's super scary if you write, you know, ES 2016 code. Like this shouldn't be too far off field. You can also tell it's Reason because I couldn't get a syntax highlighter for it, so... you'll have to enjoy the white on grey. You [00:09:00] can also use interrupts. So at the moment, while Reason is lacking a lot of things, you can-- something you may consider is trying to build some of your components in Reason and then just requiring them... from you Javascript class, so you can begin to slice off small parts of your application and build then in Reason, so you have like confidence... and good, new stuff over in the corner without having to rewrite from scratch [inaudible 00:09:24] projects. So should you use Reason today? [00:09:30] Not yet. It's still very, very immature; though, at times when I was trying to research Reason and find documentation, and shout at people on Twitter, I end up looking like this. Reduced to hiding in a dark corner with a bottle of whisky. And it has a very, very small ecosystem at the moment. There are very few dependents, there are very few packages, and a lot very few tutorials, even though main documentation has blank spaces where documentation is going to be. So you're left doing a lot [00:10:00] of stuff by yourself, and there's a lot of unanswered questions, like how do we do async? That's always a hard one. We can do it the Javascript way, I guess. But who knows if that's right. And, of course, Reason, and by extension OCaml, does have this very systems focused community, so when you walk into like an IRC for OCaml, because they're old school, you, you know, you go like, "Hey, I'm having trouble, like, rendering my Javascript for OCaml," they'll sort of look at you really funny and tell you to go away. But mostly lovely. But it [00:10:30] does mean, like you know, the-- there isn't, as I said, like the same sort of wealth of help that you would get by sticking to the mainstream. So not yet, otherwise this might happen to you. But if you want these kind of future features to help you in your project today, I highly recommend Elm. It has many of the helpful tools. It has strong typing, it has fantastic packages, and a really warm and welcoming community. However, Facebook are really throwing their weight behind OCaml. They use it for Flare, they use it for Infer, they use it for parts of Hack, as well. And [00:11:00] they are putting a lot of effort into getting it mainstream, to making sure its available, and to, you know, having all of the core products be accessible through Reason. So Elm today, but in a year's time, we might all be writing Reason. Oh, I'm going to be aggressively unemployed in three weeks, so if you want to hire me, I am available. Thanks for listening. Speaker 4: Any questions for [00:11:30] Marcel? Marcel: Not too difficult, please. Speaker 4: They can be very personal, too. Marcel: [LAUGHS] Yes. Speaker 5: Um when do you think's like actually a good time to start adopting this? Like... Marcel: Yeah, that's a really good question. So... I think piece by piece, if you do something simple like a React component, you can just have the componentry written in Reason, and Bucklescript will compile that as needed to into readable Javascript. So it can be part of your tool chain, but you can have the confidence that Reason gives. So you can do it now. 25% of, [00:12:00] the web version of the Facebook Chat, is written in Reason now. Um so I think about fine, but doing-- and things like small [inaudible 00:12:08] libraries are good, as well. But the larger pipelines of how do you go-- like, you know, doing complex UI interaction work is still a little bit out there. So, I don't know. Speaker 5: Is it like two years? Like three months? Like-- Marcel: I would say... I would say a year, maybe. Speaker 5: Not two years and three months. Is it more like three months [00:12:30] or more like two years? Marcel: It's more like three months. I think people are going to already starting to pick it up and doing cool things with it, so um kind of like Flow? You know, there were very, very early adopters, and they had the-- the pain of new [inaudible 00:12:41] doing weird things to your [inaudible 00:12:43] instances, and stuff like that. Uh but people persisted and, you know, some people got [inaudible 00:12:47] very early on and some people didn't. But that's all guesswork. Ronnie, kill me. Ronnie: Do you know what the status is for like general backend at all? The like making [inaudible 00:12:58] with [00:13:00] Reason? Marcel: I mean, there's absolutely nothing that would stop you because if you can use it to generate Javascript, that can be a r-- like run by a node server. But of course, it is also a systems level language, so you could-- Ronnie: Sorry, yeah, natively. Like running it as [inaudible 00:13:12] like... Marcel: Hmm. Ronnie: You know. Marcel: I've seen a couple of examples. I don't know how like widely it's distributed. Um so I wouldn't be able to an-- answer with like strict confidence like, "Oh yeah, all these people do it, and it's piss easy." Oh, can I swear? Too late. Speaker 7: Yeah, you said that like documentation resource [00:13:30] was pretty firm? Marcel: Mmm-hmm Speaker 7: On this? Did you remember like maybe waiting for an article, or seeing a video where you were just like, "Cool. I, like, now understand, like, the whole concept and stuff like that." Marcel: There's like a Reason evangelist named Sean something or another. Speaker 7: [inaudible 00:13:50] Marcel: Yeah, that-- that Sean guy. Sean, Reason, Youtube. Yeah, there he goes. His name is Sean Grove. [00:14:00] There you go. Look him up. He does a lot of talking about Reason, and has done for like the last six months, so obviously he's early adopting. He doesn't actually work at Facebook directly either, so...he probably has like a lot more-- he's got really good tips on learning Reason when you're not part of the inner circle. Speaker 7: Cool, thanks. Speaker 8: I have a question. Marcel: Go for it. Speaker 8: Uh how hard or easy is it to integrate Reason to existent [inaudible 00:14:23]. Like a existent rector. So say I have an app-- Marcel: Mmm-hmm Speaker 8: It is a webpack or something. How do I [inaudible 00:14:29] Marcel: Yeah, [00:14:30] cool, so that's actually surprisingly easy because you can use Bucklescript to generate Javascript, which then just your webpack instance would pick up and bundle up, as usual. Um there's a good example of this in the-- in the-- oh, please don't have anything weird in my history. Just-- I'm being very-- I should have done an [inaudible 00:14:50] for sure. I'm gonna find out like I'm-- really like chocolate cake. That's a lie, I love cheesecake. Cool, yeah. Oh, and [00:15:00] there's an examples folder somewhere. Yeah, here you go. Yeah, so um there are good examples in here where he does like Interrupt stuff, and also to do NVC where he still uses webpack. So you can basically hook something up where you do mostly, you know, Reason or Bucklescript, and that just outputs to a webpack instance that groups it together. But the good thing is you don't have to do a lot of the normal plug in stuff at that point, so it's a bit quicker than normal, which is nice. [inaudible 00:15:27] one more. Speaker 9: [inaudible 00:15:28] Does Reason have like [00:15:30] have an opinion to that, or does Reason, you know, pure functional know-- Marcel: No, no, it seems a bit more pragmatic. I know especially, like for example, the Elm package manage has extremely strict rules about how packages get represented and used, and to be allowed, and that package-- that repository of packages. Um so [00:16:00] far that doesn't seem to exist for Reason yet. Um it's still too young to have really established a community principle around it. Speaker 4: What are your hopes and dreams? [LAUGHS] Marcel: [LAUGHS] More pizza. Speaker 4: Ooh, tough. Marcel: Oh wow. Well at least there were shattered early on. Speaker 4: All right, thanks, Marcel.