Or, if you've bought into "SSR", configure your backend to continue to run Frankenstein's Monster server-side but omit the <script> tags that inflict "hydration" on users.https://twitter.com/scottjehl/status/1161354176716320770 …
-
-
Replying to @slightlylate
you know I'm with you in this, but isn't one of the major selling point of Custom Elements (Web Components, whatever) automatic "hydration" once the definition kicks in? I don't think a Web without <script> is realistic, or even an option these days, so I wouldn't push too far.
1 reply 0 retweets 4 likes -
Replying to @WebReflection
the issue here is the (false) promise of "isomorphic JS" which causes folks to build apps to the limits of what their servers can handle, not the client. So a caricature, but grounded in immodest amounts of JS. I'm only advocating for the modest variant.
1 reply 0 retweets 5 likes -
Replying to @slightlylate @WebReflection
A pattern I'm starting to advocate with teams is that they can keep their React monstrosity, but sequester it to the server (via "SSR"), then have that emit a small number of WC/jquery scripts for progressive interactivity in the limited places it's needed.
2 replies 2 retweets 9 likes -
Replying to @slightlylate @WebReflection
On a purely emotional level, and as someone who overuses JS in negative ways and feels uncomfortable about it, the idea of going back to using jQuery (specifically) is a hard pass. So, that part of this story needs work. There has to be a better lib to use.
3 replies 0 retweets 1 like
Yeah, I wouldn't actually recommend jQuery per sae; doing some modern Web Components seems like the Right Answer (TM). They can be tiny, independent, and progressively enhanced.
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.