-
Notifications
You must be signed in to change notification settings - Fork 153
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
Introduce "nodom" binary #882
Conversation
Sometimes developers may want to run arbitrary JS on a Worker safely/without access to a DOM. In those situations, the whole vdom implementation is overkill. This provides a DocumentLite with none of the implementation.
Based on the ease of integration with Since the worker-thread code is loaded dynamically, we can continue to do that and integration should be easy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Maybe we can find a name more descriptive than "lite". This feels like "worker-dom-but-no-dom". :)
E.g. "index.nodom.amp.ts" and "DocumentStub". Or "AntiDocument"... "NegaDocument".
Quick comment while out on leave: Please verify the contents of these new binaries, since the |
Good to know! I wasn't sure if the lack of |
@kristoferbaxter: seems like the |
This reverts commit f5679a1.
summary
Interactive pieces of AMP would like to safely run arbitrary JS without impacting the main thread. While often that may involve dom mutation, there are instances where that isn't necessary. A current example is Protocol Adapters.
For cases like these, it doesn't make sense to ship a binary containing the vdom implementation. Instead we could ship a dom-less "lite" version of
worker-dom
.Element
and friends don't enter the build.The method for removing the unnecessary code was similar in both cases.
Namely, hoisting the relevant to the entrypoints.
results (mjs)
Note: using the
rollup-plugin-analyzer
I was able to detect further improvements we could make to main-thread code. worker-thread seemed relatively optimized. I plan on adding this as a dev dependency in a future PR.