FREST Substack

Apps Are Dead; They Just Don’t Know It Yet

Guyren Howe — Tue, 10 Mar 2026 11:53:29 GMT

The App has had its day. The several hundred icons you never use on your computing devices have been sub-optimal relics for decades already, but AI is about to render the whole paradigm entirely unmanageable.

Apps are containers that trap both data and capabilities. When software was scarce, that made sense. But AI is rapidly making software abundant — and now the container has become the bottleneck.

There’s no sensible way to organise access to apps. I have dozens of apps on my phone that seemed useful when I downloaded them, but now I have no idea what they do and no efficient way of finding out other than to run them. I know I have apps for image processing, but I have no idea which ones those are.

Hell, Apple’s “springboard” launcher on the iPhone has so little functionality that it is embarrassed by the 1984 original Mac Finder.

There’s also no real way to use apps together. That’s not even really a concept. The clipboard is a 1980s hack, and the share menu is just a slightly quicker form of the same simplistic idea.

Now enter AI.

People are already building apps in a couple of hours. I can barely manage the hundred or so apps on my phone today. Apple’s App Store has about 2.5 million apps.

When the cost of creating an app approaches zero, the idea that we should organise our digital lives around thousands — or millions — of separate apps becomes absurd.

The Political Economy of the App

The app paradigm didn’t arise because engineers thought it was elegant. It arose because it matched the economic moats of the software industry. Early on, the moat was distribution — shipping software was hard, so functionality was packaged as products. Later the moat became reliability and long-term support — businesses trusted large vendors like IBM, Oracle, and Microsoft to maintain complex systems for years. Then the internet introduced another moat: service infrastructure. Running reliable online systems required enormous operational expertise, so software again consolidated into tightly controlled applications that owned their data, logic, and interface end-to-end.

But those moats are eroding. Distribution is trivial. Infrastructure is commoditised. And AI is rapidly reducing the cost of producing software itself.

It turns out the app is not the natural unit of computing.

It is the natural unit of computing under conditions of software scarcity.

Beyond the Walled Garden

If the app was the natural structure of computing under software scarcity, what happens when software stops being scarce?

Once you start wondering what a world without apps might look like, things get interesting. For most of the history of computing, software organised data. But when AI begins dissolving those walls, the natural alternative appears: data organising software.

Right now I cannot process the data locked inside my apps in any way other than what the owners of those apps permit. We’re so used to this that it barely even occurs to us that things could be different.

But imagine something simple.

Maybe I want to compare how often I’ve used a particular word across all my writing over time. For a programmer that’s a small project. For most people it’s essentially impossible. Hell, not just impossible — unimaginable. It wouldn’t even occur to most people to even imagine such a thing.

Yet computers are pure thought machines. Any computable abstraction we can conceive is available to us. We should conceive more ambitiously.

Almost everyone in the world now carries an almost-free device capable of presenting real-time simulations of reality that are hard to distinguish from the real thing. These machines support sophisticated human interfaces — cameras, microphones, styluses, touchscreens, sensors, VR.

And yet our lives are still organised around windows and clicking icons like it’s fucking 1984.

No.

I refuse to believe that our current computing paradigms are anywhere near the peak of what we might do.

Try to forget your assumptions about what a computing device looks like and how it behaves. Imagine God’s iPad. Think about the tasks you actually want to do during your day.

Flatten the walls between apps. Imagine manipulating any data at any time, through whatever representation or interface makes sense. Imagine a world where Microsoft doesn’t own your words and your presentations, and you can do far more than what Microsoft has decided you should.

Set your imagination free.

You can see it dimly, right?

Maybe not in perfect detail. But you can certainly see how far it is from what we have now.

The future of computing will not be apps. It will be fluid computation over shared data.

Up next: how AI will transform APIs.

First-Class Models: The Missing Productivity Revolution

Guyren Howe — Thu, 26 Jun 2025 02:20:00 GMT

TL;DR: First-class models with branching and merging capabilities represent an almost entirely unused enormous productivity and expressiveness unlock in programming and computer systems.

The Current State: Well-Designed Systems, Constrained Users

Imagine you’re building an accounting system from scratch. You’d design it properly: a normalized database schema, algebraically defined operations for debits and credits, account reconciliation, and comparison functions. You’d implement data-only, invariant-preserving operations using database functions and procedures, with clean authorization models. The result would be a database perfectly customized for accounting, supporting multiple simultaneous client interfaces in any language.

This represents the current state of the art—and it’s genuinely good architecture.

But now put yourself in the shoes of the users: knowledge workers, engineers, analysts who depend on this beautifully designed system. Despite having access to well-structured data and operations, they face a fundamental limitation when it comes to the kind of thinking their work actually requires.

The Hypothesis Gap

Consider an engineer working on a project management system. They’re constantly asking computational questions that our current systems simply don’t support:

- What if I replace this supplier with one offering different prices?

- If I increase this capacity parameter, how much larger does the engine room need to be? How much more cement do we need?

- Would using a different manufacturing process have significantly changed our profitability last year?

Today, when faced with these questions, professionals resort to crude workarounds: rough estimates, Excel spreadsheets copied from the main system, or in rare cases, custom programs written specifically for the analysis. Each approach disconnects them from the authoritative data source and requires manual reconciliation with the primary system.

The Solution: First-Class Model Branching

What we need is the ability to explicitly manipulate and navigate between different models of our system’s state. This goes beyond simple version control—it’s about making hypothesis exploration a core system capability.

Time as the First Dimension

Users should be able to view any previous state the system was in, not just as read-only history, but as a living branch they can extend and modify. This isn’t just data versioning—when examining past states, users should be able to run the older versions of functions that were available at that time, maintaining complete computational consistency.

Hypothesis as the Second Dimension

Without changing the authoritative state, users should be able to create simulation branches. Imagine branching your company’s current accounting state to model next month’s performance. You manually enter projected sales for California stores, then use regression or AI to estimate likely values for other regions. You can then:

- Compare this hypothetical future against a baseline projection

- Diff the states to understand the specific impacts of your California strategy

- Selectively merge insights back into your planning process

This is a generalization of what programmers do with Git, but applied to all system state and made accessible to ordinary users.

The Navigation Interface

Users need intuitive ways to see and navigate branches without getting lost in complexity. While this presents interesting UI challenges (including fraud prevention), the core operations are familiar: branch, compare, merge, and rollback. The key is making these operations meaningful for business content, not just code.

The Technical Foundation: Unifying Synchronization

The branching and merging users perform manually should be built on the same foundations that handle automatic synchronization in distributed systems. This means generalizing the work done in CRDTs (Conflict-free Replicated Data Types) and other synchronization primitives.

Currently, we have a fragmented landscape:

- CRDTs handle concurrent collaborative editing

- Git provides version control with manual conflict resolution

- Database replication uses various conflict resolution strategies

- Most business systems avoid conflicts entirely through restrictive permissions

By unifying these approaches, we can create composable synchronization primitives where user-driven branching and automatic conflict resolution are different manifestations of the same underlying mathematical operations.

Some changes (updating contact information) can auto-merge across all branches. Others (modifying core business logic) require explicit human decisions about propagation. The system provides the infrastructure for both, with the choice of automation level being a design decision rather than a fundamental limitation.

Beyond Spreadsheet Prison

This approach solves what we might call “spreadsheet escape”—the common pattern where users copy data into Excel to explore scenarios, losing connection to the authoritative source and creating reconciliation problems. With first-class modeling, users stay within the system where their explorations maintain semantic relationships and can be selectively integrated back into the main state.

The engineer wondering about supplier changes doesn’t need to export data and lose track of dependencies. They branch the current state, modify supplier relationships, and let the system compute cascading effects while maintaining full traceability back to the source.

The Productivity Revolution

When modeling becomes a first-class system capability rather than an ad-hoc user workaround, we unlock fundamentally new ways of thinking about business problems. Decision-makers can explore scenarios with the same rigor programmers bring to code, but without requiring programming skills.

The knowledge worker asking “what if” questions deserves computational support that matches the sophistication we bring to the underlying data management. First-class models provide that support, turning hypothesis exploration from a painful exception into a natural part of how systems work.

This isn’t just better tooling—it’s a different relationship between users and their computational environment, one where the system actively supports the kind of exploratory thinking that drives actual business value.

This is Frest

Attentive readers will realise that this is a description of the UI design principles underlying Frest (the subject of this Blog).

Composition to the Rescue

Guyren Howe — Thu, 16 Jan 2025 02:36:45 GMT

Software's Original Sin

Every time I hand-roll another HTML form, I die a little inside.

Our industry's greatest moral failure isn't security breaches or privacy violations. It's that we've built a priesthood of programmers, hoarding the power of computing behind arcane incantations of JavaScript and Docker containers. We've chosen approaches that suit our highly trained elite rather than ones that democratize computing.

Where are all the bicycles for the mind?

We've known how to do better since the beginning. Excel turned millions of accountants into functional programmers. FileMaker let ordinary folks wield the power of relational databases. But instead of building on these successes, we've created systems so complex that even the priests struggle to maintain them.

Every business application today is essentially the same thing: small islands of simple code floating in a sea of state, connected by brittle ceremonies of data transformation. We pretend we're building grand computational cathedrals, but we're really just state farmers, tending our JSON and praying our API calls don't fail.

What if it all worked like FileMaker mashed with Excel?

What if every piece of software could be changed as easily as a spreadsheet? What if you could right-click anything - a chart, a form, a dashboard - see exactly how it was built, and change any part of it? What if "like that, but for my department" was three clicks instead of three weeks of development?

The Architecture of Liberation

The dirty secret of enterprise software is that most of it is just moving data around and occasionally showing it to humans. We dress it up with sophisticated terms like "microservices" and "event sourcing," but we're basically building ever more complex ways to fail at simple things.

I think this happens because the boundaries around shared work and ownership within a business just are at the wrong point for software. The vast majority of the software development effort into the world goes into idiosyncratic, short-term, business-driven dreck. Frest defines an architecture style that makes it natural to cooperate on a more optimal scale.

Our APIs are rigid contracts written in stone. Our security models are Byzantine mazes of permissions. Our user interfaces are change-resistant monuments to someone's best guess from six months ago. And God help you if you want to combine data from two different systems.

This isn't just inefficient - it's a fundamental betrayal of what computing should be.

Consider a typical "modern" business dashboard. Behind that seemingly simple chart lies a tangled web of API calls, data transformations, and hard-coded business rules. Want to see the same data slightly differently? That'll be a two-week sprint and three meetings with the architecture team.

Excel users are laughing at us. They've been doing ad-hoc data manipulation and visualization for decades. FileMaker users can build entire business applications in an afternoon. Meanwhile, we're writing boilerplate code to validate form inputs. Again.

The Revolution Will Be Composable

The solution isn't better frameworks or more sophisticated development tools. We don't need another way to generate CRUD apps or yet another JavaScript framework.

What we need is a fundamental rethinking of how software is composed.

Imagine a world where:

- Every piece of data has an address, but what you see at that address depends on who you are

- Everything you see always has a useful, relational, searchable UI

- Security isn't a bolt-on feature but emerges naturally from how things compose

- Functions are just relations waiting to be filled in

- Everything is a query, and every query can be changed

This isn't science fiction. The building blocks have existed since the 1970s. The relational model. Functional programming. Capability-based security. We just haven't put them together right.

The missing piece is a composition model that makes all of this natural and inevitable. A way to say "like that, but..." and have the system just understand.

The Path Forward

We've spent fifty years building software that serves the priesthood. Tools that make sense if you think in abstractions and can hold a mental model of asynchronous state mutations. Tools that actively resist modification by anyone without years of training.

It's time to burn the priesthood down.

The next generation of software won't be built on promises of scalability or developer ergonomics. It will be built on a radical premise: that everyone deserves tools they can understand and modify.

In the next post, I'll show you exactly how this works. How a simple idea about composing models leads to software that's naturally malleable, secure, and distributed. Software that normal humans can actually bend to their will.

The priests won't like it. But then, they never do.

State Farming

Guyren Howe — Sun, 14 Jul 2024 00:33:35 GMT

Coding is State Farming

If you just see all the code involved in a typical business app, it is tempting to see it as a single, grand piece of computational architecture.

While in some sense it must be that, business software in practice is nearly always small pieces of fairly simple code that run asynchronously, serialising and deserialising bits of the state of whatever is being worked on. We write islands of code in a sea of state.

The instances of running code can be separated by:

time — perhaps a backup process must be run every night at midnight;
space — computation distributed in physically separate devices must be sent across a network;
logic — Some of the logic of the final computation might be best executed in the database; or
resource constraints — we must do some computation in pieces or in the database because the data involved don’t fit in memory.

In some cases, a computation might just be suspended in memory and resumed (e.g. when waiting to read a file), but mostly, some values must be serialized in one place and deserialized in another, and code finishes here and new code runs there. Through a file or a database or a network packet, the effect is in many ways the same: computations separated by time and space, connected through the sea of state.

These computation islands might be very different. You don’t control the web browser rendering your HTML, for example. Not only are we building asynchronous systems; we are building them out of different code written by different people — code we may or may not trust.

The fight to manage the retrieval or generation of the right state so we can carry out the next step of some computation is the source of most of the complexity in business software. An engineer must constantly bear in mind where something is running, with what privileges, able to assume such and so invariants (i.e. things that have been made true by computation before this). And “state” can be subtle — our state isn’t just the HTTP request we’re processing, but that at this point in the code, we have authenticated the user, who has these privileges, …

Turing Complete code is trouble

Every computation written in a Turing Complete (TC) programming language (as opposed to declarative/logic languages like SQL) which fetches some state in order to do a Very Important Thing is:

a consumer of resources;
a source of bugs;
a source of latency;
a maintenance burden,
…

We can all agree that we should seek to minimise these issues. It’s why we use high level languages. It’s why we’re continually moving toward higher level programming languages (e.g. Rust and its affine types). It’s a big part of why we use frameworks and all the rest.

But code in TC languages will always be where we get most of our bugs and vulnerabilities. Better languages are great, but better still would be to just have fewer computations that must be written in regular programming languages.

Coding as State Farming

The database is the most stable part of any business application. Code comes and goes, waxes and wanes, we use different whole applications, but you’ll still have a good chunk of database state that was put there in the first few days your app ran.

Maintaining that state is one of the two most important tasks your code does (the other is emitting the right outputs, where that is API calls or user interface generation). We are all in this sense state farmers.

The tasks we achieve with the code we write can be separated into three kinds:

causing side-effects (e.g. sending an email);
creating new state from other state (creating a new appointment based on a HTTP request); and
performing complex computations (resizing an image).

The last of these is, kind of, the only one we really must perform in a regular language — at least, in a way that is vulnerable to all of the issues that code brings.

Side Effects through New State

Sending emails and other sort of external state change must in the end be performed by regular code. But these effects are in general self-contained and can be represented as a consequence of a clear and simple set of input states.

This means that we can generally set things up so side effects can be represented as “creating state from other state”. So for sending out emails, we can marshall the template and its arguments in the database and then run the small amount of fixed code that causes the side-effect to occur. We can send any sort of email to any sort of address with any sort of content, all without having to change any TC code.

Creating State from other State

Much of the code we write just rearranges state. A HTTP request comes in from a user, we pull the request apart, and we create state as a result — a new appointment, say.

Since we can just rearrange state in a relational query language, we don’t need to use our TC languages for this.

However.

SQL is an abomination. It hides the sublime elegance of the relational model inside a language and a set of assumptions that would cause the creators of COBOL to blush.

There are alternatives…

Setting SQL aside…

My discussion here leads to two conclustions with regard to SQL:

SQL is awful, but it’s really well worth using, much more than most folks do, in any event. This also means that you should learn to use your database well, which is more than most folks do either. Postgres in particular has a lot of features that make the awfulness of SQL not quite so bad; and
We should be seeking — demanding! — alternatives. CozoDB is the best project I know of right now. Check it out. It’s really cool.

Rules

SQL is a logic engine, although its design tries hard to hide this. In particular, it’s a bit odd to use a rule in SQL. A rule expresses how to derive some state from other state. We can say if a customer is on the gold list, they get a 10% discount. Or if an order is created, a shipping task should be created for the warehouse.

It is useful to think of rules as being either:

forward, meaning that whenever a new case of the antecedent of the rule becomes true, we immediately generate and insert its consequent; or
backward, meaning that when we want to know if the consequent is true, we go looking for matching antecedents

In SQL databases, a forward rule is a trigger, and a backward rule is a view or query.

Declarative Triggers

In most relational databases, triggers execute code in a regular programming language. In many cases (SQL Server, Oracle), we have a choice between a clunky-but-close-to-the-data language like PL/SQL or TSQL, or Python.

However, Postgres and SQLite both support triggers in something like pure SQL, giving us declarative rules, letting us have rules while avoiding the issues TC languages bring. Even within the limits of the other databases, we can write state-rearranging triggers in a simple, essentially declarative way, just chaining together SQL queries.

Limiting Turing Completeness

Much — most, even — of what you do in your TC language can be straightforwardly expressed in the data layer, especially once we can represent functions in the data layer.

A widely used example of a Rails application for tutorials is a blogging app. Here is the code for creating a following relationship from one user to another:

  # Relationship Controller action
  def create
    @user = User.find(params[:followed_id])
    current_user.follow(@user)
    respond_to do |format|
      format.html { redirect_to @user }
      format.js
    end
  end

  # User Model
  has_many :following, through: :active_relationships,  source: :followed

  def follow(other_user)
    following << other_user
  end

Rails is doing a lot of the work here, so this code is simple. Still, it could just be done in SQL, in a lot fewer lines

INSERT INTO active_relationships(follower_id, followed_id) VALUES(current_user_id, followed_id) RETURNING follower_id, followed_id

Imagine a very simple framework where the TC language inserts all incoming requests as JSON into a requests table (you would probably be logging the request anyway, so if we stop doing that, we’re not using significantly different storage). Now, a trigger on the requests table can extract perform the above insert and then gather values and a mustache template for the resulting web page.

The only reason you’re balking at this is because SQL is terrible. Modern SQL (particularly SQLite and Postgres) is somewhat less terrible than you imagine if only you’ll learn to use it — start with the utterly wonderful The Art of SQL. Still, it’s bad. If we had a modern Datalog with at least the sophistication of SQLite, this would all look almost obvious.

Shaping the inputs to code

Such TC code as we must write should be written such that the data given to it has exactly the shape needed to carry out the must-be-Turing-Complete part of the computation in the most straightforward way possible. Note that this is just good coding practice anyway.

The consequence of the above following might be rendering a web page to the user’s browser. We might have one function that turns values and a template into HTML. Another would take HTML and send it to the user. The data layer can invoke User Defined Functions for the first, and return the second as the result of the action that inserted the original request into the requests table.

What does this Mean?

I am arguing for writing software differently in two different ways:

We should do more in the query language, limiting the use of TC programming languages to where we must; and
We should simplify the TC code we write. Since we have to travel through the sea of state in the database anyway, we should use the power of the query engine to present our TC code with exactly the data in exactly the shape that will make that code easiest to write.

Also, our industry should support development of a better alternative to SQL (i.e. Datalog). The success of SurrealDB, Supabase and the like demonstrates that developers are open to change in this area. A few million dollars of VC investment could stand up a proper commercial Datalog database which might well take over the world.

Why now? So What?

Guyren Howe — Thu, 17 Aug 2023 02:36:23 GMT

Regarding FREST:

Why Now?

Two opportunities:

programming is inefficient and unreliable
non-programmers mostly can’t do their own computing without consulting a programmer

The relational model offers large, relatively easy responses to both opportunities. There are a variety of other opportunities in rethinking how APIs work and how we create user interfaces.

Relations are grossly under-used

Because SQL is abominable, yet it has been our only way to operate on data relationally, the elegance, security and efficiency of the relational model in representing most of your business logic has been almost entirely ignored.

Muggles find relations intuitive

The software industry has done an awful job of providing computing abilities to non-programmers. Tools like Visual Basic, while admirable and extremely effective, still require the user to commit to learning the fundamentals of programming, which is non-trivial and challenging or impossible for many.

The really generally successful end-user computing tools are:

- Excel and

- FileMaker/Access/FoxPro/4th Dimension/…

Excel is a functional programming tool. The others are relational programming tools. They let the user employ the most useful data types (simple types, relations, lists and functions) through flexible user interface actions.

Note that functions are just a special kind of relation. Note also that the user is directly manipulating data structures, but expressed in a rich GUI, rather than through code.

UIs from APIs

It’s actually pretty simple to support a pretty flexible sort of embedding of content from multiple sources. Rather than a rigid, app-like web, we can have a component based UI model.

Rich content coexists happily within this model: Relationally, a “document” can be a single atomic value of a column, although it will often be useful to provide relational views of their contents — imagine a drawing document accessible as tables of objects, groups, layers, and so on.

So What?

Imagine that all of the data in the world was available through a ten times richer version of Access or FileMaker. All of the most useful information in the world is available as tables. Everything useful you can do with SQL, you can do trivially across different data sources and APIs that don’t need to cooperate (but they can for efficiency).

Just by intuitive GUI operations, the user can slice and dice the data they are seeing and how it is represented.

For this new paradigm to be realised, data sources need only implement a little more than the typical decent REST API (consisting of type/metadata information and GUI representation).

Time Travel? We can do much better than Time Travel

There are remarkable new UI possibilities based on the seamless embeddability of FREST components. Since (internal and external) API calls are presented as database updates, it is trivial to just keep them. It would then be fairly easy to let the user click on anything they can see and we can show them a tree-style trace of how this thing was built, and we can allow the user to change any of the arguments to change what they’re seeing or to see a new thing.

Over to you

What I need is the time to implement this, while still having a reasonable income. I’m pretty flexible. A part-time tech or writing gig seems most likely. But there are several possible handsome products and services that could be built on top of this, if you’re in an investing sort of mood. A tiny investment, even by typical Angel standards, would be enough.

If you can help change the world by supporting me, please get in touch!

RESTful presentation

Guyren Howe — Wed, 16 Aug 2023 07:31:04 GMT

One ASPECT of FREST can be nicely separated and used on its own, to great benefit. That is the presentation model.

FREST is based on truly RESTful values at URLs having representations. It adds some more expectations that produce a very flexible protocol for content embedding, where your mind map can contain a drawing, within which is a spreadsheet, in one cell of which is another (or the same) mind map.

It’s really quite simple.

Every FREST endpoint’s value can be presented in the following ways:

icon
cell
row
table header
full

There will be some other, optional ones.

Every FREST endpoint supports a request for its metadata (eg using a HTTP OPTIONS request). Among other things, that metadata includes mustache templates for each of the presentations.

Every FREST endpoint can be retrieved in a JSON representation. That JSON representation can be fed into any of the Mustache templates to produce a representation of the value for each purpose.

Neither JSON nor well-crafted Mustache templates (meaning, ones from which any sort of