– Arpad “Swatinem” Borsos



follow along:

Let us take a walk down memory lane

The dark ages of web development…

Servers (mostly PHP) spat out a bunch of static markup.

At some point jQuery (or earlier alternatives) came along to bring some interactivity to the web.

Query some elements, bind events, change some classes or modify the DOM in other fancy ways.


But that is hard to hand code, and hard to maintain because it has tight coupling to the DOM and server.

Templating came along

Web moved towards “single-page-apps”, rendered completely via javascript.

Things needed to become “declarative”. A template “declares” how your markup should look like.

“The view as function of the state” for you FP fanboys :-)


Early systems just rendered a template *string*, like on the server, and injected it via `.innerHTML`.


Still need to do manual event binding, plus recreating the whole DOM puts a lot of stress on browser. And it messes with browser-internal state like cursor-positions in form fields.

Abstractions and Tradeoffs

Then came along React and brought with it a thing called the “virtual DOM”.

Goal: Touching the DOM is slow, avoid it as much as possible.

So we write a declarative template, *magic happens* and the DOM is updated with minimal changes.

Abstractions and Tradeoffs

This *magic* has a high cost! JS Bundles get larger and larger :-( (<800K at pagestrip, minified, without code-splitting)

What if…?

I talked about this before… Almost a year ago, at ViennaJS

JS does *not* offer zero-cost abstractions


I gave an extended version of that talk again at LinuxWochen; that extended version had the following slide…

what React should have been

// a compiler plugin!
// it kind of is due to jsx, but it does not go far enough!

// transform this:
const FnComponent = props => (

// into something similar to this:
class FnComponent {
    constructor() {
        this.elem = document.createElement('h1');
        this.text = document.createTextNode();
    render(props) { = props.title;
    // …

// not creating / comparing useless js objects all the time
// just updates the data that’s needed

// generate different code for client or SSR *at compile time*!

Life happened

aka I’m a reaaaally lazy fucker


did some experiments around generating code from templates, got distracted, never finished… :-(

But then…

I do stalk a couple of people on GitHub.

One of them is:

Known for the bundler rollup, among other things.

(Solves the problem of way too large js bundles. Check it out!)

What is that…?

Demo Time

Some things I personally dislike…

It should have been more lightweight, focusing on just one thing (rendering to DOM)


Has a custom solution for Component events. (just pass a function as prop and call that maybe?)


Comes with its own state management. (redundant if you use mobx or redux)


Comes with its own CSS solution, may not be what you want if you do js-based styling.

That is it!

Try it for yourself in the repl, experiment, have fun.

Take a look at the GitHub issues, contribute :-)




Introduction to Svelte

By Arpad Borsos

Introduction to Svelte

Some history of js frameworks and how we arrived at svelte.

  • 1,374
Loading comments...

More from Arpad Borsos