Perhaps surprising: I agree with @slightlylate that the discussion we're having about web performance isn't helping us move forward as a community.
-
Show this thread
-
This Tweet is unavailable.
-
I think that the developer community could really, badly use a discussion about which techniques work better, and I also believe that the discussion around React isn't helping us have that discussion.
1 reply 0 retweets 9 likes -
Replying to @wycats @slightlylate
Some people want to "blame React", while React people want to "defend React". But those two narratives overwhelm a discussion about which techniques, when used together with any framework, get the best results.
2 replies 0 retweets 19 likes -
Replying to @wycats @slightlylate
So it's not "React's fault", but at the same time being defensive on behalf of your framework of choice (I include myself with regard to Ember) is contributing to the poor quality of the community conversation.
0 replies 0 retweets 8 likes -
This Tweet is unavailable.
-
I think that it's wrong to blame React, because that isn't the conversation. It's not wrong to observe that people assume that React is "fast enough" and that there's too little discussion about techniques that should come default across the board.
1 reply 0 retweets 6 likes -
Replying to @wycats
Also, I don't "blame" React. Instead I note the probability (approaching 1) that sites with 400K of 1P JS include a relatively heavy framework, too many polyfills, and many other unneeded elements. Heavy FW use is a symptom of broken culture and management priorities.
2 replies 0 retweets 10 likes -
Replying to @slightlylate
Do you agree that tooling could eliminate or defer enough unused code (in combination with better patterns and programming models) so that the size of the "raw" framework matters less than how many features of the framework you're leaning on?
1 reply 0 retweets 1 like -
Replying to @wycats
I think tooling -- coupled to good choices in view, routing, and data layers -- is *already* getting real apps to a much better place. Teams need structure. It's why I recommend Polymer Starter Kit and Ionic PWA Starter Kit and Preact CLI and Next.js -- never "raw" view layers
2 replies 0 retweets 11 likes
The systems that set up routing, automate and support code splitting as the default, conditionally polyfill and optimally serve -- tools like that are winners in tough environments, but only when paired with budgets to prevent regression
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.