• As Alex said, interop is a huge win for large orgs with multiple teams & disparate stacks • Yes, React ecosystem is huge today, but the entire web ecosystem benefits if more vendors (like Ionic) ship components that work well with *every* framework
-
-
Replying to @graynorton @slightlylate and
• 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
2 replies 0 retweets 9 likes -
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 @slightlylate and
You seem confident in your opinion, but I'm not sure where this confidence comes from. Levers and constraints differ, so it's not necessarily the case that the shape of the best platform-level solution will mirror the shape of the best userland solution for any given problem.
1 reply 0 retweets 2 likes
This is key. Compat alone constrains platform solutions in ways userland doesn't feel. There's a reason JSX is not re-integrated into the platform: it forked both HTML and JS syntax with no clear path back (and no attempt to try AFAICT).
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.