As an alternate to BigPipe, add a PlaceholderStrategyInterface implementation that renders placeholders as web components

Web Components are many things, but in the BigPipe case, we probably will only use two specific tools: Shadow Dom and HTML Imports.

By using these 2 tools in the implementation of BigPipe, we can completely eliminate Javascript in the process. However, we rely on Pollyfill (a JS library for browsers who don't support Shadow Dom natively). In other words, for modern browsers (ever green browsers), when they load a BigPipe page from Drupal, they will not use Javascript during this loading process.

For Drupal BigPipe maintainers, they don't need to think about JS anymore, another win.

Furthermore, Web Components are already production ready, but not mainstream yet. This list shows people who are building on Polymer (a framework based on Web Components): https://github.com/Polymer/polymer/wiki/Who's-using-Polymer%3F

Regarding tudo:

1. Change the markup of the placeholder to use "HTML Imports"
2. Change the markup of the "Expensive/Personalized HTML blocks" to be Shadow Dom compatible
3. Add Pollyfill library for backward compatibility support.

I am still learning more D8, maybe in a while, I will be able to write a patch or a new module for Web Components implementation of BigPipe.

@skyredwang if you need code reviews / collaborators hit me up. I'm also keen on getting a patch that represents the advantages of Web Components.

@Wim Leers, another thing related: HTTP/2 Push. When a request comes in, the BigPipe knows what parts are expensive. For HTTP 1.1, the client sends the requests for the expensive parts. But, with HTTP/2, it will be interesting that we take advantage of multiplexing and push to send the expensive parts automatically.

The performance gain will be the number of expensive parts on the page x the trip time it takes from client to server.

I was talking about HTTP/2 push dynamic content. In the context of BigPipe. You send a static template first, then HTTP/2 push username, personalized flags, tokens, list of images, etc. I realize the current servers support for push is mostly for static assets.

It's always fun to read more of your R&D! Thanks for leading and pushing the boundary for our community.

Looking forward to it. In the meantime, browser support has grown. That should be in the research reporting as well. Let's shoot for March 21 as an arbitrary deadline for putting this all together.

@skyredwang does that work for you / can we get together to organize? Anyone else want to contribute?

Woohooo! Let's go!

I am spending full time on Commerce 2.x related stuff on D8 this month. So, I won't be able to do anything with Web Components soon. But, I am trying to get a GSoC student to work on that https://groups.drupal.org/node/508466#project4

It seems the browser vendor reached some consensus and WebKit is starting implementing custom elements https://lists.webkit.org/pipermail/webkit-dev/2016-March/027995.html

Also you can test for custom elements support and load the polyfill only if needed with something like

var webComponentsSupported = (
  'registerElement' in document &&
  'import' in document.createElement('link') &&
  'content' in document.createElement('template')
);
if (!webComponentsSupported) {
  var script = document.createElement('script');
  script.async = true;
  script.src = '/bower_components/webcomponentsjs/webcomponents.js';
  script.onload = finishLazyLoading;
  document.head.appendChild(script);
}
else {
  finishLazyLoading();
}
function finishLazyLoading() {
  // do something;
}

Another excellent public signal https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/EDxhDZ-...

This community post points to the consensus that has been reached on custom elements (the key piece we're talking about here)

Moving to the ideas queue.

I *think* some of this is already being worked on for core?

time to resurface this?

@nod_ Yes please

This is relevant to my interests 🙂

Was interesting reading the history here. Obviously web component support and adoption has increased greatly since this issue was created. Polyfills for IE 11 are still a concern, but with IE 11 support being dropped in Drupal 10 that could potentially not be a concern for Drupal 10 and beyond.

Using Big Pipe to address this was also an interesting concept. In fact, there has been recent work to try to solve SSR for web components, and it is conceptually similar in some ways. As part of the Lit 2.0 release there is also an experimental SSR package: https://github.com/lit/lit/tree/main/packages/labs/ssr which server renders an initial container, and can rehydrate on the client side. This is based on a Declarative Shadow DOM feature https://web.dev/declarative-shadow-dom/ which is shipping in Chrome and Edge and is also not Lit specific from what I understand. With any luck browser support will increase in the future.

(A bit of a tangent, but there is a lot that I like about Astro's partial hydration concept: https://docs.astro.build/core-concepts/component-hydration. The Islands Architecture https://jasonformat.com/islands-architecture/ might also be relevant to what we're discussing here)

There is also some relevant work in happening in contrib.

I maintain the Generic Drupal Web Components (GDWC) project https://www.drupal.org/project/gdwc. The long term goal there is to have a library of generic web components that can be used both in decoupled projects that source data from Drupal and also in Drupal's traditional rendering layer. A menu component was built out in support of the Decoupled Menus Initiative https://gdwc.netlify.app/?path=/story/components-menu--primary. Next step here is building out more components. That has stalled a bit - from my perspective in order for this to scale for decoupled sites there needs to be a better solution to state management. I have that just about unblocked which should hopefully get things moving again.

There are also a couple of noteworthy projects related to Drupal integration and component distribution. Neither are specific to web components, but both should play nicely with them.
- Component: https://www.drupal.org/project/component - defines components in yaml and creates component blocks. Module contains web component examples.
- JS Widgets: https://github.com/js-widgets/js-widgets - uses an externally hosted registry defined in json and makes widgets available to Drupal via widget_instance and widget_ingestion modules.

There are almost certainly other projects I'm forgetting to mention...

All of this to say that having a clear web component (and possibly web component distribution) strategy for Drupal would be fantastic.

Great writeup in #23!

As I understand it, the scope of this issue is just about adding a rendering strategy to core's BigPipe module to implement placeholders via web components rather than the current BigPipeStrategy, which uses <span> tags and custom AJAX code to replace those spans. If so, then +1 to that idea for Drupal 10, where we don't have to cater to IE11 anymore. Seems like it would be a clearer implementation, leveraging the appropriate web standards and browser capabilities. I'm not clear on whether it would offer any benefits other than code clarity (e.g., I don't know that ShadowDOM is valuable for BigPipe), but the code clarity benefit alone seems more than worth it to me.

All of this to say that having a clear web component (and possibly web component distribution) strategy for Drupal would be fantastic.

+100 to this! I think that's a separate scope than this issue though. Would you be willing to open a new Ideas issue for it if there isn't one already?

Retitling this issue to what I think it's about, though please correct me if I'm misunderstanding it.

#18 seemed to change this to be focused around a web component strategy rather than anything related to big pipe. I also don't necessarily have a problem with creating a new ideas issue for this if the history makes things confusing, I just think we'd ideally zero in a little bit more specifically on what that idea is first. Right now my idea is mostly just that we should have an idea :)

Hm, ok, retitling based on #18, I think.

For the larger scope of #23 / #26, I opened #3230518: Figure out how we want to incorporate web components in Drupal 10.

I moved this to the ideas queue before, but I think this actually can just be a feature request against core again.

I think the idea here is:

1. Add a new placeholder strategy, which would be in the render system, not in bigpipe module.

2. Consider whether to switch bigpipe to use that strategy.

From working in bigpipe recently, there are a lot of considerations to #2 - bigpipe is very much reliant on the AJAX system for communicating assets and (soon) messages, but that would make it a good test case for the new strategy even if we eventually decided against changing it.

I was looking at #2602726-4: As an alternate to BigPipe, add a PlaceholderStrategyInterface implementation that renders placeholders as web components which looks interesting for being no-js, but it looks like there's no way to do HTML includes without a separate HTML request, so we'd be swapping a small amount of JavaScript for a large amount of PHP requests with that, which would not be a good trade-off.