Harper im Test: der offline Grammatikchecker aus Rust im Editor

Warum Harper als Grammatikchecker in Rust entstanden ist

Harper ist ein englischer Grammatikchecker aus dem Hause Automattic, geschrieben in Rust und unter der Apache-2.0 lizenziert. Die Entstehungsgeschichte steht unverblümt im README und erklärt die Designentscheidungen besser als jede Featureliste. Grammarly sei zu teuer und zu bevormundend gewesen, seine Vorschläge mangelten an Kontext und seien oft schlicht falsch. Hinzu kommt der Datenschutz: Beim Schreiben mit Grammarly geht alles an deren Server, die Privatsphärenrichtlinie behauptet zwar, die Daten nicht zu verkaufen, verwendet sie aber laut Autor unter anderem zum Training großer Sprachmodelle.

Auch LanguageTool kommt in dieser Abrechnung schlecht weg, wenn auch aus anderen Gründen: Wer den vollen Funktionsumfang will, lädt nach dieser Quelle ein N-gram-Dataset von rund 16 GB und benötigt Gigabytes an Arbeitsspeicher, und selbst ein mittelgroßes Dokument brauche Sekunden zum Prüfen. Harper behauptet von sich, ein Dokument in Millisekunden zu prüfen, weniger als ein Fünfzigstel des Speicherbedarfs von LanguageTool zu benötigen und dabei vollständig offline zu arbeiten. Diese drei Aussagen sind selbst berichtet, sie definieren aber exakt das Ziel des Projekts.

harper-ls: die Integration in VS Code, Neovim, Helix, Emacs und Zed

Der zentrale Baustein ist harper-ls, ein Language Server, der als Paket auf crates.io liegt. Über das Language Server Protocol hängt sich der Prüfer an die Editoren, für die das Projekt eigene Dokumentationen pflegt: Visual Studio Code, Neovim, Helix, Emacs und Zed. Dazu kommt Obsidian als Notiz-Anwendung mit eigener Integrationsseite. Der Vorteil dieses Musters liegt in der Einheitlichkeit: Konfiguration, Diagnosen und Schnellkorrekturen verhalten sich in jedem unterstützten Editor gleich, weil die Logik nicht im Plugin, sondern im Server steckt.

Für den Alltag bedeutet das, dass der Text das Gerät nie verlässt. Prüfung und Vorschläge entstehen im lokalen Prozess, es gibt keinen Anmeldezwang und keinen Netzwerk-Roundtrip, der wie beim kritisierten Vorbild das Überarbeiten verlangsamt. Wer Rust selbst baut, findet die Quellen im Master-Branch, die Release-Pipeline erzeugt fertige Binaries. Die Versionshistorie zeigt ein lebendiges Projekt: v2.7.0 erschien Ende Juli 2026, v2.8.0 Mitte August, v2.9.1 zum Redaktionsstand am 29. August.

harper.js und WebAssembly: Grammatikprüfung ohne Server

Eine bemerkenswerte Eigenschaft nennt das README am Rand, sie verdient aber eigenen Raum: Harper ist klein genug, um über WebAssembly geladen zu werden. Die Dokumentation für harper.js liegt separat auf writewithharper.com, damit lässt sich der Prüfer in Webanwendungen einbetten, ohne einen Backend-Dienst zu betreiben. Der gesamte Analyse-Code läuft dann im Browser des Nutzers.

Daraus ergeben sich konkrete Einsatzfälle. Ein CMS-Anbieter kann Redakteuren einen Grammatikcheck anbieten, ohne Texte an Dritte weiterzuleiten, ein Offline-Tool kann die Prüfung mitbringen, ohne eine Runtime auszuliefern. Die Grundidee teilt die Architektur: Der Checker ist eine Bibliothek mit mehreren Fronts, einmal als Language Server für Editoren, einmal als WASM-Modul für das Web. Für die Bewertung heißt das, man kaufet kein Monolith, sondern wähle pro Umgebung den passenden Einstiegspunkt.

Sprachumfang bei Harper: Englisch heute, Erweiterungen durch Beiträge

Die klarste Grenze steht im Abschnitt Language Support: Harper unterstützt derzeit nur Englisch. Das Kernstück ist laut README aber so gebaut, dass weitere Sprachen ergänzt werden können, und Beiträge in diese Richtung werden ausdrücklich gewünscht. Für Muttersprachler und Fachleute, die englische Dokumentation, Issues oder Blogbeiträge schreiben, deckt das den Hauptbedarf ab, für mehrsprachige Teams fällt die Auswahl dagegen schwer.

Wer eine zweite Sprache braucht, hat imMoment keine Wahl bei Harper und muss parallel ein anderes Werkzeug betreiben, etwa LanguageTool, das eine deutlich breitere Sprachabdeckung mitbringt. Der Preis dafür ist bekannt: Java-Runtime, hoher Arbeitsspeicherbedarf und nach Angabe des Harper-Autors spürbare Lint-Zeiten. Beide Ansätze schließen sich nicht aus, sie adressieren aber unterschiedliche Profile. Die Entscheidung hängt am Sprachmix der eigenen Texte, nicht an der Geschwindigkeit allein.

Lange Lint-Zeiten gelten als Bug: der Performanceanspruch von Harper

Ungewöhnlich für ein Open-Source-Projekt ist die offizielle Haltung zur Geschwindigkeit. Im Abschnitt Performance Issues erklärt das Team, lange Prüfzeiten würden als Bugs betrachtet. Wer eine spürbare Verlangsamung entdeckt, soll einen Issue anlegen, wer eine Lösung findet, darf sie beitragen, nach Lektüre der Contribution Guidelines auf writewithharper.com. Das ist ein konkreter Qualitätspakt, keine Marketingzeile: Performancezuschlag wird als Defekt mit Fehlerstatus behandelt.

Für die Bewertung des Selbstberichts, ein Dokument in Millisekunden zu prüfen, bleibt eine Einschränkung. Das README nennt keine Messumgebung, keine Dokumentgrößen und keinen Vergleichswert in Sekunden, die Zahlen sind also eher Zielsetzung als Benchmark. Wer auf die Angabe baut, testet mit dem eigenen Textbestand: Ein langes Markdown-Dokument im eigenen Editor prüfen lassen und die Spürbarkeit der Verzögerung bewerten, sagt mehr als jede Angabenliste im README.

Grenzen von Harper und die Abgrenzung zu LanguageTool und Grammarly

Drei Einschränkungen sind beim Einsatz zu bedenken. Erstens die Sprachabdeckung, nur Englisch, was oben bereits ausführlich behandelt wurde. Zweitens die Community-Größe: Über 14.700 Sterne stehen rund 860 offenen Issues gegenüber, ein Verhältnis, das auf rege Nutzung und gleichzeitig auf Wartungsbedarf hinweist. Drittens die Herkunft der Aussagen: Die Vergleiche mit Grammarly und LanguageTool stammen vom Projektautor und sind Meinungsäußerung, nicht neutraler Test.

Die realistische Abwägung sieht so aus. Für englische Texte im Editor mit Priorität auf Datenschutz und Reaktionszeit ist Harper die schlanke Wahl. Wer deutschsprachige oder mehrsprachige Texte prüft, kommt um LanguageTool nicht herum, nimmt dafür Speicherbedarf und Prüfzeiten in Kauf. Grammarly bleibt für Nutzer interessant, die Browserintegration und den Abgleich mit dessen Sprachmodell wollen, und akzeptieren, dass jeder Text den eigenen Rechner verlässt. Eine dritte Alternative ist die eingebaute Rechtschreibprüfung des Editors: kostenlos, ohne Abhängigkeit, aber ohne Grammatikregeln und Kontextprüfung.

Redaktionelles Fazit

Harper passt zu Autoren und Entwicklern, die beim Schreiben von Englisch in VS Code, Neovim, Helix, Emacs, Zed oder Obsidian Hinweise direkt im Editor wollen, ohne Text an einen Cloud-Dienst zu schicken und ohne eine schwergewichtige Java-Umgebung zu betreiben. Ungeeignet ist es für mehrsprachige Redaktionen, denn unterstützt wird nur Englisch, und für Nutzer, die belastbare Vergleichsmessungen erwarten, denn die Zahlen im README sind selbst berichtet. Vor dem Umstieg sollte man harper-ls in einem realen Dokument gegen die eigene Referenz laufen lassen und prüfen, ob die Vorschläge im eigenen Fachwortschatz weniger Fehlalarme als die bisherige Lösung erzeugen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes