Svelte – the new kid on the block
Die Entstehung von Svelte
Einige Unterschiede von Svelte zu anderen Frameworks
Eine Syntax für Puristen
Out-of-the-Box Global State Management
Rendering – vorher, nachher und mittendrin
ViteJS als Kickstarter
Wann sollten Sie die Finger von Svelte lassen?
Svelte als Chance begreifen
Fazit
Svelte. Oder wie die Entwickler es selbst nennen: „Cybernetically enhanced web apps“.
Vermutlich kennen Sie die Big Player am Markt: Angular, der große Bruder React und die kleine Schwester VueJS. Alles drei sehr etablierte Javascript UI Frameworks und in der Web-Welt nicht mehr wegzudenken. Doch inzwischen drängt etwas Neues auf den Markt: Die Rede ist von Svelte.
Da stellt sich doch direkt die Frage: Benötigen Sie das? Schon wieder ein neues Framework? Nachfolgend gehe ich diesen Fragen auf den Grund.
Die Entstehung von Svelte
Die Entwickler von Svelte haben sich gefragt, ob es nicht möglich wäre, den ganzen Ballast aus den aktuellen UI-Bibliotheken zu entfernen und trotzdem effizienten und stabilen Code herzustellen?
Mit Version 1 von Svelte versuchten sie, diese Frage zu beantworten bzw. ihre Hypothese zu bestätigen. Sie nahmen das React-Framework und passten es für ihre Bedürfnisse an. Die Aussage, „Svelte – the new kid on the block“ ist nur halb wahr, denn Version 1 von Svelte erblickte bereits 2016 das Licht der Welt. Interessanterweise kam zum selben Zeitpunkt Angular, wie wir es heute kennen, auf den Markt.
Mit Version 2 vertieften die Entwickler von Svelte ihr Vorhaben und als sie feststellten, dass ihr Ansatz ziemlich cool war und auch anderen Entwicklern helfen könnte, wurde mit Version 3 im Jahr 2019 ein komplettes Roundup betrieben und das Ganze noch einmal sauber aufgesetzt. Entwicklerfreundlich und komplett in Typescript geschrieben. Das UI Framework Svelte war geboren.
Einige Unterschiede von Svelte zu anderen Frameworks
Zum Erstellen von Web-Anwendungen werden in aller Regel UI Frameworks herangezogen. Und Svelte ist ebenfalls ein UI Framework, allerdings ohne das ganze „Framework“. Das klingt erst einmal fragwürdig, ist aber bei genauerer Betrachtung wirklich pfiffig. Svelte ist in erster Linie ein Compiler. Es wandelt das, was wir in eigens geschriebene .svelte-Dateien tippen in pures Vanilla Javascript um. Und dadurch eröffnen sich ganz neue Möglichkeiten der Programmierung…
Das Wort „Svelte“ (engl. für „schlank“) beschreibt sehr gut die Merkmale im Vergleich zu den großen Jungs. Dadurch, dass es zu simplen Javascript-Code kompiliert wird, zugeschnitten auf die Bedürfnisse der Anwendung, und jeglicher zusätzlicher Ballast entfällt, reduziert sich die Größe einer lauffähigen Anwendung enorm. Kommt eine Angular-Anwendung noch mit ~180 kB aus und wird ReactJS bereits auf ca. 6,3 kB gedrückt, lacht Svelte nur und reduziert sich selbst noch einmal auf ganze 3,5 kB. Da muss man schon echt mit der Lupe hinschauen, um das wirklich zu glauben.
Und wie schafft Svelte das?
- Zum einen benötigt Svelte keine Runtime Library. Durch das Kompilieren werden alle nötigen Funktionen in die fertige Anwendung gebracht. Eine Runtime Library, die alle möglichen Funktionalitäten des Frameworks bereitstellt, braucht es hier also nicht.
- Zum anderen stellt Svelte vieles bereits von Hause aus bereit, welches normalerweise erst mit Fremd-Bibliotheken erweitert werden muss, unter anderem Reactiveness oder sogennantes Global State Management. Ein Blick in die Abhängigkeiten einer frisch aufgesetzten Svelte-Anwendung zeigt also das Gleiche, wie ein Kühlschrank in einer Studenten-WG – gähnende Leere.
Angular oder React setzen zum aktuellen Rendern der Oberfläche einen sogenannten Virtual DOM1 ein. Das ist, vereinfacht gesagt, ein Abbild des aktuellen DOMs mit dem anschließend durch Vergleichen (Diffing) festgestellt wird, welche Elemente sich in der Oberfläche geändert haben und neu gerendert werden müssen. Klingt auf den ersten Blick sehr kostenintensiv, ist allerdings schneller als ein normaler Update-Zyklus.
Svelte schlägt hier einen anderen Weg ein2: Bereits während des Kompiliervorgangs ersetzt es Komponenten mit hocheffektiven, imperativen Code, der den realen DOM „chirurgisch genau“ anpasst und dadurch deutlich schneller arbeitet, als die anderen Frameworks es tun.
Eine Syntax für Puristen
Die Entwickler von Svelte haben sich gefragt, wie wohl eine komfortable und dennoch performante API aussehen könnte. Die Antwort war simpel: Die beste API ist keine API. Durch das Pre-Compiling kann eine .svelte-Datei in jeglicher Form gebracht werden, welche die Svelte-Entwickler sich gewünscht haben. Jeder Ballast-Code kann dadurch vermieden werden und Bindungen an klassische Javascript-Konventionen entfallen.
Eine klassische ReactJS-Component sieht wie folgt aus:
```
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>
);
};
```
Svelte erscheint im Vergleich deutlich aufgeräumter:
```
<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>
```
Im Vergleich lässt sich schön sehen, dass die ReactJS-Variante fast 3x größer ist! Die ganze Magie für das Binding und „Reactiveness“ passiert zur Compile-Zeit, ohne dass sich ein Entwickler darum kümmern muss. Ein einfaches Zuweisen von Variablen wird etwa wie folgt umgewandelt:
`count += 1;` wird zu `count += 1; $$invalidate(‚count‘, count);`
Out-of-the-Box Global State Management
Bei der Entwicklung von Anwendungen wird häufig auf das beliebte Redux Pattern zurückgegriffen.3 Im Ursprung eine eigene Javascript-Bibliothek, mit Wurzeln in Facebooks Flux Patterns4, wird es von anderen Bibliotheken adaptiert bzw. erweitert. Das Ziel ist das sogenannte Global State Management. Hierbei wird für die gesamte Anwendung (oder auch nur Teile davon) ein globaler Zustand gespeichert und mittels spezieller Trigger und Funktionen der Zustand verändert (Actions und Reducer genannt).
Durch die hohe Popularität wurde auch hier in Svelte bereits beim Design darauf geachtet, die Arbeit für Entwickler so leicht wie möglich zu gestalten. Somit bietet Svelte von Hause aus ein Global State Management an und kann auf einfache Weise genutzt werden. Weitere Fremd-Abhängigkeiten werden dadurch weiterhin ferngehalten und die Anwendung bleibt schlank. Eine Win-Win-Situation also.
Müssen in anderen Bibliotheken die Actions, Reducer und Selectors noch mühsam selbst geschrieben und an die richtige Stelle im Projekt geschoben werden, lässt sich dies in Svelte ganz einfach implementieren:
```
import { writable } from 'svelte/store';
<script>
// definieren des Stores
export const myName = writable("Marco");
</script>
// Binding innerhalb eines Templates
<span> Mein Name ist {$myName}</span>
// Ändern des States
<script>
onMount(async () => {
$myName = "Polo";
});
</script>
```
Der Trick liegt hier im $-Zeichen versteckt. Sobald Sie dieses Symbol vor den Variablen-Namen schreiben, erkennt Svelte, dass Sie mit dem Global State arbeiten möchten und passt den Output-Code zur Compile-Zeit entsprechend an. Und reactive ist das Ganze natürlich auch sofort.
Rendering – vorher, nachher und mittendrin
Eines der wichtigsten Features darf von Svelte natürlich nicht unerwähnt bleiben: Wo Programmiersprachen und Frameworks wie PHP oder ASP.NET nur Server-Side Rendering (SSR) anbieten, Angular, VueJS und React hingegen ausschließlich Single-Page Applications (SPA) sind, bringt Svelte beide Welten zusammen5 und erschafft dadurch komplett neue Möglichkeiten zum Anwendungs-Design.
Durch spezielle Formatierungen der Datei-Struktur und der Verwendung von eigens zur Verfügung gestellten Methoden aus dem Framework lassen sich bereits während des Abrufs vom Server Daten aggregieren und in die anschließend gerenderte Seite einbinden. Der Vorteil liegt klar auf der Hand: Es benötigt keine weiteren Requests über das Internet zum Server, um Daten initial zu laden. So könnte bspw. eine Tabelle mit einem großen Datenbestand zur Ladezeit vorbefüllt werden, und anschließend im Browser als SPA weitere Requests (wie u. a. Paging oder Sortierung) ausführen, wenn diese benötigt werden.
ViteJS als Kickstarter
Normalerweise besteht eine Anwendung aus vielen verschiedenen Dateien. Hinzu kommen dann noch Fremd-Bibliotheken sowie das Aufsplitten in verschiedene Module, Routen, Konfigurationen…
Die „klassische“ Web-Entwicklung bedient sich jeher standhaften Frameworks wie Webpack oder RollupJS, um das sogenannte „bundeling“ vorzunehmen. Eine Anwendung wird entsprechend zusammen geschnürt und anschließend zum Browser ausgeliefert. Je nach Konfiguration wird dieser Vorgang zur Entwicklungszeit mit einem Development Server hochgefahren, oder für das spätere Deployment produktionsreif gebracht.
Mit wachsender Größe einer Anwendung wächst auch die Komplexität. Viele verschiedene Routen und Sub-Module entstehen und das Bundeling dauert länger und frisst zusätzliche Ressourcen. Trotz Hot Module Replacement (HMR)6 steigt so die Dauer des „hot loadings“, nachdem eine Änderung am Code vorgenommen, den Speicher-Button bedient und das Ergebnis im Browser angesehen wurde.
Svelte bedient sich hier einem Newcomer: mit ViteJS7 wird das ganze Bundeling umgangen, und die Geschwindigkeit auf ein Bruchteil reduziert. Zum Vergleich: eine frisch aufgesetzte Angular-Anwendung benötigt zum Starten des Development Servers ca. 15 Sekunden, Svelte braucht mit ViteJS hingegen lediglich 2,7 Sekunden. Beeindruckend, oder?
ViteJS schafft diese Leistung, indem es sich wie ein normaler Web-Server verhält. Durch native ESM8 überlässt es dem Browser den Job des Bundlers und liefert nur jene Module und Code-Teile aus, die auch wirklich benötigt werden. Somit reduziert sich der Overhead und die Geschwindigkeit steigt.
Wann sollten Sie die Finger von Svelte lassen?
Wenn Sie jetzt denken „shut up and take my money“, dann lohnt sich vorher noch ein Blick auf die Gegenseite beleuchten. So schön sich das alles auch anhört, es gibt auch gute Gründe sich nicht für Svelte zu entscheiden:
Svelte eignet sich (noch) nicht für Enterprise Anwendungen
Wie mit jedem neuen Framework auf dem Markt, braucht es Zeit, um zu reifen. An manchen Stellen existieren noch größere Bugs, Features sind noch nicht implementiert oder es entstehen häufiger Breaking Changes. Deshalb sollte Svelte (vorerst) nicht für große Enterprise Anwendungen in Betracht gezogen werden, insbesondere da häufiges Refactoring schnell zu Frust führt.
Für kleine und mittelgroße Anwendungen ist Svelte aber sicherlich bereits sehr nützlich.
Die Community-Unterstützung ist gering
Stellen Sie bei Stack Overflow eine Frage über Angular, werden Sie vermutlich in 5 Minuten eine 3-seitige Antwort mit 5 Code-Beispielen und 10 Referenzen zum Weiterlesen bekommen. Durch die erst noch wachsende Popularität fehlt diese treibende Kraft der Community bei Svelte schlichtweg noch. Das heißt, dass Sie viel ausprobieren oder in der eigentlichen Dokumentation oder dem Framework-Code lesen müssen. Wer diesen Mehraufwand scheut oder wem die finanziellen Mittel dafür fehlen, sollte lieber auf eines der ausgewachsenen Frameworks zurückgreifen.
Keine Zeit / Kein Geld für Selbstbauarbeiten
Durch den Fokus der Kern-Funktionalitäten (und das Fehlen eines großen Geldgebers, wie es bei React oder Angular der Fall ist), fehlen in Svelte einfach noch wichtige Features wie bspw. die Dependency Injection, die in anderen Frameworks vorhanden sind. Ggf. müssen Sie also einige Features selbst implementieren und pflegen.
Ein anderes Framework ist bereits in Benutzung
Haben Sie bereits ein Team von Entwicklern aufgebaut, das intensiv mit einem Framework vertraut ist, sollten Sie sehr sorgfältig abwägen, ob die Einführung eines neuen, jungen Frameworks für Sie erstrebenswert ist. Da Svelte im Kern nichts anders als andere Frameworks macht (nämlich das User Interface zu rendern), ist der Mehrwert zu gering, um eine bestehende Anwendung komplett umzubauen.
Svelte als Chance begreifen
Die genannten Nachteile bzw. „Probleme“ können sich mit einer anderen Perspektive auch als Chancen entpuppen!
- Durch den Einsatz parallel zur eigentlichen Entwicklung können Sie das Know-how im Team nachhaltig fördern.
- Zudem werden durch die frischen Ansätze eingefahrene Entwicklungsmuster aufgebrochen und regt alle Beteiligten zum Neudenken an.
- Durch den „Zwang“ zum Selbstbau entsteht ein viel tieferes Verständnis zu den bereits eingesetzten Technologien (wer bisher Dependency Injection leidenschaftlich gern nutzt, wird erst richtig verstehen, wie es funktioniert, wenn er einen Injector selbst geschrieben hat).
Ein weiterer Pluspunkt ist die Entwicklung von Web Components mit Svelte. Durch die einfache Syntax und dem schlanken Output lassen sich auf einfache Weise Web Components erstellen, die Sie anschließend in ein bestehendes System integrieren können. Das schafft zum einen eine gewisse Framework-Unabhängigkeit, zum anderen können Sie so auch die Entwicklung auslagern.
Sollten Sie vor der mangelnden Community-Unterstützung zurückschrecken, hier ein persönlicher Tipp: Entwickler wie Sie und ich sind „die Community“. Werden Sie selbst zur Unterstützung für andere! Wissen und Beispiele müssen sich mit der Zeit aufbauen. Wer allerdings frisch in das Thema einsteigt und anderen dabei hilft, das Framework zu verstehen und neue Anwendungen zu entwickeln, erwirbt einen guten Ruf unter den Entwicklern, und stärkt das Bewusstsein für das Framework Schritt für Schritt. Ganz nach dem Zitat von Mahatma Gandhi: „Sei selbst die Veränderung, die du dir wünschst für diese Welt“.
Fazit
Zusammengefasst lässt sich festhalten, dass Svelte frischen Wind in die Welt der Web-Entwicklung mit Javascript bringt. Durch die neuen Ansätze und Technologien lassen sich neue Architektur-Muster umsetzen. Auch der Performance-Gewinn bringt einen vielfachen Mehrwert, sowohl während der Entwicklung als auch später im Produktiv-System.
Wie sich Svelte am Markt behaupten wird, kann nur die Zukunft zeigen. Aus meiner Perspektive stehen die Chancen für „the new kid on the block“ gut, insbesondere da es meiner Meinung nach keine Konkurrenz zu den bestehenden Frameworks darstellt, sondern wunderbar parallel existieren und das Portfolio erweitern kann. Für mich ist es ein sehr spannendes und gelungenes Framework und ich werde damit das eine oder andere Projekt umsetzen. Ebenso habe ich bereits von anderen Entwicklern gehört, dass damit alt-eingesessene PHP-Anwendungen nach und nach in eine Single-Page Application migriert werden – klingt nicht schlecht, oder?
Hinweise:
[1] Virtual DOM
[2] Svelte: Rethinking Reactivity
[3] Redux Pattern
[4] Flux Pattern
[5] What is SvelteKit?
[6] Hot Module Replacement
[7] ViteJS
[8] Native ESM
Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!
Marco Rehmer
Marco Rehmer ist Frontend-Entwickler und hat von Anfang 2021 bis Ende 2023 bei t2informatik gearbeitet. Seitdem arbeitet er als Freelancer, auch für t2informatik. Neben UI/UX-Design Prinzipien und Architekturmuster hegt er auch eine gesunde Leidenschaft zu Kaffeesorten aus aller Welt. Und wenn er gerade nicht vor der Tastatur sitzt, hängt er an der ein oder anderen Kletterwand und schaut sich die Welt von oben an.