Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

At first I was gung ho about web components. I was so excited I used Mozilla's X-Tag for one project and Polymer in another project. I am now no longer in favor of using them and it makes me sad, actually.

Web components are simply too heavy. They add latency to download (yeah you can combine them but I've never found tooling (including Vulcanize) that worked very well). Also the shadow dom's separation makes styling more difficult across multiple components requiring awkward shadow dom hacks in the CSS and / or duplicating / adding more CSS to components themselves. Same with using JavaScript and third party libraries not expecting to use the ShadowDom though this isn't so bad.

When I'm working on something that needs to be optimized for low bandwidth / high latency I go as lightweight as possible and I concat as much stuff together as I can. I want web components to work so badly but they're way too slow for me to use anytime soon.

View on HN

"Too heavy" seems like it should be qualified—maybe you mean they are "too heavy to use for widget-level components in a web app with the current implementations"?

That's a weaker claim, and leads to the question of what they might be good for right now. I imagine for example Stripe's payment widget could be a pretty nice use case? In other words, higher-level widgets that are substantially encapsulated already, and are already often loaded as remote resources.

But I've only looked a little at the W3 specs and haven't tried using them in reality.

> "Too heavy" seems like it should be qualified—maybe you mean they are "too heavy to use for widget-level components in a web app with the current implementations"?

Current implementations yes but when browsers have 100% integration? I want to say yes but would love to say no. My biggest issues (latency, trying to concat and minify down and duplicative CSS) are not really addressed anywhere but until all browsers have the full implementation I can't say for sure I'll admit.

> I imagine for example Stripe's payment widget could be a pretty nice use case? In other words, higher-level widgets that are substantially encapsulated already, and are already often loaded as remote resources.

That seems like a great use case. I'd prefer, and probably most others, to host my own components versus externally referencing them but in some cases where you can't really get around it (I'm not familiar with Stripe's payment widget but Google Maps is certainly like this) I could see that being a good use case. Honestly that in and of itself may justify its existence but I'm just not convinced of its use fullness outside of that just yet.

Polymer dude here. Some points:

- What's wrong with vulcanize (combines all your components into one single html file)?

- Polymer now offers Shared styles, so that you don't have to duplicate your css. And you can use BEM or what ever you like.

- Get ready for HTTP2 in a few years.

> What's wrong with vulcanize (combines all your components into one single html file)?

Most of the issues I ran into were relating to inconsistent pathing. It was difficult to get every type of thing that could use a path (image tags, css, html inclusions, etc) working in a way that worked at both the path of the component and the newly created path when combined. Perhaps this has changed since the last I used Vulcanize but it was very painful at the time.

I also had a hell of a time getting the google maps, and a few other google components, to Vulcanize with the rest of my components but I honestly can't remember the issues now.

> Polymer now offers Shared styles, so that you don't have to duplicate your css

That's Polymer specific though; is there a way to do that with native web components? I could be missing something but it looks specific to Polymer. Regardless I'm glad this is being addressed to a degree but the solution seemed somewhat unintuitive as it's not using CSS semantics for driving the style.

Essentially the majority of projects I work on have developers and designers on them. The designers are usually pretty good with CSS, Illustrator and Photoshop so anything outside of CSS requires quite a bit of learning for them so that's a hill I have to battle with techniques such as these.

> Get ready for HTTP2 in a few years.

Just like I'm not going to be able to use ES6 for many years I'm not holding my breath here :)

Web Components are defined in script, they add no more download costs than any other script or styles.

Shadow DOM's style scoping is very intentional, and brings sanity to styling. Cross-scope styling is possible via CSS custom properties in a much more principled way than letting styles leak all over the entire document.

And since a shadow DOM's styles don't have to even look at the rest of the page's styles, they can be computed much more quickly.

"letting styles leak all over the entire document"

CSS selectors allow for a pretty wide breadth of targets -- they can be as narrowly specific or as broadly general ("leaky") as the author likes.

What's the exact problem that another layer/mechanism of scoping solves that being thoughtful about your selectors doesn't?

ShadowDOM removes the need for a component user and a component author to collaborate in order for styles to be encapsulated. This, in turn, enables easier distribution and usage of generalized components.

Exactly, how many times do you want to use a component but find it near impossible because it's written with a framework, or uses CSS styles that conflict with your own, or is written for use with a different version of the very framework you're using... this is why we keep re-inventing the same dumb web components over and over again.

It's basically impossible to implement lower bounds for descendent selectors without scoping.

You can kind of fake it with build steps and some luck, but it will always have holes and problems with dynamically updated DOM.

Faking lower bounds also keeps the browser from knowing that it doesn't have to invalidate the isolated scopes when properties above them changes.

One-hundred Shadow DOM Elements, each with 10 DOM elements and 10 CSS selectors.

One-thousand `regular` DOM Elements with 1000 CSS selectors.

It's a simple math. 10 times faster.

I don't think that's a fair comparison. Why would you need so many selectors in the 'regular' case and what are they doing? I've worked on some pretty complex apps and have never even come close to 200 selectors in total; probably not even 100 but I'm not 100% sure.

Shadowdom allows for specific targeting within a component; is that necessary faster than a query using another element / class name for targeting a component in "regular" usage? I'm curious on the numbers here as I don't know that you're necessary right or wrong here.

I had the exact same thoughts when I first read about web components, or rather HTML imports in particular. The extra requests and latency introduced are not worth the benefits of having pluggable components. I can already imagine people writing server side code to include these "web components" inline into the static markup sent to browser, which somewhat defeats the purpose of having these components be dynamically interpreted by the browser.

Or maybe the correct way of using web components would be to create component "rollups" on server side, to reduce the latency effect of the extra requests. Or the browser might start caching common components between page requests.

Maybe the current web component spec is just the first step to get the reusable web started...

HTTP2. In the HTTP2 world, extra requests don't add any additional latency. The browser multiplexes them over a single connection. I think I'd heard that it even uses a common compression dictionary for all requests, which means that boilerplate code that's duplicated between components will get compressed away.

>In the HTTP2 world, extra requests don't add any additional latency.

They don't add any additional TCP connection latency, sure. I think it's a bit unrealistic to claim there won't be any congestion of the multiplexed stream which causes additional latency.

>I think I'd heard that it even uses a common compression dictionary for all requests, which means that boilerplate code that's duplicated between components will get compressed away.

I may be misremembering, but I thought that was just for request headers?

>I may be misremembering, but I thought that was just for request headers?

That's correct: https://http2.github.io/http2-spec/compression.html.

HTTP2 also supports server push—the web server sends resources that the browser is going to need without waiting for them to be requested: http://blog.xebia.com/2015/08/23/http2-server-push/

What extra requests? Are there any requests you get with Web Components that you don't with React, Angular, jQuery or plain JavaScript?

Web Components are just a set of APIs and capabilities in the browser. They don't imply anything about the number and type of files that are used to create your app.

I was comparing importing Web Components using HTML imports vs. static inlining the web component code within initial markup sent to browser.

Putting it another way - whats the advantage of HTML imports over server side imports?

Server side imports may increase the initial payload, but that will still be quicker compared to extra fetch requests for the web component.

@nostrademons is right that http2 will level the playing field for this battle... so definitely keeping an eye out for it!

Web component APIs and HTML imports are mostly orthogonal, except that HTML is a nice way to package HTML, CSS and JavaScript.

You can inline your custom element definition just like you can inline anything else.

I use webcomponents (specifically Polymer stuff), and all I do is just roll together all the components I'm going to need for an app in one big concat-and-minified file. You don't have to fetch a gazillion components, any more than you have to fetch a gazillion .js files - cat, minify, gzip works on webcomponents as well. Plus, as other people mentioned, http2 solves this problem as well.

Please file vulcanize bugs or give feedback here on what didn't work for you.

Every componentization system will require concatting to get good performance on today's web (http2 push is close but quite here yet).

isn't the lack of tooling primarily due to the fact that it is very early? I would expect all of that to improve in the future

http2 may help you with that. Your tooling could also potentially inline the components too, you don't have to make an http request for each one. That fact that Vulcanize didn't work too well for you for whatever reason seems like something that shouldn't be terribly difficult to fix.

> That fact that Vulcanize didn't work too well for you for whatever reason seems like something that shouldn't be terribly difficult to fix.

Maybe? I'm not sure. The vast majority of issues I had with Vulcanize stemmed from pathing changes.

So say you're working on a component that exists at /components/mycomponent/mycomponent.html

When you're referencing JavaScript, images, CSS, etc you typically assume you're at / but it doesn't work like that for everything. So you either have to setup a configurations so you have a universal prefix to use for everything or do everything relative to root (which at least in the environments I deployed into not really doable as the root could change). So the vulcanizer needs to understand and reroute everything within your component and since there is no way to override the way the browser fetches content you're left with trying to figure out everything to include and doing it via ajax (if you wanted to be automated about it).

I'm not saying it's impossible but it seems difficult to do to the point where I don't know that that's the best path for web development to go down.

I honestly can't remember some of the other issues I've run into. Mostly JavaScript errors from third party components and even other Polymer components but it's been about 6 months or so since I've used it. I'm sure Vulcanize has gotten better by now and I know Polymer has.

HTML Imports are going away. I'm not sure the state of Polymer but my guess is that they will be removed eventually, so I wouldn't depend on a tool like Vulcanize being improved; it's a dead feature.

Instead use a normal JavaScript module loader to load components and concat them the usual way. Don't use imports.

There are several competing proposals for asset imports [1] any of which are viable. HTML Imports may persist, be supplanted by ES6 imports, or may otherwise survive in a different but similar form. Hell, I wouldn't be surprised if one day someone makes a web component to implement the current HTML Import spec using whatever the browser happens to support.

[1] https://hacks.mozilla.org/2015/06/the-state-of-web-component... (see: HTML Imports)

HTML imports allow you to bundle HTML, CSS, and Script and import them in one step. ES6 only handles the script part. We very much love HTML Imports on the Polymer team and they aren't going anywhere for us.

I expect that when the ES6 modules loader spec is finalized it will be fully compatible with the underlying semantics of HTML imports, and they will work quite nicely together.

The other terrible side effect of web components is that it gives the standards group an excuse to never update HTML anymore. "Why do we need HTML6 when you can make anything you want with big, heavy Javascript-based web component that takes expert programmers to make?" Indeed.

Just say no to web components. Say yes to upgrading HTML specs directly.

Sorry, what? The browser has sorely needed extension and componentization capabilities for many years. Why should the W3C be the gate-keepers of what's allowed in HTML? That only leads to the invention of heavy-weight and balkanized UI frameworks. We can do much better than that.

Ask yourself why the generic UI elements in Polymer, like Menu, Dialog Boxes, etc.., isn't part of HTML itself?

If you want to see balkanized UI frameworks, there it is.

> why the generic UI elements in Polymer, like Menu, Dialog Boxes, etc.., isn't part of HTML itself?

Because they shouldn't be. HTML should not be responsible for providing every possible UI element. In fact, I would argue that provides _far_ too many UI elements, and should instead provide low level user input APIs that can be used to build interactive elements.

And so web developers have to write basic UI widgets just to get basic UI elements. Or, to use a heavyweight component library that needs needs to be downloaded.

Thanks but no thanks.

HTML should provide a rich, declarative UI API by default. We shouldn't have to hunt down separate components to get that.

If you have to load Javascript, you have already lost.

A well regarded standard UI library, say jointly developed by browser vendors, could be CDN served and cached or even bundled with browsers eliminating the download cost with the massive advantage that it can be versioned independently of HTML and browsers and is optional in case a better library comes along.

Again, at the moment where javascript is required to read a website, you have already lost.

> A well regarded standard UI library, say jointly developed by browser vendors,

This is commonly known as the web browser.

lol @ browser vendors deploying UI components via Javascript, when they could just as easily deploy them in the web browser itself as part of upgraded HTML specs.

"just as easily" is an interesting phrase to use here. I have to assume that your day job does not involve building browsers.

That's the exact opposite of the reason why browser vendors are implementing web components. It's so that they can get direct, real-world feedback from actual users of a feature before baking it into standards and making it impossible to remove from the web. The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec.

We used to write web specs speculatively, without having feedback from real-world use, and it was a disaster. Take a look at the list of W3C standards:

https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Stan...

How many of them do you actually use? Remember when everything was XML, XPATH, XSLT, the semantic web, and we were going to replace HTML with XHTML?

The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec.

That's nice in theory, but what's happening in reality is that no component is going to be standardized, and HTML remains stagnant for another 15 years.

It's a little hard to make that argument when web components themselves aren't standardized yet, and are fully supported natively in only one of the major browsers.

There's pretty ample evidence that common webdeveloper behavior does make it into the spec, eg. JQuery => querySelectorAll, Javascript animations => CSS transitions & animations, long-polling => websockets, common layouts => <header>/<footer>/<main>/<nav> elements, dropdowns => <details>/<summary> elements, the addition of date/datetime/color/number/range/tel input types, etc. If you're still coding HTML like you did in 2000, you are now very obsolete.

This is completely inaccurate.

Reply on news.ycombinator.com