Web Components continue to be a subject of debates. Naturally, now when they are supported by all evergreen browsers, some people ask themselves if that should be the “new era”. Then it turns out that new standards are not a silver bullet and don't meet someone’s expectations, not all the bugs are fixed, and some parts of the web platform need further improvement.
I described few such problems in my previous blog posts (1, 2). However, certain opinion leaders having some impact on the JS ecosystem tend to criticise the idea as a whole, by claiming Web Components to be based on wrong assumptions and not practically useful. These statements have their ground, but they produce a lot of misconception among the community.
You may not yet be aware of it, but in fact Web Components are now experiencing an impressive growth in the most inert part of the industry: enterprise UI development. The big companies are interested in long term solutions, and some of them learned many painful lessons in the past. That’s why now they express strong signs of support to web standards.
In this series I will give an overview of several enterprise platforms for business web app development, adopted Web Components as part of the programming model. We will see how they introduce changes while moving towards web standards over time, what value do they bring to the open source ecosystem, and what lessons can we learn from their experience.
Salesforce
Salesforce is a software company offering a CRM platform and a suite of enterprise web applications. Many of those applications came from acquisition, which is often the case for the market expansion, and were built using different stack. At the same time, customers can build their own applications using the Salesforce platform and the tools it offers.
The case for Web Components at Salesforce was presented at Google I/O 2019 in the talk by Kevin Schaaf and Caridy Patiño. The main points of the talk are listed in the article by Arthur Evans. The reasons why Salesforce choose Web Components include the need for a common component model ensuring consistent look and feel and backwards compatibility.
However, there are other valid points in that list, which I personally think are more important – especially, concerns against proprietary solutions, risk of being stuck with legacy technologies and fear of staying in the walled garden of closed ecosystem. This is how “not invented here” symptom clearly manifests itself in a rapidly changing frontend world.
In the end of 2018, Salesforce announced the Lightning Web Components as a new component model for UI development in the platform, leveraging the benefits of the web standards. A special focus was put on the coexistence and seamless interoperability with the previous model, Aura components, with the suggestion to consider migrating to Lightning over time.
Few months after, Salesforce open sourced the Lightning Web Components framework and presented the repository licensed under MIT, new website and lwc-create-app CLI tool allowing to create a new project. Salesforce developer evangelists are also writing blog posts on the related frontend technologies, like unit testing the components with Jest and debugging.
Oracle
Oracle is a corporation which offers a wide variety of enterprise software products, including client-side web applications. Many of these apps are built with Oracle JET, or JavaScript Extension Toolkit, available under open source UPL license. Note that word “toolkit” represents and emphasises the modular structure: JET is not a framework, but rather a set of libraries.
In 2017, Oracle introduced support for Custom Elements in the 4.0 release of JET. This decision was motivated as part of effort to better align with HTML standard and modern specifications. At the same time, new architecture of JET UI components was presented to the audience of UI designers and developers as a better syntax, more intuitive and natural to work with.
Previously, until 3.2.0 release of JET, all the components were wrapped as jQuery UI widgets. New “syntax” was implemented to work side-by-side with the existing model, and migrating to it was clearly indicated as not required when upgrading to the new version. But all the new features, developer guide updates etc only targeted new web components.
Note that getting rid of jQuery was not the motivation for using Custom Elements. Two years and 3 major releases after the big change, Oracle JET is still using jQuery, as well as other not so fancy libraries like RequireJS and Knockout (there is even a “Why Knockout” section in FAQ). The transition from Sass to CSS custom properties in JET also occurs slowly.
And this is the next lesson we can learn: at enterprise scale, gradual migration is a must. Big companies can’t afford to rewrite everything from scratch, while having to maintain projects for years. Oracle JET seems to keep a reasonable balance between legacy and technology renewal, while also thinking about the ecosystem and having own vision of the future.
SAP
SAP is a corporation providing enterprise software, including ERP system. For frontend developers SAP offers OpenUI5 framework available under Apache 2.0 open source license. UI5 is positioned as enterprise-grade JavaScript toolkit for building web applications running on almost any browser, using jQuery as its foundation and following web standards.
In early 2019, SAP announced the beta of UI5 Web Components library, presented as a key pillar of the UI5 Evolution project, aiming to enable independent consumption of UI elements. As it turns out from another blog post, SAP developers evaluated Web Components starting from 2014. And now they look really optimistic: “the time has come, the web is ready!”
Few months after the initial announcement, and at the time of writing RC1 has been released just in time to be presented at UI5 Con. Apart from keeping a good pace with the actual development, SAP also published a website with interactive playground, a tutorial on how to get started, several demo apps and a newscast episode with UI5 lead architect.
One important note about UI5 Web Components is how they are positioned compared to OpenUI5 as an existing product. There is a special section describing the new components as “complementary offering”, not a successor of OpenUI5. The lesson we can learn from here is the importance of clearly formulated message alongside the architecture update.
And one more thing, related to the above point: getting rid of jQuery. Here we go again: sometimes the architects have to explain the decisions they make to the users. I strongly recommend reading this comment by Andreas Kunz from SAP to understand how carefully do big companies consider the actual value of tools they use and the impact of decisions they make.
Summary
Web Components have reached the broad browser support quite recently: Custom Elements and Shadow DOM shipped in Firefox 63 in October 2018, and Edge based on Chromium is now available in canary and dev channel. Nevertheless, certain enterprise companies have already chosen Web Components as a foundation for their UI development platforms.
Salesforce, Oracle and SAP are examples of such companies. Their frontend solutions are created using different approaches, and they are all at different stages of adoption of new component models. Comparison of those is not the primary goal of this blog post, so let me outline and briefly formulate the lessons which I think we should learn from their achievements:
Ownership. Preferring web standards over proprietary solutions is driven by the aim to avoid vendor lock-in or being stuck in closed ecosystem. Focus on web standards allows to reduce the barrier to entry for new developers, while also providing full control over the technology stack and promoting the internal competence growth.
Gradual migration. Being able to combine Web Components with other libraries is a key to ensure the smooth transition between two development models. A new approach, initially introduced either as “complementary solution” or “alternative syntax”, has to evolve and stand the test of time to finally supersede an old model.
Impact of decisions. Big companies carefully evaluate the choice they make when it comes to upgrading the technology stack, and this is especially relevant for rapidly evolving JavaScript ecosystem. In enterprise UI development, any new feature goes through a long validation phase, this is where the web standards come into play.
In the second part of the series, I will continue the overview of frontend toolkits built with Web Component from a slightly different angle. We will explore three different open source platforms which are in themselves provided as products, accompanied with the commercial services – and will hopefully learn a few other lessons from them. Stay tuned!
Oldest comments (1)
Excellent overview of the current state of web components. One of the points I've been trying to make, which is demonstrated by the large enterprise organization commitment to the platform you outlined here, is freedom from getting locked in.
Large frameworks by design make it too painful to change course.
My company extricated itself from from the most popular framework to LitElement and small supporting libs, and I never want to go through that again. With web components, thankfully, we won't have to.
Onward!