techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome

Administered by:

Server stats:

4.9K
active users

New blog post: Building a with .

blog.dwac.dev/posts/html-fragm

This explorers how we can use HTML fragments to define routes, load them dynamically, and then apply them to the main page content. It talks about more complexities with streaming (because I didn't learn my lesson last time) and even has a bonus section on shipping an application server _inside_ a .

Lots of interesting stuff, I hope you check it out!

blog.dwac.devHTML Fragments Routing - Devel without a CauseLet's build a router by fetching each route as an HTML fragment!

@develwithoutacause Why self-inflict all of this when you could assemble fragments in a service worker? (à la philipwalton.com/articles/smal)

(now ok, this either adds extra requests for the "shell", or a cache invalidation issue 🤷)

Thanks anyway for letting me watch that HTTP 203 episode! I missed the last few ones for some reason.

philipwalton.comSmaller HTML Payloads with Service WorkersThoughts on web development, open source, software architecture, and the future.

@tbroyer Thanks for sharing that. I'd heard of the approach but don't think I'd read that article specifically. The performance metrics are very interesting.

I think the difference is that routing is technically an approach and keeps context between routes in a way that a navigation would not.

HTML Fragments as a concept is also a little more flexible beyond rendering full pages. It allows you to dynamically render individual components instead of a full page. For example, you can use it to infinite scroll a list, or edit an item of the list and rerender on the server without invalidating the whole page. This is discussed more in the original post:

blog.dwac.dev/posts/html-fragm

For a fully static site with a lot of content, I think the service worker approach could work well, while HTML fragments provides a bit more interactivity.

blog.dwac.devA Simpler HTML-over-the-Wire - Devel without a CauseIs it possible to build an HTML-over-the-wire application with only native web technologies? See how far can we go with zero custom tooling, and how the web specification can change to support it.

@develwithoutacause Yes, that'd be the main (if not only) difference, and when you'd use one over the other.

If you do need an SPA (and by that I mean really *need* it: nolanlawson.com/2022/05/25/mor), then use your approach; if you can go with an MPA, then optimize it with a service worker (the server still sends the same "HTML fragments" to both, it's only the client-side code that'd be different)

Read the Tea LeavesMore thoughts on SPAsBy Nolan Lawson

@tbroyer It is important to keep in mind that while this routing approach is _technically_ an it doesn't fall into most of the modern trappings.

Everything is still server-side rendered, no impact to FCP/LCP, no framework, etc.

Where this approach shines is for sites which ride the line between a "site" and an "app". For example, an infinite scroll of posts where you want to maintain your position when temporarily navigating to other pages. That would be very difficult to achieve with a fully approach, even with a service worker.

Doug Parker 🕸️

@tbroyer There's definitely a trade-off, and you're right about those limitations.

Although I argue this approach has the issues of an _router_ specifically, which is a much smaller subset of issues than SPA's typically experience. For example this router supports:

* Full .
* No forced client-side hydration.
* No duplicated server/client build process.
* No blocking .
* No required web framework.
* `<noscript />` compatible.
* No required server.
* streaming (with some caveats).

There's a lot of features here which SPA's have historically done very poorly. This is why I put this router in a slightly different camp than those architectures.