Edge Conf: Web Components

Orde Saunders' avatarPublished: by Orde Saunders

Notes from the Web Componets panel at Edge Conf

It's hard to give an unbiased view of this topic. A component is UI encapsulation, there are a lot of requirements for components - crosses all web disciplines. Composability: should be able to build a component out of other components. Rendering: should be able to render on client and server. Portability: Should be able to move it - how many touch points does it have? (HTML, CSS, JS, URLs &c.) This isn't web components vs react - share a word but not concept. Shadow DOM - encapsulates the HTML layer. HTML imports allow you to include a component with an <import> - need to consider the URL structure of this, especially assets. Prefetching and concatenation can help. React components naturally have client/server rendering. Are we setting the bar too high with ES6 and package managers? Style encapsulation, CSS has a global namespace, need to avoid clashes. There is a specification for a loader within the browser, abstracts the full path resolution. Can trace the module stream - concat + prefetch. CSS modules - class names that are a symbol not a string - resolves to a string at run time to avoid clashes. Is there going to be a standard for components or will we keep evolving this?

Are we moving away from extensibility of existing HTML in favour of a quick implementation? What does it mean to extend an existing HTML element? There is no agreed shadow DOM implementation for each component in each browser. Trying to avoid state crossing boundaries. Every framework has the responsibility for all the accessibility. Complicated by being in a transitional state with web components. Web components don't absolve you of responsibility - look at the gold standard.

With HTTP/2 then concatenation will become an anti-pattern. It's still a new feature, can make smaller bundles to move towards it. HTTP/2 isn't going to solve things magically - some networks are still just slow. A smart server can use HTTP/2 better than HTTP/1.

The pre-parser can read HTML imports as they come in, predictively load assets.

If we're still supporting HTTP/1 and also supporting HTTP/2 we have doubled our work. Everybody in this room is using build tools - it's not the same everywhere. We need to mange a progressive transition, we don't know what this will look like yet. Be critical of people saying that HTTP/2 is the one true way and we should all switch to it.

A pre-renderer for web components on the server side is crucial for performance. React will generate the initial state on the server and if you send the same code and data the client will catch up. We can't send shadow DOM over the wire - unsolved problem.

What if we invest in the wrong tooling? If we want an extensible web we need to invest in open tooling.

ES6 modules and HTML imports are not equivalent. There's a missing API in the browser - what is the browser doing before it sends a request to the network. If we had that then they would seem more similar. ES6 modules can interact with HTML imports fine.

Why are we still having to hack performance? Shouldn't web components be async by default? Similar to CSS fonts. Best practice is to add async to imports, still need to do progressive rendering of visuals ourselves.

There are polyfills for web components but they are still slow in some cases. If you want to be extra performant you still have to do it yourself. We're still using massive libraries - feels a bit like jQuery UI or YUI. Very few people are using them - examples come from big companies like Google. Very little feedback on use - push for a v1 to get it out there and get feedback.

We need to work on tooling, the initial experience might be good but scaling hits problems very quickly. Big websites can throw enginering talent at the problem but for smaller websites it's too much of an overhead. Frameworks can help you solve problems that often get forgotten - such as frame budgets.

Scoped styles and extending native elements are priorities. HTML has too much hidden in native elements. Shadow DOM allows us to scope CSS - limits repaint.