Honestly I feel this approach will insert many possible side effects to an app. One of the problems I have stumbled with bigger apps is css render blocking.
The team of Svelte did a similar approach: they insert all css in the head after Svelte finish loading, but sometimes it takes like a second to execute that code so all the app's layout loads naked and only then css is insert.
If a simple app (like an online color picker) visually depends on your package it would make more sense to have those styles already in the HTML file (critical css, SEO, SSR, etc). Now imagine if every package creator uses this approach, they will be a cascade of pending styles.
I feel we should let the package users decide the way they want their css to be handled. You could maybe export a function helper which loads the styles? (loadColorPickerCss())
FWIW, react-colorful only ships 1.6kb of (minified) CSS. The amount of JS that would be needed to slow down this injection would be monumental, and even then, would only be noticed if this color picker was right at the top of the document.
I think that's searching for a solution before a problem has even appeared. The amount of JS we're talking about would already make the site really rough.
Yes, I know that for this specific library this is no issue. But a bigger app will probably use more packages, then we got the node_modules hell... Also not everyone creates packages with size and zero-deps in mind like you do.
Imagine an node app were my deps are: react-colorful (0 deps, 1kb css), react-slider (8 deps, 100kb css) and tailwindcss (64 deps, 3mb css). If those package creators all use the same method to inject css into the documents' head and react-colorful render happens deep in the tree the chain could be like: 1. tailwind injects code, browsers starts downloading 3mb of a css file... 2. react-slider does the same... 3. react-colorful does the same a little faster. In my fictional case there where only 3 main deps but you can see where a cascade of waiting requests could be created for slower connections or with more package deps...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Honestly I feel this approach will insert many possible side effects to an app. One of the problems I have stumbled with bigger apps is css render blocking.
The team of Svelte did a similar approach: they insert all css in the head after Svelte finish loading, but sometimes it takes like a second to execute that code so all the app's layout loads naked and only then css is insert.
If a simple app (like an online color picker) visually depends on your package it would make more sense to have those styles already in the HTML file (critical css, SEO, SSR, etc). Now imagine if every package creator uses this approach, they will be a cascade of pending styles.
I feel we should let the package users decide the way they want their css to be handled. You could maybe export a function helper which loads the styles? (loadColorPickerCss())
FWIW,
react-colorfulonly ships 1.6kb of (minified) CSS. The amount of JS that would be needed to slow down this injection would be monumental, and even then, would only be noticed if this color picker was right at the top of the document.I think that's searching for a solution before a problem has even appeared. The amount of JS we're talking about would already make the site really rough.
Yes, I know that for this specific library this is no issue. But a bigger app will probably use more packages, then we got the node_modules hell... Also not everyone creates packages with size and zero-deps in mind like you do.
Imagine an node app were my deps are:
react-colorful (0 deps, 1kb css),react-slider (8 deps, 100kb css)andtailwindcss (64 deps, 3mb css). If those package creators all use the same method to inject css into the documents' head andreact-colorfulrender happens deep in the tree the chain could be like: 1. tailwind injects code, browsers starts downloading 3mb of a css file... 2. react-slider does the same... 3. react-colorful does the same a little faster. In my fictional case there where only 3 main deps but you can see where a cascade of waiting requests could be created for slower connections or with more package deps...