Benjamin Gruenbaum

> no widely-used library is going to work around the effects of an early-running script's virtualizations, and so in practice it is straightforward to virtualize a typical page. If this...

Here are some random examples I can name that are basically people writing an SDK: - At Peer5 we had to do this in our SDK in a few places....

> I dislike the example of Node - Node is strictly more powerful than first-run code, since it controls the platform This is precisely the capability this proposal would like...

> Yes, I know. My point is that there is a lot of code which relies on this capability not being available to userland. (Or rather, to be precise, being...

> Service workers don't really compose, can't generally be provided as part of a library, and only even see requests to the same origin, so they are not a solution...

If you would like I can connect this team to the organizers of the Node.js Israel monthly meetup :]

For the change to make sense to me we need to address deprecation cycles and semver-major changes. If the release plan can be adjusted while keeping those at an as-good...

> My understanding from the session we had at NodeConf.eu was that very little feedback is provided by the non-LTS releases, We have a concrete recent counter-example with `navigator`

> in any case I guess it's okay to assume the performance impact is null. Seriously, why would you do that? You acknowledge that the benchmark doesn't make sense because...

That's entirely fine, but a) As a library author I think you should validate that since it's not just your code that's at stake. b) You probably shouldn't post benchmarks...