My first question would be "why is React still 90K"? React team is still talking about features like hooks and concurrency (which are cool of course), but I'd *love* to see the biggest feature of all: shrinking the framework to 35K. :)https://twitter.com/slightlylate/status/1238122890450485248 …
-
-
A guess: Frameworks should enable optimizing the downstream code. When they go too slim, people load lodash, moment, amateur widgets, excess dependencies, out-of-order loads, low hw utilization, etc. I'd take 100KB heavier react for fixing that stuff.
1 reply 0 retweets 1 like -
(sorry to break the narrative here - it is a lot easier for framework authors to compete on slimming their bytes, but that's a red herring on the real problem IMO, and not surprised if this tricks users)
1 reply 0 retweets 0 likes -
Like, if you ran a roofline performance model on a website, I'm pretty sure the conclusion will be "if react goes from 90kb to 30kb, it will be 2% better, but if react goes to 200kb and fixes stuff, it'll be 3X faster"
1 reply 0 retweets 0 likes -
React hasn't made anything 3X faster though (or actually anything faster that I'm aware of, the DOM is not slow). React is about ergonomics, and it has excellent ones (maybe the best). Concurrent is about responsiveness. It does those things well at a price. Is the price right?
1 reply 1 retweet 3 likes -
While I've ~happily hand-rolled multicore WASM in the past, I'm happier writing React and letting it worry about JS + DOM optimizations. If you're not aware of the optimizations it's doing, I don't think you need to worry about 50KB or whatever.
1 reply 0 retweets 3 likes -
My bigger point is: it's great to want more from your JS frameworks, but instead of burning framework dev hours on 30KB vs 90KB, get them to go 300KB and fix the broader problems. Code golfing is fun, but 95% wrong problem.
2 replies 0 retweets 2 likes -
I was one of the first to grind on measuring power+CPU consumption on phones for this stuff... Not the problem. This stuff is tricking people into a bad reinforcement loop on misguided tool adoption + poorly spent optimization efforts.
1 reply 0 retweets 0 likes
For mobile, the question isn't (usually) the framework size; as you note. However, teams that are doing well on bundle size *almost universally* reject tools as heavy as React. 30K might not be the difference, but it strongly indicates a team that knows what they're doing.
-
-
I'm not sure what that tells us - most folks do not optimize their code irrespective of framework, so I'd expect the most popular frameworks to have slower sites on average by definition.
1 reply 0 retweets 2 likes -
Replying to @lmeyerov @slightlylate and
Worse, phrasing like "teams that know what they're doing" is this exact kind of shaming for grossly incorrect technical reasons.
1 reply 0 retweets 1 like - 29 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.