Hello. I'm very proud to be here today, and pleased to be here today. Thank you for having
me. Today, I want to give you a brief introduction to ReasonML. Before I get started, I want
to say I'm on Twitter and I would love to hear from everyone, so, if you're tweeting
about the conference, please do say hello. If anyone has any questions at the end of
my talk, my slot for office hours is at 3.30, so you can find me. Some of you might have
heard of Reason before. There's been a lot of excitement from the JavaScript community.
This got me interested. Starting this year, I decided to find out for myself what is the
big deal and why is everyone so excited about this new syntax? Today, I will be sharing
the origins of Reason and where it comes from, the type system, and why I think that's beneficial,
and the JS Interop thanks to BuckleScript. OCaml is a functioning language which originates
from the 1990s and was popular in academia. Nowadays, it's commonly used by banks and
financial institutions where code correctness is a key priority. But its syntax is often
seen as a bit of a hurdle when onboarding new developers, and Facebook saw an opportunity
here. In fact, Jordan Wark, one of the core developers behind the React project, came
up with the idea, wanting to make OCaml more familiar for JavaScript developers. He wanted
to bring it to a whole new audience, but not only to JavaScript developers but to those
who had struggled with OCaml. We've for you reached a point where we've got a language
that has all the benefits of OCaml and the decades of engineering that's gone into that
but with a similar syntax and inter opt with JavaScript. When you get started with Reason,
one of the key concepts you'll find is the type system. The instinct ive response from
a lot of developers why can't I use TypeScript or Flow? TypeScript and Flow are useful tools
when they're used effectively. But with Reason, types are really baked into the language,
and this gives us some powerful features at the language level. The first one of these
is that everything has a type. In Reason, there's 100 per cent type coverage by design.
This means you will never get that sinking feeling. You no longer have to worry about
this. Everything has a type in Reason. The type system is also guaranteed to be completely
sound. This means that, if your code compiles, types are guaranteed to be correct at runtime.
This means you will never have a type error at run time. This eliminates a huge category
of bugs from typical JavaScript development. It is a really useful feature. The third feature
of the type system I want to explain is pattern matching. I want to explain this with a quick
example. So I'm sure many of you have written switch tapes in the past. If, like me, you
might have missed an edge case once or twice. Reason comes with protection against this
built in. We call this pattern-matching. This is an competitiveness check which prevents
you from forgetting those Edge cases. It's like having a pairing Buddy there with you
picking up on your mistakes. In this example, I've been writing software to calculate the
group tables for the World Cup. I'm in a bit of a rush because the deadline was last week,
the group tables are nearly finished, so it's a bit last-minute. But here, I've declared
a result time, and it's a variant which you mean think of as an enum. This can be a win,
a draw, or a loss. My getPoints method has inferred the R is a result based on the fact.
I've already handled cases for a win or a loss. Of course, I've forgotten the case of
a draw. So, fortunately, Reason provides really useful error messages while you're developing.
Here, you can see it says this pattern-matching is not exhaustive and gives you example of
the type you've missed. So you never forget the edge cases. This is a simplified example,
but hopefully you can see that this becomes a very powerful feature with more complex
examples. Particularly when we use this with more complex data structures. It's not just
limited to variant s or enums. JavaScript interop. This comes thanks to BuckleScript
which is the build system which is responsible for compiling our Reason code to JavaScript.
We now want to dive into the performance of BuckleScript, I want assure you it's fast.
Go away and look at the benchmarks, because it's the really impressive. So, BuckleScript
generates JavaScript from your Reason code, but it doesn't just generate you go ified
minified - you go uglified minimised JavaScript. It can be read by any member of your team.
It's a valuable point if you have an existing JavaScript codebase because you don't want
to spend that time up front converting your whole codebase to Reason. You can simply start
by writing one file, one module, in Reason and dropping that into JavaScript into your
codebase. This is the approach taken by the Facebook messenger team. They began converting
their codebase to Reason, and they have 50 per cent of the Messenger codebase written
in Reason, and this is in production. It is worth mentioning that Reason has good bindings
to React.js. It comes with things like routing, state management, all built in. So it all
comes without having to any additional packages. It lets you access - you don't have to spend
a lot of time up front learning all these APIs. You can simply use your existing JavaScript
knowledge within the Reason code. This really reduces the learning curve when you're just
getting started. My favourite feature about BuckleScript isn't actually to do with JavaScript
at all. Because, if you're writing backend code, BuckleScript can compile to Native.
This means we can run our Reason code just about anywhere. This is a real useful feature
because you don't have to spend time we writing functionality just so that it can work on
different platforms. Gerald Forsyth did this writing a game called Gavitron. He managed
to employ this app to the iOS app store, the Google Play store, and to web all on a single
codebase, not rewriting any functionality or changing anything to make it work on different
platforms. This is exciting - a single codebase for different platforms. Now, this is only
a lightning talk, so I didn't get a chance to explain all the functionality of Reason,
but, hopefully, I've got across just a few of the points as to why I think it is really
useful. Facebook created Reason with JavaScript developers in mind, but it's not just limited
to JavaScript development. It aims to make the syntax of OCaml a lot more familiar for
all sorts of developers. Now, I've included a few links here that I thought you should
take a look at if you're interested in Reason. I will tweet these out after the conference
so you can find them on my Twitter. One thing I would encourage you to do is just get started.
If you're interested in Reason, play around, hack about. Enjoy the feeling of learning
something new. You don't often get that opportunity. Before I finish, I had two things I wanted
to say: first of all, I wanted to say a big thank you to the conference organisers, because
they've put a huge amount of effort behind the scenes, and particularly being a first-time
speaker, this has made the experience a whole lot less stressful, so thank you to the organisers.
[Applause]. I saw this tweet a few weeks ago, and I couldn't help but share it. Now, Robbie
Neville is a Facebook developer. He managed to achieve 3D printing with Reason. He shared
this code on GitHub so you can go and take a look. I think you'll be really surprised
at quite how simple it was to achieve this. So, on that note, if you're interested in
Reason, get stuck in, have fun, and let your imaginations run wild. Thank you! [Applause].