studio

studio ist ein Desktop-Entwicklerwerkzeug, das die Arbeit mit Moodboards, Schnitten und Sitzungen bedient - Dinge, bei denen es auf ständigen, schnellen Zugriff auf Dateien auf der Festplatte ankommt. Diese Fallstudie behandelt, wie man ein solches Werkzeug nativ baut, ohne dabei den Code für jedes Betriebssystem zu vervielfachen.

Die Prämisse war zweiseitig. Einerseits soll sich das Werkzeug wie ein natives Programm anfühlen: Dateien griffbereit, Betrieb ohne Netz, flüssig auch bei einer großen Sitzung. Andererseits soll es ein Repository und ein Kern bleiben, nicht drei separate Apps, die dann dreifach gepflegt werden müssen.

Die Arbeit mit Moodboards und Schnitten bedeutet ständiges Greifen zu den Festplatten: Hunderte von Dateien, Projektverzeichnisse, Vorschauen, die sofort erscheinen sollen. Ein Browser hält all das hinter einer Sandbox-Wand. Jeder Dateizugriff ist ein Dialog, kein Netz bedeutet keine App, und bei einer größeren Sitzung fängt die Oberfläche an zu würgen.

Wir wollten ein Werkzeug, das Dateien griffbereit hat wie ein natives Programm, ohne Netz funktioniert und bei einer großen Sitzung nicht langsamer wird. Aber ohne die Falle, in die man beim nativen Schreiben leicht tappt: separater Code für Windows, macOS und Linux, der dann zwischen den Plattformen auseinanderdriftet und die Arbeit bei jeder Änderung vervielfacht.

Tauri kehrt die von Electron bekannte Anordnung um. Die Oberfläche schreiben Sie einmal, webbasiert, aber Sie schleppen nicht den ganzen Browser mit sich - das Fenster nutzt die Rendering-Engine des Systems, während die ganze schwerere Arbeit, der Dateizugriff und die Logik in einem Rust-Kern sitzen. Das Ergebnis ist ein Binary, das in Megabyte gemessen wird, nicht in Hunderten von Megabyte, und ein echter Systemzugriff, den eine verpackte Seite nie hatte.

Der Unterschied ist nicht kosmetisch. Electron liefert seine eigene Kopie der Browser-Engine mit jeder App aus, sodass jedes Werkzeug für dasselbe Chromium erneut bezahlt. Tauri nutzt, was das System bereits hat, und fügt nur eine dünne eigene Schicht hinzu. Bei einem Werkzeug, das schnell und leicht sein soll, ist das der Unterschied zwischen funktioniert und funktioniert sofort.

Die Aufteilung ist sauber, und sie ist es, die die ganze Architektur im Zaum hält: Web zeichnet, Rust macht. Die Ansichten von Moodboards und Schnitten werden einmal geschrieben, webbasiert, während Dateioperationen, Indizierung und alles, was schnell und offline sein soll, über Tauri-Befehle zu einem Kern gehen, der nichts über das Aussehen weiß.

Der Rust-Kern ist eine eigenständige Bibliothek: Dateiladen, Indizierung, das Sitzungsmodell. Sie hängen nicht davon ab, wer sie zeichnet, sodass sich dieselbe Logik ohne Oberfläche testen und über denselben Vertrag auf jeder Plattform bereitstellen lässt. Die Ansicht ist eine dünne Schicht obenauf und nicht der Ort, an dem das Wissen über das Projekt wohnt.

Die saubere Aufteilung hat noch einen Vorteil: Es gibt nur einen Ort, an dem man Fehler ernsthaft bewachen muss. Innerhalb des Kerns vertrauen wir unseren eigenen Typen - wenn eine Sitzung geladen ist, ist ihr Modell korrekt. Aber ein Dateipfad, der aus der Ansicht kommt, ist eine Eingabe von außen. Er existiert vielleicht nicht, er kann auf eine beschädigte Datei zeigen, er kann ein Rest eines verschobenen Projekts sein.

Deshalb sitzt die Validierung genau an der Grenze - am Tauri-Befehl - und ist nicht sicherheitshalber über den ganzen Kern verschmiert. Dort, wo das Web auf Rust trifft, wird ein Fehler zu einer lesbaren Meldung für den Benutzer; tiefer müssen wir dasselbe nicht ein zweites Mal prüfen.

Das Werkzeug startet schnell, hat Dateien griffbereit und braucht kein Netz, um zu funktionieren - und vervielfacht trotzdem nicht den Code pro System. Ein Repo, ein Rust-Kern, eine dünne Ansichtsschicht obenauf und separate Apps am Ausgang, aus derselben Quelle gebaut.

Für die Person, die es benutzt, bedeutet das, dass sich das Werkzeug wie ein natives Programm verhält und nicht wie eine Seite, die eine App vortäuscht: Sie zeigen auf Dateien direkt von der Festplatte, die Arbeit geht ohne Netz weiter, und die Oberfläche würgt nicht bei einer großen Sitzung. Für die Pflege bedeutet es, dass eine im Kern hinzugefügte neue Funktion alle drei Plattformen zugleich erreicht, statt dreimal separat geschrieben und kaputtgemacht zu werden.