Because this is in the now-traditional style of cultural-React-inspired DIY-bloat (everything's pluggable, which means an exercise to the reader), the app bundle includes Proptypes, what *looks* like a full copy of Lodash, and oh so very much more.
-
Show this thread
-
The net result is to push TTI in this trace back nearly 4 full seconds: https://www.webpagetest.org/video/compare.php?tests=180912_6Q_5fd08e0ef64071de6f3cd266c36a3cac-r:1-c:0 …
1 reply 0 retweets 1 likeShow this thread -
There's a lot going on deeper in this app, it seems: https://github.com/department-of-veterans-affairs/vets-website/tree/master/content/pages … But why is the front-page paying for that? Why are our vets and their loved ones being slowed down in accessing essential services this way?
3 replies 0 retweets 6 likesShow this thread -
If there's something that *doesn't* need React, it's a drop-down menu. The sport of pure-CSS drop-downs was won more than a decade ago. There's no excuse.
5 replies 4 retweets 34 likesShow this thread -
Replying to @slightlylate
If I look at the source (in Sources pane) then what I'm seeing seems related to authentication, forms, making claims, etc. So if anything I think the goal was to make the logged-in experience have less latency from page reloads. Of course should’ve been code split from main page.
1 reply 0 retweets 1 like -
Replying to @dan_abramov
"less latency from page reloads" would be preloading cacheable assets at low priority (e.g., a <link rel="preload"> or a SW install phase), not running code on pages that don't use them.
1 reply 0 retweets 1 like -
Replying to @slightlylate
Would your experience of using Twitter improve if Twitter reloaded the page on every click? That seems to be your suggestion. I understand you re: static pages not needing React perfectly well. I agree with it. But clearly the developers didn’t use React “for a dropdown”.
2 replies 0 retweets 3 likes -
Replying to @dan_abramov @slightlylate
My point is that React was used for a dynamic part that seems to appear when you sign in. It would be better to not load that part until you actually do — and there’s nothing stopping them from implementing this with React.
1 reply 0 retweets 3 likes -
Replying to @dan_abramov @slightlylate
I think it’s a bit disingenuous to claim React makes the overall experience worse in this case since we don’t actually know what the dynamic part is like. It’s quite likely that slower initial load might be worth the wins in interaction latency _for dynamic parts_. Not home page.
1 reply 0 retweets 3 likes -
Replying to @dan_abramov
It's not React per-sae, it's *cultural* React (and other frameworks) that leave developers like this drowning in a sea of incidental complexity without the tools they need to manage the responsibilities they've (often unknowingly) bitten off by taking the reigns with JS.
2 replies 0 retweets 2 likes
The cause here isn't the view framework, it's the lack of discipline and constraint that is now nearly always co-incident with framework adoption.
-
-
Replying to @slightlylate
Can we say cultural-Polymer-inspired once in a while — just so it doesn't look like you're always taking stabs at React when you mean "client side code"?
2 replies 0 retweets 8 likes -
- 2 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.