The state of the web

Declarative shadow DOM looks to be the final piece of the puzzle that enables better SEO for custom html element, see tangent below. This could be beneficial for bridging the gap of server side rendering and progressive enhancement. For instance a declarative shadow dom tempalte is made for some vustom element. It renders immediately, even if the browser doesn't support javascript or custom elements. For most browsers, the custom element Javscript code will start running and convert it into the thing. At this point it can be "progressively enhanced" so that future elements can be inserted into the page in their minimal form. It's difficult to describe, here's an example:

On initial load a custom element "my-article" is streamed in with declarative shadow dom defining the internal structure. This allows it to be rendered instantly.

<my-article>
  <template shadowrootmode="open">
    <slot></slot>
  </template>
  <h2>Article header</h2>
  <p>Article text</p>
</my-article>

Later on in the loading cycle, my-article will be initialized via Javascript whatever stuff is done. Let's say the page is now loaded and the user's reading the article. They're getting near the end and the site preloads the next article for user's convience. Now the only thing that needs to be added to the DOM is:

<my-article>
  <h2>Next Article</h2>
  <p>Next article text</p>
</my-article>

This later part is more about custom elements and not necessarily declarative shadow DOM, but highlights the reason for them.

So what happens when a web crawler hits the page that doesn't have Javascript enabled? Well it see my-article as an unknown element, however we still specified the internal elements which it should still see (correct me if I'm wrong here). To be safe I'd suggest using a Customized Built in Element.

This isn't new per say. It's a Web API to load OpenGL shaders, built on OpenGL ES (embedded systems) spec. It used to have a lot of performance issues for mobile devices, however mobile devices continued to get more powerful and it should run fine on most modern phones.

This also isn't new but has stuck around. There's still a lot of room for improvement but the core idea is sound. Let's stop using Javascript and instead use this "WebAssembly" low level virtual machine that's related to the Javascript runtime. This way we can compile any code we want to it and have it work. This looks nice because I do not like Javascript and would much rather just write something in C/C++. Looks to pair very well with WebGL. Now withd little extra code, one could write a 3D graphics application that compiles to both native code and a website. This could be cool for a game for example, I believe StormGate is doing something like this to enable a match viewer in the web browser. Cool idea: spectate a game by opening a link and have it render in real time.