Masthash

#HTMLFragments

Doug Parker ๐Ÿ•ธ๏ธ
3 weeks ago

@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

Doug Parker ๐Ÿ•ธ๏ธ
2 months ago

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

Doug Parker ๐Ÿ•ธ๏ธ
3 months ago

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!

Doug Parker ๐Ÿ•ธ๏ธ
10 months ago

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

Doug Parker ๐Ÿ•ธ๏ธ
10 months ago

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

Doug Parker ๐Ÿ•ธ๏ธ
10 months ago

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

Doug Parker ๐Ÿ•ธ๏ธ
10 months ago

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!

Doug Parker ๐Ÿ•ธ๏ธ
10 months ago

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!

Doug Parker ๐Ÿ•ธ๏ธ
10 months ago

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.

Doug Parker ๐Ÿ•ธ๏ธ
11 months ago

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.