Skip to content
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

PR: switch to incremental parallel rendering via document implementation #167988 #14

Open
1 task done
Tracked by #167988
lemanschik opened this issue Dec 5, 2022 · 0 comments
Open
1 task done
Tracked by #167988

Comments

@lemanschik
Copy link
Contributor

I would like when this would render isolated without electron as also i would like if this would render more fast.
i would like when you merge my implementation so i can stop workaround your build process that brings me no joy or any good static analyze able code that i could depend on i do want to stop maintaining forks as also additional build processes

so that i can run this in a web browser without electron. in fact electron adds nothing to the browser its bloated bloat lets call it deprecated a old pattern that was useful before we got the right browser apis's directly.

depends on:

Streaming rendering context as also nodejs vm and so on

lemanschik 23 hours ago @lukastaegert the solution for that thing is throwing away the whole document context the module graph is assigned to

This is similar to the nodejs vm module doc === context in ECMAScript Speech.
in general the most best is to create a streaming document then load the modules inside that with its references
then throw away the doc if you want to re generate the module graph

https://developer.mozilla.org/en-US/docs/Web/API/DOMImplementation/createHTMLDocument

its a none widely known api most time only used by implementers this is also the solution to streaming rendering while it is bad to block the rendering th this does not do so so you can stream documents as it remembers the parsers open tag.

it is a independent html parser including dom including module graph

 let doc = document.implementation.createHTMLDocument("my-web-bundle-hash"); 
doc.write('<script type="module">')
// it executes as soon as you insert the tag the first time so the following fails
document.appendChild(doc.getElementsByTagName('script')[0]);
doc.write('imp')
doc.write('ort')
// ...

// .. nice sideEffect the sideEffects if any get not applied to this document as they are executed on doc
// gives us better isolation :) +1


/// overwrite 
doc = document.implementation.createHTMLDocument("my-web-bundle-hash"); 
doc.write('<script type="module">')

doc.write('import {} from "')
doc.write('my-module-hash";')
// it executes as soon as you insert the tag the first time so this works but you need to close the tag now on doc.
document.appendChild(doc.getElementsByTagName('script')[0]);
doc.write('</script>')
// now you can write new scripts to the same doc and attach them to execute.
// ...

the moduleGraph gets assigned to the current document including its sideEffect Results executed on the document as globalThis

the instantiated Module gets garbage collected if its globalThis is not existing anymore.

a new document will again ask the service worker on import to instantiate the module.
the serviceWorker then gets reasked and can serve the new content.

import ==== fetch.then.load per ECMAScript spec this did not change the ESMCache that is often talked about is the Instantiated Module Graph! this is misleading in the documentation.

even if a bit offtopic i want to mention that this speeds up any loading as you can parse html templates eg vite once in prallel they do all render on the main document independent. if you use more then one document and assign the open tags to the main document.

a bit more visual context supplied by google http 203 on youtube directly with time stamp but the whole episode is maybe useful for the most web developers. to understand how the main context works in general.

https://youtu.be/LLRig4s1_yA?t=1163

code-bin: https://jsbin.com/kaposeh/edit?js,output

And yes for your seo thing a common pattern is
Inital bootloader === serviceWorker
inital doc + assignment of 2 main rendering workers so documents
the first is the above fold content
the second is a less priority fold content section. that you track with the section interception api
and yes to schedule all that with less code you use stuff like mostjs streams which are a Clock aware scheduler implementation so you can use a variation of clockings for the rendering hooks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant