New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: server-side stache templates that support incremental rendering #1122
Comments
I think this would be really cool! I think the part to really focus on with this is how the client gets those "mutation instructions". Personally I would work backwards from "the developer shouldn't have to do /anything/. Maybe some JavaScript gets added to the |
@mjstahl yes, this is how done-ssr@3 works already! done-ssr inlines a script tag that begins fetching the mutation stream and apply mutations. I think this would be a good opportunity to share our tech with folks outside the |
@justinbmeyer i think that there is a reason why it not exists :) Only for your Info a HTML Response gets Incremental Rendered by the Browser while he streams the html file it don't needs to be there complet on the client. |
The
You can also pipe to it if whatever is creating this "file" presents itself as a readable stream. http://nodejs.org/api/stream.html and with that + deffered async stuff in html we even replace http push
i don't write now about what is right when but this is incremental rendering fully control able for every situation. I will only fast talk about the rel="preload" with css as many could think this is simply a none supported type to load the css async but it is a supported type that faster fetches as a none supported media type. And script type module is also always async JS that is none blocking!!!!! |
Frank, you have to write out in document order. Incremental rendering has no such limitation. The reason it doesn’t exist is likely because you would need a DOM-based rendering template engine. Those don’t exist server-side. |
@justinbmeyer nodejs has many dom based rendering engines 1 that would work is chromium headless firefox headless and so on but you would need the right rendering engine for the right request header this will not be performant. I have runned tests with caching prerendered pages per engine rendered serverside by the engine on request and that was not performant and also not a good idea as the rendering must happen in the browser version also and then also need to do that best device specific the best method in performance and compatiblity is to send out html from the server. I agree with your point of writing out html in order but that is not a bad thing at all for text from databases its a great fit as this can also be streamed. |
@justinbmeyer maybe i should also point out about The google Material Design Expirences that show the fact that slow loading but right timed is better then Instand loading! Examples: Click Image Fade Slow so the user Expirence is smooth Summary: Let JS Do the rest! For Search engines you render out for example the real final image tag a JS Script catches on inserted of the element and replaces it instant with the right skeleton view and that will replace them self with the original as loaded |
TLDR; Create an incremental rendering template engine for NodeJS.
Summary
Incremental rendering is awesome. It shouldn't work for only
Single Page Apps
when it would work great forMulti Page Apps
too. And while there are other server-side templates that support streaming, afaik, nothing else supports incremental rendering.A basic express app might look like this:
This would push out all the HTML except what the server is waiting on (the session and players). Once those promises resolve, the server will send out mutation instructions for those.
On the client, we'd probably have a
"mental.onDocumentReady()"
hook so people know when the page has been fully loaded.The text was updated successfully, but these errors were encountered: