React.js Conf 2015 Keynote - Introducing React Native

good morning everyone whoop and welcome to react J as the organizer of the conference I'm so excited to be here and before we get started just a couple of announcements so the first one and unusual thing is you need to drop off your badges before you exit the first day and then we'll give them back to you the second day in the morning and you can keep it the

second thing is if you need to go to the restroom there are near the registration if you need to smoke or take a fresh uh fresh air you can exit by the door you came from and if you need any help look for people with flashy green T-shirts they will be able to help you out and so without further Ado I'm now inviting Tom to talk about reacts

thank you Christopher all right so welcome everyone I'm probably as excited as he is but he did put a lot of work into organizing this thing along with Christina so um let's get started so thanks Chris so I've been here at Facebook for a while and I've worked on a bunch of different things you know I used to build products I built our search type ahead and if you've ever mentioned anyone on Facebook I built that input uh but these days I manage the react team and you know today appropriately I'm here to talk about react the first thing I want to go over

is where react actually came from I feel like every week I hear a new podcast or a new interview with somebody talking about how react was actually started so you know there's dozens of stories floating around I figured I'd give you know my perspective my view of where react actually came from and this is you know feels like a good way to open up the first ever react JSC right so react is actually born in our ads org at Facebook uh a while back we were building these client side applications and they were pretty traditional clientside MVC we use

two-way data binding and templates um same stuff that you're all familiar with and you know just the way that these apps worked you know views would listen to changes on models and then respond to those those changes by updating themselves manually and there were you know a bunch of apps built this way and they were simple they started out really simple but as we added more and more features they got more and more complicated and as we added more and more people to the team along with adding more features we ended up slowing down a lot you know as a

company we just started moving more slowly on these very big very complicated code bases so you know over time our our apps just became a nightmare to work with and what we what we realized is that on some changes to these apps so some new data would flow in what would happen is some small change somewhere deep in the tree would end up effectively having to render the entire app or figure out what needed to be changed and mutate all of these different views right we called these things cascading updates internally um

these updates were really slow because not only do you have to do all the bookkeeping to figure out what needs to be mutated then you need to go and actually you know have the views all update themselves and there was a lot of wasted work here so additionally over time Engineers couldn't keep in their heads what would cause these cascading updates to happen right so the code was really really unpredictable we became less confident in the code that we were writing uh and

anytime we changed anything we were rendering most of our application anyway right the thing that we realized was that we already wrote code that described what our components looked like or what our applications looked like given an initial set of data so when the data changed like why can't we just reexecute that exact same code there's some obvious problems with that but conceptually it's just so much