I understand that but I don't think WCs currently have the features to replace everything modern frameworks do. Rather than ignore them entirely I try to encourage folks to use them for their shared UI because that seems like the strongest story. And we build up from there.
-
-
Replying to @rob_dodson @treshugart and
Can you elaborate on which features specifically?
1 reply 0 retweets 0 likes -
Replying to @passle_ @treshugart and
SSR, a strong routing story, state management, lazy-loading like Suspense
2 replies 0 retweets 4 likes -
Replying to @rob_dodson @treshugart and
I think SSR and lazy-loading are fair points yeah, but I'm always surprised (and this may be naively thought on my end) to see people use "WCs are missing framework features", because at its core, most frameworks also just offer a component model
1 reply 0 retweets 6 likes -
Replying to @passle_ @rob_dodson and
If you need state management, you'll still pull in some external state management lib (redux, mobx, whatever), if you need routing, you’ll still pull in a router. Most frameworks have a good router, but the router is not part of the framework.
2 replies 0 retweets 7 likes -
Replying to @passle_ @rob_dodson and
⚡Klaxon Retweeted Maarten
At the same time, I can do this with web components, too. So I'm very much in agreement with this sentiment: https://twitter.com/Maarteuh/status/1122875689751982080 …
@Maarteuh (which I already believe to be the case for frameworks, too)⚡Klaxon added,
1 reply 0 retweets 6 likes -
Replying to @passle_ @rob_dodson and
Furthermore, I believe many people's problems with using web components as their app context is overusing shadow dom, and overusing web components; not *everything* needs shadowdom and not everything needs to be a web component
6 replies 1 retweet 15 likes -
Replying to @passle_ @treshugart and
It's true they're not part of the frameworks, but they're often tailor made to work harmoniously and there's a big ecosystem of support. Almost everything is possible with WCs but it tends to be much more ad-hoc. I think it's much harder to scale that across a big team.
1 reply 0 retweets 1 like -
Replying to @rob_dodson @passle_ and
And I agree re: over use of shadow dom. That's kind of what started this whole discussion. If you want to program like you're using react, it almost makes sense to put everything in shadow dom, but that's actually _not_ what you want. And that's counterintuitive.
1 reply 0 retweets 9 likes -
Replying to @rob_dodson @passle_ and
Otherwise you end up with a <my-app> that buries everything in shadow dom all the way down. I used to think (and teach) that's how it was supposed to be done but I think that may have been a mistake.
2 replies 0 retweets 12 likes
I recall being somewhat horrified when I first saw the `<my-app>` thing w/ no light DOM. Still am, but was too.
-
-
Replying to @slightlylate @passle_ and
Yeah from the developer side it gave you what you wanted and rendered ok but ultimately feels like the wrong approach
2 replies 0 retweets 0 likes -
Replying to @rob_dodson @slightlylate and
Why though? If it's truly an app does it matter? Do we want iOS and Android apps to render content to their (lacking)equivalent of light DOM? Put another way: Gmail isn't indexable, and if it were written as <g-mail></g-mail> it wouldn't matter.
3 replies 0 retweets 3 likes - 4 more replies
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.