tc39 / proposal-module-expressions

https://tc39.es/proposal-module-expressions/
MIT License
438 stars 18 forks source link

Effect on bundle size / main thread parsing time, etc #71

Open matthewp opened 2 years ago

matthewp commented 2 years ago

My uneducated read of this proposal is that it will encourage people to use features like Workers (pending https://github.com/whatwg/html/issues/6911) more often, good, but it will also encourage them to put their worker code in the same script that their main-thread code is in, potentially bad.

What effect will this have on the bundle size of main-thread scripts? What effect will it have on parse-time, and real world Time to Interactive (TTI)?

Is there anything in the proposal that aims to limit the performance degradation caused by combining code from 2 files, that run in different threads, into 1 file?

acutmore commented 2 years ago

Hi @matthewp - my feeling on this is that tooling can help here. A bundler producing a more optimized 'production' output could extract the contents of the module block into a separate file that was only loaded by the worker.

Originally authored code:

// index.js
const m = module {
  import someLib from "lib";

  // lots of code that makes this module larger than some 'maxModuleBlockSize' bundler config
  // ....

  export default value;
};

const w = makeWorker(m);
...

Bundler emits:

// module-hash-xyz.js:
import someLib from "lib";

// lots of code that makes this module larger than some 'maxModuleBlockSize' bundler config
// ....

export default value;
// index.min.js
const w = makeWorker(module {export { default } from "./module-hash-xyz.js" });
...
matthewp commented 2 years ago

@acutmore Thank you, given that you cannot access scope variables then I think this seems like a safe optimization to do and will help quite a lot.


To perform that type of optimization, presumably the tool will need to know that this module is used as a Worker. So if used dynamically the optimization couldn't be performed (passing the module to a function that then creates a Worker, for example).

kriskowal commented 2 years ago

Yes, the caveat is valid: the tool would need either to optimize all module blocks and fragments as if they were potential worker entrypoints or have information out of band to identify entrypoints. Regardless of module blocks, bundlers will need to know all the entrypoints for workers, as might be achieved with a property in package.json or a code-comment on the block.