4 ms·

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?

• robdodson 11y ago
  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.
• spankalee 11y ago
  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.
  • revelation 11y ago
    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)
    • spankalee 11y ago
      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.
  • Touche 11y ago
    > 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.
  • bsimpson 11y ago
    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.
• phpnode 11y ago
  Here's a thing which tries to do that - https://github.com/codemix/htmling/ https://github.com/codemix/htmling/
  • Touche 11y ago
    Thanks, are they able to render custom elements that have shadow DOM, including the styles?
    • phpnode 11y ago
      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.
      • kawera 11y ago
        Using the CLI, can templates import other html bits (classic header/content/footer for example) ?
        • phpnode 11y ago
          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.