Univer: Das isomorphe Office-SDK für eigene Tabellen-, Dokument- und Folien-Oberflächen
dream-num/univer bietet eine praxistaugliche Open-Source-Implementierung mit stabiler Einsatzbarkeit für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Was das TypeScript-Monorepo dream-num/univer bietet: Plugin-Architektur, Canvas-Rendering, eine Facade API für Browser und Node.js sowie eine klare Trennung zwischen OSS-Kern und kommerzieller Pro-Ebene.
- Für wen ist es gedacht?
- Univer richtet sich an Teams, die Tabellen- oder Dokumentbearbeitung in ein eigenes Produkt einbetten wollen, etwa in ein SaaS-Angebot, ein internes Tool oder eine KI-Anwendung. Es ist kein fertiges Office-Paket und kein Betrachter.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein SDK statt einer gehosteten App: Die Positionierung von Univer
dream-num/univer bündelt ein quelloffenes SDK zum Erzeugen von Office-Anwendungen innerhalb eines eigenen Produkts. Das README beschreibt es als Full-Stack und isomorph: Dieselbe Architektur soll Tabellen-, Dokument- und Präsentationsfunktionen im Browser und unter Node.js liefern. Die Bausteine sind ein Plugin-System, Canvas-basiertes Rendering, eine Formel-Engine und eine Facade API, die in beiden Umgebungen gleich ansprechbar ist.
Ausdrücklich grenzt sich das Projekt vom reinen Dateibetrachter ab: Univer sei ein Framework für eine eigene Produktivitätsoberfläche. Als Einsatzfelder nennt das README das Einbetten von Editoren in SaaS-Produkte, interne Tools, BI-Workflows und KI-Anwendungen sowie die serverseitige Verarbeitung von Arbeitsmappen und Dokumenten. Genau dieser Headless-Weg macht das SDK auch für Agenten und Automatisierung interessant, weil Arbeitsmappenlogik ohne UI in Node.js laufen kann.
Die Projektzahlen zeigen ein etabliertes Vorhaben: Laut Metadaten 14234 Sterne, 1275 Forks und 149 offene Issues, Standort des Hauptzweigs ist der Branch dev. Das Projekt steht unter Apache-2.0 und wird von DreamNum Co., Ltd. seit 2021 entwickelt; Dokumentation, Showcase und API-Referenz liegen unter docs.univer.ai.
Plugin-first und Canvas-Rendering: Die Architektur hinter der Facade API
Drei Strukturentscheidungen tragen das SDK. Erstens wird jede Fähigkeit als komponierbares Plugin geliefert, sodass Funktionen hinzugefügt, entfernt, ersetzt oder nachgeladen werden können, ohne den ganzen Stack zu übernehmen. Zweitens halten Canvas-basiertes Rendering und eine dedizierte Formel-Engine komplexe Arbeitsmappen reaktionsfähig; die Rendering-Ebene wird über Dokumenttypen hinweg geteilt.
Drittens bündelt die Facade API Arbeitsmappen, Worksheets, Bereiche, Dokumente, Formeln, Befehle und Ereignisse hinter einer höheren Oberfläche, die im Browser und in Node.js identisch funktioniert. Die UI-Komponenten sind laut README in React 18 gebaut, unterstützen React 18 und 19 und bieten minimale Kompatibilität für React 16.9 und 17; Integrationen mit Vue und Web Components werden ebenfalls genannt.
Dazu passt die Dark-Mode-Unterstützung: UI-Komponenten und Rendering-Engine passen sich hellen und dunklen Themes an. Wer nur einen Teil des Funktionsumfangs braucht, nimmt genau die Plugins mit, die dafür nötig sind, und hält das Bundle klein.
Preset-Modus gegen Plugin-Modus: Zwei Wege zur ersten Arbeitsmappe
Der Schnellstart unterscheidet zwei Integrationspfade. Der Preset-Modus liefert kuratierte Plugin-Sammlungen samt notwendiger Facade-Registrierung und Styles:
pnpm add @univerjs/presets @univerjs/preset-sheets-core
Danach erzeugt ein createUniver-Aufruf mit UniverSheetsCorePreset({ container: 'app' }) eine lauffähige Instanz, und univerAPI.createWorkbook({}) öffnet die erste Arbeitsmappe. Dieser Weg ist der schnellste für Sheets-, Docs- und Node-Profile.
Der Plugin-Modus gibt die volle Kontrolle: Eine pnpm add-Zeile zieht über ein Dutzend @univerjs-Pakete, darunter @univerjs/core, @univerjs/design, @univerjs/engine-formula, @univerjs/engine-render und @univerjs/sheets-formula. Anschließend werden die Plugins in Reihenfolge registriert und die Facade-API über FUniver.newAPI(univer) erzeugt. Beide Pfade brauchen einen Seitencontainer, im README steht dafür ein div mit id app und height 100vh.
Eine Betriebsdetails-Angabe verdient Aufmerksamkeit: Alle @univerjs-Pakete sollen auf derselben Version gehalten werden, sonst drohen Inkonsistenzen zwischen Kern und Plugins.
Laufzeitanforderungen: Browser-Ziele, Intl.Segmenter und Node-Versionen
Das SDK wird laut README mit dem Ziel Chrome 88 kompiliert und soll auf Edge >=88, Firefox >=90, Chrome >=88, Safari >=14.1 und Electron >=12 laufen. Weil Univer auf Intl.Segmenter setzt, empfiehlt das README ein Polyfill wie @formatjs/intl-segmenter, wenn die Laufzeit die API nicht mitbringt. Als Build-Tools sind Vite, esbuild oder Webpack 5 vorgesehen; ältere Werkzeuge ohne Unterstützung des exports-Feldes in package.json, häufig Webpack 4, brauchen zusätzliche Pfadzuordnungen.
Für den Headless-Betrieb gilt Node.js >=18.17.0. Wer dagegen am Monorepo selbst entwickeln will, braucht Node.js >=22.18 und pnpm >=10. Diese Trennung zwischen Laufzeit- und Entwicklungsversionen ist dokumentiert und sollte vor dem Einbinden geprüft werden.
Die Release-Historie bewegt sich zügig: v0.25.1 erschien am 27. Juni 2026, zuvor v0.25.0 am 30. Mai und v0.24.0 am 23. Mai 2026. Wer auf stabile APIs setzt, sollte die Änderungsnotizen der Releases verfolgen, da sich das Projekt noch vor Version 1.0 bewegt.
Funktionsumfang nach Oberflächen: Sheets reif, Docs solide, Slides im Aufbau
Die Fähigkeitentabelle trennt Offen-Source-Funktionen von Pro-Erweiterungen. Tabellen gelten als ausgereifteste Oberfläche: Der OSS-Kern deckt Arbeitsmappen, Arbeitsblätter, Bereiche, Auswahl, Formeln, Zahlenformatierung, Filter, Sortierung, Datenvalidierung, bedingte Formatierung, Hyperlinks, Kommentare, Suchen und Ersetzen, Notizen, Tabellen und die Zeichnungsintegration ab, dazu erweiterbare UI-Plugins.
Dokumente bieten ein reichhaltiges Dokumentmodell, Bearbeitungs-UI, Listen, Hyperlinks, Kommentare und Schnelleinfügung. Folien werden als in aktiver Entwicklung beschrieben, mit Präsentationsdatenmodell und UI-Paketen. Daneben steht Bases für eigene strukturierte Datenerlebnisse auf derselben Plugin-, Befehls- und Modellarchitektur.
Wichtig ist die Klarheit bei Reifegradangaben: Das README nennt keine Veröffentlichungsdaten oder Metriken für einzelne Oberflächen. Wer Slides-Funktionen einsetzen will, sollte den Funktionsumfang gegen die eigene Anforderungsliste prüfen, statt einen gleichbleibenden Reifegrad über alle drei Oberflächen anzunehmen.
OSS-Kern, Pro-Ebene und der Betrieb des Monorepos
Dieses Repository enthält den quelloffenen Kern und First-Party-OSS-Plugins; Univer Pro wird separat als kommerzielle Erweiterungsebene entwickelt. Das README formuliert Grenzprinzipien: OSS-Pakete sind unter Apache-2.0 eigenständig nutzbar, Pro ist für die Nutzung der öffentlichen OSS-SDK-APIs nicht erforderlich, Fehler und Sicherheitsprobleme in OSS-Paketen gehören ins OSS-Repository, und die OSS-Dokumentation soll nicht den Eindruck erwecken, Pro-Funktionen steckten in öffentlichen Paketen.
Die Apache-2.0-Lizenz gewährt eine unbefristete, weltweite, gebührenfreie Urheberrechts- und Patentlizenz samt Weiterverteilungsbedingungen. Für kommerzielle Einbettungen ist das eine tragfähige Basis; die Grenze verläuft nicht bei der Lizenz, sondern bei den Funktionspaketen.
Wer mitentwickeln will, findet eine dokumentierte Struktur mit Verzeichnissen packages/, examples/, common/, e2e/, tests/ und docs/, paketbezogene READMEs sowie Befehlen wie pnpm install, pnpm dev, pnpm build, pnpm test, pnpm typecheck, pnpm lint, pnpm test:e2e und pnpm storybook:dev. Community-Kanäle sind GitHub Discussions, Discord, Twitter/X und YouTube, Sicherheitsmeldungen gehen an ein eigenes Security-Policy-Dokument. Förderung läuft über Open Collective.
Fazit: Ein Baukasten mit klarer Grenze zwischen OSS und Pro
Univer passt, wenn du Office-Bearbeitung als Bestandteil eines eigenen Produkts brauchst und bereit bist, Plugins selbst zu komponieren oder auf Presets zu setzen. Die Stärke liegt in der Architektur: Ein Codebestand, Canvas-Rendering und eine Facade API, die vom Browser bis zum headless Node.js-Dienst reicht, sparen doppelte Implementierung für UI und Server ein.
Nicht geeignet ist das SDK, wenn du ein fertiges Office-Paket mit Garantien suchst. Es fehlen Leistungsmessungen, Nutzungsstatistiken und Reifegradangaben für einzelne Oberflächen, und Slides stehen laut README noch in aktiver Entwicklung. Der Umfang der kommerziellen Pro-Ebene wird in diesem Repository nicht beschrieben und muss separat geklärt werden.
Vor dem Einbau empfiehlt sich eine kleine Beweisführung: Richte ein Projekt mit pnpm add @univerjs/presets @univerjs/preset-sheets-core ein, öffne mit univerAPI.createWorkbook({}) eine Arbeitsmappe und teste Formeln, Zahlenformatierung und Filter mit deinen eigenen Daten. Prüfe danach im Funktionsverzeichnis, welche benötigten Fähigkeiten im OSS-Kern liegen, und kontrolliere die Versionsgleichheit aller @univerjs-Pakete in deinem Lockfile.
Redaktionelles Fazit
Univer richtet sich an Teams, die Tabellen- oder Dokumentbearbeitung in ein eigenes Produkt einbetten wollen, etwa in ein SaaS-Angebot, ein internes Tool oder eine KI-Anwendung. Es ist kein fertiges Office-Paket und kein Betrachter. Prüfe zuerst den Preset-Modus mit @univerjs/preset-sheets-core und kläre danach, ob die benötigten Funktionen im Apache-2.0-Kern liegen oder hinter der kommerziellen Pro-Ebene.
Community-Notizen