• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Künstliche Intelligenz
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung/Architektur
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Manuel Ernst 22. April 2025

Neuerungen in Svelte 5 – Einführung von Runen

Svelte 5: Zustands-Aktualisierungen sind auf Zuweisungen beschränkt

Der Svelte Compiler der Version 4 orientiert sich an Zuweisungen an Zustandsvariablen, um eine Zustands-Aktualisierung zu identifizieren. In vielen Fällen funktioniert das auch gut, arbeitet man aber zum Beispiel mit Arrays, ist man gezwungen, zu Workarounds zu greifen: Üblicherweise würde man ein Element über den Aufruf von array.push(...) hinzufügen. Da dies jedoch keine Zuweisung impliziert, die der Compiler versteht, muss man stattdessen eine Kopie der existierenden Liste erzeugen und der State Variable neu zuweisen [1]:

<script>
  let myList = []

  function addToListInvalid() {
    // die zuweisung funktioniert zwar, die Aenderung
    // wird aber nicht im DOM wiedergespiegelt weil sich der compiler
    // nur an zuweisungen orientiert
    myList.push("added invalid")
  }

  function addToListValid() {
    // weil `myList` einen neuer Wert zugewiesen wird erkennt der Compiler
    // die Aenderung und veranlasst ein DOM update.
    myList = [...myList, "added valid"]
  }
</script>

<button on:click={addToListInvalid}>add Invalid</button>
<button on:click={addToListValid}>add Valid</button>

<ul>
  {#each myList as entry}
    <li>{entry}</li>
  {/each}
</ul>

Tatsächlich wird "added invalid" korrekterweise der Liste zugewiesen, ein Rerender wird aber nicht veranlasst.

In Svelte 5 möchte man dagegen erreichen, dass gewohnte und bekannte Sprachmittel eingesetzt werden können, ohne auf framework-spezifische Eigenheiten Rücksicht nehmen zu müssen.

Zustandsverwaltung in Svelte 4 und Vereinheitlichung in Svelte 5: Reaktivitäts-Paradigmen ausschließlich auf Komponenten-Ebene

Die verschiedenen Sprachmittel, die in Svelte 4 zur Definition von reaktiven Elementen zur Verfügung stehen, sind grundsätzlich nur auf der untersten Ebene einer Komponente verfügbar. Das folgende Beispiel lehnt sich an den bereits bekannten Click-Button an [2]:

<script>
  let clickCount = 0 
  $: doubledClickCount = clickCount * 2
</script>

<button on:click={() => clickCount++}>
  clickcount {clickCount} \ {doubledClickCount}
</button>

Die Logik, die in dieser Click-Button-Komponente implementiert ist, soll nun herausgelöst und in eine Form gebracht werden, so dass sie in anderen Komponenten wiederverwendet werden kann. Wir nehmen also die Building Blocks, verfrachten sie in eine separate Funktion und rufen diese einfach auf [3]:

<script>
  function createCounter() {
    let clickCount = 0 
    $: doubledClickCount = clickCount * 2
    
    return { clickCount, doubledClick }
  }

  let { clickCount, doubledClickCount } = createCounter()
</script>

<button on:click={() => clickCount++}>
  clickcount {clickCount} \ {doubledClickCount}
</button>

Obwohl es sich hier durchgehend um valides Javascript handelt, stehen auf einmal die Funktionalitäten, die ursprünglich vorlagen, nicht mehr zur Verfügung. Der Compiler erkennt nicht mehr, dass clickCount eigentlich als Zustands-Variable angesehen werden soll und weigert sich, doubledClickCount als abgeleitete Variable zu definieren. Um die Ausgliederung von Komponenten-Logik zu ermöglichen, ist man stattdessen auf sogenannte Stores angewiesen, ein grundsätzlich abweichendes Konzept, auf das hier nicht weiter eingegangen werden soll, weil Stores mit Svelte 5 obsolet wurden.

Das Ziel von Svelte 5 in dieser Hinsicht ist, die Handhabung von Zustand bzw. Reaktivität unabhängig vom Use Case zu vereinheitlichen.

Abgeleiteter Zustand / Derived State

Stützt man sich bei der Entwicklung einer Komponente auf abgeleiteten Zustand (der $:-Marker), muss man sich einer entscheidenden Eigenheit dieses Sprachmittels bewusst sein: Die Neuberechnung passiert erst, nachdem die Komponente neu gerendert worden ist. Die Implikation dieser Tatsache lässt sich im Beispiel gut verdeutlichen: In der Methode increment wird clickCount inkrementiert und direkt im Anschluss wird in der console.log-Anweisung sowohl auf clickCount als auch auf doubledClickCount zugegriffen [4].

<script>
  let clickCount = 0 
  $: doubledClickCount = clickCount * 2

  function increment() {
    clickCount = clickCount + 1
    console.log(`clickCount: ${clickCount} / ${doubledClickCount}`)
  }
</script>

<button on:click={increment}>
  clickcount {clickCount} \ {doubledClickCount}
</button>

Nach dem ersten Klick würde man also diese Ausgabe erwarten: clickCount: 1/2. Tatsächlich lautet diese aber clickCount: 1/0, weil zu dem exakten Zustand die Neuberechnung von doubledClickCount noch nicht geschehen ist. Die beiden Variablen, die ja voneinander abhängig sind, sind auf einmal nicht mehr synchron, was in der Folge zu subtilen und schwer zu identifizierenden Bugs führen kann.

Svelte 5 zielt darauf ab, On-demand-Berechnungen von abgeleiteten Variablen auszuführen und nicht erst zu einem fixen Zeitpunkt in der Zukunft.

Dependencies in Derived State

Im letzten Beispiel wird eine abgeleitete Variable doubledClickCount definiert, die abhängig ist von clickCount und die bei jeder Änderung neu berechnet wird. Angenommen die Berechnung dieses abgeleiteten Wertes soll in wiederverwendbarer Form in eine separate Funktion ausgelagert werden [5]:

<script>
  let clickCount = 0 
  $: doubledClickCount = calculateDoubled()

  function calculateDoubled() {
    return clickCount * 2
  }
</script>

<button on:click={() => clickCount++}>
  clickCount: {clickCount} / doubledClickCount: {doubledClickCount}
</button>

Auch hier würde man auf den ersten Blick erstmal kein Problem vermuten, handelt es sich doch hier um korrektes und valides Javascript. Zum Problem wird diese Notation jedoch, weil der Svelte Compiler nur die Abhängigkeiten berücksichtigt, die er in dem reaktiven Ausdruck (`$: doubledClickCount = calculateDoubled()`) identifizieren kann. Da hier clickCount nicht vorkommt, wird die Methode zur Neuberechnung nicht ausgeführt, wenn sich clickCount ändert, weil der Ausdruck nicht unmittelbar von clickCount abhängig ist.

Mit Svelte 5 wurde eine Ermittlung von Abhängigkeiten eingeführt, die nicht zur Buildtime, sondern zur Laufzeit durchgeführt wird. Das bedeutet zum einen, dass jede Zustandsvariable, die im Laufe der Berechnung abgefragt wurde, auch in Zukunft berücksichtigt wird und zum anderen, dass diese Ermittlung nicht nur einmal passiert, sondern kontinuierlich, um Zustandsänderungen ignorieren zu können, die nicht mehr relevant sind.

Svelte 5 Runes

Nachdem es sich bei den oben beschriebenen Umbrüchen im Reaktivitätskonzept um sehr einschneidende Änderungen handelt, haben die Svelte-Entwickler sich entschlossen, einen neuen Weg einzuschlagen, um Reaktivität abzubilden. Version 5 verabschiedet sich von dem Konzept, Javascript-Sprachmittel mit zusätzlicher Bedeutung zu überladen und benutzt stattdessen herkömmliche Funktionsaufrufe mit speziellen Namen, die der Svelte Compiler identifizieren kann.

Auch wenn es aussieht, als würde es sich um Javascript-Funktionen handeln, sind es viel mehr Marker, die der Compiler konsumiert und die entsprechenden Aufrufe mit zusätzlicher Funktionalität anreichert. Diese reservierten Funktionsnamen werden "Runes" genannt.

$state

Die wichtigste Rune ist die $state-Rune [6]:

<script>
  let clickCount = $state(0)
</script>

<button onclick={() => clickCount++}>
  clickCount: {clickCount}
</button> 

Die Rune bekommt den Initialwert des Zustands übergeben und erzeugt eine Zustandsvariable, mit der dann auf die bekannte Weise umgegangen werden kann. Mit dem entscheidenden Unterschied, dass man als Entwickler nun mit Arrays und Objekten, als State angelegt, genauso interagieren kann wie aus JavaScript gewohnt, weil Änderungen am State ebenfalls vom Framework identifiziert werden. Dies geht sogar soweit, dass auch tief verschachtelte Objekte/Arrays korrekt überwacht werden.

Im folgenden Beispiel wird eine Liste von Personen lokal gespeichert. Durch die Buttons wird zum einen eine Person hinzugefügt und zum anderen wird bei einer weiteren Person der Geburtstag verändert. In beiden Fällen ist es nicht notwendig, das Framework explizit über die Veränderung zu unterrichten (React) oder aber durch umständliche Workarounds eine Neuzuweisung zu veranlassen (Svelte v4) [7].

<script>
  let persons = $state([{ name: 'Ada', birthday: '2022-02-22' }])

  function addPerson() {
    persons.push({ name: 'Alan', birthday: '1912-06-23' })
  }

  function fixBirthday() {
    persons[0].birthday = '1815-12-10'
  }
</script>

<button onclick={fixBirthday}>fix birthday</button>
<button onclick={addPerson}>add person</button>

{#each persons as person}
  <p>{person.name}: {person.birthday}</p>
{/each}

Technisch wird dies über eine Datenstruktur gelöst, die sich "deeply reactive state proxy" nennt. Konkret bedeutet dies, dass über einen Proxy Wrapper die Svelte Runtime jeden Zugriff auf die nativen Methoden von Arrays (push, pop, slice, …) wie auch jeden schreibenden Zugriff auf Objekt-Properties erkennt und entsprechend einen Rerender der Komponente veranlasst.

$derived

Die $derived-Rune adressiert die Probleme, die mit der Implementierung der $:-Notation einhergehen: die verspätete Neuberechnung von abgeleiteten Werten und die inkonsistente Ermittlung von abhängigen Zustandsvariablen. Angelegt wird eine abgeleitete Zustandsvariable analog zur Definition einer State-Variable, statt der $state-Rune wird die $derived-Rune verwendet. Innerhalb der Klammern des Aufrufs wird der Ausdruck übergeben, der evaluiert werden soll [8]:

<script>
  let clickCount = $state(0)
  let doubledClickCount = $derived(clickCount * 2)
</script>

<button onclick={() => clickCount++}>
  clickCount: {clickCount} / doubled: {doubledClickCount}
</button>

Beim Erzeugen der Komponente wird die Berechnung einmal initial ausgeführt und dabei in einer Art "Logbuch" festgehalten, welche State-Variablen abgefragt wurden, als diese Berechnung durchgeführt wurde. Im obigen Beispiel ist das zum Beispiel die clickCount-Variable. Erfasst wird dieser Zugriff über den gleichen Mechanismus, den wir uns auch schon im Rahmen der $state-Rune angeschaut haben: Ein Proxy erkennt Zugriffe und verknüpft sie mit der Berechnung der abgeleiteten Variablen. Anschließend veranlasst die Laufzeitumgebung die Neuberechnung, wenn sich eine der abhängigen Variablen verändert.

Zwei spannende Aspekte bringt diese Herangehensweise mit sich: Dieses Logbuch wird permanent bei jeder Neuberechnung aktualisiert. Dies hat zur Folge, dass dynamisch angepasst wird, welche Zustandsvariablen tatsächlich gebraucht werden. In diesem Beispiel wird zusätzlich das Flag calculateDoubled geführt, welches beeinflusst, ob die Berechnung erfolgen soll oder nicht [9]:

<script>
  let calculateDoubled = $state(false)
  let clickCount = $state(0)
  let doubledClickCount = $derived(calculate())

  function calculate() {
    if (!calculateDoubled) return '-'

    console.log('calculating...')
    return clickCount * 2
  }
</script>

<button onclick={() => calculateDoubled = !calculateDoubled}>toggle</button>

<button onclick={() => clickCount++}>
  clickCount: {clickCount} / doubled: {doubledClickCount}
</button>

Zu Anfang ist die Berechnung von doubledClickCount also abhängig von den beiden State Variablen calculateDoubled und clickCount. Wird durch Aktionen in der Komponente das Flag auf false gesetzt, veranlasst dies eine Neuberechnung von doubledClickCount, weil durch return jedoch verfrüht aus der Berechnung ausgestiegen wird, erfolgt jetzt kein Zugriff mehr auf clickCount. Ab diesem Zeitpunkt ist also die Neuberechnung von doubledClickCount nur noch von calculateDoubled abhängig. Ändert sich clickCount, hat dies keine Neuberechnung zur Folge. Erst wenn das Flag wieder auf true gesetzt wird, wird auch die Neuberechnung erfolgen (und letztendlich auch ein DOM-Update nach sich ziehen). Zweitens spielt es keine Rolle mehr, wo abhängige Zustandsvariablen zum Einsatz kommen. Wird, wie in dem obigen Beispiel, die Berechnung der verdoppelten Klickzahl in einer separaten Methode durchgeführt, wird die Laufzeitumgebung trotzdem entsprechend darüber informiert, dass eine Zustandsvariable referenziert wurde, die relevant für die Neuberechnung ist.

Der Tracking-Mechanismus, der die Abhängigkeitserkennung im Kontext der $derived-Rune und das Zugriffs-Tracking (geschachtelte Objekte, Arrays, …) von Zustandsvariablen ermöglicht, bringt noch eine weitere entscheidende Eigenschaft mit sich: Die Berechnung einer abgeleiteten Zustandsvariablen erfolgt erst dann, wenn tatsächlich ein Zugriff darauf ausgeführt wird. Das hat zwei Dinge zur Folge: Der Wert steht unmittelbar zur Verfügung, sobald eine Interaktion mit ihm erfolgt. Zweitens stößt die Laufzeitumgebung die Berechnung erst dann an, wenn auch tatsächlich im Code oder im Template auf die abhängige Variable zugegriffen wird. Dadurch werden unnötige Berechnungen ausgelassen, die die Performance der Anwendung negativ beeinflussen können. Im Gegenzug dazu würde unter React eine abgeleitete Zustandsvariable bei jedem Neu-Rendern berechnet werden. Möchte man das nicht, muss man sich mit Hilfsmitteln wie useMemo behelfen, was unter Svelte 5 überflüssig geworden ist.

Svelte 4 und Svelte 5 im Vergleich: Komponentenübergreifende Reaktivitäts-Paradigmen

Zu den Nachteilen der Svelte-4-Implementierung gehört auch, dass es nicht möglich ist, Reaktivität komponentenübergreifend mit einheitlichen Mitteln zu definieren. State Variables, die mit let definiert wurden oder abgeleitete Variablen (markiert mit $:) sind in einer Komponente nur auf unterster Ebene verwendbar und verhalten sich ansonsten wie normale Javascript-Sprachmittel, die vom Svelte Compiler ignoriert werden. Dementsprechend verhält sich der Code dann nicht mehr wie erwartet.

In Svelte 5 ist es nun möglich, Runes zu verwenden, um komponentenspezifische Logik ausgelagert zu definieren, ohne auf Ersatzmittel wie Stores zurückgreifen zu müssen. Vor allem, dass nun einheitliche Sprachmittel eingesetzt werden können, ist ein großer Vorteil im Vergleich zum Status Quo in Svelte 4. Wollte man in Svelte 4 Komponenten-Logik separat implementieren, war man auf ein Hilfsmittel angewiesen, das "Store" genannt wird. Ein Store ist ein Objekt, welches Daten speichert und gegebenenfalls ein Interface anbietet, mit dem diese Daten manipuliert werden können.

Das Beispiel der Counter-Logik sieht in der Store-Implementierung so aus [10]:

<script>
  import { writable } from 'svelte/store'

  function createCounter() {
    // eine instanz eines veraenderlichen stores wird erstellt
    const { subscribe, update } = writable(0)

    function increment() {
      // um daten zu aktualisieren, muss die methode `update`
      // mit einem handler aufgerufen werden
      update(currentCount => currentCount + 1)
    }

    return { subscribe, increment }
  }

  const counterStore = createCounter()
</script>

<!-- mittels des $ zeichens wird signalisiert dass eine subscription -->
<!-- auf dem counterstore angelegt werden soll -->
<h1>Count: {$counterStore}</h1>

<button on:click={counterStore.increment}>Increment</button>

Man sieht gut, dass nun ein anderes Interface für das Halten, Manipulieren und Anzeigen von Daten erlernt werden muss. Hingegen ist das in der Svelte 5-Implementierung, die sich Runes bedient, nicht mehr notwendig [11]:

<script>
  function createCounter() {
    // anlage einer state variable wie gewohnt
    let clickCount = $state(0)

    // abgeleiter zustand mittels $derived rune
    let doubledClickCount = $derived(clickCount * 2)

    // die manipulation funktioniert genauso wie auf Komponenten Ebene
    const increment = () => clickCount++

    return {
      // wichtige zu beachten: clickCount und doubledClickCount müssen
      // mittels eines getters exportiert werden
      get clickCount() { return clickCount }, 
      get doubledClickCount() { return doubledClickCount },
      increment
    }
  }

  const counter = createCounter()
</script>

<button onclick={counter.increment}>
  clickCount: {counter.clickCount} \ {counter.doubledClickCount}
</button> 

Genauso kompakt wie im Store-Beispiel, allerdings mit den gewohnten Sprachmitteln, funktioniert das Rune-Beispiel. Wir haben hier sogar noch einen integrierten abgeleiteten Zustand mit an Bord, was im Store-Kontext nur mit wesentlich mehr Aufwand (Man benötigt einen "derived store", eine besondere Variante eines Stores.) und Boilerplate zu lösen gewesen wäre. Möchte man die createCounter-Methode in eine separate Datei auslagern, ist dies ebenfalls kein Problem, die einzige Bedingung ist, dass die Datei die Endung .svelte.js oder .svelte.ts trägt, damit der Compiler weiß, dass er diese Datei zu inspizieren hat.

$effect

Bei der nächsten Rune handelt es sich sicherlich um eine der kontroversesten Neuerungen in Svelte 5, die für einiges an Irritation gesorgt hat. Die $effect-Rune sieht auf den ersten Blick aus wie der useEffect-Hook aus React und ist auch für einen sehr ähnlichen Anwendungsfall gedacht, nämlich als eine Art "Übergang" zwischen dem deklarativen und dem imperativen Programmierparadigma. Konkret bedeutet das, dass die Runtime eine Funktion immer dann aufruft, wenn sich Abhängigkeiten verändern. Dies ermöglicht es zum Beispiel, DOM-nahe Operationen wie focus auszuführen, die nur imperativ möglich sind.

Anders als bei useEffect in React müssen allerdings die Abhängigkeiten nicht manuell definiert werden, sondern werden automatisch aus dem Kontext des Funktionshandlers extrahiert. Das geschieht auf die gleiche Weise wie bei der $derived-Rune: Bei der ersten Ausführung wird notiert, welche reaktiven Werte gelesen werden ($state, $derived und $props), um diese dann mit der Handler-Funktion zu assoziieren. Ändert sich eine der festgehaltenen Abhängigkeiten, wird die Funktion automatisch ausgeführt. Dabei gilt das gleiche wie bei der $derived-Rune: Abhängigkeiten werden kontinuierlich neu evaluiert.

Aus der Handler-Funktion kann zusätzlich eine Funktion zurückgegeben werden, die von der Runtime immer dann aufgerufen wird, wenn aufgrund von geänderten Abhängigkeiten der Effekt neu ausgeführt wird. Das ist zum Beispiel dann sinnvoll und wichtig, wenn es darum geht, "Aufräumarbeiten", wie den Reset eines Timers, durchzuführen. Im Beispiel wird das Click-Counter-Beispiel um eine $effect-Rune erweitert, welche bei bestimmten Werten eine Nachricht ausgibt [12]:

<script>
  let clickCount = $state(0)

  $effect(() => {
    if (clickCount == 11) console.log('over 10!')
    if (clickCount == 9001) console.log('over 9000!')
  })
</script>

<button onclick={() => clickCount++}>
  clickCount: {clickCount}
</button>

Im Kontext von React hätte man dem useEffect explizit clickCount als Abhängigkeit übergeben müssen, die Svelte-Runtime dagegen identifiziert clickCount automatisch als Abhängigkeit, weil die Variable bei der ersten Ausführung gelesen wird. Im Beispiel wurde bewusst eine imperative Operation (das console.log) ausgeführt, welche nicht auf deklarative Weise möglich gewesen wäre. Im Gegenzug ist es wichtig, die $effect-Rune nicht für Anwendungsfälle zu missbrauchen, die deklarativ besser gelöst wären. Möchte man zum Beispiel eine Nachricht anzeigen, sobald mehr als zehn Klicks erfolgt sind, wäre es vielleicht naheliegend, dies direkt in der $effect-Rune und mittels eines Flags zu tun [13]:

<script>
  let clickCount = $state(0)
  let showMessage = $state(false)

  $effect(() => {
    if (clickCount !== 11) return

    console.log('over 10')
    showMessage = true
  })
</script>

<button onclick={() => clickCount++}>
  clickCount: {clickCount}
</button>

{#if showMessage}
  <h1>over 10!!!</h1>
{/if}

Grundsätzlich funktioniert das so auch. Es wird aber auch grundsätzlich sehr entschieden davon abgeraten, eine solche Zustands-Synchronisierung über einen Effekt zu behandeln [14]. Die $effect-Rune sollte nur als Hintertüre verwendet werden, da undurchsichtige Performance und Synchronisierungs-Probleme die Folge sein können. Der obige Anwendungsfall lässt sich mit einer $derived-Rune zum Beispiel wesentlich eleganter umsetzen [15]:

<script>
  let clickCount = $state(0)
  let showMessage = $derived(clickCount > 10)

  $effect(() => {
    if (clickCount === 11) console.log('over 10')
  })
</script>

<button onclick={() => clickCount++}>
  clickCount: {clickCount}
</button>

{#if showMessage}
  <h1>over 10!!!</h1>
{/if}

$props

Die $props-Rune wird genutzt, um auf die Parameter einer Komponente zuzugreifen. Bislang wurden die Eigenschaften einer Komponente über das Javascript-Schlüsselwort export definiert. Der eigentliche Zweck des export-Schlüsselworts ist es, bestimmte Sprachmittel (Variablen, Funktionen, Klassen etc.) aus einer Javascript-Komponente zu exportieren, so dass sie von außerhalb referenziert werden können. In Svelte-Komponenten hingegen wurde die Semantik hinter export umgedeutet, um zu kennzeichnen, dass Werte in eine Komponente hineingegeben werden können. Mit Svelte 5 entschloss man sich, diese Diskrepanz aufzulösen und stattdessen eine Rune einzuführen, die den Zugriff auf Komponentenparameter ermöglicht. Das folgende Beispiel enthält wieder einen Click-Button, diesmal wird über einen externen Parameter der Startwert injiziert [16]:

<script>
  let { startCount } = $props()
  let clickCount = $state(startCount)
</script>

<button onclick={() => clickCount++}>
  clickCount: {clickCount}
</button>

Besonders wichtig: Properties, die über $props empfangen werden, sind ebenfalls reaktiv, das bedeutet, wenn ein Prop zum Beispiel im Kontext von $effect oder $derived verwendet wird, veranlasst dies ebenfalls eine Neuberechnung bzw. Reevaluierung.

Fazit: Wie Svelte 5 Inkonsistenzen behebt und die Codequalität steigert

Mit Svelte 5 wurden durch die Einführung von Runes zahlreiche Unsauberkeiten und Inkonsistenzen behoben, die in Svelte 4 zu schwer wartbarem Code und Performance-Problemen führten. Diese Neuerungen tragen entscheidend dazu bei, die Entwicklungserfahrung zu optimieren und die Effizienz der Anwendung zu steigern.

Dieser Artikel bezieht sich in erster Linie auf Runes und ihre Eigenschaften. Jedoch sind im Zuge der Einführung von Svelte 5 noch einige weitere, rückwärts inkompatible Änderungen eingeflossen, die aber den Rahmen dieses Artikels sprengen würden. In der offiziellen Svelte-Dokumentation findet sich ein hervorragender Guide in Bezug auf Änderungen in der neuen Version [17].

Ansonsten sei noch das hervorragende Svelte Einsteiger-Tutorial erwähnt, das interaktiv die verschiedenen Building Blocks des Frameworks behandelt und verständlich und nachvollziehbar erklärt [18].

Autor