Custom Elements Coming to WebKit | Hacker News Reader

Custom Elements Coming to WebKit

lists.webkit.org

42 pointsspankalee18 comments

My interest in custom elements has waned because it doesn't have an answer for server-side rendering.

Has there been any work towards that?

I think server-side rendering is a bit of a red herring. What matters is how fast you can get to first paint. Executing some client-side JavaScript to get the DOM setup for first-paint is fine, as long as the payload delivery + render time is fast, and it can be really fast, especially when you create custom elements optimized for first paint.

Custom elements are a very good compression format: you define a element once, and use it over and over, each time saving space over having had written out the whole component definition. In cases of heavily reused elements, the size of the definition + per-element savings * number of instances will be an overall reduction in wire size.

Thinking of elements in term of compression is useful to me, when considering server-side rendering: Server-side rendering is a bit like taking a compressed file, decompressing it on the server, sending it to the client, and then recompressing it on the client. That clearly doesn't make sense with regards to audio and video, so it should raise questions about markup too.

Just like other uses of compression, you need the size reduction to be large enough, and the decompression speed to be fast enough, to realize an overall improvement. The key for custom element libraries will be creating small, fast, first paint optimized feature sets that the critical content can be written in, so that the initial view is actually faster than server-side rendering.

In addition to that view (which isn't universal, for sure!), and some work in Polymer for extremely lightweight elements, there's also work in Polymer towards enabling more traditional optimizations: one is that in Polymer 1.3 you can create an un-upgraded element (the tag in markup, but no registered definition for it), set up children, properties, attributes and event listeners, and when the definition is loaded and the element upgraded, all the existing data is wired in properly. This lets an app do lazy loading on an element-defintion basis. We're also looking at how an element could do a similar thing for it's shadow root: recognize that the shadow root is already rendered and just attached to it, rather than re-stamp it. These primitives are some of the most important needed for server-side rendering.

There are two main benefits to server-side rendering:

- time to first paint is faster on CPU-constrained devices (e.g. low-end phones), and

- interoperability with non-JS-powered UAs (like robots)

I believe a big part of the desire for server-side rendering is a fear that search performance may be penalized if a crawler doesn't speak JavaScript, or tries to crawl the page when it's not in a state a human user would consider stable. I know there's been work done on Googlebot to make it correctly interpret client-rendered pages. If you could confidently say "Using Web Components will not have a negative affect on your search ranking; Googlebot can crawl and understand Web Components at least as well as traditional HTML elements," it would allay many of the concerns about WC, especially with regard to server-side rendering.

Even on high-end hardware it's hard to hit 200ms first paint doing purely client rendering. Even when using a CDN. Would love to be proven wrong here.

By the time this standard gets into major browsers todays high end phone will be tomorrows low end phone.

Even most web crawlers these days execute a bit of JavaScript.

The analogy doesn't work for me. Server-side rendering is the equivalent of starting a program, waiting for it to give an "all initialized" sign and then dumping it's state. Next time, you just resume it on the saved state. (this is pretty much what dump-emacs does)

Except that the state is more compactly represented as the one-time element definitions, plus multiple instances, and the state has to be sent over the wire. Given the prominence low-bandwidth, high-latency mobile connections, this is critical. To me the key is very fast initial app setup in script. That should beat server-side rendering.

> Executing some client-side JavaScript to get the DOM setup for first-paint is fine, as long as the payload delivery + render time is fast, and it can be really fast, especially when you create custom elements optimized for first paint.

But those things are not that fast. You can inline the scripts but then you're just making your page heavier (and not taking advantage of caching).

Anything is possible with enough effort but I want to use a technology that makes good results easy. Server-side rendering gives you that, if you can run the exact same code in both contexts you don't have to worry about the types of optimizations you're referring to.

Nothing publicly released that I know of but I may be out of the loop :)

But it should be possible to stamp a template into a custom element (if it requires one) and get all the markup in place server side. If you're not using Shadow DOM this becomes even easier.

Here's a thing which tries to do that - https://github.com/codemix/htmling/

Thanks, are they able to render custom elements that have shadow DOM, including the styles?

no, it's a way to share the same templating syntax on the client and server but isn't a full server side rendering solution. It's pretty fast though, just about the fastest templating engine out there last time I checked.

Using the CLI, can templates import other html bits (classic header/content/footer for example) ?

yes, you can do something like `HTMLing.registerElement('foo-bar', {})` and then when you use `<foo-bar />` in another template it will render it. I should note that I'm not maintaining this library very well because I've mostly switched to React, but it does work.

Can we realistically expect widespread browser support of web components by the second half of 2017?

I'm optimistic that we'll see pretty widespread support, maybe 3 of the 4 major engines, by the end of 2016, with the 4th following shortly. The face-to-face meetings have gone extremely well, and all browsers are pretty motivated to ship quickly.

The Web Component polyfills and Polymer will also be updated to support the new versions of the standards.

I think so. At this point all browsers are on board with shipping Custom Elements and Shadow DOM and Template has already shipped everywhere. The holdout is HTML Imports and the Chrome team is currently working on a revision to that spec to build it on top of the ES2015 module loader so it's not contentious (https://github.com/w3c/webcomponents/blob/gh-pages/proposals...). But HTML Imports is not a requirement for Web Components, the big win is Custom Elements, so seeing everyone get on board with that is awesome :)

The title change to "Prototyping Custom Elements API" from "Custom Elements Coming to WebKit" is not accurate.

The linked email was a reply to an old thread about prototyping Custom Element API, but the actual email is about starting the _real_ implementation.

Reply on news.ycombinator.com