
Go Long on Web Components - velmu
https://medium.com/@velmu/go-long-on-web-components-b1e0689f64e4
======
eric_b
I've never understood what real problems Web Components solve with all their
complexity. In _theory_ shadow DOM and Custom Elements are useful - but the
implementation in Web Components leaves a lot to be desired for people trying
to actually build applications in the real world.

They punted on important things, like inter-component communication, state
management, and even code organization (templates, styles, and scripts are all
in the component together? Seems great until it falls over in apps of any
consequence)

At the end of the day, frameworks like React, Vue, and even Angular are
solving the problem for application developers more comprehensively.

I just don't see a future for web components, other than for folks who want
the latest and greatest thing and care more about mastering complexity than
delivering apps quickly.

Edit: One other thing that I think will prove, in time, to be a bad idea, is
this notion that everything must be its own component. Apps are
interconnected, and most "components" are not going to be re-used in practice.
Why enforce this segregation when 90% of the time it's a hindrance? By all
means de-couple when there are re-usable bits, but that's just not true most
of the time.

------
mbrock
Very reasonable, but I dispute the implied notion that React and Web
Components are competitors, or that React is in any way obsolete because we
can use Web Components.

As the React docs state:

> React and Web Components are built to solve different problems. Web
> Components provide strong encapsulation for reusable components, while React
> provides a declarative library that keeps the DOM in sync with your data.
> The two goals are complementary. As a developer, you are free to use React
> in your Web Components, or to use Web Components in React, or both.

[https://facebook.github.io/react/docs/web-
components.html](https://facebook.github.io/react/docs/web-components.html)

The author seems to understand this, but still seems to indicate that Web
Components lessen the need for DOM view frameworks, when actually they just
make it easier to encapsulate widgets.

~~~
ergo14
Yeah, I think one can create application with lets say preact + polymer, or
vue.js + vue-web-components just fine. I see these solutions working together.

~~~
wanda
There's Aurelia as well.

[http://aurelia.io](http://aurelia.io)

~~~
ergo14
Aurelia has a way to output web components?

~~~
WorldMaker
Sort of? It's kind of built out of almost web components, if you squint, and
there's an export tool, mostly together: [https://github.com/aurelia/web-
components](https://github.com/aurelia/web-components)

The Aurelia argument seems to be that it's the Web Component spec that's not
entirely all together still, not Aurelia's version of web components at a
somewhat orthogonal angle to the spec.

This thread from the developer:
[https://news.ycombinator.com/item?id=8950360](https://news.ycombinator.com/item?id=8950360)

------
101km
[http://jonrimmer.github.io/are-we-componentized-
yet/](http://jonrimmer.github.io/are-we-componentized-yet/) [https://platform-
status.mozilla.org/#html-imports](https://platform-status.mozilla.org/#html-
imports)

HTML Imports are only implemented in Chrome and it is going to stay that way,
Firefox and Safari aren't having it. This is arguably a bummer but not
critical for Web Components.

What is critical is that Custom Elements and Shadow DOM (V1) are in the latest
Chrome and Safari but not on the horizon for Firefox and Edge. Supposedly it
is planned, but unclear when it will actually arrive. 2018?

~~~
ergo14
According to announcements made by google guys on few conferences both IE and
Firefox actively work on implementations.

~~~
greenyouse
The Browser Support chart on webcomponents.org shows that they're working on
it[1]. I think it's a pretty good way to track web component compatibility
(outside of caniuse).

[1][https://www.webcomponents.org/](https://www.webcomponents.org/)

------
yesimahuman
The use case I'm most excited about for Web Components are those producing
reusable components (like YouTube embeds you describe). Building the same
components for different frameworks no longer makes sense when you consider
that you could publish a web component instead that would work out of the box
with most modern frontend frameworks. I'm incredibly bullish on them now, and
we're going to be turning Ionic components into WC's so we can work with all
frameworks people want to use (because, there hasn't been one single framework
that has "won" the frontend market)

~~~
my_ghola
> consider that you could publish a web component

Is there any place you can go look at Web Components built by others and
contribute your own? plus a package manager to include them easily in your
projects would be the best way for them to come to light.

~~~
Spone
[https://www.webcomponents.org/publish](https://www.webcomponents.org/publish)

------
aeharding
Are there any good ways to keep your data in sync between a model and the DOM
with Web Components? Something similar to what Vue or React have?

~~~
floatboth
Polymer.

Check out [https://github.com/arqex/freezer](https://github.com/arqex/freezer)
if you like immutable data, it works very well with Polymer. All you need to
do to integrate them is something like this:
[https://github.com/myfreeweb/micro-
panel/blob/34aeb46600fab5...](https://github.com/myfreeweb/micro-
panel/blob/34aeb46600fab5ebfb24f72777e723675dadc34b/src/micro-
panel.js#L59-L65) (the itemModified stuff is extra, specific to my app) Then
just pass the freezer object or its children down the component tree with one-
way bindings.

------
paulrd
Joe Gregorio has a great video presentation that answers some of the questions
I see posted here:

[https://www.youtube.com/watch?v=GMWAHzXQnNM](https://www.youtube.com/watch?v=GMWAHzXQnNM)

------
ojr
I want to go long on a component paradigm that targets the web (server or
client rendering) and native iOS/Android views, only one framework has strong
support for this (React). It speaks highly of its design

~~~
wanda
The Web Component paradigm will target (pseudo-)native through progressive web
apps and ServiceWorker.

------
pdog
React and Vue.js are actually used in production for many real projects.

Who uses Web Components? (Besides, apparently, the YouTube rewrite in 2017.)

------
revelation
Web components are essentially syntactic sugar. It's not so much a technology
in and of itself as a way to help web developers avoid copy & paste strain..

So of course they work with anything and are "natural". There is nothing in
them! It's a macro or preprocessor system if you want..

~~~
ergo14
Not entirely true - you get things like shadow dom with them - which means
"proper" encapsulation.

~~~
floatboth
And custom elements provide a way to actually create, well, your own DOM
elements. Libraries like React provide their own "fake" components that are
only usable from within the libraries. With Custom Elements you can actually
provide a DOM API for your element, that can be used from plain JS.

And HTML Imports provide deduplication. They're a solution to the "I have four
copies of jQuery on my page" problem.

------
interfixus
If a time machine is ever built, could someone please go back and steer the
young Brendan Eich towards a career in medicine or medieval literature? And
Berners Lee, while you're at it. Then call John Ousterhout or someone like
him, and tell them to get cracking. Imagine the boatloads of nonsense we could
be without today.

~~~
jancsika
This may be off topic, but is there a word for a compliment the acceptance of
which necessarily disparages someone else?

~~~
interfixus
There must be. There simply must.

Mind you, I'm not disparaging Eich and Berners Lee, only their products. Web
technology is a mess. I was horrified when I saw my first html all those long
years ago. I'm horrified still. And saddened to think what might have been.

