Most of the software people use at work has quietly become live. Documents show who else is editing. Chat messages arrive without a refresh. Design tools show other people's cursors. Nobody thinks of it as a feature anymore.
Manufacturing software mostly hasn't caught up. Screens show the state of the world as of the last time someone pressed reload, and everyone learns to press reload a lot.
Fewer seats, higher stakes
Part of the reason is economics. Business software is usually sold by the seat, and a collaboration tool that every knowledge worker in the world might use can afford to invest heavily in polish. The number of people running production at hardware companies is much smaller.
We don't think that's a reason for factories to get worse software. If anything, it runs the other way. A stale document costs someone a few minutes. A stale screen on a production floor costs more, because the work it describes is physical:
- Quality opens an issue against a unit, and the screen a planner has had open since lunch still shows it ready to ship.
- A redline changes a torque value on a task, and the technician's open page still shows the old one.
- Two people pick up the same task from a queue because neither page showed the other had taken it.
Factorial enforces rules like holds on the server no matter what a screen shows, so stale data can't make the system do the wrong thing. But a technician shouldn't find out about a hold by having their work refused. People coordinating physical work need to see the same state at the same time.
So in Factorial, collaborative screens are live. A new issue appears without a refresh. A finished task disappears from the queue. Each page shows who else is viewing it, and a green Live indicator shows that it's connected.
How it works
Factorial is a Go application whose interface is rendered on the server and kept up to date with Datastar. There's no separate front-end application holding its own copy of the data, so there's no second copy to go stale.
- One open connection per page. When a page loads, it opens a long-lived stream to the server. If the connection drops, the page reconnects and catches up on its own.
- The server checks, the browser doesn't poll. Every couple of seconds, the server re-reads what each open page shows. It does this in batches: one query per kind of page covers every person viewing one, and people looking at the same record or the same filtered list share the work.
- Only changes are sent. The server fingerprints what each page shows and sends an update only when the fingerprint changes.
- Morphing, not reloading. An update is freshly rendered HTML. Datastar morphs it into the page, changing only the parts that differ, so nothing flickers and nothing jumps.
- Edits arrive immediately. When someone edits a value in a table, the change is pushed to everyone viewing that table as soon as it commits, without waiting for the next check or re-rendering the page.
Live updates that don't get in your way
A page that changes underneath you is only an improvement if it never takes your work away. That's the part that took the most care.
- A field you're typing in is left alone while it has focus.
- When you're editing a table cell, your draft, your cursor, and any open picker survive updates around them.
- Values you've entered in a form but haven't saved aren't reset by an update.
- Sections you've expanded or collapsed stay the way you left them.
And when two people really do edit the same thing, Factorial tells you. If someone else changes a cell while you're editing it, the editor says so before you save, instead of letting you find out later.
Fast enough to stay out of the way
Re-reading every open page every couple of seconds sounds expensive. In practice, it's a small number of well-indexed, batched PostgreSQL queries, and in our experience so far the bigger cost of a live page is rendering its HTML, not getting the data or delivering it. If the One Billion Row Challenge taught a generation of programmers anything, it's how far careful code on ordinary hardware can go. We target p95 response times of 100 milliseconds, at operational scale.
Software should show people the factory as it is right now. Anything else asks them to make decisions about physical work from a snapshot of the past.
Read more about how Factorial is built in The Tao of Factorial.