Univer · an open source office kit you build into your own app
Univer
A real spreadsheet, running inside somebody else's web app. This one is built with Univer, an open source kit you drop into your own product. The same kit also draws documents and slide decks.
A workbook, a document and a slide deck are the same kind of object
One codebase, and a workbook, a document and a slide deck are the same kind of object in it
Univer comes from a team called dream-num, and you build it into your own product. Here is the spreadsheet it gives you, running in a browser tab, looking up prices against a product table. Your users get a real spreadsheet, a real document editor and a real slide editor, all three inside your app. And underneath all three sits one kind of object, with a saved state and a number that says which version of the file you are holding.
Three answers, and a correction to the pitch
By the end you'll know what a workbook and a slide deck have in common inside this codebase, and which edits are allowed to touch your saved file. And I'll show you where the free licence actually stops, because the pitch needs a correction. Six document types run in the project's showcase, and one of them runs entirely on the free packages.
Three hard problems sit under every grid on a web page
Putting a grid on a web page is a solved problem. Three things after that are hard. Two people typing in one cell without clobbering each other. An undo that knows exactly what to undo. And a formula that still calculates when there is no browser anywhere, on a server. Univer's answer is to solve those three once, underneath, and let the spreadsheet, the document editor and the slide editor all inherit the answer.
One door in, and three lines that say which class handles which type
The door in is eight lines of real code. You ask the runtime to create a unit, and you hand it a type and some data. A unit is one open thing with an id and a saved state, whether that thing is a workbook, a document or a slide deck. Three lines say which class handles which type. Sheet gets Workbook. Document gets DocumentDataModel. Slide gets SlideDataModel. All three extend one base class, and that base class is where the saved state and the revision number live. A revision number is a counter that lets two copies of one file work out which copy is behind. So a workbook and a slide deck differ by one value in a list of type names.
One runtime under all three, and only one of them is free
The project runs all of this in a public showcase, and I opened three of them. The spreadsheet runs on the open packages. The document editor is open too, and its tables and its charts come from the paid plugins. The slide editor is the paid slide package, watermark and all. Three separate editors, one runtime underneath every one of them.
All six types run. One of them is built on the free packages.
The repo describes six document types in one runtime. Spreadsheets, documents, slides, boards, relational tables and PDFs. Go to the showcase and all six of them run, across five hundred and forty-seven demos. Then I opened what each demo actually loads. The spreadsheet pulls in three packages, and all three are free and Apache licensed. The slide deck, the PDF, the board and the relational table each pull in packages with pro in the name, and the slide demo is stamped, License Required. The open core registers three document types, and the project's own front page still lists PDFs as coming soon. Six types in the product, one type fully inside the free licence.
Two kinds of change, and only one crosses into your file
Every change in Univer carries a label, and that label decides whether the change reaches your saved file. A saved change goes into the file. The repo's own comment calls a saved change the smallest unit of conflict resolution, and what that means is the smallest piece the software will argue about when two people edit one cell at once. A screen change never enters the file. Where you scrolled to, whether the sidebar is open. Those are real changes to what you see, and the saved file never hears about them. And one action can make several saved changes. Delete a row, and that single action produces the saved change for the delete, the saved change that puts the row back for undo, and the saved change for the cell contents. I made three edits with no screen attached at all, and got three commands, seventeen saved changes, and zero screen changes.
Four fields carry a batch of saved changes
A saved change carries only plain data, small enough to write down and send. The free code already does exactly that. One line forwards saved changes to a background worker, and only saved changes. The format it sends is in the repo too. A unit id, the revision it started from, the revision it produces, and a list of saved changes whose contents are written out as text. So an edit from your keyboard, from a server, or from a piece of software acting for you is the same kind of thing on the wire. The part that hands out revision numbers and merges two people's edits is the collaboration server, and the team sells that one separately. In the free packages the revision counter never moves. Mine stayed at one.
A slide takes a different route to the same engine
One drawing engine draws every document type. Each open thing gets a scene, and everything inside a scene is the same base object. The spreadsheet and the document editor go further and share one component class, with one draw call between them. A slide is a viewer that holds one scene per page, on that same engine. And I like what that buys you. A document can sit inside a cell, and a spreadsheet can sit inside a document, with no second renderer to negotiate with.
Twenty packages ship twice, once without a screen
You can read this project's core rule straight off its folder names. Sixty packages, and forty of them sit in twenty pairs, a logic half and a screen half. The filter is one package and the filter's menu is another. The table of contents, the same. The contributor guide states why. Running with no screen, on a server with no browser, is the same priority as running in the browser. So I ran the logic half on a server runtime with no browser and no page at all, put a sum formula into a cell, and got fifty back.
The free licence buys the engines. The multiplayer layer is the paid product.
What the free licence gives you is the core, the engines and the plugin set. Real time collaboration, edit history, import and export, printing, charts, pivot tables and calculation on a server are Univer Pro, a separate commercial product you pay for. The team also wrote a boundary rule into its own documentation, saying the open source docs should not imply that paid capabilities are available in the public packages. They drew the line, and then they published it. I have not seen many projects do that.
Open does not mean equally finished
The three open surfaces are at very different stages. Inside the drawing engine, the slides folder holds two source files. The documents folder holds a hundred and fifty-five. The project says the same thing in words. Spreadsheets are its most mature surface today, and the presentation model and its interface packages are under active development. Under the project's own stability policy, that second phrase makes the open slides interface experimental. I would not build a presentation product on this one today.
The hard half is the free half
Both catches land in the same place if you are the one building. You are getting the part that is genuinely hard to build. The object model, the formula engine, the drawing surface and the edit bus, under a licence that lets you ship all of it in a commercial product. Run several workbooks on one page if you want, and the project's own docs show three at once. What you pay for, when you pay, is the multiplayer layer and the file format compatibility.
Google Sheets can do this today, on Google’s servers
Google Sheets already does all of this, and Google publishes a way for your own app to read and write a sheet, which you could wire up this afternoon. That is true, and the difference is where the document lives. With Google Sheets the document lives on Google's servers, inside Google's account system, and your app talks to it across the network. With Univer the document lives in your page and in your own database, and you decide where the edits get routed. I would rather have the document in my own storage. Handsontable and AG Grid hand you the grid. Univer is going after the whole document.
Where Univer sits among the embeddable spreadsheets
Handsontable, paired with HyperFormula, is the embeddable grid with a real formula engine behind it. AG Grid is the enterprise data grid. Grist is an open source relational spreadsheet, and you host it as an app. Univer is the one going after all three document types with one object model. And it is the successor to Luckysheet, from the same team. That repo is archived now, and its description reads, Luckysheet upgraded to Univer.
Sixteen lines to a workbook, or sixty-one
Two ways in, and they are very different lengths. The short path is two packages and one call. Sixteen lines of code, and a workbook appears. The long path, where you pick every piece yourself, is thirteen packages, eleven registration calls and sixty-one lines before an empty workbook shows up. Both paths are in the quick start. I would start short and take the long one the day you actually need it.
Who should install Univer this weekend
I would reach for Univer if your product needs a real spreadsheet inside it and you want the document in your own storage. And I would start with sheets, not slides. I would wait if you need file import and export, or two cursors in one document on day one, because both of those sit in the paid tier. And I would skip it if what you want is a grid to display rows in. That is a much smaller job than this one, and Handsontable or AG Grid will do it.
Apache-2.0, TypeScript, browser and server
Apache-2.0, so you can ship it inside a product you sell. It is written in TypeScript, the typed flavour of the language browsers already run. It works in current Chrome, Edge, Firefox and Safari, in Electron, which is the wrapper that turns a web app into a desktop app, and on a server with no browser at all. It is an early build, from a codebase that has been going since 2022, with a 1.0 release candidate out for testing right now and new code landing today. The default install is still the early line, and the release candidate is the one I would watch.
What is the last app you used that quietly turned into a spreadsheet?
What is the last app you used that quietly turned into a spreadsheet? Mine was a project tracker that grew formulas, and then grew a chart. The repo is dream-num slash univer, on GitHub. New repo tomorrow.
