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.
-
-
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.
1 reply 0 retweets 1 like -
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 -
Sorry - maybe I missed you on those days. All I’ve ever seen from you is ragging on React for encouraging bad practices. I’ve not seen you push things like Next as safety guardrails that help React be more of a pit of success. But that’s a great message! Agree
1 reply 0 retweets 2 likes
Look at the post, look at the links to the frameworks I cite. They're links to Sapper (not Svelte). Polymer PWA Starter Kit (not Polymer). Ioinic PWA Starter Kit (not Stencil or Ionic), Preact CLI (not Preact). Etc. etc.
-
-
Adam Rackis Retweeted Alex Russell
I missed this tweet - seems there was in fact a whole copy of lodash - lucky guess
I’m genuinely curious though: does Sapper or Preact CLI have some magic to prevent all of lodash from being plopped into your bundle? I can’t imagine how it could.https://twitter.com/slightlylate/status/1039700965618839553?s=21 …Adam Rackis added,
1 reply 0 retweets 0 likes -
Replying to @AdamRackis @slightlylate and
I actually think Preact CLI does have that specific magic!
1 reply 0 retweets 4 likes - 7 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.