search

domenic / proposal-blocks

Former home of a proposal for a new syntactic construct for serializable blocks of JavaScript code
215 stars 5 forks source link

Is this adding parse time to the main thread? #6

Closed jakearchibald closed 6 years ago

jakearchibald commented 6 years ago

One of the benefits of new Worker('foo.js') is the parsing of foo.js has no impact on the main thread. Is this proposal moving the problem back to the main thread?

How would the parse time of the proposed blocks compare to an external worker, or template strings containing JS?

surma commented 6 years ago

I have no idea how blöcks would be implemented in detail, but in my mind, it would add parse time to main thread (provided you are using blocks on the main thread).

If parse time becomes a problem, you can still move the parse cost by doing it inside the blöck:

await worker({|
  const m = await import('/something.js'); // ← something.js will be parsed off-thread
  return m.superExpensive();
|});
jakearchibald commented 6 years ago

But in that case you're moving the content into another resource, which was MS/Mozilla's complaint about tasklets.

domenic commented 6 years ago

Yes. If you want separate source files, this feature is not for you.

The envisioned use case here is for cases where developers would have just wrote the source code inline anyway, thus hogging the main thread processing time (and parsing time, of course). But by making it easy for them to move small snippets into another thread, we can avoid the runtime cost.

So you'd use all the usual techniques for breaking up your app's initial parse time, even with blocks available.