It’s just a 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 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.

Originally published at https://aifoc.us on February 21, 2026.

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.

Originally published at https://aifoc.us on October 12, 2025.

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.

Fictional example of embedding existing web functionality into a ‘chat app’

In 2020, while on my team, Jason Miller documented the Island architecture (first proposed by Katie Sylor-Miller). At the time it 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 be 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 to 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.

Originally published at https://aifoc.us on May 28, 2025.

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.

I decided to look for the genesis of the phrase “The web will always win” and it turns out the earliest quote still indexed is a post linking to Dave Winer’s post where he doesn’t actually directly say it (it’s implied).

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 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 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 react in 5 years like we did with mobile. I want to be proactive and help shape the future of the web.

Originally published at https://aifoc.us on May 17, 2025.

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&mldr;. 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.

Dynamically generated UI from prompts

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&mldr;.

Chat GPT thinking and building — part 1

Chat GPT thinking and building — part 2

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 non-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&mldr; 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?

Originally published at https://aifoc.us on May 12, 2025.

I remember the exact moments when major transitions in my life happened. The first time I got a BASIC program working. The first time someone used one of my programs. My first email. The first time I visited a website. The first time I made a website. The first time I saw my future wife. The first time I held each of my children.

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&mldr; 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.

Originally published at https://aifoc.us on May 9, 2025.

Using the browser as a service is an incredible opportunity. It allows us to take the declarative HTML and combine it with the developer defined procedural execution of JavaScript and run deep analysis on the content.

…

Running a browser on the server will allow us to more easily build services which parse data that is generated dynamically, it will allow us to more easily us run our own logic against the logic in a page (form fill as an example) and I believe that it will open up the ability to more effectively run actions against data embedded on the page.

It’s taken a while, but I think we are getting there.

I’m enamored by Puppeteer. Puppeteer is a JavaScript library that sits on top of the Chrome Dev Tools protocol and it allows you to automate and script the Chrome browser.

My day-to-day work involves a lot of debugging web servers and ensuring. Like many developers I use curl to make requests to a web server and check the response. It’s an amazing utility, however in today’s world many developers are building sites that are built using a lot of JavaScript and this makes it impossible to inspect the complete response.

I decided to create a cUrl-like utility for fetching a resource and running the JavaScript on the page called domcurl.

domcurl is a small NodeJS application that uses Puppeteer and can be installed by issuing the following command: npm i domcurl. Like the curl command you can issue a simple domcurl [url] to fetch the resource and run the JS on the page.

It doesn’t replicate all of curl, but it is quite featureful with the following features.

• Specify a url to fetch. i.e, domcurl [url]
• Inspect the response headers with -v. i.e, domcurl -v [url]
• Set cookies with -b i.e, domcurl [url] -b "test=hello; Domain=airhorner.com; HttpOnly;" -b "hello=world; Domain=airhorner.com; HttpOnly;"
• Add custom headers using the -H argument.
• Manually set the STDOUT with -o and STDERR with --stderr

I’m finding it quite useful eventhough it can’t stream the results like curl can because it has to wait for the CSS and JS to be downloaded and executed.

I also took the liberty to add a couple of extra features that are specific to JavaScript and Chrome.

• Output a Chrome Dev Tools trace file (including screens hots.) domcurl --url https://example.com --trace test.json
• Include it as a JavaScript module if you have the need to integrate it into any of your existing applications.

const {domcurl} = require('domcurl'); domcurl(https://medium.com/%60https://paul.kinlan.me/%60,%20%7B%7D);

Whilst this tool is more of a demo than a full service, I think The Headless Web is maturing and tools like Puppeteer and others are going to help us realize the continued power of the web. We just need to build for it.

Originally published at https://paul.kinlan.me/domcurl/.

domcurl: curl + JavaScript was originally published in Dev Channel on Medium, where people are continuing the conversation by highlighting and responding to this story.

One thing that Mike said was “the Web is my API”, where he talked about the being able to expose your site and your data in a page via microformats and other structured data and being able to access it directly from another another browser context, using a simple XMLHttpRequest and the CORS API:

Anyway, what’s cool about this is you can treat the web as an API. The Web is my API. “Scraping a web page” may sound dirtier than “consuming a web service”, but it’s the cleaner approach in principle. A website sitting in your browser is a perfectly human-readable depiction of a resource your program can get hold of, so it’s an API that’s self-documenting. The best kind of API. But a whole HTML document is a lot to chew on, so we need to make sure it’s structured nicely, and that’s where microformats come in, gloriously defining lightweight standards for declaring info in your web page. There’s another HTML5 tie-in here, because we now have a similar concept in the standard, microdata.

It was around the same time that I was starting to work on Web Intents, the spirit of which was the similar — give users access to data and services from another origin — but it was a lot more complex. I wanted to enable discovery of services and then to interact with those pages. And Mike wanted to move the web to providing access to data and services. It stuck with me. Even if I did forget the original attribution.

I recently did a talk for Nordic JS where I highlighted that we don’t build really build truley interconnected services on the web, and when we do it follows a model of mostly server to server interactions. That is a web site will integrate with a 3rd party service by routing all API request through their server to the remote service and managing all the complexities that come with that.

It works, we have entire web built with this, but it can be incredibly complex when you consider authenticaion, authorization, transport protocols and differing RPC methods (REST, GraphQL etc). Mike was proposing something much more elegant, that with CORS enabled sites and a bit of JavaScript, we can talk directly to the remote service by using the site.

There have been a couple of issues that cropped up in between. The primary issue is that even though CORS is widely supported in browsers, developers rarely use it. CORS is a protection that we need on the web but it’s hard to set up and debug, and the “Web as an API” has not really been pushed too much.

We are moving to a world where sites are getting generated in the client with JS and sessions and state for the user are managed in the entirely on the client.

We still need the ability to communicate from our sites to a remote service, and I still strongly believe that we need to decentralize our integrations with other sites and apps, but the first thing that we need to do is connect our sites and apps together in away that is more than just a link. We need our sites to expose their capabilities and functionality directly to other windows on the users system.

Every website should be able to expose an API that the owner of the site is control of, directly to other clients.

The good news is that we can already do it, we’ve had the primitives on the platform for at least 7 years (postMessage and MessageChannel), and forever since window.open, but we don’t use these tools to interact with sites for similar reasons why we don’t use CORS: It’s hard and it’s nearly impossible to define a sane API that is simple and consistent to use and that doesn’t require pulling in huge third party libraries for each service that you want to interact with.

The platform only allows you to communicate between sites using messaging passing which means that as a service owner if you wanted to create an API, you have to build a state machine that serializes messages in to some state, reacts to it, and then sends a message back to the client and then you have to create a library that does that for the developer consuming your service. It’s incredibly complex and convoluted and I belive is one of the primary reasons why we haven’t seen more adoption of Web Workers and client-side APIs.s

We have a library that helps: Comlink.

Comlink is a small API that abstracts the MessageChannel and postMessage API’s in to an API that looks like you are instantiating remote classes and functions in the local context. For example:

Website

// Set up.
const worker = w.open('somesite');
const api = Comlink.proxy(w);
// Use the API.
const work = await new api.Test();
const str = await work.say('Yo!'); 
console.log(str);

Web Worker

class Test { 
  say() { 
    return `Hi ${this.x++}, ${msg}`;
  }
} 
// Expose the API to anyone who connects. 
Comlink.expose({Test}, window);

We expose an API on the service, we consume the API in the client via a proxy.

Is there a better example?

I built a site that subscribes to a pubsubhubbub endpoint and when it recieves a ping it sends a JSON message to a user defined endpoint. I didn’t want to manage the push notification infrastructurion for this small app, another site I built (https://webpush.rocks/) can do all that, I just want to use integrate with that service..

But how do I get the subscription URL (the piece of data I need to be able to send notifications) held in the client of webpush.rocks back into my site?

When I initially built this site, all you could do was let the user open the site and then copy and paste the URL between the pages. Why not just expose an API that any site could use? That’s what I did.

webpush.rocks defines an API called PushManager that has a single method on it subscriptionId. When the page loads it exposes this API to the window as follows:

class PushManager {
  constructor() { } 
  async subscriptionId() { 
    //global var ick... 
    let reg = await navigator.serviceWorker.getRegistration();
    let sub = await reg.pushManager.getSubscription();
    if(sub) { 
      return `${location.origin}/send?id=${sub.endpoint}`;
    } 
    else { 
      return ``; 
    }
  } 
} 

Comlink.expose({PushManager}, window);

The API interacts with the PushSubscriptionManager API in the DOM and returns a custom URL to the calling site. The important thing here is that because it is running asynchronously I can wait for user verifcation that they want to perform the action (or not).

Back on the calling client site (the app that wants to get the subscriptionId). When a user clicks on the link, we obtain a reference to the window we just opened and hook-up our Comlink proxy to it. The service API is now exposed to our client and we can instantiate the PushManager API like it was a local service, but it is all interacting with the remote instance service in the other window.

let endpointWindow = window.open('', 'endpointUrlWindow');
let pushAPI = Comlink.proxy(endpointWindow); 
let pm = await new pushAPI.PushManager(); 
let id = await pm.subscriptionId(); 
// Update the UI. 
endpointUrlEl.value = id;

Here is a very quick video of what is happening. A very simple and light-weight interaction, it opens the service and then gets the ID it needs.

As a service provider I have exposed a constrained set of functionality that is only available on the client to another site and I can secure it and ask for user consent at the same time before I return the data back to the user, all with a simple to use API.

The Web is the API.

Quite rightly, we don’t let sites inspect or manipulate the DOM or state of another origin, but I posit that if you have control over the services and functionality of your site and how users engage with it then you can expose the most important information and services to any client that wants to use your service securely (you are in control) and it allows you to:

• Focus on what you are good at.
• Fast data transfer between sites and apps because it is all in the client.
• IPC even when offline.
• Run code in the origin context

What API’s should sites expose?

This is something that I would like to explore more. I exposed some basic functionality to a Push Notifications service because that is the intent of the site, but the important piece for me was that I was in control of which parts of the DOM that I wanted to give back to other developers.

I would like to get to a place where every site can expose a consistent API to users and a way to discover other functionality and services.

Each site owner could expose just the core functionality to their service so that we could do CRUD based operations. We could have complex interactions.

We could get to a web where we have Unix like services that do one thing well and a user pipes them together all on the client.

Each site could expose a VDOM of a subset of the page that is defined by the service owner so that we have a consistent way to pull move data based on the DOM between sites securely.

I could imagine that we might want quick access to all of the schema.org based objects or other structured data on the page (they could be dynamically generated) like Mike did in his original post.

Comlink gives us a way to expose and consume services quickly and easily on top of the platform primitives that have been around for years. We finally have a lot of the pieces in place that allow us to make the Web the API.

The Web is my API. Make it yours too.

Originally published at paul.kinlan.me.

The Web is my API was originally published in Dev Channel on Medium, where people are continuing the conversation by highlighting and responding to this story.

I never got over the death of Web Intents. I always felt that there is still a serious problem on the web, we build silos that lock the user into one web site and we don’t connect our apps together to build richer experiences. We have links that allow us to navigate to another site, but we don’t connect our apps to functionality that we can use in our sites. Be it picking an image from a cloud service to use in your app, or editing an image in the users preferred editor; we just don’t link our services the way we link our pages.

Web Intents was a failed attempt to fix that. The Share API solves one use case for interconnecting sites and apps, but generally IPC and service discovery have never been solved and I think I have a solution… Ok, I don’t have a solution, I have an experiment that I am incredibly excited about.

Over the past couple of months Surma on my team and Ian Kilpatrick were working on a shim for the Tasklets API. The Tasklets API was designed to allow a light-weight multi-threaded API’s to exist on the web. An ES6 class could be exposed as a ‘tasklet’ and you could call it without blocking the main thread — great for UI’s. The tasklet API by itself is very interesting, but the most interesting piece for me was that they built a Polyfill using a Web Worker and developed a way to expose the functionality of the ES6 class that was defined in the Worker. They had abstracted all of the complexities of the postMessage API away into a neat package and a sane model for JS developers.

One of the reasons that we built the Web Intents API was because the developer experience of creating an API and a service that worked with the postMessage API was incredibly complex, you have to deal with the postMessage API and then you have to manage a complex message processing system and associated state machine.

It’s just complex. It get’s even worse if you want to have two windows interacting with each other. The window you open has to signal back the the opener that it is ready before you can start to send it messages. TL;DR - window.open opens about:blank before it navigates to the URL you define.

It gets even more complex when you want to pass messages between multiple windows or workers in other windows.

I think this is one of the main reasons why people expose client side API’s. It’s too hard.

The tasklets polyfill had a solution buried inside of it and I cheekily asked Surma if he could refactor the tasklets API into a simple Proxy API, a couple of hours later out popped Comlink. Comlink is a small API that abstracts the MessageChannel and postMessage API’s in to an API that looks like you are instantiating remote classes and functions in the local context. For exampe:

Website

const worker = new Worker('worker.js'); 
const api = Comlink.proxy(worker); 
const work = await new api.HardWork(); 
const results = await work.expensive();

Web Worker

class HardWork { 
  expensive() { 
    for(let i = 0; i < 1e12; i++) 
      sum += /* …omg so much maths… */       
    return sum; 
  }  
} 

Comlink.expose({HardWork}, self);

We expose an API on the service, we consume the API in the client via a proxy.

I think it is incredibly compelling and Comlink by itself has the ability to revolutionize the usage of Web worker by drastically improving the developer experience by providing a simple API for their team to be able to use.

Doing the same thing between windows is just as easy.

But I had another thought… I can reinvent a small part of Web Intents was supposed: improve service discovery and make it easy for developers to interact with the services.

Web Intents?

One of the neat things about the Comlink API is that it automatically will try to use Transferable objects to pass data between the client and the service, and it turns out that MessagePorts are transferable. The idea that I had is that if I could create a simple API that is designed to just return a MessagePort based on some criteria (such as verb) then as the client, I wouldn’t care where that MessagePort came from.

Here is my thinking: I will have a site that acts as a middle-man and will maintain a list of services and where they live and will be able hook up clients who ask for types of services, kind of like so.

• A service site will be able to say to the middle man “I offer service X that works on data Y and lives at page Z”
• A client site will be able to say to the middle man “I need a service that does X on this data Y. What do you have?”

Mapping this back to a rough design, I need a Service that exposes two methods: register and pick.

register, will, well register the service with the middle man. pick on the other hand is a little more interesting and I’ve broken it down into a couple of steps.

The flow isn’t overly complex when you dive into it. I crated a basic wrapper that you include in every service and client application. The wrapper handles the first interaction with the middleman and does some basic housekeeping by wrapping the complexities of opening a window to the service picker at ‘https://web-intents.glitch.me/pick'.

Once the picker is open it will find all the services that match the criteria the user needs, it will then present it to the user as a simple list. The user opens their preferred site and behind the scenes that site exposes it’s API back to the original client via the middleman. Finally, when the connection is complete and we are talking to the chosen service we can remove the middle-man.

The process actually is a little more complex than I am letting on. Under the hood we are passing a lot of MessagePorts between windows but the consumers of the API never see any of this complexity. The good thing is that that when the client and the service are connected and they talk directly via a nice service defined API and they don’t actually know who is on either end. Neat.

Below is a quick dive into the code to show how simple it is.

Service (demo)

The service is relatively simple, it has a class that interacts with the DOM and logs some output.

We expose the Test class to the ServiceRegistry and we offer a way to register the capabilities of this service.

class Test { 
  constructor() {} 
  outputToPre(msg) { 
    let output = document.getElementById('output');          
    output.innerText += msg + '\n'; 
  } 
} 

let registry = new ServiceRegistry({ Test });
register.onclick = async () => { 
  let service = await registry.register('action','*',location.href); 
};

Client (demo)

The client is simple, we create an instance of the registry and call pick.

pick connects to the middleman, and waits for the user to select the service. Once the user selects the service the middleman (ServiceRegistry) passes the API that the remote service has exposed to the client. We can then instantiate an instance of the remote API and invoke methods on it.

let registry = new ServiceRegistry(); 
let resolvedService = await registry.pick('action','image/*'); 
remote = await new resolvedService.Test(); 
remote.outputToPre('calling from window.');

I am quite pleased with this as an experiment. Here is a video of the Service Discovery and invocation of the above code.

Let me know what you think. Too much?

Originally published at paul.kinlan.me.

Reinventing Web Intents was originally published in Dev Channel on Medium, where people are continuing the conversation by highlighting and responding to this story.

Take notifications for example, introduced in Chrome 42; they allow developers to easily re-engage with users who opt to receive messages. But what if the user also has their native app installed? There was no way for you as the developer to know if your user has your app installed on their current device. If the user has the app installed there might be no reason to prompt for notifications from the web as well.

In Chrome 59 we are introducing a new API called getInstalledRelatedApps(). This new API lets you determine if your native app is installed on a device.

Note: This API is behind an Origin Trial, this means that we are in an experimental mode and are actively looking for feedback. You have to opt your site into this trial because it is not available broadly on the web. You can now sign up for the trial.

This is an incredibly powerful API because it gives you access to information that you can’t infer from the web. This means that there must be a provable bi-directional relationship between your site and your native app. There are three core components that make this work.

1. There is a reference to your native app from your Web App Manifest via the related_applications property. This is your site saying that it is related to the native app.
2. There is a native app installed with the same package name as the one referenced in your Web App Manifest. The app must have a reference from your AndroidManifest.xml via the asset_statements element. This asserts that your native app has a relationship with your site.
3. If the above two criteria are met then a call to getInstalledRelatedApps() will resolve the list of apps.

These three steps are in place to ensure that only you can query your apps and that you have reliably demonstrated ownership of the site and app. They are now described in more detail.

Define the relationship to your native app in your Web App Manifest

You need to ensure that you have a Web App Manifest linked to from your site. In the manifest you must define a related_applications property that contains a list of the apps that you want to detect. The related_applications property is an array of objects that contain the platform on which the app is hosted and the unique identifier for your app on that platform.

{
  ...
  "related_applications": [{
    "platform": "play",
    "id": "<package-name>"
  }],
  ...
}

Note: Only Chrome on Android supports this, so the platform must be set to “play”. You also need your “id” to be the exact package name for your Android App.

Create the relationship to your site in your AndroidManifest.xml

Next, you need to have your native app signal to the device that it is related to your Web App. You need to define the relationship with your site by ensuring that the app has the same package name as that defined in the Web App Manifest and that it also refers back to the website using the Android Digital Asset Links infrastructure.

Creating the link back to your site is possible by adding the following to your AndroidManifest.xml:

<manifest>
  <application>
   ...
    <meta-data android:name="asset_statements" android:resource="@string/asset_statements" />
   ...
  </application>
</manifest>

And then adding the following to your strings.xml resource, replacing the <site-domain> with the domain of your site:

<string name="asset_statements">
  [{
    \"relation\": [\"delegate_permission/common.handle_all_urls\"],
    \"target\": {
      \"namespace\": \"web\",
      \"site\": \"https://<site-domain>\"
    }
  }]
</string>

Test for presence of the app

Once you have the required metadata deployed on your app and on your site, you should be able to call navigator.getInstalledRelatedApps(). This returns a promise that resolves to the list of apps that are installed on the user's device that meet the above criteria (i.e., have been proved to be owned by the app developer).

navigator.getInstalledRelatedApps().then(relatedApps => {
  for (let app of relatedApps) {
    console.log(app.platform);
    console.log(app.url);
    console.log(app.id);
  }
});

Testing on localhost

In your strings.xml set the "site" property value to be http://localhost:[yourportnumber] like the following.

<string name="asset_statements">
  [{
    \"relation\": [\"delegate_permission/common.handle_all_urls\"],
    \"target\": {
      \"namespace\": \"web\",
      \"site\": \"http://localhost:8000\"
    }
  }]
</string>

Ensure that your Web App Manifest has the correct package name for your locally installed App. When you deploy your Android App, make sure that you update the site property value to be the correct URL for your site. The most efficient way to manage this is through your product flavours (Release, Debug, etc.) which allows you to specify different resource files based on the build target, meaning that your Release target will only ever contain your live domain.

Use cases

There are many different ways that you can use this API. Here are some quick examples of possible uses and common pieces of functionality that you will find useful.

Cancel the progressive web app installation if the native app is installed

You can intercept the beforeinstallprompt event. The general flow is to call preventDefault() on the event so the banner doesn't show right away, check to see if there are no apps installed and if so call prompt() to show the banner.

window.addEventListener("beforeinstallprompt", e => {
  if (navigator.getInstalledRelatedApps) {
    e.preventDefault();  // Stop automated install prompt.
    navigator.getInstalledRelatedApps().then(relatedApps => {
      if (relatedApps.length == 0) {
        e.prompt();
      }
    });
  }
});

Prevent duplicate notifications

One of the intended uses for this API is to allow you to de-dupe notifications from both your Native Application and your Web App. There are a couple of options available to you.

If the user has your application installed and they don’t have notifications enabled already on your site, you can use the getInstalledRelatedApps() method to selectively disable the UI that the user would normally use to enable the feature.

window.addEventListener("load", e => {
  if (navigator.getInstalledRelatedApps) {
    navigator.getInstalledRelatedApps()
    .then(apps => {
      if(apps.length > 0) { /* Hide the UI */ }
    });
  }
});

Alternatively, if the user has already been to your site and has Web Push enabled you can unregister the push subscription during the onload event.

window.addEventListener("load", e => {
  if (navigator.getInstalledRelatedApps) {
    let sw = navigator.serviceWorker.ready;

    navigator.getInstalledRelatedApps()
    .then(apps => (apps.length > 0) ? sw.then(reg => reg.pushManager) : undefined)
    .then(pushManager => {
      if(pushManager) pushManager.unsubscribe();
    });
  }
});

This API is not available directly to the service worker so it is not possible to de-duplicate notifications as they arrive at your service worker.

Detect if your PWA is installed from a native app

If the user has installed your Progressive Web App through the old Add to Homescreen method (i.e, in anything prior to Chrome 58) then it is not possible to detect if your app is installed. Chrome added your site to the Homescreen as a bookmark, and this data was not exposed to the system.

If the user has installed the web app using the new Web APK functionality, it is possible to determine if your web app is installed. If you know the package name of your Web APK then you can use the context.getPackageManager().getApplicationInfo() API to determine if it is installed. Please note that this is experiemental.

Not Working?

File a bug right here against the Chrome implementation. The correct people will be notified (I’ve sneakily put this in, so I am sure they will be grateful).

We are keen to keep getting feedback on the spec and if you have any issues or suggestions, file an issue against the spec

Originally published at developers.google.com.

Detect if your Native app is installed from your web site was originally published in Dev Channel on Medium, where people are continuing the conversation by highlighting and responding to this story.