Problem/Motivation
Thanks to
#2469431: BigPipe for auth users: first send+render the cheap parts of the page, then the expensive parts →
a lot of brilliant work has gone into implementing the Big Pipe architectural concept into Drupal 8. What I understand of the work is that the critical path (the minimal set of markup that can be full cached and delivered quickly to user) can be determined thanks to the work done in annotating the cache contexts and cache tags of each render-able thing. Everything that is determined to be "expensive" is then placeholdered and replaced in a secondary process.
This allows the initial page to be delivered, extra data to be inserted into the page, and then the personalized, "expensive" components are triggered to get get their data.
Kind of like customizing a car. You buy a standard car and then get kits to replace the tires, stereo, and other things you want to replace. Getting the car can be easy, just get one from the lot. But getting the customized kits for accessories can be time-intensive since you need to get the ones that you like.
Anyway, as
#2469431: BigPipe for auth users: first send+render the cheap parts of the page, then the expensive parts →
states in it's issue description, there are many ways that the replacement of placeholders can be handled. Web Components as defined by the emerging set of specifications (here: http://webcomponents.org/ ) can be compatible way. There are a few advantages and disadvantages of this approach and it would be worth our while to explore if the trade-off is in our favor.
Advantages:
1. Web components are built with HTML, JS, and CSS
Web components are built to define a set of inert markup that can be pushed into the DOM and later activated to drive a frontend component. Web Components are built to define their own behaviors and appearance. Portability is a key focus. The promise of building a component and then being able to reuse it over different projects is key here.
2. Web components are atomic and can be combined.
Many examples of component systems can be found on the interwebs. Using these comopnents together, developers can quickly build applications. While this is actually a pretty old concept the main difference here is how easy it is to make components and how developers can build their own component libraries instead of relying on slow-evolving vendor-driven ones.
3. Although incomplete browser vendor support exists today, the goal is to have these components supported natively.
Today polyfills such as found on http://webcomponents.org/ exist to ensure "evergreen" browser support (read: no oldIE) almost all browsers have annouced the intent to support or partial support for the standard. Chrome and Opera have full support, Firefox has partial, and MS Edge and Safari will eventually have partial support.
4. JS behaviors
The components themselves can take on duties such as observing when they need to update, reacting to other actions on the page, or on the server. Components can have 2-way data binding.
Disadvantages
1. Required to include another polyfill
Today the webcomponents.js polyfill is another 34 KB of javascript that would need to be loaded on any page a web component is needed. That's a 34 KB we wouldn't need if we didn't use Web components.
2. Speed
Today working with the polyfill is slow. Speed is improving but the sheer fact that you have to work with polyfills / secondary requests may be an issue. How much of an issue? We need to have numbers to put towards the performance question of Web Components and see if
3. Opinionated
Using web components is picking a path. While you can use web components with other frameworks (like Angular) there could be some scenrios where you don't want to work with them. I guess this is really a question about whether this should ever be brought into core or should be contrib-only.
See:
#2469431-108: BigPipe for auth users: first send+render the cheap parts of the page, then the expensive parts →
#2469431-166: BigPipe for auth users: first send+render the cheap parts of the page, then the expensive parts →
Proposed resolution
TBD
Remaining tasks
TBD
User interface changes
TBD
API changes
TBD
Data model changes
TBD
