Computer, build me an app

0 0

Many moons ago, the wisest of the JavaScript elders came down from the mountain and said, I have created J query. And the villagers said, JQuery? The actor from zombie. And he said, no, it is not a man, it is magic. We will tame the browser gods. And the villagers were the browser gods were capricious and had misery on the lands. And re-plowed the fields, and at the time of the next harvest, they tasted sweet and AJAXy. And there were conferences and that was the end of the first JavaScript era. The tide came and went. The moon rose and fell. Years passed. And while JQuery was still a dominant religion, some were fearful it was not powerful enough for the elaborate designs of the modern age. And one came from Zuckerbergia and said, you're all doing it wrong. These primitive incantations do not befit our modern age of science and technology. Look at the wretched structures, I fear for my safety. In Zuckerbergia we make not mud huts, but magnificent towers not with magic, but with machines. Come, let me show you. And the villagers looked upon the machines and they liked not what they saw. The traveler was cast out as a heretic. And yet some followed these machines and helped to meet their ambitions. And the heretics, and the heresy became the new thing and that was the second era of JavaScript. And I'm here to talk about the third era. I'm Rich Harris from the "New York Times," and this is called computer, build me an app. You probably think I'm going to talk about using the platform. Web performance advocates are saying we should use the platform, it's interpreted as don't use React. And there's been this rather contentious debate between the two sides. And the trouble is, they're both kind of right. They're talking past each other. It can simultaneously be true that abusing frameworks leads to a degraded user experience, and the DOM APIs are hot garbage. I wanted to find a solution to the problem. In New York, you can attend Brooklyn JS and the other meetups. And it stands for Jed Schmidt, the co founder of the meetup. He's a brilliant programmer and an all around good guy. And he was explaining his vision of a next generation user and space framework. And he said something along these lines. The directed graphs, but the run time is to DOM. Writing an app should just be writing a graph and the compiler would figure out where the bipoles are and render the code to make sure that relationship stays consistent across states. I don't have a computer science background. And to be honest, I was in at the time, it was gibberish. One word stuck in my head, compiler. And it led to an epiphany. Frameworks are not tools for the code, they exist in your mind. They help write better code, but they can help you structure your thoughts and express them. What if the framework didn't run in the browser at all? What if it was a compiler. We need to understand how frame works work. Before I go on, there's something I need to make totally clear. I'm going to criticize React. And I need you all to know it comes from a place of love. It's a wonderful tool. It's like JQuery, Backbone and others that haven't just made life easier for people who use the tools, they changed the way the entire community thinks about solving the problem. But there's a tendency towards group think. And that React is the pinnacle and there's no further progress to be made. It looks like the maximum. This talk is talking about exploring this new one known territory. Now, the best thing that React did for the frontend community was to popularize the idea of state driven user interface. That was usually event driven. When the browser sees something happen, do these things. In the state driven world, you instead say this is how I want the user to see this is what I want the user to see for a given state. And you tell that to the framework and the framework communicates with the browser on your behalf. This is a very director and performant way of updating the DOM. But as you know from personal experience, it doesn't scale. Becomes too complex too quickly whereas this scales beautifully. The way that it does that, the paradigm today is the virtual DOM. Whenever your state changes, you reinvent your entire application and say, here you are, this is what the user should see. They compose the virtual DOM with the real DOM and figure out what it needs to bring the DOM up to date. And you hear people say that the virtual DOM is faster than the real DOM, which is complete bullocks. It is easier for the browser to go from the first step to the last step. Virtual DOM is pure overhead. We tolerate is because of the programming model that it enables. And could we achieve that without that in the middle? If so, the apps get leaner and faster. In other words, they would become svelte. Svelte is a real world. The Cambridge dictionary says it's attractively thin, stylish. Merriam Webster, suave, and urban dictionary, anything cool, hip or generally awesome. That was from 2005. I have no idea if kids are still saying that. Nevertheless, I will take it. Svelte works, and the compiler turns it into an AST. And this is svelte generated. That gives you a JavaScript class like any other that you can import into the application, give it something a render to and a tree of data and it does its thing. We now proceed to the live coding portion of the talk. So, I'm just writing bear with me. The demo gods are not on my side. Well, this is annoying. [ Laughter ] I have a big problem on my screen. Okay. Maybe. Yeah. I don't think so. >> Okay. [ Applause ] RICH: Okay. So, I've replaced the hard coded data with a variable. And if we have the DevTools, then we can manipulate the data using the component API. Like so. And we can put any JavaScript expression in these in these tags. So, we can do things like that. And the nice thing about using HTML is that you know what? I'm going to try to just do it all on this screen instead. Okay. So, a really important thing to know is this CSS is being inserted into the context of the component's markup. It's able to encapsulate it. It's added this computer generated class to the element and it's doing the same thing to the CSS class name down here. And you'll notice because it is generating a source map, we're able to see exactly where those styles came from. When you're building a big, complex app, it's incredibly useful to see where the CSS came from. That's often overlooked and it's a huge productivity win. And by analyzing the CSS markup, we can detect a new style sorry, I've just got to get back to the same place. Oh, my god, this is not on my way. I'm going to skip ahead to the next slide. We can add if any listeners in line on our elements. It might be. I don't know. Okay. I think I might skip some of the next parts of this because it's starting to get a little bit embarrassing. But we can what I wanted to show you is that we can start to do some nice, slick user interface things. Like some really effective custom transitions. What we're doing here is defining some CSS that's generated for a given moment when your component when your element is being transitioned into the DOM. And normally with animations and transitions, it's in a request animation callback. And that's less than ideal, it's a jank. And turns it into behind the scenes and they are more performant and kinder on your friends' battery. And we can get them to talk to each other in a sense. This is an application where we have some to dos that haven't been done and others that have been done. And if I click on the labels, it moves from one side to the other. Which is fine, but the human brain doesn't like that. It doesn't like it when objects disappear and reappear. It likes it when objects remain a sense of constancy. And we have helper transitions with this function, cross fade. And if I add those to my component. I this was fine an hour ago. [ Laughter ] Tell you what? I will Tweet out the slides as they are supposed to appear. Let's move on. And so, an important shift has happened here. In a very real sense, you're not writing the code behind your app. You are writing some instructions. And the browser, the compiler is generating the code for you. And this is because a lot of the code and I want [audio breaking up on Skype] the compiler. And it is why not use JSS? And I'm going to get, again, at this conference, and answer that. So, it still uses a language called HTML X, it's a super script of JavaScript. This is a nightmare for a compiler. In JSX, it's an element, component, text, an array of fragments containing all three. And the compiler can't do anything with that. It needs to know what the value of that expression is going to be. Which is why we need the virtual DOM machinery. Now, having said that, the Facebook team are working hard on this problem and just yesterday Dominik Galloway successfully completed a little experiment to get React server-side rendering in a similar compiled format. And React SSR is now as fast as svelte. And even though client side is a much were much harder problem, this is something you should be very excited about if you're a React user. Nevertheless, I prefer to use HTML based languages when I'm describing user interfaces because HTML is the language of the web. I don't need to worry about all of these others that JSS presents. And I also feel that using an HTML based language is more inclusive to the large number of developers who are simply more proficient with HTML and CSS than JavaScript. Now, am I the only person that's reached the conclusion that compilers are the next frameworks. This is a project for web components. Glimmer is an engine that compiles to a format. There's a framework from eBay that delivers really good performance with compiler techniques. And Angular is working on a next generation renderer called Ivy. These are fantastic frameworks and you should check them out. A question I get very often is, surely if your components are being converted into vanilla JavaScript, it's bulkier than just instructions to a framework. Efferently you reach an inflection point where you would have gotten a smaller app by using the framework in the first place. That differs from framework to framework but holds true. Svelte components have a low incremental cost because the compiler can reuse a lot of code. Secondly, in practice, by the time you get to that point, you should be using code splitting. And you just don't reach that inflection point. Code splitting is a technique that allows the browser to lazily load assets as they're needed. With a traditional framework, the smallest chunk is at least as large as the framework and the other dependencies that you're using and svelte doesn't have that problem. As it happens, we can solve this problem. Conduit is an application that is part of the real-world project which is an endeavor to get different frameworks to build the same app to see how they compare at a real use case. It's basically a medium frame. And according to a recent article, it just svelte is down here in the middle next to Apron and 2. This is the initial payload size. This is the React implementation. It's not entirely fair, this isn't using code splitting and svelte is. But adding all the JavaScript assets, svelte is about 40% of the size of the React one. It definitely does scale. And we can see the effect in the startup metrics. This is 3 seconds, time to first meaningful paint, and the other version is about a second and a half. There's another important metric, which is lines of code. Svelte has about half the number of lines of code that the React version does. And that's not an aberration. That's something that we see all the time. Because it turns out that you can express UI concepts much more cleanly and succinctly if you're using a language that's designed for that task. A few lines of code is good. You can write the lines quicker, but the app is more maintainable. Fewer bugs. Svelte is reasonably flexible and powerful, but you need something more if you're going to build ambition apps. And in the React world, we have a project called Next. The idea is each page is a comment. And you get the server and client rendered versions, so the navigation is instantaneous. And could we take the same svelte philosophy of compilers and apply it to that problem? Yes, we can. Where has my mouse gone? So, I'm going to create a new sample project. Short for svelte app maker. Here's one I made earlier so we don't need to wait for dependencies to install. And if I build my app, then this is the basic start to template. And you can see as before, we've got the client-side rendering, nice and slick. It's very fast. But if we look at the actual workup that you get from the server, it's server rendered. You get that fast initial load. If I were to build this, then we can have a look at production stats for this. And you can see that it's less than 7 kilobytes. You can't see. It's quite small. Less than 7 kilobytes of JavaScript. Which is more than necessary, but it's a good start. For reference, if we look at the same app built using Next, then it's well over 200 kilobytes. Which is frankly too much for an app that doesn't yet do a great deal. I have some numbers on the server side rendering performance. So, I don't want to get too high up in the performance stuff. I want to promote the idea that we should be comparing frameworks along interesting dimension. Such as does this frame work help me build a more accessible web? Svelte will warn you if you build if you use things that aren't accessible. Does it help us build slick user interfaces? Does it help us write fewer lines of code? And can we write tools that are more sophisticated than stuff that's based on the command line. I have been inspired by these two projects. In the remaining 60 seconds, I'm going to try to show you what I have been working on. This is a graphical user interface for building apps. And you can do some pretty cool stuff if you have tools that are deeply integrated with the frameworks that they serve. I can open and I can go straight to the page that I'm currently on. If I want to look at a particular element and edit that, then I can click the cross hairs. But go straight to the source code to go ahead and edit it. I have been building apps like this for a short while and it's transformed how quickly I'm able to build stuff. In summary, the first era, homesteaders tended to code bases my hand. And the second era was the industrial age when we started to use machines for everything and people wrote a little bit about the pollution. But we can't deny that it have a transformative effect on productivity. The third age is the information age. Machines are becoming intelligent. How can computers, helpers, fulfill our potential as creative professionals? I think this is some largely unexplored territory. Doesn't just apply to user interface. It also applies to tools and everything else that we work on. So, I hope that you will come and explore it with me. And with that, thank you.