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.
Hey everyone, Svelte creator here. Thanks /u/archivedsofa for posting the video.
If anyone is curious about the framework, we have a friendly Discord chatroom where the Svelte community hangs out — please drop by and say hello!
tl;dw?
Maybe /u/rich_harris may like to comment
How does this compare to Stencil?
https://stenciljs.com/
Technical difficulties aside, definitely going to check out svelte!
This is really cool. Can anyone explain, though, what the drawbacks of an approach like this would he compared to using React? Community support maybe?
Despite the rocky demo this was an excellent talk. Well done Richard! I’m looking forward to looking into svelte
I just finished Origin by Dan Brown and if he calls it Winston when I watch this...
EDIT after watched - that was svelte!! - pretty cool - thanks.
Interesting, starred on GitHub! I think you should point out the advantages of the small bundle size more than pointing out JS evaluation performance. The network will always be the bigger bottleneck. And if you're targeting users in the US, most of their phones are pretty damn fast at evaluating JS.