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.
-
-
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.
1 reply 1 retweet 2 likes -
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 -
Replying to @lmeyerov @slightlylate and
(And to be clear: I'm 100% on evangelizing awareness around code overheads - that's a premise in a lot of my day job - but core app framework size is being weaponized incorrectly, afaict, for marketing or ignorance.)
1 reply 0 retweets 3 likes -
I mean "know what they're doing" in the most literal sense. In cases where sites perform well, teams have knowledge of (and mastery over) the contents of their bundle.
1 reply 0 retweets 1 like -
Replying to @slightlylate @lmeyerov and
And core framework size *would* be determinant for a large fraction of sites if they were setting reasonable budgets/targets. What I mostly observe in debates is that core lib size isn't the issue only because so much else is unknown/unaccounted-for.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @lmeyerov and
100K of critical-path JS on first load, for a mobile site that has a broad audience, is about right. If you're taking 35-40K of that for your *view framework*, that's...a lot.
1 reply 0 retweets 1 like
...and because view framework choice sets up so many other choices, it's imperative that these view frameworks message reasonable limits and goals to their users. React's...challenges...there are at least twofold.
-
-
1/3. I'm glad you agree that it is way more impactful for almost everyone for frameworks to solve the size problem for apps on top, vs trimming 50KB from the framework. I encourage people to switch from evaluating & evangelizing framework size to that!
1 reply 0 retweets 0 likes -
Replying to @lmeyerov @slightlylate and
2/3. Personal note: Apologies for using the colloquial interp of "who know what they're doing". As a language & system designer, I'm sensitive to when we push our inability to solve problems to our users, especially for enabling a wider pyramid of folks.
2 replies 0 retweets 0 likes - 22 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.