As part of Greenwood's rendering strategy, it employs the use of Workers to encapsulate the rendering of Web Components for since SSR for Web Components requires exposing a DOM to the runtime, thus technically polluting the global NodeJS scope. However, it does add a lot of overhead, and as identified in #1079, having to emulate the Worker model for a server(less) workflow, is clunky not only for maintenance, but requires outputting two versions of the same file, essentially.
In theory this seems good, but in context with #970, it could make Greenwood a lot faster. Ideally we should be able to statically generate the templates ahead of time and inline them and just leverage the executeRouteModule functionality from at runtime.
As far as concerns with with global scope pollution is that for the WCs it is unavoidable and unlikely to ever be standard in the runtime. It also has a clearly defined scope and so does not manipulate anything in the time, it is purely additive. Maybe worth creating a discussion for? Also, serverless / edge functions have their own scope that gets spun up / torn down, so those can be isolated by default at least through the hosting runtime.
Not sure if VM modules could work? Ideally something that has the greatest degree of portability per #953 would be ideal if it was going to be a default.
Type of Change
Enhancement
Summary
As part of Greenwood's rendering strategy, it employs the use of Workers to encapsulate the rendering of Web Components for since SSR for Web Components requires exposing a DOM to the runtime, thus technically polluting the global NodeJS scope. However, it does add a lot of overhead, and as identified in #1079, having to emulate the Worker model for a server(less) workflow, is clunky not only for maintenance, but requires outputting two versions of the same file, essentially.
Per https://github.com/ProjectEvergreen/greenwood/issues/1104, it seems that Workers will at least be needed for local development as a means of providing a means for cache busting ESM modules.
Details
In theory this seems good, but in context with #970, it could make Greenwood a lot faster. Ideally we should be able to statically generate the templates ahead of time and inline them and just leverage the
executeRouteModulefunctionality from at runtime.As far as concerns with with global scope pollution is that for the WCs it is unavoidable and unlikely to ever be standard in the runtime. It also has a clearly defined scope and so does not manipulate anything in the time, it is purely additive. Maybe worth creating a discussion for? Also, serverless / edge functions have their own scope that gets spun up / torn down, so those can be isolated by default at least through the hosting runtime.
Not sure if VM modules could work? Ideally something that has the greatest degree of portability per #953 would be ideal if it was going to be a default.