Are “Web Components” in the future for PatternFly?
Web development has become increasingly complicated in recent years. The questions of which framework to use often can eat up much time at the start of a project. I can’t remember the number of times people have asked me while working on a Knockout project if I’ve heard of Durandal, or when considering Angular 2 – what about React/Flux or Aurelia?
Patternfly is a community project that promotes design commonality and improved user experience. Its offerings include open source code, patterns, style guides and an active community that helps support it all. But, this complexity, choosing web frameworks, also affects PatternFly. Our goal is “to build a UI framework for enterprise web applications”. That requires that we remain outside of the discussion of which framework is best and provide a solid set of patterns and designs for developers to rely on.
How can you build a UI framework when there are so many choices and so many strong feelings about the different choices? In my opinion, it’s important for developers to choose the framework that is best for the project and fits their skill set. There isn’t one choice that works for everybody and it’s important that we support all developers that want the benefit of well-designed components that can be used in enterprise applications.
Web Components – an answer?
One way you remain outside the fray of which UI library is best is by staying as close as possible to the platform you are delivering to. In our case, it’s the browser. Browser makers all have agreed to implement the W3C specification so this instantly puts those specifications in a pivotal place for us. In recent years, Web Components have been introduced as a potential means of solving the differences between UI Frameworks. You can read the specifications if you are interested here: https://www.w3.org/standards/techs/components#w3c_all. The various browser teams have already started implementing these specifications at least to some level and commitment is being considered across the board as you can see from this link: http://jonrimmer.github.io/are-we-componentized-yet/. Some browsers don’t have 100% support for all of the features so we’d use a polyfill to handle those missing gaps.
One promise of Web Components is to help developers base reusable components on web standards implemented in all browsers. For a project like PatternFly, the value became immediately clear once we started reading through the specifications. Instead of needing to potentially provide a version of PatternFly for each possible framework (Angular, React, jQuery…), we could create one core PatternFly Web Component library with examples of how to use these in each framework, updating the examples as new frameworks invariably come along.
What does a Web Component look like?
We’ve created an example using some help from https://github.com/MikeCostello/bootstrap-web-components:
You can see a Bootstrap progress bar Web Component here: https://github.com/dgutride/patternfly-web-components/blob/master/components/pf-progress.html
To use this Web Component in normal HTML, it’s really quite simple to pull it in. One of the features of Web Components is the ability to include and reuse HTML documents in other HTML documents – https://w3c.github.io/webcomponents/spec/imports/. The example below demonstrates what this looks like in practice.:
<link rel="import" href="components/pf-progress.html" />
Then to use the component in code:
<pf-progress value="40" type="success"></pf-progress>
For any framework to use this, they’d only need to bind to the attributes. This is already a very common thing frameworks need to do with other HTML attributes, such as setting a class name for a div. Here is an example of how one could use this in a React project:
Where do we go from here?
This is just a small glimpse into what we are thinking of for PatternFly’s future. We plan on blogging about other aspects of Web Components shortly as well (Shadow DOM, ES6 modules/tree-shaking benefits and Angular 2 examples of Web Component use).
Now is the time for you to get involved! How do you feel about this possible direction for PatternFly? Is the benefit obvious or are there use cases we aren’t considering? Please join our mailing list, on gitter or on IRC – Freenode at #patternfly to be part of the conversation.
For more information on our community and how to get involved with PatternFly visit http://www.patternfly.org/community/.
Join the Red Hat Developer Program (it's free) and get access to related cheat sheets, books, and product downloads.