 Good morning. Can everybody hear me? Yeah. It sounds good. So, first, Jack already told you why you would like to build a single page up, and in the next 20, 25 minutes, we are going to talk a little bit why. My name is Nikolai Baciski. I'm from Bulgaria. I work for Automatic as a developer. You can find my site at txtopulate.me. You can find me on Twitter, as Nikolai B. So, the two main reasons to build a single page up is that they are first, a bit faster. Then the other reason is that they really help us for a more engaging user experience. And before I get to the more technical stuff, I would like to take a step back and talk about change. What do we know about change? First, we really know that people hate change. And you can judge it by the reactions of people for the Facebook UI changes. Then another thing we know is that people are really having a hard time tracking changes of the state. As you can see from this street game, we are not really good at following stuff like this. We are much, much better at just judging the relationships of a static phenomena and not so much about processes. Actually, this is kind of the difference between writing and running an old school web application where, I wouldn't say old school, it's more of a traditional one where you do a request every time and every time you get a response and between a single page up. And the big difference is how we deal with change. So, in an old school web, every time we want to change something, let's say we want to write a post. If we want to write a post, we type stuff and the moment we hit publish, come on, the whole page will refresh. We will basically, did it refresh? Yes. So, every time we change something, the whole page refreshes. We throw away all of the interface and we start every time from scratch with whatever the server gave us. In a single page up, it's a little bit different because we don't have this huge pool, this huge refresh. We don't have the luxury of throwing everything away and after that, starting from scratch. So, we have to be very careful at each change to just change the bits we need. And the end result, even with modern frameworks like Ember and Angular, is something like this. Even if you want to build something really small, I'm sure a lot of you have tried it to build a simple show and hide thing where you click a button and it shows a little bit of information. If you click hide, it changes it back and it changes the name of the button, like the label of the button between show and hide. Actually, you need to take care of three or four or five different situations. You need to take care of, oh, what do I load in the beginning? Like, what is my current state? And it's a great example of why tracking state is hard. And today, I'm here to offer kind of a solution. It is called React. As Jack mentioned in his talk, it is built by some really cool guys at Facebook. And React is just a UI library, nothing more. React is not a framework. It doesn't deal with the rest of the single-page app details like making remote requests or routing or what else. Or trying to sync data between multiple components and stuff. Actually, React is pretty simple. Its main building block is called a component. And a component is just a special JavaScript class which has a render method. And this render method, the only thing it does is it returns the HTML of this component. And that's about it. You may be curious why here we have HTML instead of typical JavaScript code. And this is something called JSX. And behind the scenes, React compiles this to actually plane JavaScript objects. They look something like this. But the cool thing is that designers can edit the code because it's almost exactly like normal HTML. Then we can have components one into each other. And the cool thing is that if you want to use the post meta component over here, actually post meta isn't something special. It is just another JavaScript variable. You don't need to understand everything. But all of the properties we passed here, in this case, post, which looks like a typical JavaScript, sorry, HTML attribute, we can access them in the child component with these dot props, dot post, in our case. And this is how components get their data. Another thing that components can do is that they can have internal state. And this is the really helpful part. In our case, let's say, we want the post meta to have a more button which shows us even more post meta, which is initially hidden. And whether the extra meta is shown or hidden is our internal UI state. And React help us keep it and keep track of it more importantly via this dot state. We can define the initial state and then we can access the state using this dot state. And if we want to change it, in our case, when somebody clicks the button, we want to toggle the state, right? We can use set state. And the coolest thing is that the moment we call set state, or some parent component changes the properties, our component is immediately re-rendered. We don't need to show extra meta, we don't need to hide it, we don't need to attach the DOM at all. React takes care of this. And now that we know a little bit about components, let me tell you a few more things about them. First, as you saw, they are composable. So we can nest as many components we want. And as a result, they really become the building blocks of our application. So normally, we have a bunch of markup, right? But now, our app can look something like this. We can have semantic and meaningful names of different parts of our app, and they can be first class objects in our application. For example, we can have a master bar, a navigation, we can have logos and stuff, and we can have a post listing where each thing is not just a div with class post. And we can just call it post. And everybody who sees it can know what we are talking about. And each post can have, in addition to the content, again, a post meta thing which encapsulates the whole post meta, and not just a big div with a class post meta. Actually, React has a really cool Chrome extension, which is called React Something, which lets you browse the components of your website, of your current page. It adds you another tab in the WebKit def inspector, and it's really cool. And actually, this is from a real app. This is from the new WordPress.com UI, which you can see now at WordPress.com, I guess. Most of it. So anytime I go to a new page, I don't go to the HTML elements because looking at this structure is so much nicer. And I can go deeper as much as I want, and I can actually see the HTML, too. It's in a different tab. Okay. A few more things about components. Components, because they are pretty normal JavaScript objects, they are pretty easily testable. Also, the way React works really help us prevent cross-site scripting attacks, because anytime we put any content through props, for example, and we try to use it in the render method, it will basically get escaped. Of course, there is a way to put arbitrary HTML. For example, we are going to need it if we get an HTML from the rest API. But it is explicitly made pretty dangerous. Of course, it doesn't look as dangerous as Jack. But still, it does a pretty good job. Another thing, and this one is pretty important, is that components are not templates. Most of the templates are pretty underpowered. But React lets us use the full power of JavaScript. We can write whatever JavaScript we code. We can write whatever expressions we want. And it is just plain JavaScript. You don't have to read another, sorry, you don't have to learn another language. Also, most of them reinvent all of the basic functionality like loops, if clauses. And it was hard enough to learn how to do this in JavaScript and PHP. Next. Components are very easily reusable for the first time in my life, and I've been building interfaces for good for bad for some years now. For the first time, actually, I can reuse components kind of reasonably. Let me give you an example. We have an avatar component which does, which just gets the HTML for a router like an image tag. And it is based on the email. I don't need to have a JavaScript or PHP function which does this. This is a first class thing in my application. I just give it an email and it does its thing. And we can use it in the comments. We can use it in the post meta, probably. And the best thing is that, let's say we decide one day that we want to add profile information on hover. When you put your mouse or tap on a gravator, you get a little window based on a remote API on an Ajax code which gives you information about the user. The coolest thing is that I can actually have in this component both the markup and the JavaScript code which does the remote request or stuff like this. And it makes it really reusable. Because before, if you had to add hover, you had to somehow figure out a way to have on every page the JavaScript for the event handlers, for the hover handlers, and stuff like this. Now, you can have it all in a small, self-contained avatar component. But wait, I thought that the really common best practice and something they have been teaching us for so long has been to keep logic and markup separate. Separations of concerns are good. We have to separate our concerns. Is there somebody who disagrees it? We have to separate our concerns. Zero. Nice. But I have a few questions for you. How often do you need an event handler without any markup? Another question. How often do you need an onclick without a button? Also, how often do you need a button without an event handler? Without an onclick handler? I'll give you a hint almost never. So, all of the HTML and all of our display logic, like event handlers, something that decides how something should look, how something should be formatted, what should happen on hover, on click, blah, blah, blah. They're actually the same concern. And especially on the front end, on the back end, it's a little bit different. But on the front end, we've had those two technologies, HTML and JavaScript, and we have actually been separating technologies, and we haven't been separating concerns. And again, the display logic and the markup are actually the same concern. And they belong together. And this is why components actually make a lot of sense, to have both the markup and the event handlers and the basic display logic together. Okay. I'll let this sink in for a few seconds. Now, it is a good time to address the real elephant in the room. And it is re-rendering. So, every time I change even a little bit, my whole component is re-rendered. Isn't this slow? Also, if we re-render every time, this probably means that we remove something from the DOM and we create it again. Doesn't this mess up my scroll position? Doesn't this mess up my focus? Because if we remove something, the browser cannot keep focus. And if I re-render a form, at the exact same time some user is typing, this will get really bad. I mean, our users won't be happy. However, it turns out that React is pretty fast. And I have a feeling you will ask me why. So, I'll just tell you. Behind the scenes, React is using a virtual DOM. What does it mean? It means that instead of at every change and at every re-render, instead of just doing all the DOM changes, it keeps an internal object representation of our components. If you remember in the beginning, it kept nested objects of something like DOM elements, but they're not DOM elements. They're custom React stuff. So, here is what happens on every update. Every time we call set state or a new object or a new component is rendered. First, React runs our render method to get the new representation. This is probably a good place to tell you that your render method should be pretty fast and shouldn't do extra stuff. Also, it shouldn't have side defects. Ideally, it shouldn't make remote requests and stuff like this, because it will be called many, many times. Then, after React has the new representation, it makes a diff with the previous version of it it has. Let's say we want to hide something. In our render method, we'll just have an F. And in the new representation, some piece will be missing. So, React will be pretty smart. It will do a diff. You can read more about this on this website. I'll publish the slides a little bit later so you don't have to retype URLs. So, React is pretty fast and makes a diff between the two instances. Oh, this one, here are the differences between the both. Then, it computes the minimum set, the minimum number of DOMOPS operations it needs to make to achieve the new state based on the other one. So, for example, if we have removed all of the elements of a list, it may be smart enough to just remove the whole list instead of doing 17 million operations for each element of the list. It can do a lot of smart stuff there. Then, after it computes the set of changes, it batches them and executes them on the DOM. For example, if with one change, we change 17 components. React can go and compute what is the best way to change all of these things at once. If you have done any performance improvements on the front-end app, usually the best piece of advice you get is very rarely touch the DOM and be very careful because it turns out that the DOM and changing it is really slow. And also, as Jack mentioned, these days, browsers are really fast. So, it's actually faster on every change to run the render again, but be very careful with changing the DOM. And this is why I personally let React deal with this because it has proved so much better than me. Now, the virtual DOM actually is useful not only for speed improvements. There are a few more benefits. Number one, because we're not in the browser anymore, we can do server-side rendering. React can render a component into a string. And this way, you can build isomorphic applications. These are applications which run both on the server and on the client, and this can kind of solve your SEO problem. Also, it can make the initial load of an app so much faster because you have it over-rendered, you won't need to wait for the data from the APIs and stuff like this. Also, a virtual DOM opens a lot of other doors, like using SVG instead of an image, and this can be totally transparent. My avatar component can use a canvas to draw moustaches of people. And I may not even know about this. And if I structure my moustache somehow, React may even be smart about rendering them. Also, React can be probably in the future. It may just use web workers to do all of the work in parallel, like all of the rendering. And doing all of this manually is really hard. I know. Everything is great. It's even more beautiful than an Austrian spring. But at some point, our apps start growing. We have all of these beautiful components, but we need something to tie them together. It may be on the roof, it may be somewhere else. But this topic is incredibly new. There have been huge single-page apps only in the past few years, and React is also very new. So even the industry doesn't have a really good idea what is the best approach. To build what is the best approach for having a common place for all the data for all of the components. Because every component can link all of its data request doesn't make sense in the long term. Because if you keep posting one component and one other component changes the same post, it will get really messy. I don't have a lot of insight about this, because we are also still learning about it. Probably the biggest contender right now is called Flux. It was even in the title of this presentation. It is a pattern. It is a pattern also used in Facebook. It is not a framework. It is more of an architectural blueprint. You can learn more on those few links, like the official explanation and blog post. There are a few pretty good posts from the community. So if you are building something bigger, probably not before you actually need it, but it is worth looking at. I won't go into a lot more detail. So if you are at this stage already, just find me after that. I will be more than happy to chat because I am really interested into how to pick a little bit bigger apps on the front end. So a short summary. If you remember two things from this presentation, they would be that React lets you build components and not templates. They are self-contained functionalities which work really well. The other one is that React lets you just magically re-render and just never touch the DOM again. The third one is that the virtual DOM is pretty simple because we don't have to touch the DOM again. It takes it away from us for good. Also, it is really fast and it is fun. Thank you. I have a question for Nicolai. Thanks for the great talk, first of all. There has been a lot of talk about an upcoming standard called Web Components. Do you have something to comment on how Web Components and React could possibly work together? What is the difference that you see there? What do you feel is the future? So, first, just one sentence background. Web Components is a, it's a want-to-be standard which does something similar. It helps you encapsulate all of the functionalities and markup and CSS at once. It has a bit different approach from React in the sense that it doesn't shield you from the DOM, but the general idea is the same. Just the ways are different. And honestly, I don't think that React by itself will live incredibly long, but the ideas will live really long and probably in the end, they'll just converge at some point. But still, there is one big difference. You can use React today in production as many, many companies do, including asset automatic with WordPress.com stuff. Using Web Components in production, even Google doesn't do, and they're driving the project. It needs, it kind of works in Chrome. Actually, in Chrome, it works, Web Components work pretty well. But in other browsers, you need, like, several tons of extra JavaScript, which is just slow. So, if you want to use, if you want to use the same ideas, but today, React is probably a more sensible choice. And the people writing the standard are actively talking with the React people. They're not hating each other. So, probably in the end, there will be something productive out of it. Thank you. Any more questions? Okay. You can find me after that. I'll be more than happy to thank you very much.