If there's no reason to switch from Preact, then why should anyone standardize on WCs as opposed to standardizing on Preact?
-
-
Replying to @dfabu @graynorton and
Overall, if the answer to "why switch from Preact to WCs" is "no reason at all; in fact, SSR gets worse" then we should try to standardize Preact/React components in userland and turn the result into a "std" layered API.
1 reply 0 retweets 0 likes -
Replying to @dfabu @slightlylate and
The fact that there's no reason for you (or any given individual dev) to switch to WCs today doesn't mean that there's not value in the ecosystem as a whole shifting to adopt a platform-native component model eventually, as the standards evolve.
1 reply 1 retweet 5 likes -
Replying to @graynorton @dfabu and
In practice, the web ecosystem will never standardize on any particular userland solution, and shouldn't. Layered APIs don't really change this equation; they're just a new way for the platform to ship features, with a "pay-for-what-you-use" consumption model.
1 reply 0 retweets 4 likes -
Replying to @graynorton @slightlylate and
The problem is that we won't standardize on custom elements with shadow DOM, either. Thanks to slot SSR rehydration issues, userland SSR solutions are faster to paint than the "standard" and just as fast to TTI.
1 reply 0 retweets 0 likes -
Replying to @dfabu @slightlylate and
It's not clear that the rehydration challenges with Shadow DOM are unsolvable. In the worst case (tho I doubt it will come to this), it will be back to the drawing board. Userland solutions are a good measuring stick for platform features, which inevitably have a longer arc.
2 replies 0 retweets 2 likes -
Replying to @graynorton @dfabu and
I'm also skeptical of the long-term need for SSR, particularly as practiced today with ultra-long late pauses when massive JS bundles eventually arrive. The "do less work total" plan is a good one.
3 replies 2 retweets 5 likes -
Replying to @slightlylate @graynorton and
There's no way to beat SSR for FCP, not even in principle. I'm totally on board with reducing the size of bundles, but we're really no better off with a big WC bundle that doesn't paint until it's interactive than we are with a giant Preact bundle.
1 reply 0 retweets 0 likes -
Replying to @dfabu @graynorton and
I see so many sites blowing it thanks to SSR. You're in the dialed-in, tuned-up micro-group that isn't burning 500ms+ on the server for every round-trip thanks to SSR overhead because you know that to get the win your server-side has to *actually be fast*.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @graynorton and
Luckily, SSR performance tends to be monitored and optimized, because you have to pay for more server time when it gets slow. Client-side TTI is often a negative externality. ("What if we just made the client do it, instead? It works fine on my iPhone XS.")
1 reply 0 retweets 0 likes
Again, and I hate to broken-record this, but you're in the group that _cares_. And it's a tiny club. So much of SV makes a mess, takes the promotion, and moves on. The "new architecture" doesn't actually deliver the sold-in benefits? The developers are happy, soooooooo.....
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.