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.
-
This Tweet is unavailable.
-
-
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 -
Replying to @slightlylate @wycats
I’d strike Polymer from that list given the lack of an SSR story. Fatal to good FMP.
1 reply 0 retweets 1 like
That's an...interesting...claim. I see lots of SSR solutions that don't early flush, delay TTFB by a huge amount, double-or-triple-up overall data sent, etc. It's very much a footrace, but if you're lighter you don't need as much force.
-
-
Replying to @slightlylate @wycats
Just because you can get SSR wrong doesn’t mean you should bet on a technology that won’t ever let you get it right. H2 and SW have similar footguns; I wouldn’t use a framework that prevented me from using them.
2 replies 0 retweets 2 likes -
Show me the traces. It's easy: https://www.webpagetest.org/easy Paste in the URL of a good example, select "Mobile - Regular 3G", hit submit, share WPT result!
1 reply 0 retweets 0 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.