DEV Community

Cover image for We Should Stop Hating Web Components

We Should Stop Hating Web Components

Harsh Singh on April 30, 2021

So you just heard about this thing called web components and you did a quick google search. apart from a few tutorials and some github pages you al...
Collapse
 
mich profile image
Michel Tobon

Frameworks are not the language!
One of the points why I am so strongly inclined to use Web Components is because they are part of the web standard, while frameworks like React try to create their own standard, they also damage the opportunity to adopt tested and well developed standards.

I use Web components because specially at a large organization it simplifies the delivery of consistent design systems and solidifies the way we work in large teams, that is not to say I don’t use React, I do; but when it comes to delivering a set of components that can be shared and used across multiple fev experiences, web components provide a solid and standard set of tools that go directly to the browser instead of going through the build system.

One of the reasons why I believe developers are affraid of web components is because some of them are not consumed as dev/build time dependencies but as runtime dependencies, but this is the way javascript really works, in the window you are not working with your framework of choice anymore, you have left that nice IDE world and now you are working with the browser’s operation.

I think it is of most importance to know the platform you are working with before even knowing the ways to simplify development on it. Web components are a great native way to encapsulate logic, style and markup within a container that is standardized and unified across (most) browsers. Give them a try

PS: of you do miss react, Stencil’s dev experience is ~95% the same

Collapse
 
theharshsingh profile image
Harsh Singh • Edited

Yes, but style encapsulation is also presented as its biggest con. but that is not true. developers dont have to use Each and Every technologies of the web component suite. if you dont want style encapsulation then just dont use Shadow DOM at all! and if you are following BEM methodology, you will not see any side-effects. Shadow DOM is just for heavy, self-dependent Web Components. and yes Stencil's DX is almost the same as React. and there are also Hybrids.js and Switzerland.js if you want to write functional web components that are quite similar to the React ones.

Collapse
 
mich profile image
Michel Tobon

Agreed!

Most of thetime I don’t use shadow on my web components but for enclosed design systems I would argue that style encapsulation is really good it does prevent major style collision problems when working at larger scales

Collapse
 
ekanadily profile image
Esam A Kanadily

Do you think that web components is ready? i mean do they have what is required to make whatever a dev might need. or they still need impovments?

Collapse
 
theharshsingh profile image
Harsh Singh

Short Answer: Yes! Web Components are ready for production.

Long Answer: it really depends on what kind of project you are working on. for a small to medium size product web components are perfect. but if it is going to be a big project, then due to lack of resources and support, you will have to build many things on your own which are readily available in other frameworks.

Collapse
 
ekanadily profile image
Esam A Kanadily • Edited

The closer you are to the metal the longer you will survive without learning something new.for me that is the gut of web components.

Collapse
 
theharshsingh profile image
Harsh Singh

This is the driving force behind the development of Web Components API. Frameworks come and go and because most of them force you to learn their way of programming and tools, which may first seem to be easy and pleasing but later when these frameworks die or become less popular you are forced to abandone it and learn a new framework that is currently trending in the market and the cycle goes on. Web Components are here to save us from this vicious cycle. what it needs is a series of some minor and major improvements and some good tutorials. I am thinking about starting a series of tutorials on Web Components.

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

I am thinking about starting a series of tutorials on Web Components.

That would be very nice. I've read up a lot on what web components can technically do, but I don't have a clear image of how they would ideally be used for anything bigger than a basic hello-world-component.

Thread Thread
 
dannyengelman profile image
Danny Engelman • Edited

I started a series of Dev.to posts last week; based on real world Web Components

Thread Thread
 
theharshsingh profile image
Harsh Singh

That's really awesome pal. i will surely check em out.

Collapse
 
nicozerpa profile image
Nico Zerpa (he/him)

I think one of the things that hold web components back is the lack of declarative programming.

Most frontend devs learned components through some UI framework or library that is declarative. Having components in Vanilla DOM but having to code them in an imperative style might feel like a step backwards for some people.

Also, some JS devs don't like using classes, and that's a problem because Custom Elements requires using them.

Collapse
 
theharshsingh profile image
Harsh Singh

Yeah i agree that Web Components API needs improvement but you can already use libraries like Hybrids.js or Switzerland.js for creating web components in "functional" way and completely avoid the use of classes.

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

The collection of APIs we often call "web components" aren't really supposed to be a finished product; they provide low-level access to browser features that let you do almost everything you need, but at the expense of making the most common cases more cumbersome than necessary.

The point is that these APIs make it much easier to build your own declarative systems without having to bother re-implementing too many of the same features every time.

I personally don't even like frameworks like Vue or Svelte too much, because they're a bit too declarative for my taste, meaning I give up control over how data flows through the application. With web components I can build my own micro-framework with like 50 lines of code and continue building stuff on top of that instead.

Collapse
 
theharshsingh profile image
Harsh Singh

Yes Web Components were meant to be used in that way. You can either write your web components using vanilla js or you can use a collection of tiny helper libraries for performing different functions like routing and state management. and its not like there are no libraries available out there. there are over a dozen libraries just for adding the routing functionality in web components, but they are all either badly documented or lack any support from the community. i urge the Web Component community to come forward and start helping the newcommers and do more than being a Symbolic entity.

Collapse
 
kerryboyko profile image
Kerry Boyko

Honestly, what we need is a standard for web components that allow it to interact with the various frameworks out there, specifically, it should be able to react to changes in attributes, and emit events back to a state manager. I wonder if there's a simple HOF that can make this simple enough.

The reason why this would be a game changer is because every company seems to have it's own branded UI library, making components for React, Vue, or whatever they're using. What would be a game changer is if you could write those components as web components so that each team can choose whether to use them in React OR Vue or whatever framework, essentially allowing companies to avoid vendor lock-in for front-end frameworks.

Collapse
 
theharshsingh profile image
Harsh Singh • Edited

Everything you mentioned above is already implemented in Web Components.

  • A Robust Standard has already been laid out. You can readily use web components in any framework just like any other HTML element. Angular already uses Web Components under the hood.
  • You can observe when a property changes and react to those changes by declaring the attributes you want inside the static get observedAttributes method inside the class and a method called attributeChangedCallback will be invoked every time the attribute changes which will provide you with both its previous and current value so you can compare the changes
  • You can use CustomEvents API for creating and dispatching custom events and you can use any framework agnostic state management library for managing the global state. and for local state you can use getters/setters
Collapse
 
dannyengelman profile image
Danny Engelman • Edited

One point to add.

Web Component technology is older and more used than most people know.

The <video>, <audio>, <textarea>, <input> and many more complex HTML tags
are implemented in each Browser with Web Component technology.

In Chromium you can tell by the user-agent (= tech term for Browser) label on the shadow-root:

Us mortal developers can not access the HTML elements inside user-agent shadow-root.

Also see: javascript.info/shadow-dom

But... that technology was not available to us 3rd party developers

What we now call "Web Components" (Custom Elements API, Templates, shadowDOM)

IS that very same technology available to us all

But we can't access user-agent managed shadowDOM!

So everyone who claims Web Components is young, not yet fleshed out, bare metal, hardly used, technology...

Does not understand how the Browser works.

Collapse
 
bracikaa profile image
Mehmed Duhovic

I don't hate the idea of web components. As a matter of fact, on every project I've worked on we've created reusable components in different frameworks (good code practices, yadah, yadah, yadah). I've never worked with them directly, so I can't say more, until I try.

Collapse
 
ashishk1331 profile image
Ashish Khare😎

I always been using web components above any framework, and that too a custom tiny concept. Main reason it is fast, no compiler complaints, I know how the engine works and only js knowledge is required. This blog tells how to create one, or just search this form,
creativebloq.com/features/web-comp...

Collapse
 
valeriavg profile image
Valeria

Thank you for the article, we should have more of those!

Web components are not a replacement for [your favourite library], they can be used alongside any. And that's the main aim: reusability across all different frameworks and lack of thereof. In other words, web components are tiny building blocks and the glue is not included.

What's for their popularity, it's worth mentioning AMP framework, that is based on web components and used wildly.

Collapse
 
theharshsingh profile image
Harsh Singh • Edited

I accept that Web Components are not a replacement for any full fledged framework. but even React is just view library which depends on other packages and libraries for making a fully functional website. In the same fashion we can use various tiny libraries for performing different functions required to make a full fledged website. like for routing we can use the Vaadin router or Slick Router and we can use Rxjs, Valtio or Akita for state management. but due to lack of tutorials and experience, new developers get scared by the fact that they will have to learn to bind all this pieces together on their own.

Collapse
 
ivan_jrmc profile image
Ivan Jeremic

Why do I need a programming language to make web-components work? I think HTML tags should be the only thing needed to work with web-components

Collapse
 
theharshsingh profile image
Harsh Singh

The Answer lies in your question. You need a PROGRAMMING LANGUAGE to create web components cause you cant write LOGIC using HTML. HTML is a markup language, not a programming language. and a custom element without logic will be nothing but a generic div tag you can apply styles to.

Collapse
 
ivan_jrmc profile image
Ivan Jeremic • Edited

Correct but what bothers me JS is the only one why not ship HTML/CSS as a framework in the future? Sounds crazy but I mean the whole rendering engine as a installable framework wasm could do this maybe so the browser could be just a wasm runtime that way other languages can maybe have DOM integrations to not only JS.

Thread Thread
 
theharshsingh profile image
Harsh Singh

That's a good idea. but i doubt that this idea can be materialized anytime soon due to the reasons pointed out in this thread Why Wasm cant replace JS. plus Javascript is a language that was designed just for making websites interactive while wasm is a general purpose programming language. so you will still have to use some kind of framework for DOM interactions.

Thread Thread
 
ivan_jrmc profile image
Ivan Jeremic

I hope that one day we can do this because that would catapult HTML/CSS development and no one need to worry about compatibility because the developer decides which version of HTML and CSS he will use in a project and he can be sure it looks everywhere the same.

Collapse
 
anuragvohraec profile image
Anurag Vohra

I personally think web component is the future.
I have created bloc (business logic component) based framework : npmjs.com/package/bloc-them

And have created component library built on top of it.
npmjs.com/package/use-them

Collapse
 
arvindpdmn profile image
Arvind Padmanabhan

For a more objective discussion, read about the advantages and best practices concerning Web Components: devopedia.org/web-components