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. |
dreamofabear
left a comment
There was a problem hiding this comment.
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 Updated mjs/js comparison for this new binary: |
@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.Elementand 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-analyzerI 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.