@jaredwhite Yeah DSD is definitely missing some useful lifecycle methods. I had to do something similar in my #HtmlFragments experimentation, specifically for getting streaming to work correctly.

https://blog.dwac.dev/posts/streamable-html-fragments/#chunked-declarative-shadow-dom

I still maintain we need a hook to know when an element is parsed, but I feel like we're losing that battle.

https://github.com/WICG/webcomponents/issues/809

Streamable HTML Fragments - Devel without a Cause

HTML fragments part 2: Streaming tweets. Search the far corners of web standards to learn how we can *stream* HTML fragments directly into the DOM.

@westbrook @davatron5000 @stubbornella This proposal reminds me a lot of my #HtmlFragments investigation a lot while back (albeit with a very different use case in mind).

https://blog.dwac.dev/posts/html-fragments/

I wonder if there is a potential path for this proposal which is less "Vue in the browser" and more "a primitive SFC format which frameworks can compile to". I wonder if this could solve multiple problems:

1. #SSR small fragments of #HTML after page load.
2. Vertical slice of separation of concerns for a component.
3. Import module format (like #HtmlImports or #HtmlModules).
4. Lazy loading a component and its styles without requiring CSS-in-JS.

Kind of a smorgasbord of requirements but I can see value in the right primitive here.

A Simpler HTML-over-the-Wire - Devel without a Cause

Is 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.

Are there any good #web conferences / meetups with an #RFP open in the #BayArea or virtual?

There are a few projects I've been working on which I'd love to give talks about and share with the community (not Angular related). Could be talking about any/all of:

1. #HydroActive - A different take on hydration in an HTML-first world. https://github.com/dgp1130/HydroActive/
2. #rules_prerender - A #Bazel ruleset serving as a fast and scalable #StaticSiteGenerator. https://github.com/dgp1130/rules_prerender/
3. #HTMLFragments - A no-tooling, web standard-based approach to HTML over the wire. https://blog.dwac.dev/posts/html-fragments/

Greatly appreciate boosts for reach!

GitHub - dgp1130/HydroActive: An experimental library for hydrating web components and adding "sprinkles of reactivity" to pre-rendered HTML.

An experimental library for hydrating web components and adding "sprinkles of reactivity" to pre-rendered HTML. - dgp1130/HydroActive

GitHub

@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.

A Simpler HTML-over-the-Wire - Devel without a Cause

Is 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.

@jjude The routing demo is here:

https://github.com/dgp1130/html-fragments-routing-demo/

And the original #HTMLFragments demo of a Twitter clone is here:

https://github.com/dgp1130/html-fragments-demo

Which links are dead? The post is pretty new, so I would hope anything I referenced is still up, but maybe I typo-d something...

GitHub - dgp1130/html-fragments-routing-demo

Contribute to dgp1130/html-fragments-routing-demo development by creating an account on GitHub.

GitHub

@tomayac 😁 I hadn't heard of "mini apps", I'll have to read more in that series, but the use of iframes sounds very similar. It reminds me a bit of the `embed` element I proposed here: https://blog.dwac.dev/posts/html-fragments/#ecosystem

I imagine sandboxing would make those iframes tricky to work with in a lot of respects. With #HTMLFragments, at least everything is in the same frame and has the same JS execution context.

A Simpler HTML-over-the-Wire - Devel without a Cause

Is 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.

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!

HTML Fragments Routing - Devel without a Cause

Let's build a router by fetching each route as an HTML fragment!

So apparently #Firefox is at least partially right here. `document.write()` implicitly resets the document meaning `document.body` gets reset to `null` and recreated when #HTML is parsed.

My mistake was observing the `document.body` _before_ the reset, so content streams into a _new_ `<body />` element I'm not observing.

The solution is to `document.open()` explicitly to reset the document early, _and then_ observe `document.body`. Subsequent `document.write()` calls will append to that `<body />` tag and trigger mutations.

There's still some weird divergences between Firefox and #Chrome / #Safari which could probably be addressed, but I was able to make #HTMLFragments work at least.

https://github.com/dgp1130/html-fragments-demo/commit/97901e3d0ddaf38b4ef170d81719eddb52cab090

Shout out to Olli Pettay for identifying the issue so quickly!

Add Firefox support to streaming use case. · dgp1130/html-fragments-demo@97901e3

Firefox didn't work for streaming use cases and would never trigger the `MutationObserver`. This appears to be because `doc.write()` implicitly calls `doc.open()` if it wasn't explicitly ca...

GitHub

Playing around with streaming #HTMLFragments in #Firefox and discovered my whole demo doesn't work because of one small Firefox bug: It doesn't trigger `MutationObserver` on `document.write()` for an inner document. 😭

https://bugzilla.mozilla.org/show_bug.cgi?id=1811782

Hopefully it's something which can be fixed relative easily, but I'm worried it'll fall through the cracks as one of those "not that important because why would you ever do that" bugs.

1811782 - `document.write()` does not trigger `MutationObserver` of `document.implementation.createHTMLDocument()`

UNCONFIRMED (nobody) in Firefox - Untriaged. Last updated 2023-01-22.

Been playing around more with #HTMLFragments (blog post incoming soon) and I realized the streaming implementation is slower than it should be.

https://blog.dwac.dev/posts/streamable-html-fragments/#streaming-complete-chunks

If you stream two nodes with a delay between them, the first node actually won't stream at all! They'll both appear at once.

```javascript
response.write('<div id="1"></div>');
await timeout(1_000);
response.write('<div id="2"></div>');
```

This is because we use a `MutationObserver` and detect the addition of `#2` to know that `#1` is done parsing. However `#2` doesn't exist until 1 second after `#1` was sent. So in any realistic streaming scenario, the last element is displayed one batch later than it should.

Streamable HTML Fragments - Devel without a Cause

HTML fragments part 2: Streaming tweets. Search the far corners of web standards to learn how we can *stream* HTML fragments directly into the DOM.