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

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.