You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we have full native support, we may well need to reconsider the instance sharing question for this project with the native loader, and especially if this project continues to polyfill new modules features going forward.
That is, instead of treating the polyfill loader as entirely disjoint, it will be more and more common now to have varying subgraphs which use different new modules features.
One approach here might be to separate into two projects - a pure import maps polyfill only, and a new experimental project for new modules features.
If we go with the two build concept, then the polyfill should continue to use its own loader for performance, while the new project would be fully shared with the native loader.
Now that we have full native support, we may well need to reconsider the instance sharing question for this project with the native loader, and especially if this project continues to polyfill new modules features going forward.
That is, instead of treating the polyfill loader as entirely disjoint, it will be more and more common now to have varying subgraphs which use different new modules features.
One approach here might be to separate into two projects - a pure import maps polyfill only, and a new experimental project for new modules features.
If we go with the two build concept, then the polyfill should continue to use its own loader for performance, while the new project would be fully shared with the native loader.
For background on the performance issue see #208.
The text was updated successfully, but these errors were encountered: