 Hi. Can you hear me well? Yeah. Good. Okay. So, as Daniel said, my name is Nikolai. I work for automatic. I have a small website at techshoplay.me, and you can find me as Nikolai beyond Twitter. A lot of you might have already heard, there is a huge bus around the forthcoming REST API in WordPress, and there are many projects using REST API in one way or another, like Calypso or many other people are already building stuff with REST API. And the most common use case for the REST API is building single-page applications. These are JavaScript-based applications running mostly in the browser as a front-end and using something like the REST API as a back-end. So, before we go even deeper, first, why would we even want to use single-page applications? Because they seem like a totally different way of building web apps. They seem a bit different from WordPress itself, and most of the people here have been building things in WordPress. Why do we need to change even something? Well, there are two main reasons, and one of them is that single-page applications can be a lot faster, especially in cases where the user stays on our website a lot longer, because we don't have to reload everything on every single click. It makes them often at least feel so much faster than traditional web applications. And also, just because all of the transitions can be a lot quicker and everything lives in the browser, we have a lot more flexibility. This means that single-page applications can be a lot more engaging, too. Because we can do so much stuff with the user when we're liberated from the constant request to the server. And it was pretty obvious when we launched Calypso, which is the new WordPress.com front-end that it just felt so much, so much faster, and we could do a lot more things on the front-end. If you want, you can just go to WordPress.com and test it out, or not. It's fine. So now that we know why would we want to build a single-page applications, I would just like to take a step back quickly and talk about something else. I would like to talk about change. So if we know one thing about people, is that they hate change. They hate things changing in front of themselves. And also, people are not incredibly good at following changing states as you might see, and as you might have seen on the streets. Just for our nature, it is very hard to follow what is going on. We are much, much better suited for a slower pace of life where things almost do not change. It is just an evolution thing. We very, very much prefer sitting and observing. And actually, change is exactly the difference between classic web applications and single-page web applications. In a classic web app, let's take the WordPress admin. Every time you change something, let's say you want to add a title and you write some content, you make your change, and then you press publish. So every time you make a change, the whole page reloads. We just trash everything we have and we start fresh. Which also historically has been very, very common. Instead of change something, let's do a revolution and change everything. And this is how classic web applications work. And this is actually pretty, pretty convenient. However, in single-page applications, we don't start from scratch at every single request. Instead, we have to just apply a small number of changes to the UI. We have to go for some more data to the server and come back and then change only this small bit that changed. So it very often leads to huge amounts of complexity, just it's mind-blowing and things very, very quickly become a lot more complicated. And this is why, if you have done a little bit more complicated things with jQuery in the browser, it very quickly becomes this huge mess of callbacks, updates to the UI, fetches. And it is just hard because it is our nature to not be able to easily follow and to deal with change. And here comes React. So React comes from Facebook and it is a small UI open source library. React is not a framework unlike Angular or Amber. It is just a UI library. It just deals with the changes in our UI, in our HTML inside the browser. Now we're going to show a little bit of code. It's nothing too complicated, so do not be scared even if you are not an incredibly serious developer. It's so fine. The core part of React are so-called components. And each component is something actually pretty simple. The main thing in the component is a single method called render. Its only goal is to return the markup for this component, the HTML. As you might see, this HTML here doesn't really look a lot like JavaScript. And you'll be right. This is actually something called JSX, which is an extension. Again, it comes from Facebook. And it allows us to write tags instead of some weird function calls and objects. And it makes it so much easier to work with designers and people who just know HTML like all of us probably. Internally, all of this is actually translated to plain and simple JavaScript objects. And then it is executed by the browser. Something really cool about components is that they can be nested. Let's say we have a post component and inside we want to have a post meta. And this is not magic. Post meta is just a variable which leads to another React component. It's nothing more. So our custom components work at the same level as the HTML elements and we can nest and mix them as much as we want. We can also pass our arguments to components which in JSX look like HTML attributes and they're called props. And all of the props can be accessed inside of the component in this dot props. It's pretty simple. Sometimes a component needs to access that data which does not come from the outside, but it sometimes wants to keep its own state. For example, let's say we have the post meta and it can be hidden or it can be shown. So it makes a lot more sense to keep whether it's hidden, not in props, but somewhere deep inside as something called state. And when if we want to change something in our component, let's say we want to have a button which shows and hides the post meta bits. We can use something called this set state. And we can change the internal state. And here comes probably the most interesting bits of React is that we don't need to actually change the UI ourselves. The moment we change the data, React is smart enough to render the HTML itself. So we don't have to do absolutely anything. And this, to be honest, was the main reason we started using React because it makes all of those interactions so much simpler for the developer. I'm sure a lot of you have used jQuery style. UI is where if a button is clicked, when you click a button, you need to check the current state and sometimes show a certain piece, sometimes hide the certain piece. And especially in cases where you have more than one thing to show and hide, it almost always leads to some inconsistencies which are very, very hard to debug. So I showed you the main things about components. I want to go a little bit deeper about why components can be really cool. The first reason you kind of already saw is that components are composable. We can nest them incredibly easy and as deep as we want. We can have a master bar and then inside we have a user greeting. Inside we have an avatar. Inside we have some text. Inside we have some logout link. We don't need any boilerplate. Every component is a first-class citizen and it doesn't matter if it comes from the browser like a paragraph or a span or a div or it comes from one of our colleagues who wrote a logout link component. And exactly for this reason, components make it really easy to see the building blocks of an application. Usually when you are viewed a source of a typical web page, you see a lot of diffs with a lot of classes and you don't always know what those, what exactly do those mean. And with React, it is really easy to see the structure of our applications because again all of the boilerplate is very well hidden behind those components. See, you can have a master bar, then you can have a masthead, then you can have a navigation which can and any one of those can mean whatever you want. It can have as much HTML or JavaScript as you want. And of course inside you can have just plain paragraphs and text. Something incredibly cool is there is a Chrome and I think a Firefox extension, too, which lets you actually explore on a living web page in your browser the React components. Actually, this is from WordPress.com. I think, yeah, this is from Calypso where it's so much easier to see, oh, here is a post component which has the site ID. Here is what kind of posts it is showing. Here is who is the author. It is showing images. And then here is a list of all of the posts inside an infinite list. So if you're a developer, if you want to do an infinite list, you just put everything inside an infinite list component, you just tell it how to fetch new ones and that's about it. And all of those look exactly like HTML. Another great advantage of using components is that since they are very well isolated, they are so much easier to test. And by testing, I mostly mean no automated unit testing or integration testing, whatever. I'm kind of interested in security stuff sometimes. So it is very useful that components really help with React itself. They really help with text assess problems which are by far the most common vulnerability on the web these days. Anytime you pass any data to props or to state and use it inside a JSX, it is automatically basically escaped because React assumes you pass text. Of course, you sometimes want to pass real HTML. Let's say you need some markdown stuff or some HTML is coming from the database and React is pretty flexible and it lets you do this. However, you need to do it like this. You need to pass the actual, the raw HTML as a prop code dangerously set in our HTML. Which will probably remind you that if you really do not know what you're doing, it may be slightly dangerous. So this has been really, really useful. No XSS. Another cool thing about components is that they're not templates. They're not using some underpowered weird templating language. They're using plain JavaScript. We can write loops. We can write if clauses. And it's so just JavaScript. We don't have to learn too much. And a lot of designers these days already know a little bit of JavaScript and PHP anyway. Also, we can use all of our functions or libraries directly there. We don't have to import them in weird ways. Components are also incredibly easily reusable. Let's say we have a comment and in comments we have avatars, right? Let's say we build an avatar component where we pass the email and it builds all of the gravatar stuff. We can incredibly easily reuse exactly the same avatar component somewhere else. Let's say we can have it in the comments. We can have it in the post meta to use the author email. And we don't have to write the whole boilerplate with md5 of the email where we always forget to convert the email to a lower case. And sometimes it doesn't work. Also, let's say we want the avatar to do something special on hover. I guess you've seen those where it shows your, let's say, your gravatar profile or your website profile. So if we were using the same avatar component everywhere else, it would be really easy to just change it in one place and voila, we have this hover functionality everywhere else on the website. Because every component includes both the markup, both the HTML and the JavaScript needed for all of the, usually it is mostly the JavaScript needed for all of the event handlers and sometimes doing some requests or stuff like this. And it's very handy that a component includes both because they're in one place. Except that for many, many years, people have been telling us that we should be keeping our logic and our markup separate, right? And we all know that separation of concerns is good. However, I have a few questions. First, how often do we need an event handler and how often do we use it without the HTML it is attached to? Or how often do we need a DOM element without any of the event handlers? And to be honest, the answer is almost never. So HTML and the display logic are actually the same concern. However, for most people, the problem is that JavaScript and HTML are different technologies. And this is why there is this urge to separate them. But we're not separating technologies here, because HTML and display logic, again, are exactly the same concern. One of them doesn't really mean much without the other. Because why do we care about a button if we don't know what it does? So they're just the same concern and they belong together. And from my experience, this works incredibly well. Okay. I think I showed you a lot on components. However, we haven't mentioned something. We haven't mentioned the elephant in the room. It is the whole re-rendering magic. And it's actually really like magic. You change some data here and your UI updates automatically. We have done this before or we have tried to do something like this with Backbone. And it had few problems. First, everything was moving around because every time we threw away the whole component. But usually, the biggest problem is that most people think it is just incredibly slow. Because on every small change, if we get rid of everything and try it again, to be something like the classic web applications, just doing this very, very often. However, it turns out that in practice, it is very fast. The moment you change something, the UI updates automatically no weird resizing and just very fast. And the reason it is very fast is something called a virtual DOM. So instead of removing everything and recreating the whole component, virtual DOM makes things a lot smarter. So every time we want to make a change, so every component that is affected, first, we call it's render method, which we saw before. And the render method usually doesn't do much. It just returns a bunch of markup. And ideally, a render method will do only this. It will be fast because it is called very often. It will not have any side effects. Render methods do not do requests or stuff like this. Then, render returns, as you saw, a tree of JavaScript objects. Then, React keeps the previous version of this component. And it makes a diff. It calculates the difference between those two trees. And sees, oh, is there any change? And if there isn't any change, it just doesn't do anything. But let's say, oh, they added a new diff tag here. So then, when it has all of the changes, React computes the minimum set of DOM changes it needs to do to take the page from the previous UI state to the next one. To take it from the previous version of the HTML to the next one. And there are some pretty smart algorithms which lets us combine changes, for example. Instead of adding a million li items one by one, it says, oh, I'll just add them together. Also, it batches a few dates which have been done very close to each other. Let's say, first, you click something and it needs to both add a few list items, but also update a counter somewhere up in the header. React will probably wait a bit. And on the next redrawing frame of the browser, it will just do them together. And it makes it so much faster. The virtual DOM, however, is not only useful for faster speed. Because we are not dealing with the browser DOM anymore and we have our own structure, we can do a lot of really, really cool things. For example, we can just render these pages on the server. We are actually experimenting with this in Galypso for some logged out pages. And it can be really fast because, first, you render the page on the server, you serve it to the client and then React picks up all of the changes. So you don't have this massive amount of waiting on the first load. We can also use this virtual DOM to render things not only in HTML, but in SVG, VML, we can use a canvas. If we want to build an avatar component, if we want to add a moustache props or a moustache option, we can very easily do it still within the virtual DOM but use a canvas. And it can still look like a normal HTML component. Also, we can run things in a web worker. This is a new thing in browsers where it can run things in parallel. So we can just render something or we can run the different algorithms which are sometimes complicated. We can just run them in a web worker. I told you a lot about components, but probably my favorite and last thing I promise is that they're very declarative. Instead of telling it what to do, we just say here is the HTML we expect. It's like imagine instead of following a recipe or instead of reading a recipe and following it, imagine that you can just lay out all of the ingredients on the table, then you show somebody the end result, and magic, you get the cupcakes. And React is actually something similar. You just explain here is the HTML I want. And it depends on some state. And every time the state changes, React makes sure we get exactly what we asked for. And as an added benefit, this is the final version of the HTML. There is no chance that some jQuery bit in the far corner of our application will change our prop, will change our HTML in an unexpected way. This makes it really declarative, very easy to read and very predictable. Of course, it's no all great because React is just a UI layer. It doesn't have unlike Angular or Ember. It doesn't have a router or a state or things like this. It's just not a framework. But there is a huge community around it. You may want to try something like Redux, which gives you state. You may want to try React router, which gives you a router, and they're pretty cool. Also on Ahead.io, there are some really great tutorials, video, very often by the authors of those tools. And of course, React probably requires a little bit more of architectural thought, which you may or you may not want. But the general principle is often more interesting than the tool itself. I wouldn't be surprised if something like React is like a browser's work in a few years. We have been using it really extensively at Automatic for our Calypso project. And it's all open source, so you can go check it out. And if this is interesting to you, just find me after that and we can chat about it. Just a few more seconds, final summary. If you want to remember just a few small things. First, we use components. We don't use templates and they have all of the JavaScript together with them. Instead of rendering and changing things ourselves, we let React render stuff. And the virtual DOM is simple, fast, and really fun. One last thing. It would be great if you can come tomorrow at the contributor day. First, we can have more time to chat about things like this. And in my experience contributor days have been enormous amount of fun and everybody learns something. And I heard have you ever had a contributor day before? Yeah. So you can make history and be part of the first real contributor day in Finland. And this was everything for me. Thank you. Thank you. Thank you, Nikolai. Any questions for Nikolai? Any questions about React? One in front. Thank you. Hello. Thank you. Just had a question on React and the WordPress admin. Do you think that will happen? Why and when, if that case? There aren't any plans. But probably the way WordPress works is that very often plugins lead the way. And I know of a few plugins who are working on a React-based admin interfaces. So we'll see first how it goes, what are the challenges. Is it even worth it? Because Calypso is pretty cool, but it's different from WP admin. Also, Calypso itself is in its earlier stages. It's probably not as mature as WP admin. For example, it doesn't have plugin support. So there is a lot more thought to be put in what a new version of WP admin might look like. And also, we don't really need to do this. Like, it's perfectly fine if we have alternate backends or alternate interfaces for very specific needs. And still keep all of the plugins working. But in short, I don't know, we'll see. I guess that's one of the biggest challenges with the REST API. Like, keeping that low barrier of entry with plugins, but then also having that sort of the, well, building advanced QIs with React. Yes. Yeah. I'm sure we'll see a lot more projects using the REST API and some JavaScript frontends. And I'm sure there will be a lot of projects which will make it easier. Because now, especially for many developers, it's something totally new. And it's a new language. It's a new paradigm as you saw, the whole change thing. So it will take some time first to make sure this is the right thing for the community and for people to get great at it. Okay. More questions? Over there. Okay. Just a few seconds. I can see one there. There's one over there. Okay. Okay. What kind of challenges have you faced with styling the React components? Do you favor inline CSS or style siege or at least that's something I'm struggling with? With styling. Yeah, with our styling. Well, so the biggest problem with styling and components, and especially with reusing components is that very often styles leak because of scading. And the way we have solved this problem is that we almost do not use scading. We use something called what was called BEM, I think, where each class is prefixed with a component name. So basically each CSS class is limited inside the component. And for Calypso, for example, we're using SAS, which makes it a lot easier to import some global styles when you need them. The other thing that helped us scale this is that we keep the styles right next to each component so that both markup JavaScript and CSS live together. And to be honest, it has been working really, really well. Designers are really happy and CSS is much better structured this way. So today, I would probably do something like this not only in a single page application, but in whatever application. To rely less on scading and on reusing styles. Did this answer your question? There was a question near the bottom? Yeah. How is the browser support in React these days? And what kind of problems is there with the browser support? So browser support, I'm pretty sure React works on i7. I'm not sure about 6, but I really hope nobody cares about it anymore. To be honest, we do not support like with Calypso, we do not support i7 and 8 anymore, I think. But I'm pretty sure React works on i8, at least. Any questions upstairs? No? Okay, downstairs? You mentioned the Calypso, so you meant the WordPress.com interface or the software build on that. Were you involved in that project and what was the main difficulties in that? I was a little bit involved in the Calypso project, not too much. Probably the biggest challenge was dealing with state. And the components itself were pretty self-contained from the beginning, but making sure the right data comes to them and how and every time the data changes to render the components. And in the past two years, we have gone through two or three different approaches, which you can all see in the current code base. And in general, probably the biggest challenge was gaining a deeper understanding of how all of those technologies work and making sure we make the right design decisions. Which probably wouldn't have happened with something like Angular or Ember. However, this way, we have been a lot more flexible and we have a lot more control over what is going on. Also, it took Angular and Ember a long time to catch up with this way of working. Only in their most recent versions, they have this automatic re-rendering thing. And we used this style starting more than two years ago. It has been incredibly helpful in the developer experience. So this is the trade-off. We had to learn more. We had to change some approaches, but we had more control to always use the best approach. Okay, one more question. Come on. Don, be shy. I have a question if there's no other question. Have you experimented with using React on the server side by delivering the first payload? Yes. It's still not in production, I think, but you can find a few poor requests on the React repository. Sorry, on the Calypso repository. We have a few logged out pages, and it's important for SEO stuff. It's the new scene browser for WordPress.com. And it's almost done. It requires a little bit of free architecting of some bits, but it works. And it's also pretty, pretty fast. Because you get all of the HTML, and then React is smart enough to just continue and pass in this HTML some IDs and stuff. And then it can totally transparently for the developer. It hooks to the right places, and it continues from this point, and as if it was rendered in the browser. Cool. Okay, thank you very much, Nikolai. Let's give him a round of applause.