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:
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.
.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.
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.
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.
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.
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.
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.
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.
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).
> 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).
So there are a few things to keep in mind about the gold standard. First, it's not entirely accessibility related and I would argue it's mostly a best-practices check-list. When you look through the gold standard I would say a large majority of the items are things you need to take care of regardless if you're creating a web component, a simple composite of HTML tags, an angular directive, ember component, jQuery plug-in or even an opensocial widget. For instances you always need to be mindful of your dependencies, load order and local side affects when giving anything to the general public that you hope to be used.
Yes there are a handful of things that you need to do to make web components behave a little nicer in web browsers as far as accessibility goes but the majority of those items need to be applied regardless of how you break up your code so this argument isn't very interesting or useful, in my opinion.
Second, depending on your use case you may not even care about many of those items. Sure in an ideal world we would all care about every item no matter what but the truth is if you're developing components to simply organize your code in a small web app or just for your organization you may not care at all about side affects or dependencies and I think that's fair; not everything needs to stand up to the rigor of something being related for the general populous to use.
I will agree that Google does not always follow their own guidelines with this type of thing, however.
> 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).
Actually web components are just composites of plain old HTML, styling and JavaScript. They do not require any specific tooling (in fact the only tooling I've seen or used for web components is Polymer's vulcanize and it's absolutely terrible; I've never seen it work correctly on the first shot) and they only require polyfills if you want to use them in non-evergreen browsers (Firefox and Chrome mostly support what you need today). Regardless of the technicalities I do agree that web components can be slow and it's one of my gripes about them though I really don't know what tools you're talking about being required to start.
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.
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).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.