Wie wir nopa bauen, Teil 2

Es gibt nichts, wohin hochgeladen würde

Die meisten Tool-Seiten sind eine Seite vor einem Server: Deine Datei geht hoch, der Server arbeitet, das Ergebnis kommt zurück. nopa dreht das um. Die Seite besteht aus statischen Dateien – HTML, JavaScript, Schriften –, und der Code kommt zu dir statt deine Datei zu ihm. Wenn du zwei PDFs zusammenfügst, läuft das in deinem Tab, und das PDF verlässt ihn nicht.

Deshalb gibt es auch kein Konto. Ein Konto existiert, um etwas von dir auf einem Server aufzubewahren, und es gibt keinen Server, der etwas aufbewahrt – also auch nichts, wo man sich anmelden müsste.

Schwere Arbeit, im Tab

Der Browser ist eine ernsthafte Maschine geworden, und jedes Werkzeug nimmt den Teil davon, der zur Aufgabe passt:

• PDFs: pdf-lib baut und schreibt die Datei um, PDF.js zeichnet die Seiten, die du siehst. Komprimier ein PDF, und beide laufen auf deinem Gerät.
• Fotos und Audio: Neuronale Netze laufen in WebAssembly auf ONNX Runtime. Die Werkzeuge, die den Hintergrund entfernen und Audio transkribieren, laden ihr Modell einmal und behalten es; dein Foto geht zum Modell, nie umgekehrt.
• Scans: tesseract.js liest den Text einer gescannten Seite in einem eigenen Thread. Beim ersten Mal lädt es ein Lesemodell von 4–5 MB, danach ist es schon da.
• Word-Dateien: mammoth liest eine .docx, docx schreibt sie zurück – so öffnet der Word-Editor den Vertrag, den man dir geschickt hat, und gibt ihn als echte Word-Datei zurück.
• Spiele: jsnes betreibt ein ganzes NES in JavaScript. Die NES-Seite bringt zwei Homebrew-Spiele mit, deren Autoren das erlauben, und spielt deine eigene .nes-Datei, ohne sie hochzuladen.

Der Preis: Der Code muss zu dir kommen

Das hat eine Kehrseite. Ein Server-Tool schickt dir eine leichte Seite und erledigt das Schwere dort, wo du es nicht siehst; wir müssen dir das Schwere schicken. Also zählen wir es: Ein Skript in unserem Repo öffnet jede Seite in einem echten Browser und addiert das JavaScript, das sie lädt, bevor du irgendetwas drückst. Der erste Durchlauf fand Seiten, die 1,4 MB umsonst zogen – die ganze Geschichte mit Zahlen steht in einem früheren Beitrag.

Die Regel seitdem: Eine Engine lädt, wenn ihr Knopf gedrückt wird. Die PDF-Engine kommt, wenn du ein PDF öffnest, das Lesemodell, wenn du einen Scan lesen lässt. Diese Woche hat die Regel noch einen Fall erwischt: Das Board lud bei jedem Öffnen eine PDF-Bibliothek von 170 KB – für einen einzigen Menüpunkt.

Wo deine Arbeit liegt

Was du speicherst – ein Board, eine Aufgabenliste, ein Dokument, die Dateien, die die Werkzeuge erzeugen –, landet in IndexedDB, der eigenen Datenbank des Browsers, auf deinem Gerät. Die Apps speichern, während du arbeitest: Tab zu, und alles ist da, wo du aufgehört hast.

Der ehrliche Teil: Dieser Speicher gehört diesem Browser. Lösch die Websitedaten, und er ist weg; nimm dein Handy, und dort ist er nicht. Deshalb ist ein Backup einen Klick entfernt – der ganze Desktop als eine Datei, unter Einstellungen → Daten –, und auf demselben Bildschirm kannst du den Browser bitten, nopa nicht zu löschen, wenn der Speicher knapp wird.

Offline, nach dem ersten Besuch

Ein Service Worker hält eine Kopie der App auf deinem Gerät, sodass die Werkzeuge nach dem ersten Öffnen auch ohne Verbindung starten. Nicht alles wird vorab gespeichert: Modelle für neuronale Netze und das Lesemodell kommen erst, wenn ein Werkzeug sie braucht – ein Handy soll nicht hundert Megabyte Modelle auf Verdacht mit sich herumtragen.

Prüf es selbst

Öffne die Entwicklerwerkzeuge deines Browsers, wechsle in den Network-Tab und benutze ein beliebiges Werkzeug. Du siehst zwei Arten von Anfragen: unseren eigenen Code, der von nopa.space kommt, und Besuchsstatistik für Yandex Metrica und PostHog – welche Seite geöffnet, welches Werkzeug benutzt wurde. Du siehst nicht, wie deine Datei irgendwohin geht, denn das tut sie nicht. Ein Inhaltsblocker schaltet die Statistik ab, und alle Werkzeuge funktionieren genauso.

Einmal lagen wir hier selbst falsch. Das Panel auf unseren Produktseiten versprach „kein einziger POST“ – gemessen an einem Build ohne Statistik, während der Zähler in Produktion eigene POSTs schickt. Eine Leserin hätte das in zehn Sekunden bemerkt; wir haben es diese Woche bemerkt und das Panel so umgeschrieben, dass es genau sagt, was du sehen wirst.

Was dieses Design nicht kann

Ein Server kann Dinge, die ein Tab nicht kann, und das sagen wir lieber selbst:

• Keine Synchronisierung. Handy und Laptop haben jeweils ihre eigene Kopie; eine Backup-Datei trägt sie hinüber, eine Live-Verbindung gibt es nicht.
• Keine Zusammenarbeit in Echtzeit. Zwei Leute an einem Board brauchen einen Server dazwischen.
• Der erste Start eines KI-Werkzeugs wartet, bis sein Modell geladen ist.
• Ein Handy ist langsamer als ein Rechenzentrum. Das meiste dauert einen Moment; eine Stunde Audio dauert eine Weile.

Wie es weitergeht

Wenn auf deinem Gerät etwas kaputtgeht oder dir ein Werkzeug fehlt, schreib an hello@nopa.space – es liest ein Mensch. Oder fang mit dem Katalog an; Teil eins, darüber, warum es nopa überhaupt gibt, steht hier.