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
-
-
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 -
Replying to @rob_dodson @passle_ and
I recall being somewhat horrified when I first saw the `<my-app>` thing w/ no light DOM. Still am, but was too.
1 reply 0 retweets 5 likes -
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
I think the "problem" here is that, like upgrades, it's a choice that other tools elide . They either don't have the flexibility to provide the benefits (so you're left cobbling things like CSS-in-JS together) or don't want to present the complexity up-front.
-
-
Replying to @slightlylate @rob_dodson and
Right. We get dinged for the choice because it's a complexity that frameworks push to later, and because we argue about the "right" choice :)
1 reply 0 retweets 0 likes -
Replying to @justinfagnani @rob_dodson and
I think this argument only works "because SEO". Excited to see how that holds up for the folks offering it
1 reply 0 retweets 0 likes - 1 more reply
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.