
Custom Elements v1: Reusable Web Components - markelliot
https://developers.google.com/web/fundamentals/architecture/building-components/customelements
======
romaniv
Components with extensibility through inheritance written in a prototype-based
language. Having worked with around a dozen component-based systems over the
years I'm not particularly enthusiastic.

I think it would be much better for the web if browsers had a sane API for
extending _behaviors_ of any tag via attributes. This would make things easily
composable and eliminate most problems of traditional component-based systems.

    
    
        <button does-stuff does-more-stuff></button>
    

It would be even better if people working on these specs spent some time
reading research papers on how a sane component-based system _could_ work. For
example: [http://alumni.media.mit.edu/~mt/thesis/mt-thesis-
Contents.ht...](http://alumni.media.mit.edu/~mt/thesis/mt-thesis-
Contents.html) A lot of interesting ideas regarding extensible behaviors and
ease of understanding.

Edit: And yes, I'm aware of is="" functionality. It's not exactly what I'm
talking about. In fact, if the specs were designed the way I mentioned, there
would be no need for making anything special for built-in elements as opposed
to the new ones.

~~~
euyyn
> It would be even better if people working on these specs spent some time
> reading research papers on how a sane component-based system could work.

I don't know the people working on these specs, but presuming that they aren't
aware of research in the area, and moreover of what has worked in practice and
what hasn't, is audacious.

~~~
romaniv
It's true that I don't know for sure, but I haven't seen any citations, or
verbal references, or any similarities in the APIs that would indicate
familiarity with the relevant research I had in mind.

Also, a lot of research in this field is done through working proof-of-concept
systems, so there is no point in implying that those designs don't work "in
practice".

~~~
euyyn
By working in practice I don't mean "unimplementable or not", I mean the
difference between CORBA and gRPC: One can argue endlessly about the benefits
of one vs the other, but it's practical experience what's informed the latter
of how and why the former sucked.

------
SimeVidas
This article has been added 5 days ago [1], in case anyone is wondering how
recent it is.

[1]:
[https://github.com/google/WebFundamentals/commits/master/src...](https://github.com/google/WebFundamentals/commits/master/src/content/en/fundamentals/architecture/building-
components/customelements.md)

------
kevinSuttle
This is the kicker for me:

> At time of writing, no browser has implemented customized built-in elements.
> Chrome plans to implement them (status) but other browsers have expressed
> distaste for implementing the is="" syntax.

I would love to just be able to "fix" the normalization around several built-
in elements.

------
voiper1
Interesting. Only in Chrome 54/Safari 10.1/Opera 46 so far.
[http://caniuse.com/#search=web%20components](http://caniuse.com/#search=web%20components)

But there's a polyfill, and more discussion here:

[https://developers.google.com/web/fundamentals/architecture/...](https://developers.google.com/web/fundamentals/architecture/building-
components/customelements#historysupport)

------
VeejayRampay
Excellent tutorial, as usual from Eric Bidelman. It's a lot of information to
digest though, one should take time with all the different bits and pieces
covered in this article.

------
microo8
You can use custom elements also in golang :)

[https://github.com/microo8/golymer](https://github.com/microo8/golymer)

------
macawfish
I've had some success with Custom Elements, using skate.js as a higher level
interface.

This piano keyboard element: [https://micahscopes.github.io/all-around-
keyboard/](https://micahscopes.github.io/all-around-keyboard/)

Some elements for quickly drawing graphs in html:
[https://micahscopes.github.io/tangled-web-
components/example...](https://micahscopes.github.io/tangled-web-
components/examples/)

(It still needs some more convenient ways of defining the graph structure, as
well as an interface to do force layouts.)

I haven't worked on either project in a while. I kinda got tired working with
the development version of skate.js while the custom elements spec was
changing so fast. It's an excellent library, but things were moving too
quickly for me to keep up.

Today, I'd probably just do it in plain javascript, since the spec is more
stable now.

------
megous
Is it possible to nest custom elements? I suppose it should be, but how would
it be seen in DOM?

<my-container> <some-child some-attr></some-child> </my-container>

How can I get notifications in my-container when someone from outside adds
another child to it?

~~~
quest88
Yes, it would be see by the DOM as Shadow DOM I believe.
[https://developers.google.com/web/fundamentals/architecture/...](https://developers.google.com/web/fundamentals/architecture/building-
components/shadowdom)

You can get notifications through the mutation observer API:
[https://developer.mozilla.org/en-
US/docs/Web/API/MutationObs...](https://developer.mozilla.org/en-
US/docs/Web/API/MutationObserver)

------
pjmlp
Customs Elements is what would make me quite happy with UI design on the
browser side.

Now just have to wait a few years to be able to use it, or hope the polyfills
actually cover all the browsers versions we might need to target.

------
albertTJames
could it replace React ?

~~~
jbwyme
We've been using Web Components + Virtual DOM to build our web apps for the
last year at Mixpanel:
[https://github.com/mixpanel/panel](https://github.com/mixpanel/panel). The
biggest issues have been dealing with polyfill issues (especially Shadow DOM
leakage) and versioning elements (given the global namespace issue of
"registerElement")

------
cztomsik
please correct me if I'm wrong but it seems that custom elements still do
nothing about dependency hell (it's not possible to use same lib in different
versions)

~~~
reificator
Why would they be expected to?

~~~
romaniv
It's one of the biggest problems in fronted development right now and it's
something conceivably _can_ be addressed by the... well, let's call it
"guiding structural paradigm" for the lack of a less pretentious term.

~~~
reificator
I don't know, in my frontend experience dependency hell is less about
conflicting dependencies and more about literally installing 690 packages
after one `npm install <package>`.

Fixes need to happen in the broader npm ecosystem, not the standard for
creating reusable components.

------
megamindbrian
Cool! I can't wait for Google to abandon this!

------
dmitriid
Custom Elements v1. Designed by committee:
[https://pbs.twimg.com/media/DALwpYnUAAESRjr.jpg](https://pbs.twimg.com/media/DALwpYnUAAESRjr.jpg)

Polymer. Designed by people who actually do web development:
[https://pbs.twimg.com/media/DALwpYWVoAAIvkQ.jpg](https://pbs.twimg.com/media/DALwpYWVoAAIvkQ.jpg)

~~~
chrismorgan
Custom Elements is the low-level API that allows you to do all kinds of
things.

Polymer is designed to sit on top of that as a higher-level API.

This is how things should be. Otherwise you get designed into an undesirable
corner. (Example: I can imagine improvements to the Polymer code achieved with
decorators and TypeScript, for example, which would require a somewhat
different API. To need a translation layer over that for evermore is
undesirable.)

~~~
jarym
I seem to recall IndexedDB was designed with the same thinking and that hasn't
worked out so well.

(Not talking about Custom Elements here since I don't know enough about it -
the comment is levelled at the process).

It's all too easy for people in a committee to manufacture the idea of some
mythical figures further along the conveyer belt who will magically make
something useful out of a giant specification with gaping holes.

~~~
reificator
Polymer was released and worked on as a library while the spec was being
worked on. Polymer 0.x and 1.x targeted a version that was only implemented in
Chrome, which was used to build the eventual standard, and Polymer 2.x targets
the final standard.

The API for web components isn't that bad. You have to stamp DOM templates
yourself using whatever process, you have to handle attributes and properties
yourself, and that's about it. Lots of boilerplate, but a library like Polymer
can take a simple, opinionated approach to handle it for you.

From my experience Web Components have been pretty pleasant to use with or
without Polymer, it's just a matter of wiring everything up if you go vanilla.

~~~
dmitriid
> The API for web components isn't that bad.

> Lots of boilerplate

If there's lots of boilerplate, the API is bad.

~~~
reificator
ServiceWorker vs Application Cache, I'll take ServiceWorker every time.

When you're talking about a low level primitive, boilerplate is preferable. It
means you have options. You can throw Polymer or any other library on top and
get what you want out of the standard, while someone else can come with
different requirements and not be boxed in by your own.

If you can distill your argument to one sentence, it probably isn't blindly
applicable to all circumstances. Yes that was one sentence.

~~~
dmitriid
DOM APIs (which Custom Elements are) are not really "low-level". They are low-
level in the sense that they are cumbersome imperative boilerplate compared to
basically anything else on the platform.

The main problem with boilerplate in DOM APIs is not that they are "low-
level". It's that w3c never makes any effort to address the _developer_
experience when using these APIs.

This is why you end up writing 10 lines of code just to sync properties and
attributes in Custom Elements where a single `{reflectToAttributes: true}`
would suffice _and_ remain low-level.

This is the problem across the board, not just Custom Elements. The goal of a
platform (and the web _is_ a platform) isn't just to provide cumbersome low-
level APIs, but also a set of sane defaults _and_ a set of APIs that address
the majority of a developer's needs. w3c can barely provide the former, and
has never been able to provide the latter.

