Web-components

Hello patternfly,

I have just read this blog post from ionic, introducing ionic-v4 which changes directions from using angular and being an angular framework to use web-components so you can use it with whatever framework you want.
https://blog.ionicframework.com/introducing-ionic-4-ionic-for-everyone/

For everyone who doesn’t know what are web-components:
https://www.webcomponents.org/

It kind of makes me wonder about the patternfly-4 direction.
The point is, the UI frameworks/libs changes constantly and it is hard to predict what would be the next popular lib that replaces everything.
Even after you choose a lib, let’s say React, you will find yourself tweaking your lib every time a new single react version is out. You will need to introduce a new version of patternfly that support the new React version while updating peerDeps so you are no longer supporting new React versions.
If a consumer wants to update, the consumer will need to upgrade the React version while it might be impossible because he is relying on older libs who didn’t get updates yet.

Their point for using web-components is the fact it can run in all modern browsers, together with whatever lib/framework you choose for your project while breaking changes are rare because you are relying on a formal standard API the browsers are supplying.

Would love to hear your opinion about it, are web-components are the future for UI libraries that supplies components?

I used to think about web-components, that they kind of failed where angular and react and succeed and became popular but today I see it’s potential for writing UI libraries.

Disclaimer I am no longer at RedHat and do not make decisions on the direction of PatternFly. Below are only my opinions on web components and how they will impact PatternFly.

Here are my two cents on web components. They are great for making embeddable widgets on website. A good example of this would be OpenTable’s reservation widget. It is currently an iframe. A web component would be great for that.

When it actually comes to building complex applications you will likely not use web components directly. Odds are a framework will be needed, or desired really. At that point why web components over something like Angular or React?

I am biased towards React so I will speak to why I choose it over web components every time.

  1. The declarative API. Working in a declarative environment is so much easier to reason about, at least for me, than an imperative one.
  2. State Management. This is built into React. Web Components doesn’t really have something for this built in. Again you could use a library of framework, but at that point what is the benefit?
  3. Tooling. Testing React applications is way easier than ones using web components. I don’t need a browser and I can choose how much of the tree I really need to render.
  4. Type Safety. Web-components (unless you use JSX) use regular HTML for rendering, etc. It is much harder to hook TypeScript into this type of flow. React works really well with TypeScript and it can make a huge difference on large projects.
  5. Community. The React community is huge and has many of the best minds on front-end behind it.
  6. Recruiting. Recruiting candidates is much easier when you say you are using React, GraphQL, etc. People like it and want to work with it.
  7. SSR. Server Side rendering is not needed for all apps, or most apps for the most part, but it is nice to have that ability. Especially when it comes to static site generation using tools like Gatsby or Next.
  8. Cross Platform APIs. React has the same APIs for React Native and react-dom. This is great since I “learn once, write anywhere”. React Native is not a web view like the other write once run anywhere libs. So you are going to get a bunch better experience with that.

Don’t get me wrong. I fully believe Web Components have a place at the table, but for applications I will always reach for React or the next framework that offers a robust declarative api that is easy to make type-safe with a good amount of tooling built around it. That may be a framework that renders to Web Components in the future, but for now it is not.

As for PatternFly going the route of Web Components I believe that many within the UXD team would love to see that happen. I do know many, not all, of Red Hat’s product UI’s (the ones using PatternFly 4) are using React though, and by the looks of it IBM is mainly using React too based on their Carbon Design System. It is not easy to build wrappers around Web Components with React (imperative vs declarative). I do not believe Web Components would not be successful for PatternFly 4. That does not mean it will not move that direction though so you might take my info with a grain of salt.

1 Like