• Preact is great; if it's meeting all your needs, no reason for you to switch • lit-html and LitElement will get smaller when Template Instantiation lands in the platform • SSR is possible with web components, just not as far along – check Ionic's recent work here
-
-
Replying to @graynorton @slightlylate and
If there's no reason to switch from Preact, then why should anyone standardize on WCs as opposed to standardizing on Preact?
2 replies 0 retweets 0 likes -
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 @slightlylate and
Narrator: It did, eventually, come to this. In a few years, we'll take a deep breath and add a virtual DOM "std" layered API, tightly integrated with DOM Display Locking. Everybody will wonder what took Google so long to come around.
3 replies 0 retweets 0 likes -
Replying to @dfabu @graynorton and
It's unclear, in this story, who you think was driving all the other rounds of progress, not to mention LAPIs and Display Locking
1 reply 0 retweets 0 likes -
Replying to @slightlylate @graynorton and
Google! Including you, specifically! (Thanks, I really mean it!) But I still think we'll look back on today's iteration of WCs as a big distraction from the right thing.
1 reply 0 retweets 0 likes
We've certainly paid a large opportunity cost in the V0 -> V1 transition and, if I had it to do over, we'd have been focused on these problems instead of a migration to a slightly-but-not-enough-better starting point.
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.