ungap / custom-elements

All inclusive customElements polyfill for every browser
ISC License
240 stars 14 forks source link

Nop execution in non-browsers #9

Closed mitranim closed 2 years ago

mitranim commented 2 years ago

First off, thanks for the polyfill. It seems to work and has been a huge help.

For anyone dealing with "isomorphic" code, or simply using Deno or Node to test abstract components of an app, it would be nice if importing this polyfill didn't throw exceptions and simply did nothing. In those "server" environments, you're usually not concerned with loading redundant code, especially 1 small file. It would spare people some effort.

WebReflection commented 2 years ago

this polyfill has no meaning for the server ... you can use feature/detection or create documents dropping this polyfill from the layout, right? basically you are asking me to increase code size for a non-intendend use case, and I am not sure why anyone would do that? 🤔

WebReflection commented 2 years ago

P.S. with JSDOM the global is polluted with document, window, etc ... with LinkeDOM you can pollute it before parsing the document and yet no script is executed there ... it looks like you should check how to disable JSDOM execution or just use LinkeDOM instead if it works out of the box?

mitranim commented 2 years ago

Native JS modules are static. You can't feature-detect and conditionally use an import statement. You could use await import() but this syntax has less browser support and might have other negatives. To clarify: the issue affects hybrid apps which have a client component and happen to import that into their server component, such as for SSR, and which happen to use native JS modules rather than require. In SSR, you don't use JSDOM or LinkeDOM, so I'm not sure why you brought them up. Those polyfills are the kind of stuff you really don't want in your Deno or Node process. But the custom element polyfill is 1 tiny file with very little startup impact. Feature-detecting in the polyfill is more feasible than in user code that imports it via native import.

mitranim commented 2 years ago

I agree with you that increasing the polyfill's size and complexity for an edge case is iffy. Depends on the amount.

WebReflection commented 2 years ago

In SSR, you don't use JSDOM or LinkeDOM, so I'm not sure why you brought them up

Because you dont' execute JS that's meant for the browser neither? And btw, I do use basicHTML (similar to LinkeDOM) for SSR too, see heresy or others.

Those polyfills are the kind of stuff you really don't want in your Deno or Node process.

Exactly. so why are you importing those? Use an import map and solve it for the backend? just point at an empty file and call it a day? Nothing to do here. imho, as import maps are the way to solve these cases.