Convopage
See the entire conversation
PSA: embedding/applying CSS in JS is the surefire way to be on every slow path. Bloats memory, slows parsing & use, hurts caching. Avoid.
139 replies and sub-replies as of Mar 25 2017
you mean computing inline styles and such?
I feel like css modules where webpack provides the class names for you with one css payload would be fine. Could be wrong :)
even inserting a <link> tag on the <head> for what's actually needed for the content?
that's fine, but again, slower than having in doc in the first place (because preload scanner)
i see... so it's better to use preload even if the stylesheet might not be used?
depends on size, but the main thing to avoid is bundling your stylesheets inside your JS.
i guess that's a webpack thing?
but it's the JSX way 😒
and it's SLOW (as is the excess computation per element that vdom adds, but another point for another time)
Idd. I'm not a fan for sure. My React projects have separated CSS for many reasons.
Ran into this in a Webpack project recently, but I found ExtractTextPlugin to be a pretty easy fix: 😊
extract css to separate file in production by nolanlawson · Pull Request #850 · apache/couchdb-fauxton
With this change, we use extract-text-webpack-plugin to extract CSS from our JavaScript bundle into a separate CSS file. There are a few performance benefits to this change: JS bundle size is smal...
github.com
i'm sorry, i'm confused: why do you need a plugin to extract css? can you not put it the bundle in the 1st place?
My understanding of Webpack is that the "default" is usually CSS-in-JS. ExtractTextPlugin moves it to separate file.
wow, i thought you could pack things as you saw necessary. that would explain a lot. thanks!
bundling JS is the only default in webpack.
there exists solutions for css-in-js bundles and separate CSS bundles alike
however users are free at their will to choose w/e.
that being said we should add docs to what are recommended best practice
yes ofc there is a limit to how much that should be used in prod.
Right even dataURIs as advocated in that vid have perf problems (e.g. for imgs)
AFAICT everything is JS by default because 1) Node CJS module graph and 2) HMR
yes, btw this is an impetus for our WASM research.
because would open up architecture for other modules as first class citz
WASM is speculative, whereas CSS & HTML templates being super slow is NOW
/cc @nolanlawson @thespite @sebmarkbage @addyosmani
sure, I agree, but it's not like there isn't a solution for it in this case
my point is that we have a strong interest in opening up the arch.
but needed a grantworthy feature to be first implementation
mental model: n resources in, 1 bundle out. Plugins do the split
I always use ExtractTextPlugin (wish it was default). CLIs like Vue default to using it in their main templates that use Webpack.
I'm surprised to hear people _don't_ use ExtractTextPlugin, seems like a safer default
there are uses for both or mixed. But sometimes folks are lazy or don't understand the tooling.
but remember there is no default for any of this. They are all procured by loaders at user discretion.
much ❤️, these are hard problems; seems like everyone wants a "free lunch" and doesn't want to learn how their tools work!
yeah I mean maybe the name style-loader should be, inline-CSS string-into-js-module-that-adds-script-tag-loader
I mean its hard because web is one of 7 deployment targets also
like I said, I'm surprised that people don't know about ExtractTextPlugin, maybe it just needs some evangelism?
yeah. I'm thinking when we get to crafting cli templates also this will be a default for css-in-js for prod environment
PS even more so how about that extraxt-fax-plugin 😎😂
like, I didn't even consider using webpack 2 on my team until ExtractText worked out of the box. Sine qua non for production
I know it's old, but this image makes me think it's the whole premise of what webpack does...
that premise still applies
The new webpack docs can clarify pretty much any confusion. They are good docs, Sam.
nice subtweet ;). How much of this is mitigated by SSR?
wasn't meant to be! @phae mentioned yours (I'd missed). SSR won't impact if strings still in JS bundle or replayed later
haha I'm just kidding around :). Presumably SSR helps with parse and FMP, still pay for the rest (incl JS parse)
Wish I could pin this tweet 😢
AMP does it and it hasn't really come up as a problem.
Without async on link tag I don't really see an alternative.
AMP forces inline styles. We should chat re async. I'm v unhappy we don't have async/defer everywhere you can include resources
but it’s what all the cool kids are doing, or so I’m told.
I've yet to see this in prod. I've seen many, many webpack configs. Granted, maybe not as many as Alex.
we should be fixing these perf problems instead of trying to shame developers out of a preferred workflow.
we have different definitions of "shame"
also this. Is it "shaming" to note how browsers work? I see it as the beginning of a tools-based fix.
when the tools automate compiling this stuff out into external script files, nobody has to give up any workflow.
so it's unclear to me what you're actually objecting to.
telling people avoid something is shaming? OP didn't recriminate anyone...
thot lead, don't thot police
but for the small matter of JS semantics, we could.
we've been trying for years. HTML Imports, which completely fixes this, is still stuck in limbo. @slightlylate
Maybe HTML and CSS modules can succeed where imports failed, but all browser vendors need to admit the problem first @slightlylate
and now the hardest part of it all: politics!
i'm excited about HTML Modules. The mental model will work better for most JS devs I think.
OT: I haz a sad we're calling web developers "JS devs". Not understanding platform is how we got here.
by "JS devs" i mean "the people who do everything in webpack today" - but fair point.
Personally, I'm upset we're calling webmasters "web developers" ... how'd that happen?!
"Web Wizards" sounded a bit full of ourselves I reckon
where can I learn more about HTML modules? First I've heard of them.
they're a refinement of HTML Imports to work better with JS Modules: github.com/dglazkov/webco… @robwormald @slightlylate @mikeal
dglazkov/webcomponents
webcomponents - Web Components specifications
github.com
or "HTML Imports except you can get stuff out of them like ES modules"
earlier convo re: CSS-in-JS+webpack - HTML modules could work. #UseThePlatformAsABuildTarget
ugh, sorry but #UseThePlatformAsABuildTarget sucks, I don't want to have to build to dev @mjackson @slightlylate @mikeal
I don't want to target a bundler as a platform, but the native capabilities @mjackson @slightlylate @mikeal
i have a hard time buying this when we have a spec for ESModules but no way to load them.
I think we'll get there, eventually. webpack feels like a stepping stone.
my problem w/ webpack, no offense to @TheLarkInn, is it supports features the browser won't @robwormald @slightlylate @mikeal
so devs have to run it during development, and it's become a platform of its own @TheLarkInn @robwormald @slightlylate @mikeal
when devs go to move to native imports, they'll hit problems @TheLarkInn @robwormald @slightlylate @mikeal
seen enough generations of this to call it now: they won't move. Replace/new dev
remember we're debating small fraction of web dev that doesn't just use jquery
it would be trivial to make webpack emit html modules instead of CSS-in-JS...
ran angular for the 1st time (ever?) with full es native imports. beautiful thing
i had to rewrite my paths from './foo' to './foo.js' - but i have tools for that!
recently did the same for a custom elements thing w/ incremental-dom, was great! @mjackson @TheLarkInn @slightlylate @mikeal
but if I were using custom WebPack/ReqJS/SystemJS loaders I would have been stuck. @mjackson @TheLarkInn @slightlylate @mikeal
yep. static nature of angular makes lots of common webpack patterns difficult too
tell me more. The static nature of HTML Imports/Polymer makes bundling p easy. @mjackson @TheLarkInn @slightlylate @mikeal
styleUrls: [ require('./foo.css') ]
vs
styleUrls: [ './foo.css' ]
ah, so you really could use a native `import styles from 'foo.css';`, huh? @mjackson @TheLarkInn @slightlylate @mikeal
right - our compiler can grab string statically and use that when emitting
and importing css would give you both: 1) the compiler can locate the resource or.. @mjackson @TheLarkInn @slightlylate @mikeal
2) no compile and you import a CSSStyleSheet and can attach that. Transparent tools @mjackson @TheLarkInn @slightlylate @mikeal
honestly I believe that this should be impl. so bundlers not needed.
I am in support of it, but unfortunately too many bikeshed-39rs have expr. unwant
tooling should understand your app, so http2(push), preload/fetch, sw etc are seamless
thats a lot easier to say than to implement.
former is inlined as a string. latter used by compiler to statically locate file
when they move to native imports, we'll just have a output target for esm
I'm talking about the input, not the output. During dev I don't want to run bundler @mjackson @robwormald @slightlylate @mikeal
I'm planing on bundling html imports in JS using webpack until then.
like HTML Imports? /ducks (sorry)
I do, by writing and using optional, transparent tools! ;) @robwormald @mjackson @slightlylate @mikeal
Hahaha, :-P of course. We are all trying to do that (eventually)
*you* shouldn't have to - good luck convincing the ecosystem to chuck webpack. meet 1/2 way.
we need more grassroots demand for this, Polymer's been on an island. I hear @youyuxi might like them too @slightlylate @mikeal
Whoa.... Is this a thing? HTML Module spec link plz?
doesn't work in a web worker 😐
wat. Srsly, tho. How far are we down the rabbit hole when that's the concern?
you tweet daily about how running any code at all in the main thread destroys perf, so that far.
but this is UI code. It has to run on the UI thread.
also, I'm not absolutist. Load (some) code! Just do it in proportion to what's in view & watch budgets.
nah, main thread only has to apply it. Component definitions can be in worker.
components are UI, should be ok on main thread. If you're blowing budgets, move biz & i/o logic to workers @slightlylate @mikeal
splitting UI across an async serialization boundary just makes the app architecture so much more complex @slightlylate @mikeal
not to mention induced input latency.
try out aliens.click Let me know any latency issues you experience.
Does anyone have a link to an actual website doing this in production?
thoughts?
He's rightfully stating how browsers work. Mix js+css and it'll hurt.
You can lobby for a different approach. But if you ship something way today it'll hit reality.
we splice on compile so it's only a development thing for us - doesn't affect perf at all @slightlylate @gloddy
on a whole different note: I dislike the tone of voice in the first tweet, shaming people is uncool @slightlylate @gloddy
I called out no-one specifically. I merely noted how browsers work and why what I'm seeing is slow
/cc @okdistribute @gloddy
if that's "shaming", then I no longer understand language.
/cc @okdistribute @gloddy
Eek. People do that? Huh.
filesize and bundles apart would the cssom api be preferable / fast to dom nodes insertion/replcement/deletion?
another question is what you said a concern in a component based app that does code splitting and where css is static?
I would love to know if there is anything that we can improve in styled-jsx
zeit/styled-jsx
styled-jsx - Full CSS support for JSX without compromises
github.com
will look
thank you 😊