Jordan Walke - React to the Future

[Music] all right hi thanks for coming to reason comp and I also want to thank draught bit and Mike for putting this event on it's really incredible what you've done I really appreciate it and so does everyone else also thank you to all of the sponsors that that pitched in and helped make this event possible so I'm Jordan and I want to talk about react and reason today so I work on programming languages and frameworks at Facebook on the ads interfaces team and you know you might ask why do I work on this stuff so my ultimate goal or at least my personal goal is to build an application that is fast and that doesn't break when it's extended and I keep finding that it's just way way too hard to do that so I end up working on languages and frameworks with the goal of being able to make that job easier but really I just want to use those tools myself and we have a long ways to go no matter what we do it always seems like there's a there's so much low-hanging fruit making the app developers experience better but we have made some progress I've been able to participate in some of these projects as well so in 2011 I created the react.js framework then I shift my focus to mobile or a co-founded the reactive native project with three other people and most recently I started the reason effort and with other co-workers and the community helped build out a lot of the tooling that makes up the reason the ecosystem so what is reason reason is a fast food safe programming language based directly on oh camel so the way I like to think about it is that reason brings the ideas and the principles that you like about react to the whole language but most importantly I see this a way to unlock a much more ambitious future for UI development all right so react we open source react in 2013 and Tamaki no and I presented at JS conf and I haven't really done a lot of conference talks since then but I do go to a lot of meetups and I talk to a lot of people and I hear the stories about people adopting react and a lot of the stories have something in common people say reactivate my job fun again and I think that's really cool feedback and I try to think about why is that I don't really think it's because react provides like out-of-the-box IDE integration and you know an abundance of packages that they can just pull down immediately although all that stuff is really great we should strive for it I think that something deeper is going on I think that react is putting a new idea about how to build apps into people's brains and it's that core idea that feels rewarding to people the idea is really simple it's just that you should minimize application state and minimize side-effects we don't need to go go to the extreme with it but that's just a general guiding principles of react and I think that that idea is what feels rewarding to people so people might not already always express it like this but you know they might say things like I really like that react is composable I feel like I can just stack my components together and it feels like I'm you know playing with building blocks basically or they might say I really like that with react apps my code is easier to reason about it sounds like an opinion and it's not really clear what people mean when they say reason about but I think I have a pretty good idea what they're trying to say we reason about something it means that you can look at a small part of your code and you can understand a majority of the complexities and the interactions there without order to keep the whole entire program and your brain at once so it's easy to reason about now building apps this way the way that react encourages minimising side effects and state that makes your app easier to reason about and it sounds like an opinion but it's more than an opinion because it's also some you can measure so take this example here this is a react component and it renders an array of friends and for each friend it's going to render a div and it's going to print their name inside of that div but then it's going to wrap the whole thing in a container and we have another handler on the outer container that says whenever you click on anything in here we're gonna send a message to the user saying this is how many friends you have all right but notice something interesting about this time can elapse between when you render that list initially and when that event handler occurs a lot can happen in that time what if somebody were to add an additional friend of that array just mutate it out from under you I mean if they remove a friend well then that message that you send to the user it's going to be out of sync with the list that the user sees on the screen let's be patient alright so imagine you're in a really complicated codebase it's really big and uses lots of mutation everywhere no magic trying to go through you know in your head look at this code and determine whether or not that mutation could happen it turns out it's really hard so first of all you have to go to every other module that calls into yours you got to confirm that after they pass that array to your component they don't go and you take that later okay that can be pretty time-consuming but it's worse you also have to go find any other module that you're calling module passes that array to and confirm that they also don't mutate that array that was that's complicated and difficult for me to even explain so imagine trying to go through the actual code base and reason through that alright so contrast that with if you know this array is not mutable can never be mutated some language or type system that won't even allow you to do it the problem becomes much simpler this is all you have to keep in your head to understand almost completely how this component works you could reason about it so programming like this you know it allows you to experience many small wins when you're programming it's kind of like your brain gets this this reward every so often and you're confident with what you've achieved it makes programming fun it's kind of like a game I think that that's what people are talking about when they say reacting my job fun okay so react creates this pit of success with these kind of patterns they're more easy you know they're easier to accomplish they're more common that's oh the pit of success means you you just naturally fall into it now a lot of purists might say hey I know the ways that you can circumvent these guardrails and react and I can make that array be mutated and that's true but there's no denying that compared to the alternative paradigms and UI programming it's a huge improvement and it was also a massive course correction for the direction that you I was heading in before react so react has become bigger than in Ian's library at this point it's really the idea of applying these timeless principles to the domain of UI programming so it's interesting that a lot of these ideas they feel new to people but they're not they're actually is old as computer science so it made me wonder like what else did we miss right what's in store for the future of UI programming so in order to project out into the future I think is really helpful to take a look at the history of programming languages or at least the high level programming languages to see where some of these ideas originated from in 1932 Sargon way back in 1932 Alonzo Church discovered lambda calculus so lambda calculus is the simplest possible programming language you can imagine in its core construct it's just a function with some lexical lexical scoping and really it turns out that from this really simple idea of just a function that takes a single argument it returns an expression and then functions that you can apply you can construct any computable program that's interesting so we're already starting to see the idea of computer programs being expressed as an expression that describes what the computer should do instead of actually just doing it in a sequence of imperative mutations this is really early what's really amazing here though that lambda calculus was discovered before the first programmable computer was ever invented so that should tell us something so this wasn't contrived out of the constraints of technological progress in the time these ideas they seem to be timeless all right so it's not just mathematical theory though in 1952 we see the invention of the Lisp programming language family and were able to take which basically took labour to calculus and made it human usable and it's actually running on real hardware at that point but then as time went on more people developed and collaborated together there's this increased demand for type systems and a way to automatically prove or you know reject bad programs ahead of time before you ship them it sounds like a good idea to me so Roger Hindley and Robin Milner invented the ML family of programming languages by creating the hindley-milner type system so contrary to popular belief ml does not stand for machine learning but what's really cool about ml is that it it really pioneered a really great type system where types one a burden you don't have to always write them so the compiler can infer them in most cases that's really great because a lot of types of some skeptics might say yeah but static typing is all these benefits but it's a huge burden I have to always write them out everywhere it ruins the rapid development it's not so so ml is like the overall family of languages that standard ml o camel and elm all descent from so it looks like we're innovating in this really rapid pace here went from no computers even existing to actually amazing type systems like forty years so if you project out into the future I mean in 40 years from now how amazing is it going to be I mean everybody's gonna be using these awesome technologies right well apparently something had gone terribly wrong from 1973 to 2010 because when I started working as a web app developer we weren't using all of these awesome paradigms we weren't programming in patterns that were easy to reason about we weren't even using static types as into that at that time and we were using actually two dynamic languages javascript and on top of that one of them was PHP so and we also have these like chronic kind of crazy server setups where we would render this markup on the server we'd send it across the wire and we try to sprinkle some JavaScript on it on the client you know with the hopes of making the static document somewhat interactive you know it's easy to kind of bash this but at the time this was the status quo this was how everybody built web apps the worst part about it though was that everything was based on mutation so that means if you wanted to change a color of something you just reach out to that dom node and you just tell it to change the color and then somebody else wants to do the same thing then they'll also do that and then hopefully well I don't know who wins there's really no order to it so I started creating several prototypes of what we now call the react.js library so wrapt didn't just solve one problem I know it's good to solve one problem but we actually solve multiple problems at once kind of made it confusing to explain to people like here's the value of react but but it did solve several so first allowed us to render that markup on either the server or the client we didn't have to decide upfront so that means that you can render all your app on the client and then if the constraints change maybe you're in a different area where network location or you know network bandwidth is less or latency is higher you can switch to rendering that on the server but the coolest thing about react is that have brought the ideas of functional programming and immutability to a wide audience some people might not really like to admit that but you know they might say oh you know I never said I like functional programming or anything and that's fine I think we should meet people people where they are and I find that if you just call it declarative programming it just it's an easier pill to swallow it's like they don't want the question there their identity as a programmer ok so I showed some of these earlier prototypes of people and this is more or less what it look like a couple of renames are different there but when I show this to people I was hoping we'd have a great conversation about all the ideas of react you know this is a good idea that's not a good idea maybe poke some holes in it but it didn't go down like that so when I show this to people what a large percentage of them saw in their heads was this endless stream of closing brackets and braces so it turns out that developers of Facebook at the time so they were used to this but this dialect of PHP where you can embed XML inside of their code ok so I kind of listened to that feedback and I dusted off some tips from atom hub and some old parsers by Marcel and I piece together this diff where I implemented JSX as we know it today inside of react so it looked like this what's cool is that this wasn't like a fundamental change or anything all all we were doing was just taking this and then turning it exactly into what we saw before literal dysfunction call see you just do it the first time almost so I thought okay that's great and if I mean the difference in reception was 90 day people were like whoa that looks great so what's this react about you know because we could actually get past this industrial friction here and talk about the real ideas that matter so reacting some adoption internally and it looked like it was going pretty well and we decided it's time to open source react and so all we had to do was just show the world what we built and then you know look at the same kind of enlightened response that we had internally that's what I thought until I got to this slide where I showed the syntax that we were using and it's kind of funny because I remembered looking out at the audience and just seeing the sea of furrowed brows in like angry faces and people were it was like visibly upset and I was like wow what's what did I say do they just they just really not like immutability or something and so we talked with some people out after the conference and turns out that they really didn't they took issue with our syntax extension and you know it's water under the bridge you know there were some harsh words on Twitter which we we don't really need to relive right now but you know eventually people got over it and they were able to see the ideas and react and we can talk about that and that's important so some people might say all right syntax yeah it can be an issue at first but if I just persist through it if other people just persist through it you know they'll get over it they'll see the real value behind your technology that's true but I like to think about pushing new technology kind of like I think of it like pushing a really heavy stone on the ground and you have to kind of friction two kinds of frictions that you're working against here you have static friction and kinetic friction so static friction tells you how hard you have to push this thing initially to get it moving and then kinetic friction tells you how hard you or how much more energy you need to put into the system to keep moving with the sardian motion and so you might think oh yeah this stone is really great and if people just push the initial phase you know they'll see how great it is afterwards but the problem is there isn't just one stone so every day on Hacker News you have 20 stones all telling you you know this is going to solve your problems and some of these stones they don't have any kinetic or they don't have any static friction at all you just start pushing them right now so people don't have to trust them that the technology is going to deliver once they invest so that's what you're working against the other problem is that you're not the only one pushing so you want to get co-workers project contributors on board you want to get them ramped up you want them to take a look at your project and send a pull request so it's not really just about you it's about what other people think too and that matters so my suggestion is to ruthlessly remove all of the static friction that you can in your technologies and so the core lesson that we learned from just the open sourcing process of react and the internal adoption is that syntax matters it really does it's really highly subjective but it matters because it influences the outcomes that's what we care about all right so fast wording six years you've open-source reacts you know it's growing it's become popular it's a full time team dedicated to innovating react and maintaining it improving it and they're doing a killer job react has quarter billion quarter billion downloads per year from NPM if you were to count all of the downloads from the content delivery and you know all the way to the client machines it's it's well into the billions per you I haven't ever really calculated it but all right so react brings better patterns to your components sounds great but where do we go from here is that all we can do what about the rest of your codebase what about your code that isn't components what about static types that was that other problem that seemed unsolved it in 2010 that's something that only a language should really solve if we're going to embrace a new language we really want one that matches react so reason brings what people like about react to the programming language level to the rest of their codebase it picks up where react lifts off so for example remember all that pain that immuno that mutation brought to our render function earlier well and reason by default records are immutable it means you know that nothing in the field nothing in the fields can be changed but most importantly you can trust that so all you have to do is just hover over something in your IDE and you can tell this can't possibly be mutated you don't have to wonder so you can see the reason already brings us local reasoning back to you but reason isn't just for the purists because you can also opt in to mutability as well so in this case these fields are mutable now I can actually update it there my immutable Settings dot is admin equals tree so that looks a lot like JavaScript well you know if it wasn't clear reason is designed to be immediately usable by JavaScript developers or really anybody from any of the other popular popular languages as well so this example here that we saw with the list that we were underneath that's both valid JavaScript JSX and valid reason so hey you already know a little bit of reason you can imagine how you know how much easier that makes it to get your co-workers on board but it's not just JavaScript so it also includes some features beyond JavaScript like pattern matching which is kind of like a turbocharged switch statement that's totally tight based and it allows you to express redux style state transitions really naturally like it's embedded into the language because it is it also catches a bunch of other kind of errors and bugs that you would have in these kind of situations like let's say well in this case I forgot to cover one state here like what if the event type is an escape but you're already logged in well I didn't cover that well this is my terminal output that I see when I forget to cover that says hey here's an example of a case that's not matched so as all these kinds of these additional checks statically guaranteed at compile time it's really helpful okay so how does all this work how's this type system so good did this just come out of nowhere well no when you're looking at reason behind the scenes it's actually oh camel one of those mmm languages so you might ask okay well then is reason the camel language well yeah sort of I guess it depends on what you mean by language right so what is in a language a language is a lot of things it's the the community of the package manager' libraries patterns use cases all these things that matter but most importantly a language is at the heart of the compiler so what's in a compiler I'm gonna totally reduce this down to an absurd level here but you can think of it in a few stages the front end which you know it describes its syntax and how you actually interact with it the middle stage which is type the actual type system where implements and implementing it the semantics and then the back end which is like actually rendering out the machine code or the JavaScript whatever you're compiling to so reason starts by replacing the syntax of a camel with one that is immediately usable by JavaScript developers okay so why start with syntax well I mean if we saw anything if we learned anything from the story of reactance that syntax matters it's the UI of your programming language so there's some quotes from people that I just randomly pulled from from Twitter to me the syntax the familiar syntax was that originally what lit my interest in reason I did some exploration of reason and some time ago and it was super intuitive to write it so this is some of the stuff that we're hearing but not everybody likes the syntax because I mean there's no syntax that everybody likes but if you consider just who were targeting it makes a lot of sense because the JavaScript developer community is huge its massive so if you want to gain adoption in a technology you want to remove friction for the largest set of people at once static fiction even if it means maybe increasing friction for a tiny relatively tiny set of the entire world of programming it's a worthy trade-off okay but then I mean it gets kind of confusing because a lot of people use reason with buckle script so which replaces the back end of a camel with one that emits idiomatic JavaScript that you can check in and that your co-workers won't yell at you for so I mean at this point when it's used this way more the Oh camel compiler is replaced with with parts of the tool chain that JavaScript developers want but importantly it's still oh camel exactly where you want to be in that battle-tested hardened type system okay so I mentioned compiling to JavaScript there's going to be other awesome talks about that at this conference but yeah this might sound kind of like a radical proposal like you're gonna change my way I you know like develop my JavaScript code base sounds like a radical departure well I would say I'm not really so sure about that I mean ever since we open source react people have been using JSX and that's not even valid JavaScript it won't run in the browser so people have to compile it into JavaScript to run it in the browser so your compile to j/s language user so now we're just talking about trade-offs in compilers like which one would you want if you're developing react apps I'm more interested in arguments and discussions about about the kind of potential that we can unlock for developers I'm not really interested in you know talking you know biasing towards the status quo because if we did that we'd still be rendering PHP on the server and we wouldn't have react so if you imagine you visualize the the potential that a JavaScript programmer has today in the JavaScript ecosystem react definitely improved a large portion of that so anything related to UI and interactions develop the developers life improved and the code was easier to reason about it didn't solve all the problems and that's it wasn't supposed to so the way I think about reason is that it brings the things that people like about react to the entire language so that every use case in the JavaScript ecosystem benefits from those same core ideas but what's often - but what's often missing from this discussion is the person who matters most who matters most these are yeah I mean you know reason and react both improve the user experience because users don't like bugs so the fact that reason can prevent a large class of that ahead of time that's great what else do users care about performance right exactly so if you take a step back you look at the entire world of programming you realize how big it really is so there's a lot of people building tools or building applications with rest C go what are they doing why are they doing that what part of always bet on JavaScript do they not understand it turns out there's some pretty good reasons users want faster startup time they want better utilisation of their hardware they want more predictable performance faster execution more throughput they appreciate that and they notice jits can be amazing just-in-time compilation but they're also pretty unpredictable too because they rely on heuristics that are really hard to pin down ahead of time hard to guarantee throw out the all the workflows if your app that you didn't test so when you want to provide the best user experience can't always afford the complexity of the JavaScript language J's developers can sometimes be in a kind of denial about this and they'll get me wrong I totally understand the appeal of pushing JavaScript in the VM to its limits especially if you're in the case or in the scenario where you also want to you also want to deploy a large part of your code base to the web say historically that means you have to target you have to write in JavaScript deploy to the web now you're in this situation where you have this existing code that's existing knowledge but you also need to run it run it in all these other environments where a JavaScript VM wasn't you'd be required to begin with so the appeal there is well I want to take this code and I want to use it in all these other use cases even if those other news cases are more demanding so so developers they're there in this trade-off work I want to target web I also want more constrained environments I want to cover all the bases so you're in a situation where you have to learn web development today and then if you want to cover these other use cases you're faced with a choice completely learn from ground up and this other staff in another language that serves these other use cases better import everything I wrote in JavaScript over there keep it in sync or I can just let the user take the hit I could push JavaScript beyond its limits maybe pass its breaking point makes sense why this is happening ultimately any library that's authored in JavaScript is held captive by JavaScript you really only be used in so many scenarios and if you don't believe me just ask all those people in the right column there but here's what's so cool about reason even if you're just writing reason targeting the web today all those skills they transfer to a huge portion of those other native use cases that are more constrained there's no such thing as one language that can do everything right there's going to be use cases so demanding that you know you need to drop down to low-level C and there's gonna be other cases still or even that's not good enough and C adds too much overhead and you have to write manual assembly hopefully none of us ever have to do that but no there's also going to be cases where you know the the current feature set of the oh camel native compiler it's not really well matched to that use case so there's definitely a lot of room there but what I've noticed is that a lot of the systems that people are building where you know you want a fast command line app you want a fast server it's actually really well-suited by the need of a camel tool chain a huge portion of them because it produces fast executables that start up instantly sounds almost too good to be true except it's already happening here's just a couple of examples that I pulled from the community fnm we mentioned that earlier it's fastener manager that is a node version manager that is so fast you can put it in your shell and you'll never notice it this happens instantly another one is Oney too so only two is a rewrite of only one but this time it's based well it's always been based on vim but this time the GUI is based on recent native so these projects they have a serious advantage when they're competing against other ones that are written and authored in JavaScript just because the performance alone the performance is an incredibly important feature to users so here's some quotes just pulled randomly off Twitter about Tony it's crazy performant like scary fast I actually didn't know one app could start that fast my Mac did I click it already started and so what's cool is that all these projects and there's many more - they were started or contributed to by people from the web community from the web ecosystem that's a lot of potential that we're unlocking we also use reason native on my team as interfaces of Facebook we compile a reason modules to JavaScript easy buckle scrip compiler but then we also have piled them natively to native executables so that we can run them extremely fast in our testing environment we don't have to spin up a JavaScript VM to actually run our tests so it's very interactive we do that using rely which is a testing framework inspired by jest but meant for native reason it's part of a larger set of utilities that we have open source called reason native which brings a lot of the node utilities and the node style of libraries and programming to reason native you check it out there so why was Native hard I mean looking at the history if he ever tried to compile a C++ program it's a nightmare usually involves you know installing 20 global things on your machine you didn't have before overheat that for another project so that that and your editing make files and environment variables for like hours before you can even get the thing to build so why was that well native builds have historically not completely automated and modeled all the dependencies that are required it's just part of the culture in a lot of the previous native programming so there's no one clicked there it's too easy for package authors to accidentally rely on something on their specific machine but you know how on yours and so you spend all your time trying to recreate that package authors machine set up an environment on your machine and it's hopefully it's documented it might not be so because of that lack of automation is really difficult to get pre-built artifacts to other people or even on your own machine across projects so these are some of the things that make you Native hard or slow or painful so what are we doing under the reason umbrella to improve things well if we want to get web developers on board with the native development development workflows we need something that's familiar it's got to be one click we need something that's easy so Audrey Papa's been building something called easy easy as it is like the one easy button that you need to press to automate to speed up and perform native builds it feels just like NPM package management also actually you got a package JSON you specify your dependencies so really any web developer can just get started really quickly and they immediately know how to navigate the project but it's not NPM it doesn't use NPM it doesn't use yarn there's a complete Korean fomentation of a package management workflow and it's implemented in reason Native itself so it's also really fast it's really easy to use you just type yes why and the command line when you're in a project and it'll just do everything it'll build install the penalties so actually pretty incredible what's happening there I think of it as like a react but for package management so in the same way that we're bringing the ideas of react to the language of threes and we're bringing the ideas of react to the package management with easy so when you run easy it reconciles your project fetches what needs to be fetch from the network builds it needs to be built and does it really fast but what's really cool that are also caches those builds for your project in dependencies across all your projects so the more you use it the faster it gets when you're when you're developing native it uses some code from oh camels package manager OPM and also has integration with oh pam so that it can consume those packages and build them and it's really standing on the shoulders of giants here with both Oh camel and oh pam and a lot of the research that went in there including some of the windows support but also supports native seed programs in c++ libraries i also supports javascript packages so it's really kind of one tool chain that can can do it all there so reason takes the ideas of react to the next level and i see it as a way to unlock your potential as a developer because it allows you to learn one language that improves the user experience across a wide variety of use cases and constraints so i want to leave you with one question what could you build a threesome maybe you could build a really cool data fetching paradigm a framework that runs everywhere maybe you could build a new UI library maybe you could build what comes after react thank you [Applause]

Channel: ReasonConf

Views: 30,454

Rating: 4.9636364 out of 5

Keywords: reason, ocaml, react, bucklescript, reasonml, reason-react, Reason Association, reason-conf US

Id: 5fG_lyNuEAw

Length: 36min 45sec (2205 seconds)

Published: Fri Nov 29 2019

Reddit Comments

[u/swyx]

further discussion in future

[u/editor_of_the_beast]

I didn't get a ton out of this talk. I didn't find anything that I really disagreed with, and I think there were a couple of nuggets of insight, but overall I didn't get a big payoff out of watching it. He gave kind of a superficial value proposition of ML type systems, saying basically "they are statically typed, immutable, and support pattern matching." No new ideas here.

I've been interested in Reason (and ML in general) for a while, but I'm not sure that it has enough of a compelling draw to switch to using it yet. I'm also very interested in writing clients and servers in the same language recently, because it brings up whole new architecture possibilities. But is ML really the answer there? I'm not saying that it's not, but it's been around forever so why don't people use it? And not just ML, Ocaml has some peculiarities compared to other MLs, specifically that variant constructors aren't first class functions themselves. This is a feature that Elm, Haskell and Standard ML all make great usage of, and it becomes really hard to live without once you've used it. It also appears in Swift and Rust, which obviously are newer languages.

Reason seems cool, but I was also interested in Elixir for a while and I think a similar thing is happening here. Elixir was just a syntax change to Erlang. It didn't really introduce any new concepts, it just re-packaged an existing language and added some niceties on top. I don't know if that's enough to spark interest in a whole new language ecosystem. I'm super pro ML's in general, but I don't know if I'm gonna hop on board the Reason train any time soon.

[u/sn0wr4in]

Got me interested, not gonna lie