if you are the watching kind https://www.youtube.com/watch?v=7S57O3VwIyQ

Photon shines with client-server distributed programs. The DAG being split optimally means it suffers less from low TTI than regular non-trivial SPAs. That said, I share your enthusiasm a lot! We could have the best of both worlds. HTML streaming makes sense in photon. We are not prioritizing it, but it should be easy enough to implement from userland. Take photon-dom for instance: it creates, mounts and attaches nodes to the dom as a continuous flow. Reverse it: instead of creating, mounting and attaching, return a formula for creating, mounting and attaching dom nodes. It’s fine grained and it’s already a tree of flows. Gather them all and serialize to HTML, then pipe it over the wire. On the client you’ll have to insert HTML bits at the right place, so you’ll need a parent-id on each fragment. Which you get for free given the existing tree structure.

exactly, I see the differences, but even when targeting to build SPAs, these techniques sound very neat

that would also be something I would love to tinker with (so that photon can compile in that way) but photon core is probably not stable enough yet, right?

If you want to start with streamed HTML then hydrate it to an SPA, then this is too early. If you want to do streamed, server-side rendered HTML, with server-only state and user events handled on the server, then it can be done today. You would get something close to phoenix liveview: state on the server and a thin client. Ping me if you want to Zoom about it 🙂

Malte can you define precisely "HTML Streaming" as it can mean several different things, I can't easily find a clear definition in that blog series

I was planning on understanding that myself: In the series he talks about https://markojs.com/ and they refer to this blogpost https://dev.to/ryansolid/server-rendering-in-javascript-optimizing-performance-1jnk

in their docs they refer https://markojs.com/docs/why-is-marko-fast/

This gives a rough understanding: > When rendering on the server, Marko renders directly to a string representation of the document (HTML) that can be sent as the HTTP response. > > When rendering in the browser, an HTML string would have to be parsed in order to update the DOM. For this reason, Marko compiles a view to a program that renders directly to a virtual document (VDOM) tree that can be used to efficiently update the real DOM when targeting the browser.

I've spent a bunch of time now investigating React's new streaming SSR. the demo's are pretty neat, but it's not something I've started using in anger yet. the insight I've pulled from their demos and messing with it myself: it is all about latency. you have latency on the client fetching the JS, you have latency on the server fetching the data to know what HTML to render. all of these can affect both the time to first paint and the time to interactive. the idea is that if you can organize the HTML you send to the client and then the HTML that becomes interactive to work in concert, you have a way to significantly increase the efficiency of the whole process and improve TTFP and TTI. on the server, React starts by rendering the shell of the page, which kicks off any data fetching needed in each component. By using suspense boundaries, the server knows on that first render to have loading messages in place wherever data is being fetched. It then sends that shell (with script tags to load client code), and keeps the connection open. as data resolves on the server, it then will send incremental updates to the parts of the page that are ready to be shown to the user. it sends both the new HTML + a tiny bit of JS to replace the fallback in the suspense boundary with the HTML. once the fallback has been replaced, the React client code can hydrate just that part of the page to make it interactive. it knows how to do this because each suspense boundary is uniquely identified by its place in the tree of react elements and in the DOM, and that is known to server & client. I like this model a lot in theory, and it seems like it would be amenable to some of the architectural decisions photon has made. the part that I think is missing is the ability to track "loading" states, and the fact that the client/server contract (i.e. what HTML is rendered on the server can be properly hydrated on the client) isn't known yet

As a sidenote to Dustin: Under “HTML streaming” I meant this general technique of allowing to have a fast TTFP and TTI, while nonblockingly sending html to the client as it becomes available. I guess there are specific/additional techniques (maybe termed similarly) to optimize the rendering and transfer of the dom parts.

Thanks – yeah it seems Photon can support this model, just need a slightly smarter DOM effect layer (today photon-dom is like 100 LOC). Does not even seem hard. In Photon the client/server are synchronized so partial rendering and loading states should work out for free IIUC.