
Custom Elements Coming to WebKit - spankalee
https://lists.webkit.org/pipermail/webkit-dev/2016-March/027995.html
======
Touche
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?

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

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

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

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

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

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

