
What kind of Web Components do we need? - hdv
https://hiddedevries.nl/en/blog/2015-07-02-what-kind-of-web-components-do-we-need
======
pavlov
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).a...](https://msdn.microsoft.com/en-
us/library/bb250408\(v=vs.85\).aspx)

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

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

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

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

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

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

~~~
BinaryIdiot
Hmm it seems HN lost my reply. Odd. Anyway...

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

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

~~~
gulpahum
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)

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

