Why We Gave Up Compiling

In the last Vol, "The Age of Install-less Apps," we made a big claim. If the screen is defined not by the device but by the server, the long chain of build, review, install, and update disappears wholesale. The reactions split exactly in half. "Does that really work?" and "We've already been using something like it." Both reactions pointed to the same place — that the chain is not a given.

This Vol digs one link deeper into that chain. The chain has many links, but there is one first link from which every other link hangs. A link so far down at the bottom that it is usually invisible. Compiling. This piece is about what compiling does to the screen, how we ended up trapped in it, and that it was never inevitable. It will be a long read. It deals with the root of the chain, after all.

Compiling is not translation

Defined dictionary-style, compiling is "translating code that people read into a form that machines execute." Not a wrong statement. That is how you learn it in the first hour of a computer class. But this definition says not one word about what compiling does to the screen.

Let us redefine compiling from the screen's point of view.

Compiling is freezing every decision of that moment into a single hard lump.

Where a button is placed on the screen, what color it is, what size the text is, what happens when it is pressed, which screen comes next — these hundreds of decisions are frozen the moment they are compiled. Decisions that had been scattered separately harden into one lump, and that lump is planted into the device. This freezing has a clear benefit. What is hardened is fast, predictable, stable. It runs consistently on the user's device.

The problem is what comes after. What is frozen is hard to decide again.

Say you want to change one button color. It is a matter of changing just one decision. But that decision is already frozen, together with hundreds of others, into one lump. To pull out one decision and fix it, you have to thaw the entire lump (open the source), change that decision, and freeze it all again (recompile). And the newly frozen lump has to be planted into the device once more — packaged, signed, uploaded to the store, waited through review, rolled out. The chain we described at length in the last Vol was, from another angle, the cost of one cycle of thawing the ice and freezing it again.

Here is the first knot of this piece. The pain of distribution we have endured was not because of laziness or old tools. It flowed inevitably out of the structure that "the decision called the screen is frozen inside the device." Do not curse the chain — look at the ice.

How we ended up trapped in the ice

This ice was not there from the start. Let us trace a short genealogy. If we know in which stratum today's frustration hardened, it becomes clear what we need to thaw.

First generation — packaged software. The era when programs were sold on CDs or floppy disks. Screen and logic alike were compiled and installed wholesale onto the user's computer. To fix something, you pressed a new version, mailed it out, and the user had to install it again. The update cycle was a quarter, in the unlucky case a year. The archetype of the ice was made here — the body of the program is frozen inside the device. Back then this was the only way. The network was slow, or simply absent.

Second generation — the web. The browser inverted the premise. A web page is not compiled. The server sends down a document that reads "one title here, one paragraph beneath it, one link beneath that," and the browser draws it on the spot where it received it. The screen is not frozen on the device. With each visit it is drawn anew, just as the server defines. So a fix was instant — change one line of the server's document, and the next visitor sees the changed screen. No build, no install, no update. It was the first rupture of the chain. We were free — as long as we were dealing with documents.

Third generation — the app store. When the smartphone arrived, the current reversed. Camera, GPS, accelerometer, push notifications, offline operation, sixty-frame animation that clings to your finger — for the native capabilities the web could not give at the time, we returned once more to apps that are compiled and installed onto the device. We froze the screen again. And this time one more layer was laid over the ice: the gateway of the store, and review. The chain hardened again, now longer than in the first generation.

Here is the single most important thing to see. The reason we returned to the app-store model was native capability, not because we wanted the ice of compiling, installing, and review. The ice was a cost that came along, unavoidably, in order to gain the capability. Yet as time passed we came to treat that cost as bundled with the capability. "If you want native capability, you must accept compiling, and the chain too." What this piece questions is exactly that bundle. Are capability and ice really inseparable?

Traces where the industry has already tried to break the ice

The industry did not simply endure this ice. Attempts to break it kept coming, and looking at the successes and limits of those attempts reveals the outline of the real solution.

Hybrid apps (the webview). They put a browser inside a shell called an app and drew the screen with the web. Because the screen could be changed from the server, the ice partly thawed. But the price was high. The webview was not as smooth as native, it struggled to reach the device's deep features, and it gave the user the awkward impression of a "web-like app." In effect, it bought immediacy by giving up some capability — the very capability for which we left the web in the first place.

Code push (hot update). A method that pushes a JavaScript bundle onto the device without going through review, updating the app's logic. It was useful for urgent fixes. But in essence it was still freezing code onto the device. It was merely slightly softer ice. It had to play tug-of-war with store policy, and large changes ultimately had to return to formal review. It did not break the ice — it merely made it slightly softer.

Server-driven UI (SDUI). From here it draws closer to the essence. A method large services have quietly used. The server sends down the screen's composition — which cards, in which order, with which data to show — as a specification, and the app receives that specification and draws it with native widgets. It showed its strength in areas that change often, like feeds and home screens. It left the screen as liquid (the server defines) while leaving the drawing hand native (the app draws). Of the three attempts, it is the closest to the right answer.

Yet SDUI too had a ceiling. It was that, usually, it was a closed system each company built only for its own service. A specification that worked only in that company's app, a structure that spoke only to that company's server. It was not a universal standard. So "our feed screen is defined by the server" became possible, but "define a screen and tools and send them to any server, any device" did not. It thawed the ice only in its own yard; it could not carry it beyond the yard.

This is as far as the industry got. Immediacy was proven by the web, capability by native, the dynamic definition of the screen by SDUI. All three existed. It was only that the three had never met on top of one open standard.

Lift the ice out, but keep the capability

What server-driven UI — the way this magazine deals with — does is exactly that unfinished confluence. Thaw only the decision called the screen, and leave the capability to draw as native. And do that confluence not in one company's yard but on top of an open protocol.

Look at the structure. The server sends down a light definition of "one title, one button beneath it, and when the button is pressed this tool is called." All that lives on the device is a single general-purpose runtime that receives that definition and draws it with native widgets. The screen stays liquid like the web, and the drawing hand stays native. The camera, the sensors, sixty-frame animation can all still be used — because the side that draws is a true native runtime. The capability we gave up when we left the web, this time we do not give up.

At this point there is no longer "a compiled, frozen lump of screen unique to this app" inside the device. There is only one runtime that can draw whatever comes. So the materiality of the act of changing the screen changes. Before, it was a matter of thawing the ice and freezing it again — opening the source, fixing, compiling, planting. Now it is a matter of putting a finger into liquid and stirring — fix one line of the server's definition, and on the next refresh the screen changes accordingly. The same "change a button color" takes three days on one side and ten seconds on the other. The difference between the two is not effort but materiality.

One scene

It will sound abstract, so let us paint a scene. Suppose the server holds a definition like this — "This screen has one welcome line, and one button beneath it. Pressing the button calls the order tool." When the user opens the app, the device's runtime receives this definition and draws it as is. The line and the button appear.

Now you edit that definition on the server. "Make it two buttons. One to order, one to cancel. Color them blue." You save. The next moment, the screens of every device in the store have two buttons. The clerks did nothing. They did not tap update, did not redownload the app, did not go to the store. You did not compile, did not wait for review, did not press a deploy button. You edited one line of the definition. A ten-minute decision reaches every screen in ten minutes. This is where the chain has vanished, all of it.

The objections that naturally arise

Any engineer who has read this far will have had several objections come to mind. If this piece does not answer them head-on, it stays an empty proclamation. Let us take them one by one.

"If every screen is fetched from the server, isn't it slow?" The screen definition is small. Not a heavy code bundle, but a light specification of "one button, one text" — usually a few kilobytes. On top of that, a definition once received is cached. The truly heavy thing, the drawing engine, is already on the device, natively. What the server decides is what to draw, not the act of drawing itself. The performance the user feels is native, plain and simple.

"Then offline, can you do nothing?" A cached definition works even with the connection lost. The last screen received stays up, and it asks the server only when the definition changes. The misconception that "it must always be connected" comes from the false picture of calling the server every moment. In reality, only the changes flow back and forth. The same principle by which the web gained offline as a PWA, but on top of a native runtime.

"Are you telling me to learn yet another framework?" No. The key is not a new tool but the order being changed. In the place where you wrote the screen as code and froze it onto the device, you put the screen as a definition on the server. What you have to learn is not a huge new system but one thing: "how to write a definition." That is why the entry point can begin with ten lines (this Vol's coding article opens those ten lines).

"What about security? If the server sends down screens and behaviors, couldn't it send a malicious definition?" That is why the runtime does not trust the received definition but verifies it. What a definition can do is bound within boundaries the runtime sets — not arbitrary code execution, but only combinations of predefined widgets and tools. It is the same idea as the browser running an arbitrary site's JavaScript only inside a sandbox. (How this boundary is drawn is dealt with head-on in the next Vol, "Every Server Is an App.")

"Isn't this an app-store policy violation?" A subtle area, and honestly, it depends. Stores have been wary of "bypassing review to change an app's core behavior wholesale with arbitrary native code." But "the server defining content and screen composition" is what every feed, every commerce app already does. The line is at whether arbitrary code is planted, not at whether the server defines the screen. As long as this model stays on the latter side, it is within policy, just as existing SDUI has been. (That said, this is an interpretation, not legal counsel. In real application you must check each store's latest guidelines.)

So what remains for compiling

Let us be honest. Compiling does not disappear. It moves its place.

Real-time control, heavy computation, drivers deep in the device, the bedrock of security — these must still be compiled and stand firmly on device and server. What contends in milliseconds and must not waver an inch is right to leave frozen. What thaws is the screen layer that people see and press. What to show, how to lay it out, in what flow it connects — that layer which changes often, is experimented on often, and must differ from person to person.

Come to think of it, the screen was something that ought to change often by nature. Prices change, menus change, button positions are experimented on, different things are shown to different users. That thing which ought to change often, we froze in the hardest place to change (inside the compiled device). That was what was unnatural. We did not give up compiling.

We merely took out of compiling what should never have been compiled.

To freeze what must be hard even harder, and to let flow what must flow — that separation is the heart of this transition.

So, doubt it

If even after reading this far you think "but will that really work," that doubt is right. A written vision can be made as plausible as you like. You can string history together convincingly and answer objections convincingly. What matters is whether it actually runs.

So this magazine does not stop at laying out a vision at length. In the articles that follow this Vol, we show directly how that liquid-state screen works in the hardest place of all — on the chip. An afternoon of an engineer handling an evaluation board with no dedicated GUI and no firmware burning. And how a farmer who does not know coding turned thirty years of field records into a screen. Lift the ice out, and the number of people who can touch it grows — that is the story of this entire Vol.

One last thing to leave you with. When did you last "recompile" something? Run that whole process again just to fix one line of the screen? That familiar ritual — at least at the layer called the screen — is beginning to disappear.

---

makemind.dev "Horizon" — This piece opens the volume "Beyond Compiling." What changes once the screen is released from compilation, followed through on a chip and in a field.