xUI.ai

Dear Elon,

Two Problems

You have two problems that I can help you solve: 1) xAI’s problem is that agentic coding for the web is a foot-gun for security and bloat. 2) SpaceX’s problem is that the web can’t ever leave Earth.

Root Causes

1) xAI

In the context of agentic coding, the web’s limiting factor is JavaScript.

Not the language itself (despite all its quirks). JavaScript has a payload problem – it must be sent over the wire to be downloaded, parsed, compiled/interpreted and executed by the browser, on-the-fly.

2) SpaceX

In the context of space exploration, the web’s limiting factor is HTTP.

HTTP has a latency problem. At the speed of light, the round-trip time from Earth to the moon is 2.5 seconds and to Mars it’s up to 45 minutes! Currently, the Internet’s theoretical maximum range is 18 million kilometers (120 seconds) at which point its ACK retransmissions time out somewhere halfway between the moon and Mars. Thankfully the Internet is adaptable. Like the switch from IPv4 to IPv6, TCP can be swapped out for something bigger in scope like DTN (Delay-Tolerant Networking) thus extending its reach to the outer planets and beyond.

This retrofit will work for many of the Internet’s protocols and ecosystems:

Sadly, the web will be left behind, hopelessly anchored to Earth. By design, HTTP is a chatty protocol. It’s a cascading waterfall of requests and responses. Every 3xx status code, every resource in <head>, every REST API call is essentially the browser asking for something and the server responding: “OK have this. But please request these other resources so I can give them to you next.” When each waterfall step adds a half-hour, “browsing the web” becomes untenable and apps with real-time interactions are nonstarters.

The Solution

My name is Rylan Barnes. I’m a software engineer and a designer. I’ve been building web apps since ‘99 and native mobile apps since ‘05 (before the iPhone) and I have a history of building unreasonably ambitious moonshots.

The Web’s Silver Bullet

For the past 3 years I’ve been obsessively researching and building a radically different approach to the web that’s not just an incremental improvement but a leap by orders of magnitude. The difference is truly remarkable. My belief is that this will finally give the web the competitive advantage it needs to leap-frog past native apps as the preferred platform for many categories such as utilities, tools, productivity, lifestyle, gaming, and social media that proliferate across native app stores but remain anemic on the web.

It’s called XTML, the web’s silver bullet.

XTML is the world’s first AI-native programming language and it serves as a course correction for the current trajectory of the web. It introduces some fundamental changes to the web as a platform to better align it with what we now know the future will hold.

React Without JavaScript

XTML is meant to feel like it could be a W3C candidate recommendation for HTML6. In fact, syntactically, it’s just HTML + 3 new tags: <if>, <for> and <state>, the smallest amount of change needed in order to shift reactive UI from imperative code to declarative code (more on that later). Put simply, XTML is just HTML that can “react” to its own state changes without the need for an aftermarket JavaScript framework.

A Parallel Runtime for HTML

The real unlock, though, is that XTML gives to HTML what Node.js gave to JavaScript: a runtime for executing outside of the browser. HTML can be a wonderfully dynamic language, but only from inside the browser. On the outside, HTML is forced to be woefully static and inert. This is where the name XTML comes from: eXtramural Templating Markup Language. This runtime does NOT duplicate the DOM, it runs DOM-adjacent. It polyfills browsers with a new API called Keyholes which serves a standardized doorway for manipulating the DOM from remote or isolated execution contexts (i.e. WebAssembly or server-side). DOM events bubble up and beyond the browser where XTML gets a chance to handle them. XTML can, at any point, mutate the DOM with write-only access using “keyholes” which serve as proxies to the dynamic “holes” in the markup.

Ironically, this reverts the web’s programming model back to its original form: code lives inside your HTML instead of HTML living inside your code. XTML is a compiled language. It takes a collection of *.html files, treats them as components not pages, and outputs a native binary. Without any code changes, the compiler can output a binary that runs client-side or server-side.

JavaScript’s Monopoly on the Web is Over

Untethering HTML from the browser’s runtime would spark an explosion of pent up innovation on the web since the language would be free to evolve without the permission of browser vendors and their standards committees.

One such example is the <script> tag. It’s now free to operate with ANY language, not just JavaScript. This cracks open the web to be built with modern, compiled languages designed specifically for sophisticated application development like Swift, Kotlin, Java, C#, Go, etc.

This will inevitably give rise to large, monolithic web SDKs, just like iOS and Android, one from each language community - the first one being xUI.ai, (the domain hosting this letter right now).

Adopt Gradually While Aiming for the Stars

So how exactly does one retrofit the entire web for duty on Mars? It will need two approaches, one for server-side websites and one for client-side web apps.

1) For Web1: One giant mirror
The first approach is simple and doesn’t even involve XTML. It targets server-side, mostly static websites. This is the early web, typically long-form content like marketing websites, blogs, news sites, academic papers, etc. It’s just a local copy of the web that gets periodically synced like Google’s local cache or the Internet Archive so that “browsing” isn’t a chore. Granted, these websites do have dynamic content from time to time, but the vast majority of that is for running ads, and advertising companies are going to want interplanetary hubs for that anyway since each celestial body will necessarily have its own separate, self-contained economy.

2) For Web2: Middle-out architecture
The second approach requires cooperation from every web developer. That’s a tall order! But if TypeScript taught us anything, the key to sweeping over the entire software industry is by being designed from the bottom-up for gradual adoption. It must overlay on top of existing codebases and you can use as little or as much as you want. Under the hood, XTML is essentially architected as a reverse proxy on steroids and every major web app already uses a CDN. This is the primary layer of adoption: middle-out architecture. But instead of merely relaying HTTP requests and responses, it serves as a translation layer for DOM events and mutations. It can be adopted one route at a time while still relaying legacy HTTP endpoints too. This prevents the need for full rewrites and allows teams to upgrade one route at a time. For example, start small by upgrading just the /settings page to XTML. Then move on to /profile, then /explore, etc, until the whole thing is running on XTML.

Taking control of the middle layer is the only way to phase out HTTP. In-between the browser and XTML all communication runs over a WebSocket. In-between XTML and your origin servers all communication runs over your protocol of choice (e.g. gRPC). Once a web app has overcome its dependency on HTTP, it becomes trivial to recompile it, with no code changes, to run client-side in the browser as a WebAssembly binary. In this mode, the web app is “installed” ahead of time in the browser, updated in the background, and can handle DOM events and mutations with microsecond latency without any networking at all, optimal for interplanetary web apps. Communication with origin servers will use local-first data sources with optimistic UI updates, provided by the aforementioned xUI SDK but unfortunately outside the scope of this letter.

Why now?

It makes sense that the web didn’t always work this way. HTTP was designed around a core assumption that the working latencies between machines would be roughly 1 second (give or take a few hundred milliseconds). Decades later, now that ubiquitous low latency has been achieved globally (9ms), we can round-trip our networking packets to the edge of the Internet faster than your monitor can refresh its next frame (16ms).

This tipping point is profound.

Recap

To recap (bluntly), the web is currently on a painful trajectory of poor performance and security nightmares, not to mention benching itself as the rest of humanity leaves Earth to explore the stars. The web needs a course correction. The plan is to phase out JavaScript and HTTP using a new flavor of HTML called XTML. Demand for these changes will be driven by being the preferred output for agentic coding and by making the web a more desirable platform than proprietary walled gardens like today’s native app stores.

XTML is based on middle-out architecture which give it the following advantages:

Status

I have recently finished building the runtime. Up next is the compiler. I’ll be publishing a whitepaper this fall. Then I port the whole thing to every other major language.

Let’s Talk

My plan was to continue this work under a new 501(c)(6) nonprofit called The Web4 Foundation but after watching your Terafab announcement I’m realizing how uniquely aligned this project happens to be with that mission (hence this letter). The web has had champions of the past that bolstered it to new levels. Google is one such example; without their investments in early experimental web apps, intercontinental networking infrastructure, and yes even their prodigal WHATWG operation, the web might still be in its blue-links-on-a-white-background era. I believe SpaceXAI is uniquely positioned as the one to “pass the baton” for that responsibility. I do not believe this to be true of any other company, hence the nonprofit above.

What I want is:

Thanks,