Hacker News Reader

Comment by everlost | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com