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.
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.
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.
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.
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 :)
Has there been any work towards that?