We throw the term component around a lot these days, but what does it really mean?
If we go by the textbook definition, a component is one piece of a larger system.
When it comes to HTML pages, we call its pieces elements. They are represented by tags that make up the page, like a paragraph (
<p>), bulleted list (
<ul>), or quote (
<blockquote>). HTML elements can also be made up of other elements. For example, a footer (
<footer>) would likely have a collection of elements inside it.
While outside the context of web development, the terms
component can be used interchangeably, within the web dev world, they tend to have exclusive meanings. An element, as mentioned above, is a basic building block with a goal of being supported by all browsers. It could be considered native to or a first-class citizens of the HTML language.
Those customizations are often meant to be reused. Consider a card. There is no
<card> element in HTML, but many web projects these days have cards littered throughout. Or even consider something that is already an HTML element, like a
<card> tag like I could for any native HTML element.
Perhaps the biggest benefit of a web component is that it is encapsulated in its own space, called the shadow DOM, such that any styling and functionality (CSS and JS) applied in that space can't bleed out and interfere with other components.
One of the biggest struggles with web components is that it's been a long road to get all browsers to agree on a standard approach. The reason the term component is thrown around so much is because most of the time we're not actually talking about official web components.
Developers didn't want to wait for web browsers to adopt a standard approach to web components, so they built a workaround. Frameworks like React and Vue use the concept of components to make it feel like we're working with components without actually using web components. And that makes sense, as we want the code we write to work in as many browsers as possible. But, there are also libraries like Stencil, which do render actual HTML components in the browsers that support it, while relying on a polyfill for those that don't.
With most front-end frameworks moving more in the direction of components, it seems as though they are going to be around for awhile. So, while it's important to understand the basics of HTML and CSS, most front-end developers are likely to end up working with the concept of components in some capacity.
If you want to learn more about components, consider: