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.
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.