Go Long on Web Components | Hacker News Reader

Go Long on Web Components

medium.com

56 pointsvelmu34 comments

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.

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

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.

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.

There's Aurelia as well.

http://aurelia.io

Aurelia has a way to output web components?

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

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

React doesn't only provide a way to sync DOM and data, it also provides its own component system that everyone uses, so in its current state React is kinda competing with Custom Elements.

http://jonrimmer.github.io/are-we-componentized-yet/ 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?

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

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/

I was watching the Google I/O feed and one of the Polymer guys was like, "Web Components are here, everything's great!". But, that's obviously not the case. Unless I missed something in the 2.0 for Polymer, they still use html imports. Which, will need polyfilled on everything but chrome.

I've been rooting for web components for a long time now. But, I still don't think it's ready for prime time. Vue has been serving me well, and feels just like web components when writing code.

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)

Would YouTube embeds ever move to web components from iframes though? Seems like iframes would actually be more suitable for this use case.

If they wanted to use iframes still, they would just have that inside the component. Then, you wouldn't need any initializing code really. Admittedly, not a huge win because it's pretty small embed code as it is.

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

https://www.webcomponents.org/publish

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?

Sure, there are multiple options, one or two way bindings, virtual dom solutions etc. Pick your poison.

Polymer.

Check out 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... (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.

Aurelia

http://aurelia.io/

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

https://www.youtube.com/watch?v=GMWAHzXQnNM

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

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

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

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

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

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

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.

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.

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

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.

To be fair to them, I doubt either of them envisioned their work to be used for anything like what it is now.

Oh, obviously not. I'm talking hyberbole. But my point stands: I intensely dislike all of js, and html only a little bit less.

I think that's probably why you're not getting much traction (and getting downvotes): the sum total of your point is "I personally don't like this stuff", and the way you conveyed that was through hyperbolic put-downs against the guys who did a lot of pioneering work to build it.

You are undoubtedly right.

Although, not putting down the guys. Regretting the direction their work went.

Reply on news.ycombinator.com