Sechs Megabyte. So groß ist eine komplette Desktop-App mit TinyJS, kleiner als ein einzelnes RAW-Foto vom Smartphone. Zum Vergleich: Eine leere Electron-App bringt allein durch das gebündelte Chromium und Node.js mindestens 150 Megabyte auf die Waage, bevor überhaupt eine Zeile eigener Code geschrieben wurde. Diese Diskrepanz ist der Grund, warum das am 12. Oktober 2026 von The Register vorgestellte Projekt TinyJS von Entwickler Tarwin Stroh-Spijer in der JavaScript-Community für Aufmerksamkeit sorgt.
TinyJS positioniert sich als ernstzunehmende TinyJS Electron Alternative für Entwickler, die plattformübergreifende Desktop-Anwendungen bauen wollen, ohne dafür ein komplettes Browser-Engine mitzuschleppen. Das Open-Source-Framework kombiniert eine winzige JavaScript-Runtime mit dem nativen Webview des jeweiligen Betriebssystems, und verspricht damit den Spagat zwischen Webtechnologien und echter Leichtgewichtigkeit.
Inhaltsverzeichnis
Key Takeaways
- TinyJS ist ein neues, quelloffenes Framework (MIT-Lizenz) für Desktop-Apps auf macOS, Windows und Linux, veröffentlicht von Tarwin Stroh-Spijer.
- Die Architektur trennt Backend (txiki.js, ca. 5,6 MB) und Frontend (natives System-Webview) strikt und verbindet beide über einen lokalen Unix-Socket bzw. eine Named Pipe, nicht über HTTP.
- Fertige TinyJS-Apps sind laut Projekt-Website rund 6 MB groß, verglichen mit mindestens 150 MB bei Electron, etwa 10 MB bei Tauri und etwa 3 MB bei Neutralino.
- macOS gilt als stabil, signiert und notarisiert; Windows und Linux befinden sich im Beta-Status.
- Entwickler können mit gewohntem HTML, CSS und JavaScript arbeiten, inklusive WebGPU und Vite-Templates für React, Vue, Svelte, Solid, Preact, Lit und Alpine.
Was ist TinyJS genau?
TinyJS ist ein Framework, mit dem sich aus Webtechnologien eigenständige Desktop-Anwendungen bauen lassen. Wichtig für die Einordnung: Es handelt sich nicht um die gleichnamigen, deutlich älteren JavaScript-Mini-Engines oder Embedded-Scripting-Projekte, die unter demselben Namen kursieren. Das hier besprochene TinyJS ist ein 2026 neu vorgestelltes Projekt des Entwicklers Tarwin Stroh-Spijer, zu finden unter tinyjs.app und im GitHub-Repository github.com/tarwin/tinyjsapp.
Die Grundidee ist simpel formuliert, aber technisch anspruchsvoll umgesetzt: Warum soll jede Desktop-App ihr eigenes Chromium mitbringen, wenn das Betriebssystem bereits ein leistungsfähiges Webview mitliefert? Genau an diesem Punkt setzt die TinyJS Electron Alternative an und spart dadurch den größten Teil des Speicherplatzes ein, den klassische Electron-Anwendungen benötigen.
Die technische Architektur im Detail
TinyJS basiert auf einem Zwei-Prozess-Modell, das klar zwischen Logik und Darstellung trennt. Diese Trennung ist der Kern dessen, was TinyJS von anderen Frameworks unterscheidet.
Der Backend-Prozess: txiki.js als Fundament
Das Rückgrat von TinyJS bildet txiki.js, eine ultrakompakte JavaScript-Runtime von Saul Ibarra Corretge. Sie basiert auf der Kombination aus QuickJS (einer kleinen, aber vollständigen JavaScript-Engine) und libuv (der Event-Loop-Bibliothek, die auch Node.js antreibt). Mit rund 5,6 MB ist txiki.js selbst schon ein Leichtgewicht.
Dieser Backend-Prozess erhält vollen Systemzugriff. Dazu gehören:
- Dateisystem-Operationen
- Netzwerk-Sockets
- Prozessverwaltung
- FFI (Foreign Function Interface) für den Zugriff auf native Bibliotheken
- SQLite als eingebaute Datenbank
- moderne Web-APIs wie fetch und WebSocket
Damit stehen Entwicklern praktisch alle Werkzeuge zur Verfügung, die man von einer vollwertigen Node.js-Umgebung erwartet, nur eben in einem Bruchteil der Größe.
Das Frontend: natives System-Webview statt Chromium
Während das Backend die Logik übernimmt, kümmert sich das Frontend ausschliesslich um die Darstellung. Hierfür greift TinyJS auf das Webview zurück, das ohnehin bereits auf dem jeweiligen Betriebssystem installiert ist:
- macOS: WebKit (Safaris Engine)
- Windows: WebView2, basierend auf Chromium
- Linux: WebKitGTK
Dieser Ansatz ist nicht neu, auch Tauri nutzt ihn. Doch TinyJS geht bei der Kommunikation zwischen beiden Prozessen einen bemerkenswerten eigenen Weg.
Kommunikation ohne offenen Port
Viele webbasierte Desktop-Frameworks lassen Backend und Frontend über HTTP kommunizieren, was faktisch bedeutet: Im Hintergrund läuft ein kleiner Webserver, oft mit einem lokal geöffneten Port. Das ist ein potenzielles Sicherheitsrisiko und sorgt gelegentlich für Konflikte mit Firewalls oder anderen Anwendungen.
TinyJS verzichtet bewusst darauf. Stattdessen läuft die Verbindung zwischen Backend-Prozess und Webview-Fenster über:
- einen privaten Unix-Socket auf macOS und Linux
- eine Named Pipe auf Windows
Beide Mechanismen liegen in einem temporären Verzeichnis mit den Zugriffsrechten 0700, lesbar und schreibbar nur für den eigenen Benutzer. Es gibt keinen offenen Netzwerk-Port und keinen klassischen Webserver, der von aussen angesprochen werden könnte. Diese Entscheidung reduziert die Angriffsfläche spürbar und ist einer der technischen Aspekte, die TinyJS als Electron Alternative besonders für sicherheitsbewusste Entwicklerteams interessant macht.
"Man muss kein ganzes Chromium mitliefern, nur um ein HTML-Fenster zu zeigen", so lässt sich die Kernphilosophie hinter TinyJS zusammenfassen, die im Bericht von The Register beschrieben wird.
TinyJS Electron Alternative im direkten Größenvergleich
Der wohl überzeugendste Grund, sich mit TinyJS zu beschäftigen, ist schlicht die Dateigröße fertiger Anwendungen. Laut Angaben auf tinyjs.app ergibt sich folgendes Bild:
| Framework | Ungefähre App-Größe | Technischer Ansatz |
|---|---|---|
| Electron | mindestens 150 MB | Bündelt Node.js plus komplettes Chromium |
| Tauri | ca. 10 MB | Rust-Backend, System-Webview |
| TinyJS | ca. 6 MB | txiki.js-Backend, System-Webview |
| Neutralino | ca. 3 MB | Leichtgewichtiges Backend, System-Webview |
Diese Zahlen stammen direkt von der Projekt-Website und zeigen: TinyJS liegt zwischen Tauri und Neutralino, bleibt aber meilenweit unter Electron. Wer heute eine neue Desktop-App plant und Größe sowie Ressourcenverbrauch als Entscheidungskriterium hat, kommt an diesem Vergleich kaum vorbei.
Plattformstatus: Wo steht TinyJS heute?
Nicht alle unterstützten Plattformen sind gleich weit entwickelt. Der aktuelle Stand lässt sich so zusammenfassen:
macOS gilt als stabil. Anwendungen werden signiert und notarisiert ausgeliefert, was für Nutzer bedeutet, dass macOS Gatekeeper keine Warnmeldungen anzeigt und die App ohne Umwege installierbar ist.
Windows (Version 10 und 11) ist als Beta gelistet. Einzige Voraussetzung ist die WebView2-Runtime, die auf Windows 11 bereits vorinstalliert ist. Nutzer von Windows 10 müssen die Runtime gegebenenfalls nachinstallieren.
Linux befindet sich ebenfalls im Beta-Stadium, unterstützt dabei aber bereits sowohl x86_64- als auch arm64-Architekturen. Voraussetzung ist das Paket libwebkit2gtk-4.1-0, das auf den meisten gängigen Distributionen über den Paketmanager installiert werden kann.
Für produktive Projekte bedeutet das: macOS-Deployments können schon heute als verlässlich gelten, während Windows- und Linux-Builds noch mit gelegentlichen Kinderkrankheiten rechnen sollten.
Frontend-Entwicklung: Bekannte Werkzeuge, neue Umgebung
Ein entscheidender Vorteil von TinyJS als Electron Alternative ist, dass sich am eigentlichen Frontend-Workflow kaum etwas ändert. Entwickler schreiben normales HTML, CSS und JavaScript, inklusive Unterstützung für moderne Grafik-APIs wie WebGPU, was TinyJS auch für rechenintensive visuelle Anwendungen interessant macht.
Für den schnellen Einstieg stehen über Vite vorgefertigte Templates für folgende Frameworks bereit:
- React
- Vue
- Svelte
- Solid
- Preact
- Lit
- Alpine
Wer bereits mit einem dieser Frameworks arbeitet, kann sein vorhandenes Wissen direkt übertragen, ohne die gewohnte Toolchain aufzugeben.
Installation: So startet man mit TinyJS
Der Einstieg in TinyJS ist bewusst niedrigschwellig gehalten und orientiert sich an Installationsmustern, die aus anderen Entwickler-Tools bekannt sind.
Für macOS und Linux erfolgt die Installation über ein curl-basiertes Skript direkt im Terminal. Für Windows steht ein entsprechendes PowerShell-Skript bereit. Wer lieber aus dem Quellcode bauen möchte, findet im Repository ein setup.sh-Skript, das den kompletten Build-Prozess automatisiert.
Diese Installationswege sind bewusst simpel gehalten, damit Entwickler innerhalb weniger Minuten vom leeren Terminal zu einer lauffähigen Entwicklungsumgebung gelangen, ein Aspekt, der gerade bei Vergleichen mit komplexeren Setup-Prozessen anderer Frameworks positiv auffällt.
TinyJS im Vergleich zu Electron, Tauri und Neutralino
Die Frage, ob TinyJS als Electron Alternative taugt, lässt sich nicht pauschal beantworten, sondern hängt vom Anwendungsfall ab.
Gegenüber Electron ist der Vorteil von TinyJS eindeutig die Dateigröße und der geringere Ressourcenverbrauch, da kein zusätzliches Chromium im Hintergrund läuft. Electron bietet dafür maximale Konsistenz der Rendering-Engine über alle Plattformen hinweg, da überall dasselbe Chromium verwendet wird, ein Punkt, den TinyJS mit seinen drei unterschiedlichen nativen Webviews nicht bieten kann.
Gegenüber Tauri, das ebenfalls auf native Webviews setzt, unterscheidet sich TinyJS vor allem im Backend: Statt auf Rust zu setzen, bleibt TinyJS vollständig im JavaScript-Ökosystem und nutzt mit txiki.js eine Runtime, die Entwicklern ohne Rust-Kenntnisse den Einstieg erleichtert.
Gegenüber Neutralino, das mit rund 3 MB noch kompakter ausfällt, bietet TinyJS laut den verfügbaren Informationen einen umfangreicheren Backend-Funktionsumfang, etwa durch die native SQLite-Unterstützung und FFI-Zugriff.
Für wen eignet sich TinyJS?
TinyJS richtet sich vor allem an Entwickler, die folgende Prioritäten haben:
- Kleine Download- und Installationsgrößen für Endanwender
- Vollen JavaScript-Workflow ohne Wechsel in eine andere Programmiersprache
- Sicherheitsbewusste Architektur ohne offene lokale Ports
- Zugriff auf native Systemfunktionen wie Dateisystem, Prozesse und Datenbanken
Weniger geeignet ist TinyJS aktuell für Teams, die auf allen drei Plattformen produktionsreife Stabilität ab Tag eins benötigen, da Windows und Linux noch im Beta-Status verweilen.
Wer sich generell für aktuelle JavaScript-Runtime-Entwicklungen interessiert, findet in unserem Artikel zum Node.js 27 Release-Zyklus weiteren Kontext zur Richtung des JS-Ökosystems.
Fazit und nächste Schritte
TinyJS zeigt, dass der Weg zu kleineren, schlankeren Desktop-Anwendungen nicht zwangsläufig über eine neue Programmiersprache führen muss. Mit txiki.js als kompaktem Backend und den jeweiligen System-Webviews als Frontend gelingt es dem Projekt, App-Größen von rund 6 MB zu erreichen, ein Wert, der Electron-Anwendungen um das Zwanzigfache oder mehr unterbietet, ohne dabei den vertrauten JavaScript-Workflow aufzugeben.
Die durchdachte Kommunikation über Unix-Sockets und Named Pipes statt über offene HTTP-Ports ist ein zusätzliches Argument für sicherheitsbewusste Entwicklerteams. Gleichzeitig bleibt zu beachten, dass nur die macOS-Version bereits als stabil gilt, während Windows und Linux noch an Reife gewinnen müssen.
Entwickler, die eine TinyJS Electron Alternative für ihr nächstes Projekt in Betracht ziehen, sollten in einem ersten Schritt das GitHub-Repository unter github.com/tarwin/tinyjsapp sowie die offizielle Projekt-Website tinyjs.app sichten, die Installationsskripte für die eigene Plattform testen und ein kleines Beispielprojekt mit einem der verfügbaren Vite-Templates aufsetzen. Angesichts des frühen Entwicklungsstadiums empfiehlt es sich, produktive Einsätze zunächst auf macOS zu konzentrieren und Windows- sowie Linux-Builds parallel im eigenen Tempo zu evaluieren, bevor sie in kritischen Projekten zum Einsatz kommen.
