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.
-
-
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 -
Replying to @AdamRackis @slightlylate and
Sorry to break this to you, though, but pretty sure Svelte uses same mechanism to code split as React, and I assume all the other frameworks: import(). See prior tweet about selection bias for why a higher % of Svelte apps pull this off vis-a-vis Reacthttps://github.com/Rich-Harris/rollup-svelte-code-splitting …
1 reply 0 retweets 0 likes
I keep saying "use higher-level systems, not raw frameworks" and you keep implying I'm arguing about frameworks. Stop misrepresenting me. Start with Sapper, not Svelte.
-
-
Sorry, if I’d seen you saying “don’t use React without Next, or similar, to guard against things like lack of code splitting / shipping all your app code up front” I would have responded very differently :-) https://github.com/zeit/next.js/blob/canary/README.md#dynamic-import …
1 reply 0 retweets 0 likes -
I say that *all the time*. I've said as much to everyone here on multiple occasions. This isn't a new position. I will, however, clarify in the post.
1 reply 0 retweets 0 likes - 11 more replies
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.