I still maintain we need a hook to know when an element is parsed, but I feel like we're losing that battle.
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.
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!
@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.
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:
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.
@jjude The routing demo is here:
And the original #HTMLFragments demo of a Twitter clone is here:
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...
@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.
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!
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.
Shout out to Olli Pettay for identifying the issue so quickly!
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. 😭
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.
Been playing around more with #HTMLFragments (blog post incoming soon) and I realized the streaming implementation is slower than it should be.
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.
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.