3 ms·

I've refreshed myself on web components, templates and shadow DOM, and I understand how each of them works, but I only see immediate benefits from templates. Th

by slver 5y ago

I've refreshed myself on web components, templates and shadow DOM, and I understand how each of them works, but I only see immediate benefits from templates. The rest seems a bit like abstraction for abstraction's sake and syntax sugar over existing capabilities. What am I missing, what's the elevator pitch for web-components and shadow DOM? Scoped styles seems to be something that's pushed with shadow DOM a lot, but isn't <style> in the page body illegal HTML (despite yes, it works)?

serverholic 5y ago
I'm wondering about the elevator pitch too. Honestly it seems like github went through all this trouble just because they don't want to commit to a framework like react. Still having a tough time seeing the benefits of web components.
- slver 5y ago
  I find it odd that people compare React and web-components a lot. Sure, superficially both have custom components. But why does that matter even? To me React's value is JSX and ReactDOM. I actually use JSX+ReactDOM without the rest of React, using basic classes. Works great.
marcosdumay 5y ago
The benefit is scoped everything (styles, JS, templates). So that when your site grows, and you start erasing functionality because you created something better, you can actually erase the entire functionality with confidence, and not have some stuff hanging around because nobody is sure what it's used for. I have personally not built anything for the web using components, so I don't know how much they satisfy that promise in reality. But that's the promise.
JMTQp8lwXL 5y ago
In some ways, it still isn't great. You can't create font rules in CSS in shadow DOM; they are ignored. WC + Shadow DOM are great for using 'new' components in, say, a legacy web application that has leaky style rules (e.g., the main app has style selectors like `button`), which would bleed into your new component.
dmitriid 5y ago
> What am I missing, what's the elevator pitch for web-components and shadow DOM? There's none except the oft-repeated "use the platform!" (as if other frameworks and libraries use something else, and not the platform). Currently web components work, if: - you have a large distributed team, and - you need to have consistent elements and styling across many properties, and - your components can be expressed as "leaf elements". That is, view-only elements. No forms, no state, only presenting some data. Beyond that the elevator pitch is "for the past 10 years, and counting, we've been bravely trying to fix the ever-growing list of problems that web components introduced by simply being. And we're solving that by throwing more and more javascript at the problem". A very non-exhaustive list: https://twitter.com/rich_harris/status/1198332398561353728?lang=en https://twitter.com/rich_harris/status/1198332398561353728?l... And things like participation in forms? It's "solved" by adding Javascript: https://web.dev/more-capable-form-controls/ https://web.dev/more-capable-form-controls/ Which is ironic, given that the original pitch was "we're piling more and more into Javascript, and we shouldn't" https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell https://fronteers.nl/congres/2011/sessions/web-components-an...: --- start quote --- I think we’re stuck today in a little bit of a rut of extensibility. We wind up leaning on JavaScript to get things, because it is the Turing complete language in our environment. It is the only thing that can give us an answer when CSS and HTML fail us. So we wind up piling ourselves into the JavaScript boat. We keep piling into the JavaScript boat. Bruce yesterday brought up the great example of an empty body tag, and sort of this pathological case of piling yourself into the JavaScript boat, where you wind up then having to go recreate all of the stuff that the browser was going to do more or less for you if you’d sent markup down the wire in order to get back to the same value that was going to be provided to you if you’d done it in markup. But you did it for a good reason. Gmail has an empty body tag, not because it’s stupid. Gmail does that because that’s how you can actually deliver the functionality of Gmail in a way that’s both meaningful and reliable and maintainable. You wind up putting all of your bets, all of your eggs, into the JavaScript basket. --- end quote ---

by slver 5y ago

serverholic 5y ago

I'm wondering about the elevator pitch too. Honestly it seems like github went through all this trouble just because they don't want to commit to a framework like react. Still having a tough time seeing the benefits of web components.

slver 5y ago
I find it odd that people compare React and web-components a lot. Sure, superficially both have custom components. But why does that matter even? To me React's value is JSX and ReactDOM. I actually use JSX+ReactDOM without the rest of React, using basic classes. Works great.

marcosdumay 5y ago

The benefit is scoped everything (styles, JS, templates). So that when your site grows, and you start erasing functionality because you created something better, you can actually erase the entire functionality with confidence, and not have some stuff hanging around because nobody is sure what it's used for. I have personally not built anything for the web using components, so I don't know how much they satisfy that promise in reality. But that's the promise.

JMTQp8lwXL 5y ago

In some ways, it still isn't great. You can't create font rules in CSS in shadow DOM; they are ignored. WC + Shadow DOM are great for using 'new' components in, say, a legacy web application that has leaky style rules (e.g., the main app has style selectors like `button`), which would bleed into your new component.

dmitriid 5y ago

> What am I missing, what's the elevator pitch for web-components and shadow DOM? There's none except the oft-repeated "use the platform!" (as if other frameworks and libraries use something else, and not the platform). Currently web components work, if: - you have a large distributed team, and - you need to have consistent elements and styling across many properties, and - your components can be expressed as "leaf elements". That is, view-only elements. No forms, no state, only presenting some data. Beyond that the elevator pitch is "for the past 10 years, and counting, we've been bravely trying to fix the ever-growing list of problems that web components introduced by simply being. And we're solving that by throwing more and more javascript at the problem". A very non-exhaustive list: https://twitter.com/rich_harris/status/1198332398561353728?lang=en https://twitter.com/rich_harris/status/1198332398561353728?l... And things like participation in forms? It's "solved" by adding Javascript: https://web.dev/more-capable-form-controls/ https://web.dev/more-capable-form-controls/ Which is ironic, given that the original pitch was "we're piling more and more into Javascript, and we shouldn't" https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell https://fronteers.nl/congres/2011/sessions/web-components-an...: --- start quote --- I think we’re stuck today in a little bit of a rut of extensibility. We wind up leaning on JavaScript to get things, because it is the Turing complete language in our environment. It is the only thing that can give us an answer when CSS and HTML fail us. So we wind up piling ourselves into the JavaScript boat. We keep piling into the JavaScript boat. Bruce yesterday brought up the great example of an empty body tag, and sort of this pathological case of piling yourself into the JavaScript boat, where you wind up then having to go recreate all of the stuff that the browser was going to do more or less for you if you’d sent markup down the wire in order to get back to the same value that was going to be provided to you if you’d done it in markup. But you did it for a good reason. Gmail has an empty body tag, not because it’s stupid. Gmail does that because that’s how you can actually deliver the functionality of Gmail in a way that’s both meaningful and reliable and maintainable. You wind up putting all of your bets, all of your eggs, into the JavaScript basket. --- end quote ---