RSS Feed for webdev - James Stone's Blog

A no backend future

Thu, 12 Feb 2026 00:00:00 GMT

A typical web tech stack is a frontend , backend and db

My prediction is the future for many ( not all) apps will be an LLM dynamically built frontend, using something like this https://tambo.co/blog/posts/introducing-tambo-generative-ui or MCP UI

Plus a DB that has strict permissions (think postgres RLS) and validation (check constraints etc)

]]>

Web Transport

Wed, 04 Feb 2026 00:00:00 GMT

There is a new (to me) way to communicate between the browser and server - Web Transport. [MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API) | Technology | Intended Use | Direction | Other Limitations | MDN | |--------------------------|---------------------------------------------------------------------|------------------------------------------|--------------------------------------------------|----------------------------------------------------------------------------| | Web Transport | Real-time, Bidirectional, can have sub streams | Server ↔ Client | HTTP/3 only. Secure context. No Safari (for now) | [MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API) | | WebSocket | Real-time, Bidirectional communication over a single TCP connection | Server ↔ Client | | [MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket) | | SSE (Server-Sent Events) | One way stream of data from server | Server → Client | | [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events) | | Web Push | Low frequncy updates, push notifications. | Server → Browser's Server → Browser | | [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Push_API) | | WebRTC | Real-time communication (audio, video, data) between browsers | Client A ↔ Client B ( could be a server) | | [MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API) | Web Transport fills a similar niche as Web Sockets. But it has a neat potential advantage over it. It allows multiple streams to be created on the same connection - crucially, each stream does not stall the connection. This solves a problem with Web Sockets where each message is sequentially processed. So if you send a large message followed by lots of small messages, the client has to wait for the large message. { /* ```mermaid graph TD subgraph "WebSocket: is a single stream" direction TB SA[LARGE\n\nMessage] SA --> SB[Small Message 1] SB --> SC[Small Message 2] end style SA fill:#ff9,stroke:#333,stroke-width:2px ``` */ } In Web Transport, multiple independent streams can be created, allowing simultaneous processing of different message types. { /* ```mermaid graph TD subgraph "Web Transport: Multiple streams, one connection" subgraph "Stream 1" direction TB MA[LARGE\n\nMessage] end subgraph "Stream 2" direction TB MB[Small Message 1] MB --> MC[Small Message 2] end end style MA fill:#ff9,stroke:#333,stroke-width:2px ``` */ } # example use case Picture a collaborative document editor where multiple users are working together: - Small cursor position updates (high frequency, need low latency) - Text changes/edits (medium-sized messages) - Document metadata (larger messages like version history) With Web Transport, all these can flow independently on the same connection, so cursor movements remain responsive even when large document changes are being processed. Unlike WebSockets, one user's large edit won't stall another user's cursor position updates. A prior solution was to open multiple WebSocket connections, one for each type of message. But this has a large overhead. --- Also of note is the Background Synchronization API [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Background_Synchronization_API) although that is not really supported and is **not** triggerable from the server.

Scroll padding top

Wed, 28 Jan 2026 00:00:00 GMT

When you have a sticky header, clicking an anchor link can cause the target element to be hidden behind the header. TIL scroll-padding-top solves this by adding an offset to the scroll position.

I think a screenshot best describes the problem:

here I have made set the header background’s opacity to 50% so you can see when you click the anchor the header obscures the target element.

On this site, I use it in the Nav.astro component to ensure that the header height is accounted for when scrolling to a fragment:

:root {
  --header-height: 3rem;
  scroll-padding-top: var(--header-height);
}

nav {
  height: var(--header-height);
  position: sticky;
  top: 0;
}

This ensures that when a user navigates to an anchor, the top of the content is aligned with the bottom of the sticky navigation bar rather than being obscured by it.

eg:

Live demo: My 2026 posts

More details: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/scroll-padding-top

]]>

Why Multi page apps are exciting again

Sat, 17 Jan 2026 00:00:00 GMT

One thing that really excites me in the browser world right now is the renewed focus on multi-page applications (MPAs).

For a long time, single-page applications (SPAs) felt like the only viable way to achieve certain features and performance characteristics. If you wanted fast navigation or polished page transitions, an SPA was basically the ~~default~~only choice.

Some of the classic advantages of SPAs included:

fast page loading after the initial load
smooth page transitions and navigation effects

But the interesting thing is that these features are no longer exclusive to SPAs.

New browser features are leveling the playing field

Compression

Soon, browsers will be able to use super smart compression based on pages you’ve already loaded. Instead of re-downloading large chunks of repeated HTML (headers, navigation, layout, etc.), servers can send much smaller diffs.

If you want to dig deeper into this, check out:

This directly chips away at one of the historical weaknesses of MPAs: having to reload the entire document on every navigation.

Native prefetching and prerendering

Another area where SPAs used to dominate was preloading.

Previously, only SPAs could easily preload the next page using JavaScript. For example, on link hover you might start loading the next page’s data, then instantly render it on click and refresh it in the background.

Now, browsers offer a native alternative via the Speculation Rules API | MDN.

Instead of custom JavaScript logic, you can declaratively tell the browser what kinds of pages should be prefetched or prerendered:

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/logout" } },
            { "not": { "href_matches": "/*\\?*(^|&)add-to-cart=*" } },
            { "not": { "selector_matches": ".no-prerender" } },
            { "not": { "selector_matches": "[rel~=nofollow]" } }
          ]
        }
      }
    ],
    "prefetch": [
      {
        "urls": ["next.html", "next2.html"],
        "requires": ["anonymous-client-ip-when-cross-origin"],
        "referrer_policy": "no-referrer"
      }
    ]
  }
</script>

This gives MPAs many of the same preloading capabilities that previously required an SPA and a client-side router.

Page transitions

Finally, although I think page transitions can be a gimmick, for a long time smooth transitions were another feature that only an SPA could provide.

That’s changing with the introduction of View Transitions. With cross document view transitions, MPAs can now animate between full page navigations in a way that previously required client-side rendering.

]]>