Entwicklungstools - perfektioniert für Svelte

IDEs, Prototyping-Tools, Debugger, Analyse- und Monitoring-Werkzeuge stellen wichtige Features für die Anwendungsentwicklung bereit. Im Web findet man für Svelte eine eigenständige IDE SvelteStorm, deren Entwickler das Ziel verfolgen die Programmierung zukünftig besser als mit den gängigen IDEs abzudecken. Verschiedene Anforderungen aus dem Blickwinkel des Prototyping unterstützen Sylph, Boldo und Kahi UI.Im Zentrum der Tools Svelcro, Svelte Inspector, Svelte Reactive Debugger und Svelte Devtools stehen Fehlersuche, Debugging, Analyse und Monitoring. Zur Implementierung einer Jamstack-Architektur mit Svelte eignen sich Tools wie JungleJS, Plenti oder primo.

Mitte 2021 stellten einige Entwickler für Svelte eine neue Open-Source-IDE SvelteStorm (Bild 1) vor. Die Programmierung fand über die Open Source Labs (OSLabs) statt. Als Organisation hat sich das OSLabs zum Ziel gesetzt, Innovationen mittels Open-Source-Software voranzutreiben.

SvelteStorm - ein IDE-Prototyp im Alpha-Stadium auf Svelte abgestimmt

Dabei tritt das OSLabs erst seit zwei Jahren in der Öffentlichkeit auf. Zum OSLabs gehören Partner wie Ripplematch, Commandeer, Codesmith und zusätzliche Software-Entwickler. Ripplematch befasst sich als Personalagentur seit kurzem mit der automatisierten Talentsuche, Commandeer entwickelt eine Schaltzentrale für verschiedene Cloud-Services und Codesmith bildet Software-Entwickler aus.Inzwischen liegt SvelteStorm zwar offiziell in Version 4 vor – allerdings handelt es sich aus Sicht des Entwicklungsstadiums eher um einen Alpha-Stand der Software. Ihr aktueller Entwicklungsstand enthält noch Fehler, die SvelteStorm für die professionelle Entwicklung als ungeeignet ausweisen. Vermutlich gehört SvelteStorm deswegen noch nicht zu den vom OSLabs als Featured Project ausgezeichneten Produkten.Auch fehlen wichtige Features, die man im Umfeld der Entwicklung mit Svelte insbesondere einer IDE erwartet. So wäre es sicherlich sinnvoll gewesen, Funktionen wie Find Component References, Find in Files oder Compare Selected zu realisieren. Diese Grundfunktionen sollten in einer IDE für die Komponenten-Entwicklung mit Svelte nicht fehlen.Die Realisierung der IDE erfolgte mit Svelte und Electron für die Betriebssysteme Linux, macOS und Windows. Wobei Electron lediglich als Wrapper zur Ausführung von SvelteStorm auf dem Desktop zum Einsatz kommt.Das OSLabs liefert die Software bisher lediglich über GitHub auf Basis des Source-Codes aus. Eine Binärversion für die drei genannten Betriebssysteme steht noch nicht zur Verfügung – sie befindet sich laut Homepage derzeit in Entwicklung. Vermutlich verfügt das Projekt derzeit über zu wenig Wissen zur Erstellung einer Desktop-App mit Electron für Linux, macOS und Windows. Auch fand die Entwicklung von SvelteStorm primär auf Linux und macOS statt. Somit sind für die Bereitstellung der Software unter Windows immer noch einige Hürden zu überwinden.

Voraussetzungen für den Einsatz

Den Quellcode von SvelteStorm stellen die Entwickler anderen Entwicklern über ein eigenes GitHub-Repository zur Verfügung. Der dortige .vscode-Ordner legt die Vermutung nahe, dass die Software vorwiegend mit VS Code programmiert wurde. Das untermauert auch die Empfehlung der Entwickler, die Einrichtung von SvelteStorm am besten mit VS Code durchzuführen.Leider entpuppten sich die Angaben in der readme.md-Datei als nicht ganz korrekt. Der dortige Inhalt entspricht nicht dem tatsächlichen aktuellen Projektstand. Was bereits beim ersten Durchlesen durch die teilweisen widersprüchlichen Hinweise zum WSL (Windows Subsystem for Linux) auffällt. Einerseits soll unter Windows das WSL in Version 2 verwendet werden, andererseits soll man nicht auf WSL unter Windows zurückgreifen.Die Installation von SvelteStorm orientiert sich an der üblichen Vorgehensweise in der Node.js-Welt. Sie teilt sich theoretisch in die drei Schritte ein: Cloning des GitHub-Repositorys, Installation aller Abhängigkeiten mittels npm install und eventuell weiteren betriebssystem-spezifischen Bibliotheken/Tools. Grundsätzliche Voraussetzung für das Cloning des GitHub-Repositorys bildet ein installiertes Git-System. Unter Windows benötigt man eine Installation der PowerShell und der Visual Studio Community-Edition. Wobei Visual Studio Community lediglich als Vehikel zur Installation weiterer Windows-spezifischer Komponenten dient. Deshalb muss man beim Einrichten von Visual Studio Community die Bereiche Python, Node.js Development und Desktop Development with C++ zusätzlich auswählen.Wie im JavaScript/Node.js-Ökosystem üblich empfiehlt sich der Einsatz der Node Version Manager (nvm)-Software. Im Bedarfsfall hilft nvm beim schnellen Umschalten auf eine bestimmte Node.js-Version (nvm use <VersionNr>), unterstützt die Installation (nvm install <VersionNr>) oder Deinstallation (nvm uninstall <VersionNr>) einer anderen Version, zeigt alle installierten (nvm ls) und über das Internet verfügbaren Node.js-Versionen (nvm ls-remote) an.Für den Einsatz von SvelteStorm verweisen die Entwickler auf die Version 16.16.0. Der Befehl nvm install 16.16.0 erledigt schnell die Installation und nvm use 16.16.0 führt eine Aktivierung durch.Für die Einrichtung von SvelteStorm sollte nach Meinung der Entwickler VS Code zum Einsatz kommen. Nach der Installation der Software bringt die Menü-Kaskade Help > Check for Updates… (Linux, Windows) beziehungsweise Code > Check for Updates… VS Code auf den neusten Stand. VS Code besitzt zwar eine Built-in Unterstützung für Git, allerdings muss Git selbst separat installiert sein. Da SvelteStorm zum Großteil mit Svelte programmiert ist, sollte zusätzlich noch die Extension Svelte for VS Code in VS Code vorhanden sein. Ferner ist eine Installation der Extension GitHub Pull Requests and Issues sinnvoll, da diese das Arbeiten mit Git erleichtern – insbesondere bei Einsatz eines Forks (Kopie) des GitHub-Repositorys im eigenen GitHub-Account.

SvelteStorm als Entwicklungsprojekt einrichten

Zunächst richtet man einem Clone des Repositorys von SvelteStorm über VS Code ein. Dazu öffnet man die Command Palette…, gibt den Befehl Git ein und wählt das Kommando Clone über die Auswahlleiste aus. Anschließend kopiert man sich im GitHub-Repository von SvelteStorm über die Drop-Down-Liste von Code die URL im Register HTTPS.In VS Code trägt man die kopierte URL in das angezeigte Eingabefeld ein und startet den git clone-Befehl. Im Anschluss benötigt VS Code einen Ordner in dem der Clone abgelegt wird. Ein Klick auf die Schaltfläche Select Repository Location startet das Cloning; nach dessen Abschluss öffnet man das Repository/den Source-Code in VS Code als eigenständiges Svelte-Projekt.Die Datei package.json gibt, wie in jedem Node.js-Projekt üblich, einen Überblick zum SvelteStorm-Projekt. Um mit den Quelldateien von SvelteStrom im Entwicklungsprojekt zu arbeiten, müssen alle in package.json spezifizierten Ressourcen vorhanden sein. Diese besorgt in einem Terminalfenster der Befehl npm install – er stellt alle für das Projekt benötigten Node.js-Abhängigkeiten bereit. Den Build einer Binärversion erledigt Electron Forge für das jeweilige Betriebssystem. So erzeugt der Befehl npm run package zunächst ein plattform-spezifisches, nicht ausführbares Electron-Dateiformat (Bild 2).

Ein eigenständiges Installationsprogramm von SvelteStorm erzeugt der passende Electron-Installer (zum Beispiel für macOS: electron-installer-dmg). Derzeit spezifiziert die package.json ein derartiges Installationspaket nur für macOS und Linux.Für das Testen der Desktop-Version setzt das Projektteam Spectron und Mocha mit Chai-Assertions ein – die zugehörigen Testfälle findet man im test-Unterverzeichnis. Für die dortigen automatischen Tests benötigt man auf dem Desktop ein lauffähiges SvelteStrom. Mangels Weiterentwicklung von Spectron empfiehlt das Electron-Team zukünftig ein anderes Testing-Tool einzusetzen. Zur Unterstützung des Entwicklungsprozesses nutzen die Entwickler Travis CI, darauf deutet im Projektordner eine .travis.yml-Konfigurationsdatei hin. Diese Software für Continuous Integration/Continuous Delivery (CI/CD) besitzt eine Schnittstelle zu GitHub. Die Travis CI-Konfigurationsdatei legt nahe, dass die Entwickler primär unter macOS gearbeitet haben.

Lokales Entwicklungsprojekt von SvelteStorm für Windows bereitstellen

Unter Linux und macOS erzeugt git clone wie oben beschrieben mit VS Code ein lokales Entwicklungsprojekt von SvelteStorm. Unter Windows hingegen bricht der Cloning-Prozess mit dem aktuellen GitHub-Repository des Source-Codes mit einer Fehlermeldung ab: error: invalid path… unable to checkout working tree. Eine Kontrolle mittels git status zum aktuellen Zustand des lokalen Repositorys und erneutem Versuch über git restore --source=HEAD :/ führt zum selben Fehler. Leider entsprechen einige der Quelldateien nicht den Konventionen für die Namensvergabe unter Windows. So akzeptiert Windows keinen Doppelpunkt im Dateinamen; wie er beispielsweise in den drei Unterverzeichnissen linux, mac, windows des Orders /assets/icons beim Dateinamen svelteStormfinal.ico:Zone.Identifier vorkommt.Um dennoch mit Git auf einem Windows-Arbeitsplatzrechner ein Cloning durchzuführen, benötigt man eine Installation des WSL (Windows Subsystem for Linux). Dazu muss die Virtualisierung unter Windows im BIOS oder den Windows-Einstellungen/Features aktiviert werden. Eine erfolgreiche Aktivierung zeigt der Task-Manger über das Register Leistung rechts unten durch den Eintrag Virtualisierung: Aktiviert an. Jetzt gilt es zu prüfen, welche Standardversion von WLS unter Windows vorliegt. Sollte bei der Ausgabe von wsl --status nicht Standardversion: 2 erscheinen, so legt wsl --set-default-version 2 diese für die Installation der einzurichtenden Linux-Version fest.Anschließend richtet über die Eingabeaufforderung der Befehl wsl --install ein WSL mit dem Linux-Derivat Ubuntu zusammen mit einem Benutzer ein. Nach der Installation des Betriebssystems empfiehlt es sich, mit der Befehlsfolge sudo apt update && sudo apt upgrade Ubuntu zu aktualisieren. Andere für WSL verfügbaren Linux-Distributionen zeigt das Windows-Kommando wsl --list --online an. Alternativ installiert wsl --install -d <Distro-Name> eine andere, gewünschte Linux-Distribution unter WSL. Um mit Git unter Ubuntu zu arbeiten, nimmt sudo apt-get install git eine Installation vor. Abschließend stellt der Git-Befehl git clone https://github.com/open-source-labs/SvelteStorm.git das Entwicklungsprojekt von SvelteStorm bereit.

IDE-Voraussetzungen für ein SvelteStorm-Projekt schaffen

Nach einer Installation von VS Code unter Windows (nicht unter WLS) fügt man der IDE aus dem Marketplace die Erweiterung Remote Development hinzu. Diese Erweiterung für den Einsatz von VS Code zusammen mit WLS/Linux besteht aus folgenden Marketplace-Erweiterungen:Erfolgt keine Neuinstallation von VS Code, so gilt es zu prüfen, ob die IDE die Extension Remote-WSL: Recommender (Bild 3) enthält. Diese Extension liefert Microsoft neuerdings zusammen mit VS Code aus, so dass keine separate Installation mehr anfällt. Remote-WSL: Recommender schafft die Voraussetzungen für die Installation der Extension Remote WSL. Die Installation von Node.js unter WSL erfolgt mittels NVM (Node Version Manager). Dazu benötigt WSL eine Installation von cURL (Client for URLs): sudo apt-get install curl.

Über die README-Datei im GitHub-Repositorys von NVM besorgt man sich den aktuellen Installationsbefehl: curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash. Dieser Befehl installiert nvm direkt in die Shell und startet sie neu. Der Befehl command -v nvm prüft, ob die Shell das integrierte Kommando nvm kennt – als Ausgabe liefert sie die Zeichenkette nvm zurück. Sollte die Shell nvm als Kommando nicht kennen, so hilft die Ausführung der Startup-Datei der jeweiligen Shell. Für die bash erledigt dies der Befehl source ~/.bashrc. Abschließend installiert nvm install 16.16.0 die benötigte Node.js-Version und nvm use 16.16.0 aktiviert sie.VS Code benötigt für das SvelteStorm-Projekt auf einem lokalen Windows-Arbeitsplatz keinerlei Source Code im Windows-Dateisystem. Für dieses Szenario hat Microsoft die VS Code-IDE zu einer Client-Server-Architektur erweitert. Auf dem lokalen Windows-Betriebssystem läuft der VS Code-Client und auf dem Remote Betriebssystem/WLS der Serverprozess VS Code Server. Bei VS Code Server handelt es sich nicht um eine eigenständige IDE – vielmehr um einen speziellen Software-Service. Dabei dient VS Code Server als Backend für die Kommunikation zwischen den Remote-Extensions von VS Code-Client und dem Server-Betriebssystem.Zusätzlich zu den Backend-Services stellt VS Code Server ein interaktives CLI (Call Level Interface) und den Aufbau von sicheren Verbindungen für die Web-IDE vscode.dev bereit. Für den Zugriff von VS Code-Client auf Dateien in WSL wechselt man über ein Terminalfenster in den Projektordner. Die Eingabe des CLI-Befehls code . von VS Code-Client installiert Code Server in WSL und führt eine Konfiguration durch. Nach fertiger Konfiguration erscheint im Hauptfenster von VS Code in der linken unteren Ecke die Anzeige von WSL. Ein Klick auf die WSL-Anzeige öffnet in VS Code die Command Palette, diese gruppiert verschiedene Befehle in die Bestandteile der drei Remote Development-Erweiterungen.Jetzt sind die Voraussetzungen geschaffen, um das SvelteStorm-Entwicklungsprojekt über WSL in VS Code unter Windows zu öffnen. Dazu klickt man auf die Anzeige WSL und wählt in der Command Palette im Bereich Remote-WSL den Eintrag New WSL Window aus. Nach der Auswahl von File > Open Folder… gibt man in der Eingabezeile die Kennung \\wsl$ ein. Daran erkennt ein Windows-Explorer, dass der Benutzer auf ein Linux-Dateisystem zugreifen will. Eine Navigation zum heruntergeladenen GitHub-Repository von SvelteStrom öffnet das Entwicklungsprojekt in VS Code. Das Open File/Folder-Dialogfenster besitzt rechts oben eine Schaltfläche Show Local, diese startet einen Windows-Explorer direkt im Projektordner.

Voraussetzungen für SvelteStorm in WSL und VS Code-Windows schaffen

Damit die VS Code-DIE über Terminal > New Terminal ein integriertes Terminalfenster für WSL öffnet, muss in den Settings als Befehlsprozessor wsl.exe gesetzt werden. File > Preferences > Settings und Klick auf das rechts obenstehende Icon-Symbol Open Settings (JSON) zeigt die settings.json-Datei an. Dort ersetzt man in der Zeile "terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\cmd.exe", den Befehlsprozessor cmd.exe durch wsl.exe. Startet jetzt das integrierte Terminalfenster in VS Code, so öffnet sich ein WSL-Terminalfenster und keine Windows-Eingabeaufforderung. Anschließend nimmt der Befehl npm install eine Installation aller benötigten Packages im Projektordner vor.Für die Übersetzung und Ausführung von SvelteStorm benötigt man einige Linux-Bibliotheken, einen installierten X-Server (als Client-Software) und einen Windows X Server. Bei den Linux-Paketen handelt sich um die folgenden Bibliotheken: libatk1.0-0, apt-get libatk-bridge2.0-0, libcups2 und libgtk-3-dev; die jeweils der Befehl sudo apt install <package-Name> installiert. Als X-Server richtet sudo apt install xfce4 xfce4-goodies die freie Desktop-Umgebung Xfce unter WSL in Ubuntu ein. Für die Ausführung von Linux-GUI-Programmen unter Windows eignen sich MobaXterm, VcXsrv, X410 oder Xming. Nach Download von VcXsrv Windows X Server und dessen Installation, legt man eine Verknüpfung auf dem Desktop mit dem Ziel "C:\Program Files\VcXsrv\vcxsrv.exe" :0 -ac -terminate -lesspointer -multiwindow -clipboard -wgl -dpi auto an.Um die korrekte Einrichtung der X Window- und der Windows X Server-Software zu testen, installiert man den Terminal-Emulator terminator: sudo apt-get install terminator. Startet man anschließend über den Windows-Desktop VcXsrv und gibt im WSL-Terminalfenster den Befehl DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0 terminator & ein, so öffnet sich ein zweites WSL-Fenster mit einem Terminal (Bild 4). Da der X Server nicht unter Ubuntu/WSL sondern Windows läuft, befindet sich dieser in einem separaten Netzwerk. Zugriffe von WSL aus erfolgen über die Umgebungsvariable DISPLAY. Diese macht in WSL für Windows 10 (mit mDNS) export DISPLAY=$(hostname).local:0 und für Windows 11 (mit WSLg) export DISPLAY=:0 bekannt.

GUI-Programme unter Linux (wie SvelteStorm) kommunizieren über das D-Bus-System, dieses startet der Befehl sudo /etc/init.d/dbus start oder sudo service dbus start unter WSL. Die package.json-Datei im SvelteStorm-Entwicklungsprojekt verwendet zur Ausführung der IDE das Script npm run start. Dieses Script nimmt eine Übersetzung des Projekts vor (npm:svelte-dev) und startet SvelteStorm über den Electron-Wapper electron-forge. Anschließend zeigt der X Server von Windows die seitens WSL ausgeführte SvelteStrom-IDE an. Über File > Open Folder und Auswahl eines Svelte-Projekts öffnet SvelteStorm den zugehörigen Ordner und zeigt im linken Fensterausschnitt die Projektstruktur mit den zugehörigen Dateien an.

Projekt-Ansicht mit einer Navigationsfunktion

Wie in vielen IDEs üblich verfügt SvelteStorm für diese Projekt-Ansicht über eine Navigationsfunktion, um innerhalb einer Projekt-Hierarchie zu navigieren. Klickt der Programmierer auf einen Dateinamen in der Projekt-Ansicht, so öffnet sich rechts daneben ein Quellcode-Editor mit dem Inhalt der ausgewählten Datei. Während des Öffnens eines Svelte-Projekts analysiert die SvelteStorm-IDE die darin enthaltenen Svelte-Komponenten und zeigt sie im rechten oberen Fensterausschnitt zusammen mit ihren Props an. Die damit verbundene Analyse der in einer Svelte-App enthaltenen Komponenten und ihre Props nennt sich Real-time D3 Component Visualization.Die in dieser Bezeichnung enthaltene Zeichenkette D3 soll darauf hinweisen, dass die Implementierung dieses Verfahrens über die D3.js-Library erfolgt. Der zugehörige Fensterausschnitt mit den Namen der Komponenten und ihrer Props heißt Component State Windows. Da es sich dabei um kein eigenständiges Fenster, sondern um einen Fensterausschnitt (Pane) handelt, spricht man häufiger vom Component State Viewer. Rechts oben in dieser View öffnet SvelteStorm durch Klick auf die Beschriftung Docs mit dem Icon-Symbol einer Lupe die über das Internet erreichbare Svelte-Dokumentation. Gibt man im Eingabefeld Search Documentation einen Suchbegriff ein und klickt auf die Eingabetaste, so zeigt der Fensterausschnitt die zugehörige Dokumentationsseite an.Dieser Fensterausschnitt unterstützt den Entwickler wesentlich gezielter beim Durchsuchen der Svelte-Dokumentation als die Original-Website. Darüber erreicht man auch das interaktive Tutorial und die Sammlung an Programmbeispielen. Startet man über die SvelteStorm-IDE mittels npm run dev eine mit Svelte programmierte Web-App, so öffnet sich in der IDE ein eigenständiges Fenster, welche die Web-App ausführt. Beim Start der Web-App aktiviert SvelteStorm den Watch/Hot Reload-Modus, so dass sich jede gespeicherte Programmänderung sofort in der Web-App widerspiegelt. Die Menü-Kaskade Help > Toggle Developer Tools zeigt in diesem separaten IDE-Fenster die Chrome DevTools an. Darüber stehen die vollständigen Features dieses Debugging-Tools von Google zur Verfügung.

Time-Traveling-Debugging zur Analyse komplexer Fehlerzustände

Eine moderne IDE verfügt über eine Vielzahl von Tools, um Breakpoints (Haltepunkte) zu setzen, den Zustand des Programms zu erkunden und zur Aufzeichnung von Logs (Protokolldateien). Die Erfahrung hat jedoch gezeigt, dass speziell im Node.js- und JavaScript-Umfeld diese Debugging-Features nicht ausreichen.Die mit JavaScript verbundene Dynamik eines Programms zusammen mit einem extensiven Gebrauch von Callbacks und Promises bedeutet im Fehlerfall eine aufwendige Suche nach dessen Ursache. Insbesondere wenn sich eine komplexe Fehlerkonstellation durch einfache Ausführung des Programms im Debugging-Modus nicht rekonstruieren lässt. In einem solchen Fall führt nur ein sogenannter Time-Traveling-Debugger (TTD) zum gewünschten Ziel.Anstatt seitens des Testers das Debugging zu unterbrechen, einen neuen Breakpoint zu setzen und die Anwendung wiederholt auszuführen bis die aufgetretene Fehlersituation vorliegt – genügt beim Einsatz eines TTD quasi ein einfacher Klick auf eine Schaltfläche. Diese Schaltfläche bewirkt einen zeitlichen Rückwärtsschritt innerhalb der Ausführung des Programms. Aufgrund dieses Sachverhalts gehört ein TTD zur Klasse der Reverse-Debugging-Tools. Der zeitliche Step rückwärts durch den Quellcode orientiert sich an bestimmten Punkten innerhalb der Programmausführung. Die jeweiligen Punkte legt der Tester vor der Ausführung des Testfalls fest oder der TTD leitet diese anhand seiner Einstellungen automatisch ab.Mit einem TTD teilt sich die Fehlersuche über die Programmausführung in drei, sich eventuell wiederholenden Arbeitsschritte ein:Da es sich bei einer Svelte-App letztendlich um eine in JavaScript geschriebene Node.js-Anwendung handelt, befassen sich zwei Entwicklungsprojekte mit der Implementierung eines TTD: SvelteStorm und DeLorean. Beide Projekte finden beim Open Source Labs (OSLabs) statt. Während SvelteStorm jedoch als Alpha-Software anzusehen ist, macht das OSLabs DeLorean als Beta-Software über einen völlig anderen GitHub-Domain-Namen wie die von SvelteStorm verfügbar. SvelteStorm als Entwicklungsumgebung (IDE) entspricht einem eigenständigen und selbst ablauffähigen Programm, während DeLorean nicht selbständig, sondern als Erweiterung/Extensions innerhalb von Chrome über die Chrome DevTools ausgeführt wird.Das TTD in der SvelteStorm-IDE startet der Tester innerhalb eines Svelte-Projekts mit dem Kommando npm run sdebug. Anschließend öffnet SvelteStorm in einem eigenständigen Fenster die Svelte-App und die IDE visualisiert im COMPONENTS & PROPS-Fensterausschnitt den Komponentenbaum als Graph mit Knoten und Kanten.Zur Anzeige des Komponentengraphs kommt die D3.j-Bibliothek zum Einsatz. Neben diesem Graphen erscheinen zwei Schaltflächen: Reset und Snapshot 1, direkt darunter zeigt SvelteStorm die zum Snapshot 1 gehörenden, aktuell von der Svelte-App erzeugten Komponenten an. Alle vorhandenen Komponenten der Svelte-App bildet SvelteStorm ebenfalls über Schaltflächen ab und beschriftet diese mit ihrem Komponentennamen (Bild 5).

Führt der Tester anschließend über den separaten Fensterausschnitt die laufende Svelte-App aus, um den Fehlerfall zu rekonstruieren, so protokolliert SvelteStorm mittels TTD-Feature alle von der App neu erzeugten Svelte-Komponenten. Dazu speichert TTD jede neu erzeugte Svelte-Komponente ab, erzeugt im anderen Fensterausschnitt COMPONENTS & PROPS eine Schaltfläche Snapshot 2, legt für die neuen Komponenten weitere Schaltflächen an und beschriftet diese mit dem Komponentennamen.Parallel dazu erfolgt, rechts daneben im gleichen Fensterausschnitt COMPONENTS & PROPS, entsprechend eine Aktualisierung des mit D3 programmierten Komponentenbaums. Dieser Vorgang der Protokollierung, Generierung von Schaltflächen mit den Komponentennamen und Aktualisierung des Komponentenbaums erfolgt bei jeder Interaktion des Testers mit der Svelte-App.Klickt anschließend der Tester auf eine der Schaltflächen mit der Beschriftung Snapshot i, so erscheinen direkt darunter aller Schaltflächen, der zu diesem Zeitpunkt der Programmausführung in der App enthaltenen Svelte-Komponenten. Ein Klick auf eine der Komponenten-Schaltflächen öffnet wiederum einen Anzeigebereich. In diesem zeigt der TTD alle zum jeweiligen Zeitpunkt in der Svelte-App vorhandenen JavaScript-Objekte an, die vom Entwickler innerhalb der App programmiert wurden.Bei einem Klick auf die Reset-Schaltfläche setzt der TTD die aktuell laufende Anwendung auf ihren Startzeitpunkt zurück. Dazu löscht der TDD alle vorhandenen Snapshots, alle dazugehörigen Svelte-Komponenten mit den Anwendungsobjekte und visualisiert die Komponentenhierarchie entsprechend der Ausgangssituation zum Startzeitpunkt. Die Reset-Schaltfläche entspricht damit einem kompletten Neustart der Svelte-App; allerdings mit dem Vorteil, dass der Compiler keine erneute Übersetzung vornehmen muss, sondern die bereits vorhandene zur Fehleranalyse verwendet.Das Arbeiten mit der Chrome-Extension DeLorean setzt eine Installation des Chrome-Browsers aus dem Dev-Channel voraus; diese Software nennt sich Google Chrome Dev. Eine ganz bestimmte Version von Chrome Dev findet man in den Chrome Release Channels gruppiert nach den jeweiligen Betriebssystemen. Nach der Installation von Google Chrome Dev besorgt man sich über das GitHub-Repository von DeLorean das Verzeichnis chrome_extension mit allen darin enthaltenen Dateien. Es empfiehlt sich, dieses Verzeichnis in das Svelte-Projekt zu kopieren, für welches eine Fehlersuche durchzuführen ist. In Google Chrome Dev wählt man über das ^…-Punkte Menü Weitere Tools > Erweiterungen und klickt auf die Schaltfläche Entpackte Erweiterung laden.

Time-Traveling-Debugging für Svelte-Apps in Chrome Dev mit DeLorean

Anschließend wählt man als Erweiterungsverzeichnis den gerade eingerichteten Ordner chrome_extension aus und installiert DeLorean in Chrome DevTools. Der Einsatz von DeLorean für Time-Traveling-Debugging setzt einen div-Container mit der id="root" in der index.html-Datei voraus. Zusätzlich muss die main.js-Datei diesen div-Container als Wurzel-Komponente der Svelte-App laden: target: document.getElementById('root').Startet man jetzt die Svelte-App mittels npm run dev im Entwicklungsmodus, so stellt Svelte die App über eine URL zum Testen bereit. Nur im Entwicklungsmodus steht der Time-Traveling-Debugger von DeLorean über die DevTools für die Fehlersuche in Chrome Dev bereit. Öffnet man die DevTools über Weitere Tools > Erweiterungen, so erscheint bei korrekter Installation in deren Toolbar ein zusätzlicher Eintrag DeLorean. Fehlt dieser, so genügt ein Neustart von Chrome Dev, das Öffnen eines neuen Fensters oder ein Refresh des DevTools-Fensters.Es ist darauf zu achten, dass über npm run dev die zu testende Svelte-App über localhost zur Ausführung kommt, da DeLorean dies voraussetzt. Startet man jetzt in Chrome Dev die im Entwicklungsmodus laufende Svelte-App, öffnet die DevTools und klickt auf den Eintrag DeLorean, so erscheint eine Connect-Schaltfläche. Ein Klick auf diese bringt den Time-Traveling-Debugger zur Ausführung und dieser erzeugt den ersten Snapshot mit der Bezeichnung State 1. Arbeitet man jetzt den zu untersuchenden Testfall ab, so speichert jede Zustandsänderung einen neuen Snapshot ab. Den Testfall führt man solange aus, bis dieser den zu analysierende Fehlerzustand auslöst. Jetzt kann der Entwickler bequem alle gespeicherten Zustände der Svelte-App durchgehen.

Jeden einzelnen Programmzustand erreicht man durch Klick auf einen der mit State i gekennzeichneten Snapshots. Wählt man einen dieser Snapshots aus, so zeigt DeLorean daneben, die von der Zustandsänderung der Svelte-App betroffenen Svelte-Komponente an. Dabei erscheint jede Svelte-Komponente in einem separaten Fensterausschnitt (Bild 6), der die Namen der Svelte-Komponente zusammen mit den geänderten Attributen/Properties und den ausgeführten Funktionen auflistet. Klickt man mit dem rechten Mauszeiger in einen der Fensterausschnitte und wählt im Kontextmenü der Eintrag Untersuchen aus, so öffnet sich ein neues DevTools-Fenster. Anschließend stehen dem Tester dort die in DevTools üblichen Debugging-Features zur Verfügung.

Prototyping fokussiert auf unterschiedliche Strategien

Generell befasst sich Prototyping mit dem Bau eines Prototyps, der vor allem zur Verbesserung der Kommunikation zwischen den Kunden und/oder innerhalb dem Entwicklungsteams dienen soll. Der Bau eines Prototyps erhöht die Kommunikation zwischen allen Beteiligten, verdeutlicht frühzeitig Probleme, konkretisiert und präzisiert die Anforderungen, verbessert die Qualität und hilft bei der Schätzung des mit der Fertigstellung der Software verbundenen Aufwands. Da jeder Bau eines Prototyps Kosten verursacht, muss dieser mit einer Planung und Dokumentation begleitet werden. Je nachdem, welches Ergebnis mit dem Prototypenbau gewünscht und wie dieser Prototyp weiter behandelt werden soll, unterscheidet man verschiedene Formen/Arten von Prototyping; zu den wichtigsten zählen:Prototpying sollte wie jeder Software-Entwicklungsprozess auch mit Agilität und Extreme Programming verbunden werden. Dabei sollten Agile Entwicklung und Extreme Programming auf alle Projektaufgaben beim Prototypenbau Berücksichtigung finden. Mit dieser Vorgehensweise multiplizieren sich die mit diesen drei Entwicklungskonzepten verbundenen Vorteile, so dass Transparenz, Veränderungsgeschwindigkeit und Problemlösung sich nochmals/zusätzlich erhöhen beziehungsweise verbessern. Insgesamt führt diese Verbindung zu einem schnelleren und qualitativ besseren Prototyp als wenn das Prototyping mit einem wasserfall-artigen Vorgehen stattfinden würde.Im Unterschied zu anderen JavaScript/TypeScript-Frameworks unterstützt Svelte an sich bereits das Prototyping. Bei der Programmierung mit Svelte stehen Komponenten, deren Gestaltung und deren Wiederverwendung von Anfang an im Zentrum. Der Entwickler muss sich bei der Umsetzung einer Komponente nicht zusätzlich um andere Belangen des Frameworks wie einem VDOM (Virtual DOM), Verfolgung der Stati oder der Reaktivität kümmern. Es gibt kein VDOM, Stati und Reaktivität einer App übernimmt Svelte automatisch. JavaScript- Funktionen einer Komponente befinden sich an einer zentralen Stelle. Führt man die Entwicklung mit Svelte anhand einer standardisierten Architektur durch, so verbessert dies die Qualität des Prototyps.So bietet es sich an, Styles und Komponenten voneinander getrennt, in unterschiedliche Verzeichnisse im Projektordner (src/styles und src/components) abzulegen. Styles, die komponenten-übergreifend eine Rolle spielen, sollten dort in einer zentralen Basisdatei (base.css) abgelegt werden. Styles, die sich nur auf eine Komponente beziehen, sollten den Namen der Komponente (<komponentenname>.css) erhalten. Dieser Querbezug verringert den mentalen Arbeitsaufwand bei der Programmierung und trägt gut zum Verständnis des Systemaufwands bei. Zudem erleichtert er später erforderliche Aufgaben in der Wartung und Weiterentwicklung.

Prototyping von Svelte-Apps mit Sylph und der Figma-Kopplung Boldo

Das beim Open Source Labs (OSLabs) entwickelte Sylph stellt das Prototyping mit dem Endbenutzer und die strukturelle Architektur der App (aus Sicht HTML/JavaScript) für Programmierer in den Mittelpunkt. Obwohl das OSLabs Sylph als Beta-Software bereitstellt, handelt es sich analog SvelteStrom eher um einen Alpha-Stand. Sylph teilt sich in vier Funktionsbereiche ein: Drag & Drop-Interface und Component-Customizer für die strukturelle Architektur, Real-time Code- mit Site-Preview (Prototyping mit dem Endbenutzer) und Projekt-Verwaltung.Aktuell bietet nur das Drag & Drop-Interface und der Component-Customizer einige Features an. Im Unterschied dazu enthält der Real-time Code- mit Site-Preview als auch die Projekt-Verwaltung nur rudimentäre oder gar keine Funktionalität. Der im GUI aufgeführte CODE EDITOR zeigt lediglich den Quellcode in Real-time an, Änderungen sind keine möglich. Sylph eignet sich derzeit nicht für den Einsatz in der Praxis, dazu müsste die Site-Preview für die Kommunikation mit dem Endbenutzer überarbeitet und um weitere Funktionen erweitert werden.Boldo legt seinen Schwerpunkt auf die Einbindung des UX/UI-Design-Software Figma in das Prototyping mit Svelte. Immer häufiger liegen Design-Ergebnisse für eine Software vor, die man möglichst vollständig im Entwicklungsprozess wiederverwenden möchte. Boldo unterstützt genau diesen Ansatz eine Wiederverwendung der Figma-Ergebnisse in der Entwicklung mit Svelte. Die Einrichtung von Boldo erfolgt mittels Cloning des GitHub-Repositorys, Installation der npm-Pakete und Aufbau einer Verbindung zu den Ergebnissen in Figma. Dazu baut Bodo mit dem Script-Befehl npm run link wie unter Figma üblich eine Kommunikation mittels URL auf. Der Share-Button in Figma öffnet den Invite-Dialog, dort kopiert Copy Link die benötigte URL.Das zusätzlich erforderliche Personal Access Token (PAT) erzeugt die Returntaste über die Account Settings im Eingabefeld Create a new personal access token. Achtung: Figma bietet die Kopierfunktion Copy this token für jeden PAT nur einmalig an! Deshalb muss man sich diesen zwischenspeichern und so sichern. Der Script-Befehl npm run dev baut in Boldo die Kommunikation mit Figma auf. Dazu generiert Boldo aus den Figma-Objekten leider keine passenden Svelte-Komponenten, sondern eine Kommunikationsdatei App.svelte. Diese speichert die Software im Unterverzeichnis ./project zusammen mit einigen Boldo-spezifischen Dateien ab.

Die Boldo-spezifische Wrapper.svelte-Datei erzeugt die zur Kommunikation mit Figma benötigten Objekte. Aktuell unterstützt Boldo nicht für jedes Figma-Objekt eine derartige Kommunikation – leider erfolgt auch keine Fehlermeldung. Generell muss darauf geachtet werden, dass der Viewport, also der in Boldo bei Ausführung der Svelte-App angezeigte Bereich, in Figma links oben im Arbeitsfenster beginnen muss. Derzeit eignet sich Boldo nur für das Prototyping von iOS-Apps (Bild 7), diese erscheint im Browser über die URL localhost:5000. Was die Richtung der Kommunikation betrifft, erfolgt diese nur von Figma nach Boldo und nicht auch in die andere Richtung. Allerdings lassen sich Figma-Objekte in Boldo über die App.svelte-Datei ändern und Boldo zeigt diese Änderungen im laufenden Prototyp an!

Komponenten-orientiertes Prototyping mit dem Kahi UI-Framework

Am weitesten fortgeschritten, was den Reifegrad der Software betrifft, ist das Prototyping mit dem Kahi UI-Framework. Das Framework stellt eine größere Anzahl von Svelte-Komponenten zur Verfügung, um mit minimalem Aufwand eine Svelte/SvelteKit-App zu entwickeln. Mit Kahi UI lassen sich alle Formen des Prototyping umsetzen. Das GitHub-Repository von Kahi UI enthält gut strukturiert den kompletten Source-Code. Dies erlaubt es, einer größeren Entwicklungsorganisation das Framework an ihre eigenen Belange anzupassen. Die Homepage macht eine ausführliche Dokumentation des gesamten Frameworks zugänglich. Den zugehörigen Quellcode der als App realisierten Dokumentation enthält ein weiteres GitHub-Repository.Ausgehend von einem initialen Svelte/SvelteKit-App macht der Befehl nmp install @kahi-ui/framework dem Programmierer das Kahi UI-Framework zugänglich. Zusätzlich benötigt man noch zwei in CSS-realisierte Stylesheets kahi-ui.framework.css und kahi-ui.theme.default.css. Zur Optimierung der Performance und Minimierung der Laufzeit einer Svelte-App bietet Kahi UI ein Custom-Build und ein Minifying dieser CSS-Dateien an. Im Bedarfsfall entfernen Filter nicht benötigte Kahi UI-Komponenten aus dem Build-Prozess einer produktiven App. Die Vorgehensweise steht auch für globale CSS-Attribute zur Verfügung. Kahi UI gruppiert die Svelte-Komponenten nach Anwendungsbereichen und hebt in der Dokumentation Änderungen mit Migrationshilfen und Neuerungen visuell hervor.Die Entwickler von Kahi UI legten besonderen Wert auf die Komponentenorientierung mit Svelte, die Programmierung mit TypeScript und die Framework-Unabhängigkeit. Das Prototyping basiert ausschließlich auf Svelte-Komponenten; dabei ermöglicht die Realisierung mit TypeScript eine Typprüfung. Die derzeit mehr als 30 Komponenten bauen die Entwickler von Kahi UI kontinuierlich weiter aus. Zusätzlich arbeiten sie daran, das derzeitige Design unabhängiger von CSS zu machen. Der Prototyp lässt sich (basierend auf den CSS-Dateien) auch in anderen Frameworks wie React oder in herkömmlichen Server-Side Rendering (SSR)-Umgebungen wiederverwenden.

In Anlehnung an Svelte bietet auch Kahi UI einen Playground mit verschiedenen Features an; er befindet sich in der Kahi UI-Dokumentation im rechten Bereich der Toolbar. Über Snippets erreicht man im Playground zusätzliche in Kahi UI programmierte Beispiele mit Quellcode, um ihn mit Änderungen zu versehen, ausprobieren oder zu übernehmen. Der vorhandene Vorrat an Snippets lässt sich über ein Eingabefeld durchsuchen; dabei gruppiert der Playground den Inhalt nach Komponenten und fertigen Apps. Eine Share-Funktion erlaubt es, den erarbeiteten Quellcode mit anderen in einem Entwicklungsteam zu teilen. Als weiteres Feature im Playground ist eine Verbindung zum Discord-System hervorzuheben, um Kontakt mit anderen Programmierern und den Kahi UI-Entwicklern aufzunehmen.

Svelcro zur Analyse von Komponentenhierarchien

Svelcro befindet sich physisch zwar im GitHub oslabs-beta des OSLabs, allerdings sollte man die Software derzeit eher einem Alphastadium zuordnen. Beim Tool handelt es sich um eine Chrome-Extension für die Chrome DevTools; derzeit noch nicht über einen der Browser-Stores als Erweiterung/Add-on zu beziehen. Deshalb muss man sich die Software über einen Clone des GitHub-Repositorys besorgen. Dort findet man den Quellcode als Svelte-App im Unterverzeichnis dev-app. Nach dessen Übersetzung und Build steht Svelcro als Extension für die Installation im Chrome Dev-Browser zur Verfügung.Die Einrichtung für Chrome DevTools erfolgt wie üblich in Chrome Dev über Weitere Tools > Erweiterungen. Die Schaltfläche Entpackte Erweiterungen laden und Auswahl des Clone-Repositorys installiert Svelcro als eigenständigen Tab in den Chrome DevTools. Es empfiehlt sich, diesen Tab durch Drag & Drop in der Toolleiste der Chrome-Entwicklungstools weiter vorne zu positionieren. Ansonsten nervt die ständige Auswahl über die Drop-Down-Liste – insbesondere bei häufigeren Analysen von Svelte-Apps oder erneuten Starts des Chrome Dev-Browsers. Auch bei parallelen Analysen von Svelte-Apps in verschiedenen Browser-Fenstern gestaltet sich die Arbeit mit Svelcro angenehmer, wenn dessen Tab-Eintrag nicht immer erneut von Hand auszuwählen ist.Den Anspruch die Anwendungsarchitektur einer Svelte-App durch Analyse zu veranschaulichen, erfüllt Svelcro derzeit leicht nicht: So erkennt Svelcro in einer Svelte-App Komponenten nur, wenn diese sich tatsächlich in einer Komponentenhierarchie befinden (Bild 8). Seitens des Anspruchs von Svelcro die Analyse von Engpässen in der Performance zu unterstützen, macht dieser Schwerpunkt auch Sinn. Schließlich führen Baumhierarchien von Komponenten in einer Svelte-App viel häufiger zu Problemen als einfache Sammlungen von flachen Komponenten. Die Beurteilung der Performance einer Baumstruktur zeitlich pro Komponente und Anzahl ihrer Renderings mag auch zielführend sein.

Komponenten einer Svelte-App, die keiner Baumstruktur angehören, lokalisiert Svelcro grundsätzlich nicht. Insofern eignet sich das Tool nur zur Analyse von Komponentenhierarchien. Bei einer Svelte-App mit mehreren Hierarchien bietet die Software derzeit leider noch keine Auswahl aus den vorhandenen Hierarchien an. Sollten von einer Komponente mehrere Ausprägungen in der Svelte-App vorhanden sein, so erkennt man im Fensterbereich Component stats die zur Analyse gewünschte anhand des von Svelcro automatisch generierten Präfix beim Komponentennamen und den passend angezeigten Property-Werten.Unklar bleibt, weshalb die Autoren im Fensterbereich Components grundsätzlich zwischen den beiden Sichten Tree und Hierarchy unterscheiden. Nach der Graphentheorie entspricht ein Baum einer Hierarchie, so dass Tree und Hierarchy identisch wären. Vermutlich soll der Fensterbereich Tree einfach die graphische Struktur der Svelte-Komponenten veranschaulichen. Entspricht dieser Graph der Svelte-App einer mehrstufigen oder nicht zusammenhängenden Hierarchie, so erkennt Svelcro nur die zuerst gerenderte.

Monitoring von Variablen/Objekten mit Svelte und Java/TypeScript

Für das Monitoring von Variablen und Objekten eignen sich das {@debug}-Tag der Svelte-Template-Syntax und reaktive Anweisungen zusammen mit einem console.log()-Aufruf. Die Template-Syntax von Svelte kennt ein spezielles Tag: {@debug <variable, … >}, um die Werte aller referenzierten Variablen über die Console der Chrome DevTools auszugeben. Die @debug-Anweisung entspricht damit einem console.log(<variable, … >)-Aufruf. Setzt man dieses Tag ohne Variablen ein, so erzeugt der Svelte-Compiler einen Aufruf des JavaScript-Debuggers. Ähnlich wie die debugger-Anweisung im JavaScript-Quellcode, bleibt das @debug-Tag bei fehlender Debugging-Funktionalität während der Programmausführung ohne Wirkung.Grundsätzlich protokolliert die @debug-Anweisung alle Änderungen der ihr übergebenen Variablen. Sind im Webbrowser parallel zur laufenden Anwendung die Chrome DevTools aktiviert, so erfolgt eine Unterbrechung der App, der Debugger startet und das Console-Register zeigt alle Logging-Werte an. In den gängigen Browsern wie Edge, Firefox oder Chrome öffnet die F12-Taste schnell die Chrome DevTools. Das @debug-Tag steht allerdings nur für Variablen, nicht aber für Ausdrücke wie Variablen-Strukturen, Bedingungen oder Objekt/Komponenten-Properties zur Verfügung. Auch eine Einbindung zusätzlicher erläuternder Kommentare zu den Werten der Variablen ist nicht möglich.Diese Einschränkungen wirken sich negativ auf die Einsatzbreite des @debug-Tag aus; sie sollten in künftigen Svelte-Versionen beseitigt werden. Um aktuell dennoch ein Monitoring für derartige Ausdrücke mit erläuternden Kommentaren zu realisieren, greift man auf eine reaktive Anweisung zurück. Eine reaktive Anweisung beispielsweise $: console.log('Erläuterung', objekt.name) protokolliert jeder Änderung der übergebenen Variablen – egal wann und wo diese in der Svelte-App erfolgt. Damit lassen sich auch komplexere Ausdrücke wie $: if (bearbeitet) console.log('Erläuterung: ', objekt.name) protokollieren. In diesem Fall erfolgt nur eine Aufzeichnung im Log, wenn auch die boolesche Variable bearbeitet erfüllt ist.

Monitoring reaktiver Anweisungen mit dem Svelte Reactive Debugger

Svelte verfügt über eigene Sprachkonstrukte zur reaktiven Programmierung – dazu gehören reaktive Deklarationen und reaktive Anweisungen; wobei letztere auch mit Bedingungen verknüpft sein können. Das Label $: vor einer Deklaration oder Anweisung erklärt diese als reaktiv: Jede Änderung einer an der Anweisung beteiligten Variable ändert die gesamte Anweisung. Durch Blockbildung lassen sich mehrere Anweisungen zu einer reaktiven Anweisung machen: $: { Folge von Anweisungen }. Ähnlich verhält es sich mit einem $:-Prefix vor einer if-Anweisung: Immer wenn sich die an der if-Anweisung beteiligten Variable ändern, kann es zur Ausführung der mit der if-Anweisung verbundenen Verzweigungen kommen.Die Reaktivität eines Programms führt zu einer nicht-sequentiellen Ausführung, was den Aufwand bei einer Fehlersuche leider erheblich erschwert. Zu einem besseren Verständnis der Ausführung reaktiver Anweisungen trägt der Svelte Reactive Debugger bei. Hierbei handelt es sich um eine Erweiterung für die Chrome DevTools, die für alle Chrome-kompatiblen Webbrowser wie Chrome, Edge, Firefox oder Opera zur Verfügung steht.Eine Installation des npm-Pakets svelte-reactive-preprocessor als Entwicklungsabhängigkeit npm install --save-dev svelte-reactive-preprocessor in einem Projekt macht den Svelte Reactive Debugger für die Svelte-App verfügbar. Danach enthält die package.json-Datei im Bereich devDependencies einen Eintrag auf dieses npm-Package: "svelte-reactive-preprocessor": "^0.8.2".Der nächste Schritt (Listing 1) importiert diesen Preprocessor und macht ihn über das svelte-Plugin der Svelte-App zugänglich:

Beim Einsatz des Bundlers Rollup führt man diesen Import und die Initialisierung über das svelte-Plugin in der rollup.config.js-Datei durch. Verwendet man für Builds das Frontend-Tooling Vite, so erfolgt dieser Import und die Initialisierung in der vite.config.js-Datei: 

Wird neben dem Svelte Reactive Preprocessor noch ein weiterer Preprozessor zur Verarbeitung von Svelte-Anweisungen verwendet, so sollte dieser vor dem Svelte Reactive Preprocessor zum Einsatz kommen.Zum Schluss benötigt der eingesetzte Webbrowser in den Chrome DevTools eine Installation der Erweiterung Svelte Reactive Debugger. Für Chrome, Edge und Opera erfolgt die Installation über die URL des Chrome Web Store: chrome.google.com/webstore/ und einer Suche nach Svelte Reactive Debugger. In Firefox erledigt man dies über Weitere Werkzeuge > Erweiterungen für Entwickler. Nach erfolgreicher Installation befindet sich in der Toolleiste der Chrome DevTools ein eigener Reiter Svelte RD. Die Chrome DevTools öffnen sich auf einer Webseite über das Kontextmenü Untersuchen in Chrome, Edge und Firefox, beziehungsweise Element untersuchen in Opera.

Ein Klick in der Toolbar der Chrome DevTools auf das Svelte RD-Register aktiviert den Svelte Reactive Debugger. Wenn man den Svelte Reactive Debugger öfters verwendet, empfiehlt es sich, den Reiter in der Toolbar mittels Drag & Drop weiter nach vorne zu positionieren. Für ein Monitoring reaktiver Anweisungen innerhalb einer Svelte-App, stellt man diese mit der Anweisung npm run dev zur Ausführung im Entwicklungsmodus bereit. Eine Eingabe der zugehörigen URL im Webbrowser startet über den im Hintergrund laufenden Webserver die Svelte-App. Bei Klick auf den Svelte RD-Reiter in den Chrome DevTools beginnt das Monitoring, sobald der Tester die angezeigte Webseite der Svelte-App über den Browser aktualisiert (Bild 9).

Svelte Inspector koppelt Svelte-App mit den Svelte-Komponenten der IDE

Der Einsatz von Svelte Inspector setzt einige Vorarbeiten in der Svelte-App voraus. Anfangs installiert der Befehl npm install –save-dev svelte-inspector über die öffentliche npm-Registry das aktuelle Paket als Entwicklungsabhängigkeit. Die rollup.config.js- beziehungsweise die vite.config.ts- und die package.json-Datei muss sicherstellen, dass beim Aufruf von npm run dev der Svelte-Compiler im Entwicklungsmodus arbeitet. Zusätzlich muss in der Definitionsdatei des eingesetzten Builders (zum Beispiel Rollup oder Vite) ein Import des npm-Package svelte-inspector vorgenommen werden:

beziehungsweise:

und startInspector() aufgerufen werden. Zum Schluss muss die Svelte-App selbst noch den Svelte Inspector starten. Dies erledigt man am einfachsten im body-Tag der index.html-Datei über dieses Script:

Nachdem die Anwendung mit npm run dev im Entwicklungsmodus startet, kommen die obigen JavaScript-Anweisungen mit zur Ausführung. Die Methode startInspector() liest alle Konfigurationsdaten des Svelte Inspector aus einer neu im Projektordner der Svelte-App anzulegenden Datei configuration ein. Die vom Schöpfer des Svelte Inspector vordefinierten Einstellungen findet man in der README.md-Datei im GitHub-Repository unten auf der Webseite. Die dort vorgegeben Einstellungen kopiert man mittels Copy & Paste in die neu angelegte Datei configuration. Der Betrieb der Svelte-App zusammen mit dem Svelte Inspector muss mit dem integrierten Webserver im Entwicklungsmodus erfolgen.

Der Svelte Inspector nutzt die Informationen des Svelte-Compilers, um eine Kopplung der im Browser laufenden Web-App mit dem in der IDE angezeigten Quellcode abzuleiten. Dazu kommuniziert Svelte Inspector mit dem in der IDE verwendeten Quellcode-Editor. Derzeit unterstützt das Debugging-Tool alle wichtigen IDEs wie Atom, IntelliJ IDEA Community Edition, PhpStorm, WebStorm, VS Code, Visual Studio (voreingestellt) sowie einige der gängigen Code-Editoren Emacs, Sublime Test und Vim. Sollte in der Entwicklung dennoch ein anderer Quellcode-Editor zum Einsatz kommen, lässt sich dieser über den Quellcode aus dem GitHub-Repository von Svelte Inspector einbinden.Die für das Debugging mit dem Tool eingesetzte Entwicklungsumgebung oder Quellcode-Editor legt das Feld editor in einer Konfigurationsdatei configuration fest. Die Konfigurationsdatei definiert auch der Steuerung des Svelte Inspectors. So startet der über activateKeyCode hinterlegte Code der Eingabetastatur (79) den Svelte Inspector. Dazu drückt der Tester den Großbuchstaben O – also zwei Eingabetasten Shift + o. Dieser Vorgang stößt die Kommunikation mit der im editor-Feld angegebenen IDE/Quellcode-Editor an. Svelte Inspector baut eine Verbindung zwischen der im Webbrowser laufenden Anwendung und der eingesetzten IDE/Quellcode-Editor auf. Anschließend liest Svelte Inspector die Dateinamen aller in der Svelte-App vorhandenen Komponenten ein.Positioniert der Tester/Entwickler jetzt den Cursor auf ein Element der im Browser angezeigten Web-App erscheint der Dateipfad (Ablageverzeichnis der Komponente) mit dem Namen der Komponente (Bild 10). Drückt der Tester nun die beiden Eingabetasten Shift + a (Großbuchstabe A), so löst Svelte Inspector den Inspecting-Mode openFileKeyCode aus. Dadurch erklärt Svelte Inspector über das Betriebssystem die in der configuration vordefinierte IDE (standardmäßig VS Code) zur aktuellen Anwendung. Anschließend öffnet diese IDE/der Quellcode-Editor die vom Benutzer positionierte Svelte-Komponente und zeigt deren Quellcode in seinem integrierten Editor an. Jetzt kann der Tester zusammen mit dem Entwickler den Quellcode der Svelte-Komponente überarbeiten, ihn erneut ausführen und das Resultat testen.

In der Praxis zeigt sich der Einsatz von Svelte Inspector als besonders wertvoll, wenn das Entwicklungsteam für Svelte-Apps mit der Software-Technik SFC (Single File Component) arbeitet. Basiert die Anwendungsarchitektur seitens der Benutzungsschnittstelle auf einer Kopplung von SFCs, so enthält jede Komponente die gesamte Funktionalität (HTML, CSS und Java/TypeScript). Dabei kann eine SFC auch geschachtelte Komponenten enthalten, der zugehörige Quellcode befindet sich jedoch immer zentral in einer eigenen Svelte-Komponente. Bei großen, komplexen Svelte-Apps lokalisiert der Entwickler/Tester mit Svelte Inspector dann recht schnell den betroffenen Quellcode. Damit erübrigt sich eine längere Suche im generierten HTML/CSS oder JavaScript-Code mittels den Chrome DevTools.

Fehlersuche in einer Svelte-App

Für die Suche nach Fehlern in einer Svelte-App steht eine Browser-Extension Svelte Devtools zur Verfügung. Dabei handelt es sich um kein eigenständiges Tool, sondern um eine Ergänzung für die beinahe gleichnamige Erweiterung Chrome DevTools. Diese Erweiterung lässt sich in alle Browser mit integrierter Chrome V8 JavaScript Engine von Google wie Chrome, Edge, Firefox oder Opera installieren. Am zuverlässigsten arbeitet Svelte Devtools in Chrome 22 und Firefox 70.0.1 und DevTools Version 1.3.1 master mit einer Svelte-Version ab 3.15.0. Eine Suche über das GitHub-Home von Svelte nach Svelte Devtools macht das zugehörige Repository zugänglich. In der ersten Zeile der dortigen README.md-Datei findet man die entsprechenden Installations-Links.Startet man nach der Installation der Svelte Devtools eine Svelte-App im Entwicklungsmodus, so erreicht man diese Extension bei den Werkzeugen für Entwickler (Firefox), Entwicklertools (Chrome, Edge) oder Entwicklerwerkzeuge (Opera) über den Eintrag Svelte. Enthalten die Chrome DevTools sehr viele Reiter, so findet man Svelte Devtools über das Icon-Symbol mit den Doppelpfeilen >>. Nach Auswahl des Menüeintrags mit dem Namen Svelte erscheint das zugehörige Icon in der DevTools-Toolbar. Jetzt lässt sich das Svelte-Icon beliebig in der DevTools-Toolbar positionieren. Eine Position im vorderen Bereich erleichtert das Arbeiten mit Svelte Devtools, da es anschließend durch Anklicken direkt zur Verfügung steht.

Nach Auswahl des Eintrags Svelte in den Firefox DevTools oder DevTools von Chrome zeigt diese Extension einen Komponentenbaum an. In manchen Fällen erfolgt die Anzeige nicht sofort, vielmehr erscheint eine Fehlermeldung: To connect to Svelte perform… . In diesem Fall muss der Browser ein Hard Refresh durchführen – die Vorgehensweise hängt vom eingesetzten Browser und dem jeweiligen Betriebssystem ab. In einigen Fällen genügt im Text der angezeigten Fehlermeldung ein Klick auf den Link click here. Alle über Svelte Devtools angezeigten Komponenten lassen sich nach Auswahl eines dortigen Eintrags näher erkunden (Bild 11). Verändert der Programmierer den Quellcode, so führt Svelte Devtools parallel eine Aktualisierung der Einträge durch.

Jamstack – ein Architekturansatz

Bei Jamstack (früher auch JAMStack geschrieben) handelt es sich im Unterschied zu LAMP, MEAN oder MERN nicht um einen durch konkrete Tools untermauerten Software-Entwicklungs-Stack, sondern um einen Architekturansatz/ein Architektur-Pattern. Die ersten drei Buchstaben JAM stehen für JavaScript, API und Markup: Die Logik der Anwendung basiert client-seitig auf JavaScript, sie benutzt wiederverwendbare APIs und vorgefertigtes Markup. Wobei es bei der Programmierung der Funktionalität mit JavaScript keinerlei Vorgaben für ein bestimmtes Framework oder eine JavaScript-Bibliothek gibt. Alle serverseitigen Operationen erfolgen durch HTTPS-basiertes JavaScript über APIs von Bibliotheken. Die Realisierung einer Website erfolgt mittels statischer HTML-Dateien, die ein Statischer-Site-Generator (SSG) aus in Markup-programmierten Quelldateien generiert.Bei der Entwicklung einer Jamstack-Anwendung kommt idealerweise ein Git-Repository oder ein Headless-Content-Management-System (CMS) zum Einsatz – das Repository fungiert auch als Quelle für das Deployment. Die Bezeichnung Headless soll zum Ausdruck bringen, dass seitens des CMS kein fixes Frontend für die Website bereitgestellt wird. Vielmehr liefert das CMS vor allem den Content, während das Frontend eine spezielle Präsentationsschicht aufbaut. Dieses Präsentation-Layer erzeugt das User-Interface unabhängig von der eingesetzten Hardware und kann so beliebige Geräte bedienen. Der Betrieb der Anwendung findet vollständig über ein CDN (Content-Delivery/Distribution-Network) statt, so dass die Entwicklungsorganisation keine zusätzliche Infrastruktur betreiben und administrieren muss.Gegenüber der traditionellen Entwicklung einer Web-App besitzt eine auf einer Jamstack-Architektur basierende Web-App einige Vorteile. Durch den Einsatz eines CDN residiert die Web-App quasi direkt vor Ort auf dem Client, was sie eine sehr gute Performance sicherstellt. Durch den Betrieb der App über das CDN skaliert diese bei steigenden Benutzerzahlen automatisch. Bietet das CDN zusätzliche Services wie die Datenhaltung, so findet der Betrieb vollkommen serverless statt.Eine Jamstack-Architektur erlaubt eine Spezialisierung der Entwickler in Frontend- und Backend-Programmierung. Bei einfachen Apps, die lediglich aus statischen HTML-Seiten bestehen, benötigt man sogar nur Frontend-Programmierer. Somit arbeitet eine Entwicklungsorganisation viel schneller und produktiver. Der Jamstack-Ansatz bietet die Chance, die Kosten in Entwicklung und Betrieb zu senken. Bekannte CDNs, welche eine Jamstack-Architektur unterstützen, stellen Netlify und Vercel dar.

Ein einfaches Static-Site-Framework

Bei JungleJS handelt es sich um ein Static-Site-Framework für Svelte, das einem Static-Site-Generator (SSG) entspricht. Die SSG-Technik bietet für die Datenhaltung ein GraphQL-Data-Layer und unterstützt dynamisches Routing. Zur Buildtime erstellt das Framework statische HTML-Seiten, die ein CDN bereitstellt. Benötigte Daten erhält das in Svelte-programmierte Frontend über GraphQL. Damit orientiert sich JungleJS an dem in der React-Welt bekannten SSG namens Gatsby. Im GitHub-Repository von JungleJS befindet sich ein Projekt-Template, mit dem man einen Einblick für den Einsatz von JungleJS beim Aufbau eines Blogs bekommt. Der Terminalbefehl npx degit junglejs/template jungle-app erzeugt das zugehörige Projekt aus dem Template.Die wichtigsten Verzeichnisse eines Projekts stellen: jungle/build, static, src/components und src/routes dar. Im build-Ordner legt Rollup die für das Deployment der JungleJS-App benötigten Files ab. Markup-Dateien befinden sich im Verzeichnis static. Svelte-Komponenten für Routing und Zugriff auf die Datenhaltung enthält der components- und routes-Ordner. Derzeit unterstützt JungleJS nur zwei Datenformate JSON und Markdown als Auszeichnungssprache. Über ein noch zu implementierendes Plugin-System sollen weitere eingebunden werden. Die Konfiguration für Rollup und Datenhaltung erfolgt über die jungle.config.js-Datei. Störend wirkt sich die fehlende Hot Reload-Funktion in der Entwicklung aus. Leider findet aktuell keine Weiterentwicklung statt, so dass sich das Framework nur bedingt für den produktiven Einsatz eignet.Als Open-Source-Software steht Plenti seitens des Herstellers unter der Apache-Lizenz. Neben einer manuellen unterstützt der Hersteller auch eine Installation über die Paket-Manager: Homebrew (macOS), Snap (Linux) und Scoop (Windows). Im Zentrum von Plenti steht ein Git-basiertes CMS, dessen Templates auf Svelte zurückgreifen. Das CMS gehört gemäß dem Jamstack-Muster zur Kategorie der Headless-CMS. Anstatt einer Markup-Sprache nutzt Plenti allerdings einfache auf JSON basierende Datenquellen. Der Funktionsumfang, was die üblichen CMS-Features betrifft, beschränkt sich derzeit auf reines Content-Editing mit Theming; ein Backend-API befindet sich noch in Entwicklung.Der Editor einer Webseite arbeitet jedoch nicht mit JSON-Dateien, sondern wie bei einem CMS üblich über dessen User-Interface. Die Software steht aktuell für macOS und Linux zur Verfügung, unter Windows gab es bisher keine ausführlichen Tests: Der Versuch eine neu angelegte Website unter Windows auszuführen, führt daher in der Regel zu einem Fehler. Für den Einstieg in das CMS erzeugt der Programmierer ein neues Projekt mit dem Terminalbefehl: plenti new site <neues_projekt>. Beim Kommando plenti handelt es sich um das Command Line Interface (CLI) des CMS, welches der Entwickler in Go(lang) programmiert hat. Aufgrund der Implementierung mit Go benötigt der Einsatz von plenti keine Node-Installation und wegen der Auslieferung als Binärdatei auch kein Go-System.Eine Anleitung zur Benutzung des in plenti integrierten Hilfesystems gibt der Befehl plenti -h aus. Aus Sicht eines CMS-Programmierers strukturiert Plenti ein Projekt gut nach Anwendungsbereichen gegliedert: assets, content (unterteilt in blog und pages) und layouts. Die für das Templating mit Svelte verantwortlichen Komponenten befinden sich in den Unterverzeichnissen: components, content, global und scripts. Das Befehl plenti serve im Projektordner startet das CMS-Entwicklungssystem, welches als Web-App über einen integrierten Webserver auf localhost:3000 läuft. Die erzeugten Entwicklungsdateien befinden sich innerhalb des Projekts im public-Ordner. Eine Konfiguration des CMS-Entwicklungssystems erfolgt über die plenti.json-Datei.In der Konfigurationsdatei erlaubt der Bereich cms den Zugriff auf ein eigenes Git-System, das in der Grundeinstellung auf GitLab basiert. Damit steht für die Entwicklung eine bewährte DevOps-Pipeline zur Verfügung, die auch einen Betrieb der CMS-App in der Cloud ermöglicht. Vorgaben für GitLab enthält die .gitlab-ci.yml-Datei im Projektordner. Den im CMS integrierten Seiten-Editor erreicht man über die im Footer-Bereich angezeigte Toolbar. Die Schaltfläche Admin öffnet die CMS Preview-Seite, klickt man auf Login, so erscheint im Header-Bereich eine weitere Toolbar. Ein Klick auf Edit zeigt rechts die Struktur einer Seite und links ihre Vorschau an. Die Bearbeitung der Quellen erfolgt mit Hot Reload-Feature und ist auch auf Code-Ebene möglich. Zusätzliche Seiten oder Media-Daten fügen die beiden rechts in der oberen Toolbar stehenden Schaltflächen Add und Media dem Projekt hinzu.

Das Open-Source-CMS primo

Der Autor von primo hat schon früh die Vorteile von Svelte erkannt, deshalb benutzt er Svelte als Entwicklungssprache in seinem CMS. Webseiten in primo bestehen entweder aus Svelte-Komponenten und/oder aus reinen Inhaltsabschnitten, die man über die Features von Tiptap bearbeitet. Bei Tiptap handelt es sich um ein Headless-Editor-Framework, das auf ProseMirror aufbaut und mit Svelte harmonisiert. Die Gestaltung von Webpräsenzen mit primo ist sehr einfach – auch ein Publisher benötigt keinerlei Programmierwissen. Neben einer Installation der Software und reichen grundlegende Kenntnisse über das Editieren und Formatieren von Inhalten aus. Zusätzlich zum Betrieb der Software am Arbeitsplatz bietet primo die Möglichkeit, im Web einen Primo Server als Cloud-CMS einzurichten.Ein GitHub-Repository gibt Anleitungen, um den Primo Server über Vercel in der Cloud zu hosten; wobei Supabase für Authentifizierung, Datenbank-Services und Speicherplatz verwendet wird. Ein zusätzliches Logging für Primo Server steht über GitHub zur Verfügung. Mit entsprechenden Benutzerkonten richtet man schnell einen Primo Server ein, so dass alle berechtigten (noch einzurichtende) Benutzer diesen über das Web nutzen können. Der Entwickler selbst macht den Primo Server über die URL try.primo.so für den ersten Einstieg allen Interessenten zugänglich. Nach Aufruf dieser Webseite kann man die Features des visuellen CMS für das Bearbeiten der angezeigten Webseite ausprobieren.Die Desktop-Version von primo liefert der Hersteller über ein Installationsprogramm für Mac (Intel, Silicon), Windows und Linux aus. Die Software befindet sich derzeit noch im Alpha-Status, Beta soll Ende 2022 erreicht sein – daher empfiehlt der Hersteller primo noch nicht für kritische Websites/Projekte einzusetzen. Die Installation erfolgt schnell und automatisch; nach Start der Desktop-App steht primo für anfallende Arbeiten bereit.Ein Klick auf die Schaltfläche + create a site erzeugt eine neue Webpräsenz und öffnet deren Definitionsfenster. In diesem vergibt man der Webpräsenz einen Namen, eine ID und wählt eine Vorlage aus. Dabei bietet primo einige Vorlagen für den Aufbau der Website an – auch eine eigene primo JSON-Datei kann man als Ausgangspunkt hochladen. Anschließend öffnet sich der visuelle primo-Editor, um die Seiten der Webpräsenz und ihre Inhalte zu bearbeiten.

Bearbeiten, Gestalten und Freigeben

Das Editieren einfacher Inhalte, reine Textbereiche (auch Sections genannt), erfolgt wie bei jedem Texteditor üblich durch Anklicken und Tastatureingaben. Für deren Gestaltung befinden sich an ihrem unteren Fensterbereich weitere Tools, die Realisierung basiert auf Tiptap. Derartige Textbereiche kommen im Internet sehr häufig vor. Komplexere Inhalte bearbeitet man nach dem Anklicken durch Klick auf die Schaltfläche Edit Content. Bei diesem Inhalttyp handelt es sich um Svelte-Komponenten, die eigene Eigenschaften/Attributfelder besitzen. Nach Klick auf das Edit Content-Icon erscheint links neben der Voransicht der Seite ein Eingabeformular. Über dieses Formular verändert man die Einstellungen der vorhandenen Seitenelemente, legt eine neue Seiten-Navigation innerhalb der Webpräsenz, URL/Web-Verweise oder Schaltflächen an.Alle Änderungen zeigt primo bereits während der Eingabe über die Tastatur in der rechten visuellen Voransicht an. Der Webseiten-Editor von primo verfügt über zwei Bearbeitungsmodi: CMS und IDE. Das ganz rechts im Hauptfenster von primo neben der Schaltfläche Aktuelle Seite neu laden stehende Switch to IDE/Switch to CMS-Icon schaltet zwischen diesen beiden Bearbeitungsmodi um. Im IDE-Modus findet sich ein Svelte-Programmierer sofort zurecht: Der Editor zeigt in drei vertikalen Fensterspalten die Svelte-Komponente aufgeteilt in ihre drei Bestandteile HMTL, CSS und JavaScript an. Jede der drei Fensterspalten enthält unten rechts einen URL-Verweis mit dem Namen Docs. Klickt man auf diesen Verweis startet ein Webbrowser und öffnet die dazugehörige Dokumentation von primo mit näheren Erläuterungen.Eine weitere Möglichkeit die Webpräsenz zu bearbeiten, bietet das Hauptfenster über die Einträge in der Toolbar – im IDE-Modus lauten diese:Rechts neben den gerade erläuterten Toolbar-Einträgen befinden sich in beiden IDE-Modi weitere, die spezielle Funktionen ausführen:Befindet sich primo im visuellen Bearbeitungsmodus, erscheint in der Toolbar ein neuer Eintrag Content, dafür blendet primo die Einträge Components, HTML, CSS und Fields aus. Über den Content-Eintrag bearbeitet man die Felder/Attribute einer Webseite; dazu gehören Verweise auf Social Links, Dateien wie Icons oder Bilder und die Site Navigation.Für die beiden Verweistypen (Social Links, Site Navigation) steht eine Add-Schaltfläche zur Verfügung, um vorhandene Navigationselemente zu ändern, weitere anzulegen, vorhandene Ziele zu ändern oder neue zu definieren. Die obenstehende ganz rechte Schaltfläche Publish erlaubt es, die mit primo erstellte Webpräsenz auf die Festplatte in einem ZIP-Archiv zu sichern (Download Site), um sie später über einen Webserver zu hosten. Alternativ führt diese Schaltfläche ein Deployment der Webpräsenz (Connect a host) auf Vercel oder Netlify durch.