5 ms·

What kind of Web Components do we need?

40 points by hdv 11y ago

marknutter 11y ago
The author seems concerned about creating custom elements for everything a site might need but isn't that what we all want - composability? It's the reason why libraries like React.js and Riot.js are so popular. Breaking everything down into components is highly desirable, and if they're portable like web components are then it's even better.
- Offler 11y ago
  I think the reason React is so popular is due to the developer experience. It's a simpler mental model where you no longer have to worry about your previous state and how to transition the view to the correct current state based on it.
pavlov 11y ago
It's funny that web components were already included in Internet Explorer 5 back in 1999! They were called "DHTML Behaviors", but the idea was the same. Behavior components encapsulated HTML, CSS and script content, and had a .htc ("HTML component") file format so they could be loaded from separate assets: https://msdn.microsoft.com/en-us/library/bb250408(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/bb250408(v=vs.85).a... I guess they didn't see much use in the real world, even though IE had a >90% marketshare for years. That might be a data point in support of the OP's concerns about the usefulness of components.
- franze 11y ago
  .htc files were a performance nightmare. They were (mis)used for pre IE8 polyfills - often delivered by ad-networks - and of course downloaded and executed in a synchronous blocking way. .htc maybe were a sane idea, but horribly executed.
amelius 11y ago
Being able to play video inside an SVG, then clipping the video by an arbitrary path, etc.
- gulpahum 11y ago
  Web Components are not needed for that. SVG2 will include the video element [1], just like html, and it should be possible to clip, mask, filter etc. it. It may take several years before that happens, but it should be coming. [1] http://www.w3.org/TR/SVG2/embedded.html#VideoElement http://www.w3.org/TR/SVG2/embedded.html#VideoElement
Nemcue 11y ago
"But aren’t tools the problem?" No, they aren't. This entire article read like it was written by someone that has never in their life been involved in the development of a website / app.
pandler 11y ago
Couldn't this argument apply equally to the way we currently publish reusable components, especially with regards to QA? The only difference I see with web components is that instead of implementing jquery-datepicker and ember-datepicker and angular-datepicker and react-datepicker, etc..., we can publish a single datepicker that operates underneath instead of within a js framework. Is that a correct assessment? I am not intimately familiar with web components. Edited to correct some phone auto-correcting.
justwannasing 11y ago
So we've come full circle back to XML? (And that was a good thing.)
moron4hire 11y ago
I think this article is thinking too literally and specifically about WebComponents. WebComponents are just macros for HTML. It's neither good nor bad, in the sense that it can or cannot be abused. Of course it can be abused, just like functions or textual include can be abused. But WebComponents aren't "new elements." They're just composition of XML data. It's more like being able to call a function and return an XML subtree. Composition is a good thing; indeed, greater abstractions for composition are probably the only concern for programming language development. The lack of composition in HTML is a serious problem.
- ahoge 11y ago
  > But WebComponents aren't "new elements." How so? What's the difference? Just like native elements, Custom Elements work with any modern framework. You can just add them to the DOM and they will work fine. They have their own attributes and methods. They also can fire events and react to attribute changes. > It's more like being able to call a function and return an XML subtree. It's not like that. You just use your Custom Element like any other element. If you want a "video" element, you add a "video" element. If you want a "my-video" element, you add a "my-video" element. You'd interact with this "my-video" element the same way as you would with a "video" element. All the DOM/event stuff works exactly the same.
BinaryIdiot 11y ago
I'm not sure this post makes a lot of sense. After using web components in several projects now I have a few gripes with them but nothing that is actually in this post (has the OP used web components in a project yet?). The gold standard is a great checklist but there are two things to keep in mind about it. First, while it's verbose the vast majority of it are obvious things a web developer would have to do anyway even if it was an Angular directive, an OpenSocial widget, an Ember component, etc. Second, it's important to follow the checklist in its entirety when creating web components for public consumption. For instance if you're building a component for your own web application you may not really care about local effects or some of the other items. Also the OP says it may not make sense for small sites to use web components but that also doesn't make sense. Here's the quote: "I’m not convinced either, that every company should come up with custom elements for all the things, just because they can. Most elements can be built very well with existing HTML, without costing as much design and development time. I feel many web projects will hardly have a use case for utilising custom elements, or the budget for creating them. They would overcomplicate things. It still feels like eating a 5 course dinner when all you wanted was a salad." The problem here is that most web components are just composites of plain old HTML and some styling and JavaScript to create a re-usable piece of a layout; this means they can be done "without costing as much design and development time" but the OP purports the exact opposite. I'm not sure why (perhaps the OP equates custom component to replacing a browser native component like a drop down? Though if so that's a very specific and specialized, custom component and doesn't really fit the wording used). There are plenty of issues with web components. Speed and the insane amount of additional connections they require are the big ones in my opinion (yeah you can combine them but there isn't very good tooling around that; even if you're using Polymer vulcanizing requires specific pathing and doesn't always work even on Google's own components) but this article really only raises valid concerns if you're going to be publishing generic components for public consumption but even think I think it far overstates the issues in that area.
- hdv 11y ago
  Thanks for your reply, BinaryIdiot. The gold standard also ensures accessibility (the responsibility for accessibility is transferred from browser maker to developer). I suspect many developers, even Google in some of their examples, will forget to add it or think it doesn't apply to them/their app, I find this a huge concern (the web until now embraced accessibility as a universal value). Web Components are not ‘just’ composites of plain old HTML, some styling and JavaScript, they require tooling and polyfilling (and some polyfilling will make apps slow for users that don't have the latest tech). This is potentially bad for new people in the industry (have to learn many tools before they can get started), and bad for users (as their device might be toos low).

40 points by hdv 11y ago

The author seems concerned about creating custom elements for everything a site might need but isn't that what we all want - composability? It's the reason why libraries like React.js and Riot.js are so popular. Breaking everything down into components is highly desirable, and if they're portable like web components are then it's even better.

Offler 11y ago
I think the reason React is so popular is due to the developer experience. It's a simpler mental model where you no longer have to worry about your previous state and how to transition the view to the correct current state based on it.

pavlov 11y ago

It's funny that web components were already included in Internet Explorer 5 back in 1999! They were called "DHTML Behaviors", but the idea was the same. Behavior components encapsulated HTML, CSS and script content, and had a .htc ("HTML component") file format so they could be loaded from separate assets: https://msdn.microsoft.com/en-us/library/bb250408(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/bb250408(v=vs.85).a... I guess they didn't see much use in the real world, even though IE had a >90% marketshare for years. That might be a data point in support of the OP's concerns about the usefulness of components.

franze 11y ago
.htc files were a performance nightmare. They were (mis)used for pre IE8 polyfills - often delivered by ad-networks - and of course downloaded and executed in a synchronous blocking way. .htc maybe were a sane idea, but horribly executed.

amelius 11y ago

Being able to play video inside an SVG, then clipping the video by an arbitrary path, etc.

gulpahum 11y ago
Web Components are not needed for that. SVG2 will include the video element [1], just like html, and it should be possible to clip, mask, filter etc. it. It may take several years before that happens, but it should be coming. [1] http://www.w3.org/TR/SVG2/embedded.html#VideoElement http://www.w3.org/TR/SVG2/embedded.html#VideoElement

Nemcue 11y ago

"But aren’t tools the problem?" No, they aren't. This entire article read like it was written by someone that has never in their life been involved in the development of a website / app.

pandler 11y ago

Couldn't this argument apply equally to the way we currently publish reusable components, especially with regards to QA? The only difference I see with web components is that instead of implementing jquery-datepicker and ember-datepicker and angular-datepicker and react-datepicker, etc..., we can publish a single datepicker that operates underneath instead of within a js framework. Is that a correct assessment? I am not intimately familiar with web components. Edited to correct some phone auto-correcting.

justwannasing 11y ago

So we've come full circle back to XML? (And that was a good thing.)

moron4hire 11y ago

I think this article is thinking too literally and specifically about WebComponents. WebComponents are just macros for HTML. It's neither good nor bad, in the sense that it can or cannot be abused. Of course it can be abused, just like functions or textual include can be abused. But WebComponents aren't "new elements." They're just composition of XML data. It's more like being able to call a function and return an XML subtree. Composition is a good thing; indeed, greater abstractions for composition are probably the only concern for programming language development. The lack of composition in HTML is a serious problem.

ahoge 11y ago
> But WebComponents aren't "new elements." How so? What's the difference? Just like native elements, Custom Elements work with any modern framework. You can just add them to the DOM and they will work fine. They have their own attributes and methods. They also can fire events and react to attribute changes. > It's more like being able to call a function and return an XML subtree. It's not like that. You just use your Custom Element like any other element. If you want a "video" element, you add a "video" element. If you want a "my-video" element, you add a "my-video" element. You'd interact with this "my-video" element the same way as you would with a "video" element. All the DOM/event stuff works exactly the same.

BinaryIdiot 11y ago

I'm not sure this post makes a lot of sense. After using web components in several projects now I have a few gripes with them but nothing that is actually in this post (has the OP used web components in a project yet?). The gold standard is a great checklist but there are two things to keep in mind about it. First, while it's verbose the vast majority of it are obvious things a web developer would have to do anyway even if it was an Angular directive, an OpenSocial widget, an Ember component, etc. Second, it's important to follow the checklist in its entirety when creating web components for public consumption. For instance if you're building a component for your own web application you may not really care about local effects or some of the other items. Also the OP says it may not make sense for small sites to use web components but that also doesn't make sense. Here's the quote: "I’m not convinced either, that every company should come up with custom elements for all the things, just because they can. Most elements can be built very well with existing HTML, without costing as much design and development time. I feel many web projects will hardly have a use case for utilising custom elements, or the budget for creating them. They would overcomplicate things. It still feels like eating a 5 course dinner when all you wanted was a salad." The problem here is that most web components are just composites of plain old HTML and some styling and JavaScript to create a re-usable piece of a layout; this means they can be done "without costing as much design and development time" but the OP purports the exact opposite. I'm not sure why (perhaps the OP equates custom component to replacing a browser native component like a drop down? Though if so that's a very specific and specialized, custom component and doesn't really fit the wording used). There are plenty of issues with web components. Speed and the insane amount of additional connections they require are the big ones in my opinion (yeah you can combine them but there isn't very good tooling around that; even if you're using Polymer vulcanizing requires specific pathing and doesn't always work even on Google's own components) but this article really only raises valid concerns if you're going to be publishing generic components for public consumption but even think I think it far overstates the issues in that area.

hdv 11y ago
Thanks for your reply, BinaryIdiot. The gold standard also ensures accessibility (the responsibility for accessibility is transferred from browser maker to developer). I suspect many developers, even Google in some of their examples, will forget to add it or think it doesn't apply to them/their app, I find this a huge concern (the web until now embraced accessibility as a universal value). Web Components are not ‘just’ composites of plain old HTML, some styling and JavaScript, they require tooling and polyfilling (and some polyfilling will make apps slow for users that don't have the latest tech). This is potentially bad for new people in the industry (have to learn many tools before they can get started), and bad for users (as their device might be toos low).