Components will kill pages

Today most websites offer interfaces for accessing the data that they hold hostage. However they are holding our data. We would prefer to have it back if we could, and AI will enable that. Our paradigm will shift this way eventually I hope.

Though it's true companies dont have an incentive to hand over data custody anytime soon, AI companies have already found a way around this in little ways and its a matter of time until it goes to where all the data we could ever want is within the AI cloud and our next task is simply taking back ownership of that (where local inference takes us).

But without visits many websites will disappear. So where will AI get its information from in the future?

The idea of representing UI as state goes back forever, I’m not that old but at least in the advent of the web, plenty of JSON -> UI specs or libraries have came into existence. If the specification is solid and a large portion of people agree upon it, I don’t doubt it will take over what we think of UI. (current contenders are json_render, a2ui etc)

The first benefit being that if I can describe my entire UI and the actions each component wants as json, theoretically, I can pass that file to any client to render be it mobile, react, a java swing app etc The responsibility of rendering becomes of anyone who wants to do it.

UI JSON -> UI Framework Above is a simple way of describing how it would generally work. Where the UI framework can be whatever it wants to be as long as it knows how to connect up the UI JSON in a meaningful way.

Now for existing apps and their respective UI’s it’s never made all that much sense to describe how your components behavior in state, useful for some, and many have done it, but a hard pitch for others.

In the agentic era, the pitch is a lot more appealing.

- LLM’s are great-enough at writing JSON

- A lot of people are sharing the sentiment that they can just vibe code small apps for themselves. Hinting at they love the actual ability for full personalization.

Though having the user generate HTML and the rest all the time by LLM’s is more error prone, slow and costly.

The user can just ask an LLM to compose a composition of components in JSON laid out how they want and connected to the API’s they care about. (that can be rendered anywhere)

Personally, if I had a catalogue of 100 distinct services/API's, and I could ask an LLM to generate a UI in JSON that I can copy and paste anywhere to render it, I would be in heaven.

If I had subscriptions to services that; (fake services)

- EMAILR: Sent Emails

- BOOKLAND: Explore books

- DEEP_RESEARCHER: Researches Topic

I could ask an LLM to "With my services, EMAILR, BOOKLAND and DEEP_RESEARCHER and their attached tools.

Can you generate me a dashboard that lists out the top 20 BOOKLAND books, below each one added a button that posts the book title to DEEP_RESEARCHER when I click it. Also add a button below each book that uses EMAILR to email me them"

It would then return something like;

  {
  "view": "dashboard",
  "title": "Book Research Hub",
  "children": [
    {
      "type": "grid",
      "columns": 4,
      "source": { "service": "BOOKLAND", "action": "list", "params": { "limit": 20, "sort": "top" } },
      "each": {
        "type": "card",
        "children": [
          { "type": "text", "bind": "$.title", "variant": "heading" },
          { "type": "text", "bind": "$.author", "variant": "muted" },
          { "type": "image", "bind": "$.cover_url" },
          {
            "type": "button",
            "label": "Deep Research",
            "variant": "primary",
            "action": { "service": "DEEP_RESEARCHER", "method": "research", "params": { "topic": "$.title" } }
          },
          {
            "type": "button",
            "label": "Email me this",
            "variant": "secondary",
            "action": { "service": "EMAILR", "method": "send", "params": { "to": "$user.email", "subject": "Book: $.title", "body": "Check out $.title by $.author" } }
          }
        ]
      }
    }
  ]

Users could share their layouts and what they like and you could end up with a market place or sane defaults for those who don't want to bother with describing what they want. No longer do you have to rely on the UX team of the service for it to be laid out how you want.

There is a metric tonne of work that has to be done to make a specification that can handle more complex things. But I'd bet a lot of users will learn to love and appreciate that the 5% of features they care about they can finally just actually place how they want it to across all their disparate apps.

I'm kind of building this already[1].

0. https://mcpui.dev/

1. https://marketplace.openship.org