4 ms·

Could you provide some specific example of something that can be easily done with custom elements that cannot be easily done with other existing APIs? (I'm spea

by gambler 10y ago

Could you provide some specific example of something that can be easily done with custom elements that cannot be easily done with other existing APIs? (I'm speaking about user-facing stuff, not some implementation detail.) Edit: Here is my quick re-implementation of their example using today's APIs: https://jsfiddle.net/pd0na425/3/ https://jsfiddle.net/pd0na425/3/ The HTML instantiation uses a single tag, just like theirs. Fully reusable. Works in all modern browsers. I believe is uses less code too.

elcritch 10y ago
I'm using it to build wrappers around d3-based graphs to make it easy for non-software engineers (mechanical, electrical), to create and modify simple PID controls. There's PLC programs and interfaces but by and large they're klunky, aren't customizable, or require learning something g like LabView. The custom elements help specifically by encapsulating the (somewhat tedious) d3 graphing and controls connections into simple HTML objects with a simple spec the engineers can lookup. HTML is then declarative and easy for non-programmers to try, test and see immediate feedback. This works out well for creating functional controls systems which can then be cleaned up by experienced developers who can tune the underlying web components. JavaScript libraries all require much more knowledge and generally don't "scale" when you want to add several graphs quickly. Frameworks like Angular2, Vie, or React all require significant learning curve and understanding of the framework generally to get working. Though Vue seems to be the simplest, but web components provide an API which Vue et al can build on by encapsulating more complex HTML/CSS/JS into semi-hidden sub-trees.
om2 10y ago
Your example has many serious limitations: (1) It doesn't let you have multiple progress bars that all advance at their own rate. (2) It doesn't work at all for custom-progress-bar elements added dynamically to the document after the timers for the first progress bar finish. (3) It makes the children of <custom-progress-bar> actually appear in the DOM, which means that code generically walking the DOM will see them and might mess them up. The basic thing that the combo of Shadow DOM + Custom Elements provides is encapsulation. You can make standalone elements that operate themselves, work just like normal elements, handle attributes and children, and start by themselves. Anything done using encapsulation can be done without encapsulation, in a sense. What encapsulation provides is better organization for your program, and more elegant and understandable code at the point of use.
- gambler 10y ago
  > (1) It doesn't let you have multiple progress bars that all advance at their own rate. It does. > (2) It doesn't work at all for custom-progress-bar elements added dynamically to the document after the timers for the first progress bar finish. It does. I think you're confusing the "library" code with the "user-land" code that drives it (the latter was copied from the example in the original article). Here is a version with two progress bars where I separated the "library" into a separate box: https://jsfiddle.net/pd0na425/4/ https://jsfiddle.net/pd0na425/4/ (3) It makes the children of <custom-progress-bar> actually appear in the DOM, which means that code generically walking the DOM will see them and might mess them up. This part is true. However, if you have code that generically walks the DOM and screws stuff up, how do you expect your website to operate anyway? The real issue is overly broad CSS selectors, and it's not really something specific to custom elements. Everyone has to deal with it for all CSS and all elements. In this case, it's actually easy to mitigate. Since all the inner elements are custom, I can easily add a prefix that will effectively prevent them from being styled by other libraries. That said, I wish W3C actually solved CSS scoping properly. That would be way, way more useful than any component API and it would be useful for every website in that uses styling.
  - ricardobeat 10y ago
    The CSS in a web component is scoped.
  - om2 10y ago
    You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) and created some new problems: (1) A timer will fire forever, even if no progress bars are currently updating. Bye bye, battery life! (2) A progress bar can't update at 60fps, even if changes to the underlying value happen that quickly. IF you continue playing whack-a-mole with these types of problems, you might see why Custom Elements + Shadow DOM are an elegant way to avoid these issues while providing good encapsulation. (As someone else mentioned, Shadow DOM provides style scoping so it doesn't have the CSS issue you raised, even if the contents are normal built-in elements, while your example does.) I hope this helps to clarify what Web Components technologies are good for.

by gambler 10y ago

elcritch 10y ago

I'm using it to build wrappers around d3-based graphs to make it easy for non-software engineers (mechanical, electrical), to create and modify simple PID controls. There's PLC programs and interfaces but by and large they're klunky, aren't customizable, or require learning something g like LabView. The custom elements help specifically by encapsulating the (somewhat tedious) d3 graphing and controls connections into simple HTML objects with a simple spec the engineers can lookup. HTML is then declarative and easy for non-programmers to try, test and see immediate feedback. This works out well for creating functional controls systems which can then be cleaned up by experienced developers who can tune the underlying web components. JavaScript libraries all require much more knowledge and generally don't "scale" when you want to add several graphs quickly. Frameworks like Angular2, Vie, or React all require significant learning curve and understanding of the framework generally to get working. Though Vue seems to be the simplest, but web components provide an API which Vue et al can build on by encapsulating more complex HTML/CSS/JS into semi-hidden sub-trees.

om2 10y ago

Your example has many serious limitations: (1) It doesn't let you have multiple progress bars that all advance at their own rate. (2) It doesn't work at all for custom-progress-bar elements added dynamically to the document after the timers for the first progress bar finish. (3) It makes the children of <custom-progress-bar> actually appear in the DOM, which means that code generically walking the DOM will see them and might mess them up. The basic thing that the combo of Shadow DOM + Custom Elements provides is encapsulation. You can make standalone elements that operate themselves, work just like normal elements, handle attributes and children, and start by themselves. Anything done using encapsulation can be done without encapsulation, in a sense. What encapsulation provides is better organization for your program, and more elegant and understandable code at the point of use.

gambler 10y ago
> (1) It doesn't let you have multiple progress bars that all advance at their own rate. It does. > (2) It doesn't work at all for custom-progress-bar elements added dynamically to the document after the timers for the first progress bar finish. It does. I think you're confusing the "library" code with the "user-land" code that drives it (the latter was copied from the example in the original article). Here is a version with two progress bars where I separated the "library" into a separate box: https://jsfiddle.net/pd0na425/4/ https://jsfiddle.net/pd0na425/4/ (3) It makes the children of <custom-progress-bar> actually appear in the DOM, which means that code generically walking the DOM will see them and might mess them up. This part is true. However, if you have code that generically walks the DOM and screws stuff up, how do you expect your website to operate anyway? The real issue is overly broad CSS selectors, and it's not really something specific to custom elements. Everyone has to deal with it for all CSS and all elements. In this case, it's actually easy to mitigate. Since all the inner elements are custom, I can easily add a prefix that will effectively prevent them from being styled by other libraries. That said, I wish W3C actually solved CSS scoping properly. That would be way, way more useful than any component API and it would be useful for every website in that uses styling.
- ricardobeat 10y ago
  The CSS in a web component is scoped.
- om2 10y ago
  You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) and created some new problems: (1) A timer will fire forever, even if no progress bars are currently updating. Bye bye, battery life! (2) A progress bar can't update at 60fps, even if changes to the underlying value happen that quickly. IF you continue playing whack-a-mole with these types of problems, you might see why Custom Elements + Shadow DOM are an elegant way to avoid these issues while providing good encapsulation. (As someone else mentioned, Shadow DOM provides style scoping so it doesn't have the CSS issue you raised, even if the contents are normal built-in elements, while your example does.) I hope this helps to clarify what Web Components technologies are good for.