Right. Site wasn't built great, so why do you continually go straight for frameworks as the problem when they represent < 40kb of it?
-
-
Replying to @ryanflorence
Why is it that the sites I see that avoid adopting framework-of-the-minute tend to do so much better? If you read my post you'll hopefully understand that I'm discussing a management and culture issue. Frameworks we can't afford being overused are a symptom.
2 replies 0 retweets 2 likes -
Replying to @slightlylate @ryanflorence
Because selection bias. Of course sites using Svelte are brilliant: they’re engineered by the elite .1%, like
@Rich_Harris. He could do almost as well w/ React if he were so inclined. But yes, obviously the long tail of badly engineered sites are made with popular frameworks.1 reply 0 retweets 2 likes -
Replying to @AdamRackis @slightlylate and
It’s disingenuous bordering on mendacious to keep blaming React for 400K JS loads when React’s 1/12 that size. I’m sure a lot of people would be curious where all that junk is in fact coming from, but so far you haven’t told us. Are multiple copies of lodash sneaking in? D3?
1 reply 1 retweet 2 likes -
there's some truth to what you say, even if that part about me is fictional (I routinely struggle with fairly basic FED challenges). But the 'pit of success' is a thing, and not all tools lead you into it
2 replies 0 retweets 7 likes -
More seriously, I do acutely see tooling / circumstances that lack a pit of success. Tons of libraries built on CJS that pull the whole damn thing in unless you import things in super secret, bespoke ways. THAT would be a good hill for Alex to fight on. Not the 30K that is React.
1 reply 0 retweets 0 likes -
React takes a certain amount (far too much, but not a fatal number) out of your budget. This isn't about "don't use React"; this is "don't use any framework without support and a budget". Was that unclear from the article or traces?
1 reply 0 retweets 0 likes -
What’s still unclear about the traces is what all is in the bundles. Like Ryan said, you listed out items that account for only about 1/6th the total 400K. The things you seem angry about don’t seem to be the cause of the problem.
1 reply 0 retweets 0 likes -
The other stuff is the result of the cultural lack of support and infrastructure I've described. Most of the components that are loaded probably should be dynamically imported. But the authors didn't start with a system that encourages that sort of structure.
1 reply 0 retweets 1 like -
Ah so no code splitting? Whole app is shipped up front? The ghost of Browserify still haunts us
. I’m lucky to have come from the requireJS side - never touched Browserify, so code splitting’s always been second nature to me.2 replies 0 retweets 0 likes
"Just be smarter" isn't a solution. Teams need goals/budgets & structure+automation to keep them on the straight-and-narrow. "Learn one weird trick in my 5 week course to fix what you broke with the last one" is demonstrably not working.
-
-
The problem is, if teams don’t know how to use import(), then they’re probably not going to be setting & evaluating perf budgets. I admit me saying “just code split” won’t solve this problem, but neither will you saying “just have perf budgets”
1 reply 0 retweets 1 like -
I don't say "just have perf budgets". I say "have perf budgets and systems that support you by automating budget conformance and optimal code structure". It's a longer sentence, but it's what I keep typing out in different forms over and over and over and over.
2 replies 0 retweets 1 like - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.