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?
-
Show 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 -
Replying to @slightlylate @dan_abramov
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.
1 reply 0 retweets 1 like -
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
-
-
Replying to @slightlylate
Thanks
This might help you reach the very people you’re trying to educate. It’s difficult for somebody who’s invested in React because it solves some of their problems to really hear your message because they mostly hear “React is bad” and not “use/avoid these techniques”.2 replies 1 retweet 6 likes -
Replying to @dan_abramov
FWIW, the http://code.gov disaster I embedded the video of in the blog post is an Angular joint. I know you feel called out, but I'm not singling React out in a way that's more frequent than its use.
0 replies 0 retweets 3 likes
End of conversation
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.