My name is Stoyan, I'm an engineer at Facebook. I'd like to introduce you to React - a new, open-source library from Facebook and Instagram. It's a library for building user interfaces for web applications. Let's talk about web applications, not web pages. Because pages are mostly content, static HTML content, with some styling from CSS and a bit of JavaScript behaviors here and there - maybe some form validation and other simple modifications of the content. The apps are different. The application data and content changes constantly - from user actions, from new data coming from the server or simply with the passage of time. On the web we build web applications using the DOM. And we keep modifying the DOM all the time, to create those rich experiences. And we all have a love/hate relationship with the DOM. On one hand it's easy and familiar, and seems to do the job. On the other hand the DOM API is verbose. We spend a lot of time just hunting for the nodes we need to modify (like getElementById or getElementsByTagName). Then once we have found the nodes, we start doing cycles of createNode/appendChild to update those nodes. Also DOM modifications are slow. The browser needs to repaint and reflow, which are costly processes, so we need to be careful when touching the DOM. Then there are the event handlers - you need to make sure you cleanup event handlers attached to nodes you remove, to prevent memory leaks. What if there was a simpler way? This is where React comes in. React lets you build your application using simple components that know how to render some data. When data changes, components update automatically in the most efficient way. And all the job of attaching and detaching event handlers is taken care of for you. Also in the most efficient way. Think about the last time you needed to create a table from an array of data. var table = document.createElement('table'); var tr = document.createElement('tr'); var td = document.createElement('td'); var text = document.createTextNode('some data'); td.appendChild(text); td = document.createElement('td'); text = document.createTextNode('some more data'); td.appendChild(text); tr.appendChild(td); table.appendChild(tr); ..... And then one the table cells happens to be a link. Oh gods! createElement('a'), setAttribute('href', 'http://'), createTextNode, append to the link, append to the td, append to the tr... Then a single letter in a table cell changes. What you're going to do? Do you keep references to all nodes? Memory inefficient. Do you traverse the table hunting for the node? Gimme the 3rd cell in the 5th row? Inefficient - the DOM is slow. Do you rebuild the whole table? Inefficient - reflows, repaints and so on. And what if there were event handlers on the cells? In React's case you say: - I have a component Table with Rows and Columns - I have an array of data - Deal with it! Then something in the array of data changes? Here's the data - deal with it. How does exactly React deal with it? You define you components in React. It builds a virtual DOM in JavaScript land which is way more efficient. Then it updates the DOM. Data changes. React computes a diff (in JavaScript land, much more efficient) and updates the single table cell that needs to change. React replicates the state of the virtual DOM into the actual DOM only when and where it's necessary. And does it at once, in most cases in a single tick of the requestAnimationFrame(). What about event handlers? They are synthetic. React only has a single listener at the top and uses event delegation. So removing a node in the virtual DOM has no effect on the event handling. The events are automatically cross-browser and W3C compliant. That means e.target works, no need to look for the event object or checking whether it's e.target or e.srcElement (IE). Bubbling and capturing phases also work cross browser. React also takes the liberty of making event like fire when you type, not when focus away from the input. And of course, event delegation is used as the most efficient way to handle events. Additional benefits of the virtual DOM is that it's all in JavaScript land. You build all your UI in JavaScript. Which means it can be rendered on the server side, so you initial view is fast (SEO is taken care of too). Also, if there are especially heavy operations they can be threaded into WebWorkers, which otherwise have no DOM access.