Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

evaluate (remove) use of Workers for SSR and prerendering #1088

Closed
thescientist13 opened this issue Apr 1, 2023 · 0 comments · Fixed by #1110, #1120 or #1121
Closed

evaluate (remove) use of Workers for SSR and prerendering #1088

thescientist13 opened this issue Apr 1, 2023 · 0 comments · Fixed by #1110, #1120 or #1121
Assignees
Labels
alpha.0 CLI enhancement Improve something existing (e.g. no docs, new APIs, etc) question Further information is requested v0.29.0
Milestone

Comments

@thescientist13
Copy link
Member

thescientist13 commented Apr 1, 2023

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 #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 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.

@thescientist13 thescientist13 added enhancement Improve something existing (e.g. no docs, new APIs, etc) question Further information is requested CLI labels Apr 1, 2023
@thescientist13 thescientist13 added this to the 1.0 milestone Apr 1, 2023
@thescientist13 thescientist13 self-assigned this Jun 3, 2023
@thescientist13 thescientist13 changed the title evaluate use of Workers for SSR and prerendering (make opt-in?) evaluate (remove) use of Workers for SSR and prerendering Jun 3, 2023
@thescientist13 thescientist13 moved this from 🏗 In progress to 👀 In review in [Greenwood] Phase 9 - Standards and Conventions Jun 21, 2023
@thescientist13 thescientist13 mentioned this issue Jun 29, 2023
25 tasks
@thescientist13 thescientist13 linked a pull request Jun 29, 2023 that will close this issue
25 tasks
@thescientist13 thescientist13 linked a pull request Jul 4, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
alpha.0 CLI enhancement Improve something existing (e.g. no docs, new APIs, etc) question Further information is requested v0.29.0
Projects
No open projects
1 participant