ING Open-Sources Lion, Its White-Label Web Component Library – Q&A with Thomas Allmer

ING recently open-sourced Lion, ING's core library of web components. Web Components, since their inception eight years ago, strive to provide a standard component model for the Web. Design systems have emerged as a natural use case for web components. It is in this context that InfoQ interviewed Thomas Allmer, core Lion contributor, on the motivation behind ING's open-source move, the Lion component library and its design goals, and the benefits for the community of developers at large. Answers have been edited for clarity.

InfoQ: You mentioned that ING has a long and rich history of building web components. Tell us about previous work at ING involving web components, and the use cases for web components at ING.

Thomas Allmer: ING started using web components in 2006. Pretty much right when web components became available. So in some sense, we could be considered web components veterans. By now most external and internal web applications are either purely web components or are using web components to a certain extent. Even most mobile apps are "hybrid" e.g. they do have certain features as a web view using those same web components. To quote Danny Wijnand, "ING Asia's app has very successfully applied it with great results regarding performance."

InfoQ:  How old is Lion and how did you come to be involved in its development?

Allmer: At ING, pretty much from the start, a component set was created to be shared across all programs. These components followed ING's design guidelines, which were in a lot of places aligned with Material Design. However, as usage grew and time passed, these requirements changed. A global ING UX became reality, the browser specs changed, accessibility and performance had to be better. In short, the component set of that time could not meet these requirements. Therefore, around two years ago, I proposed to work on a new two-tier component system. Meaning we have:

• The Lion tier, which only focuses on functionality with great performance, accessibility, and flexibility (through extensibility)
• Our own ing-web tier, which focuses on strictly following the global ING UX, with pre-translated labels, distributing styles and providing long release cycles.

This separation helped in building the components and proved to be a valuable asset in many unexpected ways (like the ability to focus on a small part of the requirements, keeping a clean codebase, discussions outside of ING, and more).

InfoQ: What is the rationale behind open-sourcing Lion?

Allmer: Open-sourcing Lion means to be able to get a truly battle-tested solution. Lion is currently primarily used within ING itself and therefore solves the use cases we encountered so far. We do hope that many developers will start extending Lion in various ways. In some situations, it might not work as expected or as nice as possible. This brings the opportunity to discuss and improve it for everyone (also for the version we use within ING).

Another reason is that ING has a high buy-in into web components so it makes sense to foster its community and showcase possible solutions for common issues.

Last but not least, giving back to a community is a reward in itself and also makes sure web components stay relevant.

InfoQ: Web components have matured over the years, and are now being used at scale in large applications, such as YouTube, the Apple Music web client, GitHub, and I assume in ING applications. Web components, however, continue to generate controversy among developers. What are in your opinion and practice the main hurdles faced by developers seeking to use/reuse web components?

Allmer: Web components are a great way of building reusable components. They, however, lack the buzz that frameworks have. There is no central website or authority to give end-user directions. Specs for web standards are not everyone's bread and butter.

Furthermore, all web implementations tend to stay low-level to make sure they can be used in various ways. This, however, makes them not that simple to use generally. Exactly for that reason, multiple libraries emerged to make the life of developers easier.

Still, when not using a framework, you do have to make a lot of decisions yourself. How to handle state, localization, routing, testing, demoing, deployment - not everyone has the manpower to tackle all those concerns themselves. Best practices emerge but there is still much to do.

On top of that, creating good components is hard no matter the technology. And there are not that many very good examples around. With Lion, we want to show what web components worked for us and how we approached implementing them.

Shameless plug: together with some web components fans, I also started an open-source project which aims to help with some of these issues and to give back to this awesome community.

InfoQ: The open-wc site announces what it terms as "Open Web Component Recommendations". What are (some of) those? What is the basis for these recommendations and what is the consensus around them? What makes the recommendations "Open"?

Allmer: Open Web Components is all about giving guidance and tools for working with web components. This includes getting started (we have codelabs), general development guidelines, linting, testing, demoing and building for production. All these recommendations align with a buildless development experience, and shall work directly in modern browsers. It means sort of going back to the roots where you worked with HTML files, a simple text editor and the browser.

We consider it open as nothing is set in stone and depends on community feedback. For example, we started off recommending webpack and now have webpack and rollup (preferred) side by side. At some point, we might solely recommend rollup (or another tool that works well with web components).

InfoQ: To take a specific example, open-wc recommends Visual Studio Code's IDE, with alternatives (like IntelliJ or Atom) mentioned in passing. Are there features of Visual Studio Code that cannot be found nor replicated in other IDEs?

Allmer: In the world of JavaScript, there are way too many options (for everything). We try to help by giving recommendations of things that definitely work. Still, all our recommendations are just that - recommendations. In the case of the IDE, Visual Studio Code has all the needed plugins to bring many of our other recommendations (like ESLint, Prettier, or lit-html) right into the editor.

Will it stay forever at the top? Only time will tell.

InfoQ: What are Lion's design goals and key features? How does Lion address the developers' concerns you mentioned previously? You mentioned for instance that Lion is a core package of white-label web components. What does that mean?

Allmer: Lion is probably different than most current component sets in the sense that it deliberately does not put any styling on its components. Therefore, it looks visually rather bad and you do have to invest in applying your own styling/behaviors. This, however, brings us into the unique position that we can fully focus on the functionality and do not need to cater to all these thousands of variations you can build to make it your own. So Lion brings all required fundamentals like localization, overlays or forms, with a very well-thought-out API, in addition to accessibility and performance. You will need to bring design, UX and some time. Overall, it gives you a huge head start in creating a scalable component set you can use in any* framework or no framework at all.

* React needs handmade wrappers

InfoQ: How many web components are included in Lion and how are they organized?

Allmer: Our biggest categories are Forms, Overlays and Localize. Each of these could probably fill multiple blog posts by themselves so let's give a very brief overview:

• Forms: An extensive set of enhanced input fields
  • is accessible by deliberately putting needed parts in Light DOM
  • has a real JavaScript value (modelValue)
  • has a sync/async feedback system with support for localized and customizable messages (can be used for error validation, info/warnings and more)
  • has inputs for email, number, date, datepicker, IBAN, and more
  • has automatic nested data with serialization (for sync with database)
• Overlays: A system to manage overlays content
  • handles accessibility for you (including for instance aria or focus)
  • handles local (tooltip) and global overlays (dialog)
  • has knowledge of all overlays to support nesting and blocking functionality
• Localize: Loads and provides translations
  • uses es modules by default
  • supports namespaces (can be per component)
  • namespaces can map your own API endpoints
  • provides a mixin for direct consumption

InfoQ: The raison-d'être of components is reusability, which relates to configurability and extensibility. How may developers extend Lion's web components? I am thinking in particular about style customization, which, I understand, is intentionally left out of the web components design. I reproduce for our readers a picture from the release note showing bare-bones Lion components next to ING-customized Lion components:

Allmer: When you want to build your own design system on top of Lion, you do get a lot of functionality out of the box. In most cases, extending a Lion component and adding specific styling will be all you need. Sometimes you may want additional functionality that you can directly add to your extension. We advise having one package for your users they can depend on. This means you may want to re-export all features that are used from your package as well.

Generally, I can say that we had great success with our ing-web package. Developers like to work with it and in many cases don't even know that they are actually using a Lion feature. It is an implementation detail for them.

InfoQ: You released the beta not too long ago. What has been the feedback from early adopters so far?

Allmer: I do know that the tabs implementation of web component is an extension of @lion/tabs and we already got valuable feedback for the component.

Furthermore, I assume that many implementations of design systems will stay in-house so we will only get to know about them indirectly (possibly through questions/issues).

InfoQ: Lion is open source and still in beta. You mentioned that feedback and contributions are welcome to shape the stable release. How can fellow developers concretely help?

Allmer: The most important part is trying Lion out and extending it for your own use case. If something feels strange or does not work as expected, please give useful feedback and let's work together to make Lion a worthy foundation for various design systems.

Developers seeking to use or investigate Lion's web components can check out the GitHub repository. Alternatively, all Lion components are showcased and documented via a live Storybook. Components are distributed in individual packages which can be separately installed. For instance, installing Lion's <input-iban> component is achieved by running the following script:

npm i --save @lion/input-iban

Following that, the component can be imported as follows:

import '@lion/input-iban/lion-input-iban.js';

The component can thus be used as any other HTML tag:

<lion-input-iban label="Account" name="account"></lion-input-iban>

About the Author

Thomas Allmer is a software engineer at ING. He is a huge fan of buildless development and likes to work as close as possible to "the Platform" (Browser). He enjoys open source and is a core contributor to Lion web components and Open Web Components.