New blog post: Building a #router with #HTMLFragments.
https://blog.dwac.dev/posts/html-fragments-routing/
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 #HTML (because I didn't learn my lesson last time) and even has a bonus section on shipping an application server _inside_ a #ServiceWorker.
Lots of interesting stuff, I hope you check it out!
@develwithoutacause Why self-inflict all of this when you could assemble fragments in a service worker? (à la https://philipwalton.com/articles/smaller-html-payloads-with-service-workers/)
(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.
@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 #HTMLFragments routing is technically an #SPA approach and keeps #JavaScript context between routes in a way that a #ServiceWorker 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:
https://blog.dwac.dev/posts/html-fragments/
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.
@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: https://nolanlawson.com/2022/05/25/more-thoughts-on-spas/#:~:text=viable%20in%20practice.-,The%20virtues%20of%20SPAs,-So%20given%20everything), 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)
@tbroyer It is important to keep in mind that while this routing approach is _technically_ an #SPA it doesn't fall into most of the modern trappings.
Everything is still server-side rendered, no impact to FCP/LCP, no #CSR 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 #MPA approach, even with a service worker.
@develwithoutacause Well, it **is** an SPA with (almost) all the issues of SPA (albeit with less client-side code): no bfcache, load spinner/abort, focus management, scroll restoration; that need to be handled by more JS.
https://github.com/WICG/navigation-api#customizations-and-consequences-of-navigation-interception
@tbroyer There's definitely a trade-off, and you're right about those limitations.
Although I argue this approach has the issues of an #SPA _router_ specifically, which is a much smaller subset of issues than SPA's typically experience. For example this router supports:
* Full #SSR.
* No forced client-side hydration.
* No duplicated server/client build process.
* No blocking #JS.
* No required web framework.
* `<noscript />` compatible.
* No required #Node server.
* #HTML 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.