• The problem with Web Components
  • By Adam Silver
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: stevens1995
  • Proofread by: Baddyo, Moonliujk

Problems with Web components

Web components are becoming more and more popular in the Web community. They provide a way to standardize and encapsulate JavaScript enhanced components without a framework.

However, Web components have some disadvantages. For example, they have some technical limitations that can easily be misused and lead to user loss.

It is possible — and certainly my hope — that the Web components will improve over time and these issues will be resolved. But for now, I’ll put that on hold.

In this article, I’ll explain why this is so. An alternative approach to developing components is also suggested.

They are limited

Michael Haufe explains in his critique of Web components:

  • Custom CSS pseudo-selectors cannot be used with Web components
  • They do not work seamlessly with native elements and their associated apis
  • For example, if we want to create a custom button, we can’t inherit HTMLButtonElement directly, we have to inherit HTMLElement

In addition, Web components must be defined through classes in ES2015, which means they cannot be transformed to provide a better experience for more people.

Therefore, there are a number of technical limitations that need to be addressed when using Web components directly.

They are not widely supported

Currently, cross-browser support for Web components is relatively poor. So enhanced user experience won’t work for everyone.

That doesn’t mean we can’t use them, it just means we need to provide a basic user experience that works for everyone. This is an incremental enhancement.

But we should seriously consider whether using Web components is the most inclusive option. If we don’t use Web components, we can provide the same rich experience to a wider population. I’ll explain that later.

Polyfill provides a way to provide broader support. But when you use it to make Web components more effective, they are often slow, unreliable, and difficult to work with specific limitations.

So while we as coders prefer to use standards-based techniques, it’s not necessarily beneficial to the user — that should be our first priority.

They are easily misunderstood and misused

Jeff Atwood said that any application that can be written in JavaScript will eventually be written in JavaScript.

But just because we can do something with JavaScript doesn’t mean we should use it. There is even a W3 principle that says we should use the least powerful tool.

Web components are made up of JavaScript apis, which means we should only use them when wE need JavaScript. But as Jeff Atwood predicted, people sometimes use Web components when they don’t need them.

When we use JavaScript as a dependency but don’t provide any fallback solutions, the user experience is terrible. Even WebComponents.org (built with Web components) shows a blank page when JavaScript is unavailable.

For the same reason, people are encouraged to make components that use AJAX to request data and render themselves, like small iframes.

This approach creates some avoidable problems, which I’ll explain with an example.

Imagine that we want to load a table showing sales data for our website products, as follows:

<sales-figures></sales-figures>
Copy the code

First of all, it’s just a list. There is no sorting of columns, so JavaScript is not required. The browser provides the

table for this, which can be used anywhere.

Second, as mentioned above, when the browser does not support Web components, or when JavaScript fails to run, the user will see nothing.

In order for our table to work in these cases, we need to put

. This is called graceful downgrading.

in
<sales-figures>
  <table>.</table>
</sales-figures>
Copy the code

If the component already has a filled table when the page loads, wrapping it with

results in us and the user getting nothing.

Finally, using AJAX introduces some usability and accessibility issues.

  1. AJAX is generally slower than page refreshes, not faster.
  2. We need to create custom load indicators that, unlike the browser’s load indicators, are often inaccurate and unfamiliar to users.
  3. We need to make AJAX work across domains, which is not straightforward.
  4. The page will shake as the component loads, causing visual glitches and potentially causing the user to click on the wrong thing. You may have heard that the skeleton interface is one way to solve this problem. They are placeholders placed in the final display position after the component is loaded. But while they help, they don’t completely solve the problem because they can’t always predict the exact size of what will be loaded.
  5. Point 4 also affects users of screen readers, because they do not know whether the component has been loaded, failed to load, or is in the process of loading. The ARIA real-time area provides a way to communicate these states to screen readers. But when multiple components load, the user is bombarded with notifications.

When these extend to multiple Web components on a single screen, we can create a very unpleasant, unique, and slow experience for the user.

AJAX components that depend on the requesting server are no longer invisible to the framework and can therefore interoperate with each other. Since interoperability and technical unknowability are the two main advantages they are designed to provide, this somewhat defeats the purpose of using Web components.

Importantly, none of these problems are the fault of the Web components themselves. We can easily develop such a component without a Web component. But, as shown, it’s easy to misunderstand Web components and unknowingly use them in ways that harm users and code authors.

They’re hard to organize

Suppose we have two Web components. One is for sortable tables and the other is for extensible rows.

<sortable-table>
  <table>.</table>
</sortable-table>

<expandable-rows>
  <table>.</table>
</expandable-rows>
Copy the code

But if we want a sortable with expandable rows, we need to nest components like this:

<expandable-rows>
  <sortable-table>
    <table>.</table>
  </sortable-table>
</expandable-rows>
Copy the code

The relationship between

and

is operated on

is ambiguous. For example, it’s hard to tell if


.

or

Order is equally important. If each component enhances the table, it may cause conflicts. Also, it is not clear whether an external or internal component initializes the table first.

(Note: You probably haveisProperties are one solution, but Jeremy Keith explains that browsers won’t be able tomedium.com/@adactio/ex…) Make it happen.

They cannot be used directly in the application

One of the expected benefits of Web components is that we can put a script for each component on the page and they will work — regardless of the technology stack applied.

But unlike standard elements, we may need to add extra code to make them work. In some ways, this is a bit like adding a framework or library.

An example of this is polyfill, which I mentioned earlier. If you choose to use Polyfill to provide more extensive support, you will need to have the corresponding code ready on your web page.

Another example is when you need to prevent javascript-enhanced components from causing page jitter during initialization.

This is usually done by adding a script tag to the of the document to provide CSS hooks. This, in turn, can be used to style components with the JavaScript available and avoid page thrashing.

This may not have an overall impact, but it does negate one of the possible benefits of using Web components.

Components that do not use Web components and frameworks

You’ve probably heard of alternatives to using Web components as frameworks.

While I’m in favor of creating an interface without a client framework, this can be misleading for several reasons.

First, client frameworks often provide additional functionality in addition to interface enhancements.

Second, Web components can be used with frameworks.

Finally, it has been possible to create javascript-enhanced components without frameworks and Web components for a long time.

By creating components in this way, we can avoid the shortcomings I described in this article.

Let’s use the same sortable and row extender as before to demonstrate this.

First, we need to create a JavaScript file for each component, just as we would with a Web component. We can define SortableTable and RowExpander classes in it.

SortableTable.js // Define the SortableTable class and related behavior
RowExpander.js // Define the RowExpander class and related behaviors
Copy the code

Once done, we can initialize the component like this:

/ / table
var table = document.querySelector('table');

// Initializes the sortable
var sortable = new SortableTable(table);

// Initializes the row extender
var expander = new RowExpander(table);
Copy the code

We can make these components fire events like Web components. Something like this:

Sortable. AddEventListener (sort, fn); Expander. AddEventListener (" expand ", fn);Copy the code

By using regular JavaScript in this way, we can not only write clean code that is not limited by technology, but also make the code accessible to a wider audience.

conclusion

Web components are promising because they provide developers with a way to create standards-based interoperable components.

As a result, we can more easily understand other people’s code and create components that can be reused across projects.

But even with enhancements specifically made for the cutting-edge browsers that support them, there are still limitations and issues that we need to address.

I expect Web components to get better in the future. Until then, I’ll stick with regular JavaScript to avoid current technical limitations and provide the most reasonable experience for users.

Many thanks to Amy Hupe, who not only edited this edition from start to finish, but also made it as simple and intuitive as possible. This is not easy for an article about a Web component that tells the whole story. 🙌

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.