DEV Community: Tom Jackson

Why SvelteScript Is a Good Thing For The Future of The Web

Tom Jackson — Sat, 02 Jul 2022 16:31:00 +0000

Evan You, the creator of Vue, made this observation about Svelte's labelled statements.

// Detect dark theme var iframe = document.getElementById('tweet-1057291776724271104-940'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1057291776724271104&theme=dark" }

The idea here being that moving beyond the constraints of JavaScript, via the Svelte compiler, makes Svelte its own language. Evan isn't wrong and Svelte themselves aren't shy about admitting that this is the case.

Typically, the front-end community hasn't responded well to frameworks or languages that treat the Web as a compile target or try to replace it's core languages: HTML, CSS and JavaScript. Dart is a great example of this. Languages that seek to replace those core languages often have the following problems:

They increases the risk of adoption because we are now writing a language that isn't as ubiquitous and as universally supported as JavaScript
They potentially exclude the use of existing JavaScript tooling or impose some complex boiler plate to get that tooling.
They increase the distance between the code that runs in the browser and what we actually write

However, Svelte doesn't completely discard the languages of the Web like Dart does - it extends them. It also does this in a way that safeguards against most of the risks outlined and allows Svelte to deliver great features like the aforementioned labelled statement

Rich Harris, unsurprisingly, does a better job of explaining how Svelte extends the core languages of the Web here and we can summarise this by paraphrasing the following three points:

It extends HTML by adding JavaScript expressions in markup, directives for controlling behaviour and reacting to input, syntax for using conditions, loops and asynchronous values
It extends CSS by adding a scoping mechanism that keeps styles from clobbering each other
It extends JavaScript by making reactivity a language primitive

As a community, we've become accustomed to the first two but the third is still a controversial topic because of those criticisms outlined above. It's important though, not to ignore the developments made in the 2010s to JavaScript frameworks.

React Isn't Just JavaScript Anymore

The community can largely agree that building modern complex apps with vanilla JavaScript isn't a great idea. I for one am glad that I no longer write code like this:

const btn = document.createElement('button'), 
      btnText = document.createTextNode('increment'), 
      counterDisplay = document.createElement('div'); 

let counter = 0; 

btn.appendChild(btnText);
counterDisplay.innerHTML = counter;  
window.document.body.appendChild(btn);
window.document.body.appendChild(counterDisplay);

btn.addEventListener('click', ()=>{
  counter ++; 
  counterDisplay.innerHTML = counter;
})

Doing the same thing with any modern framework is hugely different and that is a good thing. Take React for example:

import React, { useState } from 'react';

function Example() {
  // Declare a new state variable, which we'll call "count"
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

There is no denying that this code is a huge departure from the vanilla JavaScript example. The community has already shifted away from writing just JavaScript, because JavaScript isn't sufficient to write complex UIs. All frameworks play fast and loose with JavaScript in some way. React has hooks, Vue has getter setters and Svelte has labelled statements. Everyone is bending the rules of JavaScript to get reactive behaviour.

Svelte is different though, because it's a compiler, it can do things that by definition are not possible with ECMA-262 like changing the semantics of existing unused syntax. This is the source of Svelte's biggest criticisms but also its greatest advantage over frameworks that do adhere to ECMA-262.

How Does Svelte Address These Criticisms?

Svelte is very targeted about where it departs from Web standards and only does so if there are some real gains to be made. Like in the case of labelled statements and stores. These deviations are localised to individual Svelte modules to further mitigate the risk of adoption. There's no demand for complex boiler plate to interop with JavaScript. Svelte has carefully extended Javascript in such a way that it can still make use of the existing tooling and continue its development without departing significantly from existing Web technologies.

There is one criticism that remains valid though, and it's highlighted very well in this talk by Kyle Simpson. By treating the Web as a compile target, we unavoidably increase the distance between the code in our IDE and what is actually running. We make it harder for anyone looking at our source code to actually work out what's going on. This isn't just a problem for Svelte though, realistically this is a sacrifice we make with all front-end frameworks.

I find it quite telling that the descriptions for React Dev Tools and Svelte Dev Tools are almost exactly the same. They are both tools for inspecting the component hierarchies in the browser. They are both trying to take the muddled, hard to understand, imperative code you'll see when you view page source and brings it closer to the declarative code we write in our IDEs.

Svelte, being a compiler, has come under more criticism than it's competitors in this area but that doesn't follow. Yes, the code we serve the browser is very distant to what we are actually writing but that is as true of React as it is of Svelte.

To summarise, Svelte, like all front-end frameworks, does increase the distance between the code we write and the code we serve to the browser. However, because the deviations from JavaScript are targeted and carefully implemented, Svelte doesn't discard the years of accumulated knowledge and tooling the Web's community has gained.

So What Are The Advantages of SvelteScript?

The core advantage of Svelte being a language is that it allows developers to write code like this:

<script>
    let count = 0;

    function handleClick() {
        count += 1;
    }
</script>

<button on:click={handleClick}>
    Clicked {count} {count === 1 ? 'time' : 'times'}
</button>

The difference between this and the earlier JavaScript example is huge. Svelte fundamentally changes how accessible your code is, how easy it is to maintain, and how easy it is to reason about.

This is a huge advantage, but the freedom departing from JavaScript allows the Svelte team is its greatest asset.

It's time to face facts, JavaScript needs help to continue being the language of the Web. Increasingly, there are things we as developers want to do on the Web that aren't possible with just JavaScript. The widespread adoption of Typescript has taught us that languages that compile to JavaScript and target the Web platform can solve these issues.

Compilers inherently have an edge over frameworks that operate strictly within ECMA-262 because they allow the teams developing them more freedom to add the features we as developers need to build modern apps.

Svelte is uniquely positioned to shape the future of the Web precisely because it is a language, not a framework. The JavaScript community isn't just developers who work on the Web and changes that make sense for the Web platform don't always make sense for JavaScript. We, as a community, need to be able to adapt the core languages of the Web without being constrained by the larger community and we need to be able to make those adaptations without discarding the significant progress JavaScript has made over the last 27 years.

Does Your JS Spark Joy? Svelte and the Future of the Web

Tom Jackson — Thu, 02 Jun 2022 14:01:32 +0000

At You Gotta Love Frontend 2019 Rich Harris posed a simple question to the audience:

Does your JS spark joy?

The idea here was to demonstrate that writing less code is the only true way to improve performance by a meaningful margin.

I think we can take the question a step further though. In fact, applying the laser focussed minimalism of Marie Kondo to your code base is a neat way of summarising the core benefits of Svelte and gives you a good idea of how it's changing the web.

So, I'm going to begin and summarise this article by posing two questions to you.

However, before we begin, I think it's important to give a brief overview of the framework and its crucial differences from other component-based frameworks like React.

So what is Svelte?

Svelte is a compiler that does the job of a component-based framework. It takes your .svelte files and converts them into HTML, CSS and JS. Effectively moving the complexity of the framework to the build step so the runtime is smooth.

By comparison, traditional frameworks like React famously have expensive runtimes.

With Svelte your browser gets what it was built to run immediately; HTML, CSS and JS.

At this point, you might be asking how we achieve reactive state-driven apps this way. This is a valid question, but Svelte has a good answer. Unlike React with Svelte, you're not reliant on the Virtual DOM and expensive DOM diffing to manage and update your application's state. With Svelte the DOM tree is manipulated directly when state changes and, through some clever quirks of the compiler, this is achieved very efficiently by a single bundled JS file.

So, the TLDR is: Svelte leverages the familiar concept of moving our framework's runtime away from the client by compiling your declarative component-based code to imperative instructions the browser understands at build time.

All right, let's move on to those questions! Ultimately, as front-end developers, I think we should ask ourselves two questions.

Does our JS spark joy in us as developers?

Does our JS spark joy in our users?

If the answer to either of those questions is no, like Marie Kondo, we should thank it, then discard it.

Section 1

Does your JS spark joy in you as a developer?

Does it allow you to write simple maintainable declarative code?

Traditional component-based frameworks were created so you, the developer, could write neat understandable declarative code and avoid the hefty imperative implementation that's required to get the browser to actually do what you want.

With React, the trade-off for having this nice dev experience is an expensive runtime on the client.

However, with Svelte, because it's a compiler, the bundle size of Svelte itself isn't important - it's the output of that compiler that is actually being run. This has freed up the Svelte team to develop a remarkable developer experience.

Here are some of my favorite code examples that highlight Svelte's great developer experience.

Svelte's skinny syntax

React was a huge step forward, abstracting the imperative JS that actually manipulates the DOM into a much simpler format, but React also introduces a lot of boilerplate to hide that complexity behind its hooks.

Here's how you'd implement a simple form in React:

import React, { useState } from 'react';

export default () => {
    const [a, setA] = useState(1);
    const [b, setB] = useState(2);

    function handleChangeA(event) {
        setA(+event.target.value);
    }

    function handleChangeB(event) {
        setB(+event.target.value);
    }

    return (
        <div>
            <input type="number" value={a} onChange={handleChangeA}/>
            <input type="number" value={b} onChange={handleChangeB}/>

            <p>{a} + {b} = {a + b}</p>
        </div>
    );
};

Here's the equivalent code in Svelte:

<script>
    let a = 1;
    let b = 2;
</script>

<input type="number" bind:value={a}>
<input type="number" bind:value={b}>

<p>{a} + {b} = {a + b}</p>

Svelte removes so much of that boilerplate leaving us with more readable maintainable code that is much more accessible to non-technical colleagues.

Svelte provides a better CSS experience

The basis of modern front-end frameworks is JS. When you write in React you are primarily working with JS but your browser serves HTML. This results in a subpar CSS experience for the React dev.

We all want CSS files that are scoped to our components and many of us want the HTML, CSS and JS that drive our component to live in one file. There are many solutions for achieving this with React but the downside of all of them is that they rely on installing extra dependencies and learning extra syntax to get this behavior.

With Svelte, because .svelte files are a superset of HTML we can simply include all of our HTML, CSS and JS in one file and the Svelte compiler will add unique hashes to our CSS classes to ensure they are scoped to their components. Here's what that looks like:

<script>
    alert('Hello world!')
</script>

<style>
    h1{
        color: red;
    }
</style>

<h1>Hello world!</h1>

If you want to add global CSS, don't worry Svelte has you covered with the :global(...) modifier:

<style>
    :global(body) {
        /* this will apply to <body> */
        margin: 0;
    }

    div :global(strong) {
        /* this will apply to all <strong> elements, in any
             component, that are inside <div> elements belonging
             to this component */
        color: goldenrod;
    }

    p:global(.red) {
        /* this will apply to all <p> elements belonging to this 
             component with a class of red, even if class="red" does
             not initially appear in the markup, and is instead 
             added at runtime. This is useful when the class 
             of the element is dynamically applied, for instance 
             when updating the element's classList property directly. */
    }
</style>

Svelte is truly reactive

For your program to be reactive, the dynamic variables within it have to be defined when you declare them.

The front-end community has been striving for an efficient way to write reactive code for a long time now and the solution we've settled on is the virtual DOM.

The virtual DOM is essentially a lightweight snapshot of your app's DOM structure. In React, every time your state changes that snapshot is compared to the previous one, and the real DOM is only changed where they differ.

This is a huge progression from previous frameworks that would rewrite large portions of the DOM tree just to make small changes. There is a 'but' here though. If we know ahead of runtime which variables depend on one another, we can change only what is necessary when our state changes without any comparisons. This is what Svelte does, the virtual DOM isn't fast it's merely faster than rewriting the whole tree. Direct DOM manipulation, if it is precise, has always been faster than the virtual DOM approach.

Svelte allows us to be explicit about which variables are dependent on one another. It allows us to create an app that knows which variables to update, the order to update them and is faster at updating them than it's competitors.

In order to understand how Svelte gets this behavior let's look at some examples lifted from Paul Stovel via Rich Harris.

var a = 10;
var b = a + 1;
a = 11;
b = a + 1;

Here we can see that getting b to depend on a is clunky to say the least. It requires that any time we change a we also have to reassign b. As a solution to this problem, Paul Stovel proposed the theoretical destiny operator:


var a = 10;
var b <= a + 1;
a = 20;

In this example, the <= binds the value of b to a. Unfortunately, this syntax doesn't exist in JS but, Svelte, being a compiler, is less constrained by the limitations of JS than other frameworks.

Svelte has leveraged this, to convert the labeled statement, a fairly unused piece of syntax, into the theoretical destiny operator.

let a = 10;
$: b = a * 2;

It's that simple - b is now bound to the value of a. Whenever a changes b will update. All the boilerplate React demands you write to get the equivalent behavior is gone. Yes, obviously there is still a lot of complexity hidden by the compiler but it's not forcing that boilerplate on you. What the client runs is efficient vanilla JS that directly manipulates only those parts of the DOM you have explicitly declared will change when your state does.

Essentially, because Svelte is a compiler, it has been able to drastically improve upon the front-end dev experience and this isn't just my opinion - Svelte was voted most loved Framework in the Stack Overflow 2021 developer survey.

Section 2

Does your JS spark joy in your users?

Does it help you deliver performant apps with great UX without compromising your developer experience?

The obvious benefit of Svelte being a compiler is that the bundle size the browser is served is significantly smaller. Svelte, according to this article, is 10 times smaller than React and ReactDOM when zipped. Not only is Svelte a lot easier for the browser to run, but once it's up and running it's faster too because it doesn't rely on virtual DOM diffing. That all translates to faster load times for your user and an app that is interactive more quickly.

Last year's Google page experience update taught us that performance is the new SEO. It signaled the beginning of a new trend where UX is the most important factor in your app's search ranking. This major overhaul coupled with the increased traffic from low-performance devices has created an environment where Svelte really shines. Svelte, unlike React and Vue, can still offer great performance on low-performance devices like smart watches, payment terminals and smart TVs.

As developers, we have become obsessed with shipping one solution that works across all devices. We've ditched closely coupled legacy CMSs for shiny, headless offerings that can drive our content on all devices.

Why not take the same attitude with our front-end framework? React and Vue simply aren't options that will result in a responsive UX on a payment terminal. In this environment, Svelte is the only framework that is efficient enough, ultimately allowing you as a developer to work on a single tech stack that serves the range of devices that access the internet in 2022.

This brings us full circle, back to the original point Rich Harris was making at You Gotta Love Front End 2019. The only true way to increase the performance of our apps is to reduce their size. The only true way to give our users an excellent experience is to reduce the amount of JavaScript we are serving their device. Our two goals of having happy users and happy developers are both served by reducing the amount of code we write and ship.

Thank it, then discard it

Svelte means slender or elegant and the name is apt. The core benefits of Svelte all stem from the fact that it is a compiler and that that compilers output is, well, svelte. This allows us to do away with expensive run times in the browser, removes the constraints of needing our code to be read by the browser and it achieves all this without compromising on the developer experience.

The mantra of the first major JS framework JQuery was:

Write less, do more

Svelte, like JQuery in the Noughties is empowering developers to write more efficient minimal code that is accessible to more devices, users and developers. So, if your JS doesn't spark joy - thank it, then discard it.