Rome ne s'est pas faite en un jour.

This is roughly translated as:
"Your 'enterprise' should start using web components today".

Enterprising Misconceptions

In terms of doing business, enterprise-y technologies do not typically evoke thoughts of quick, flexible, or easy except maybe from someone trying to sell you something "enterprise-grade". They'll throw those words out to combat misconceptions of what that phrase means and then also remark on how they're also stable, supported, and secure. Now that my sales pitch is out of the way, let's talk about web components in the enterprise.

Web Component Misconceptions

I have seen a number of recent posts from people I otherwise respect in the industry misrepresenting web components in a way that may lead others astray. My TLDR; to most of them is just regurgitating some of my Google-y indoctrination, but it applies: use the platform. The landscape of frameworks and libraries for front-end development is extremely fluid, but the core platform remains a stable, and innovative space to do development.

There is notable risk in going all-in on web APIs that have not reached standard specification (v0 web components with HTML Imports, is a great example), but there are also reasons the risks might be worth taking if you can provide a richer experience to users in browsers that have implemented an early spec. I would even say that there are all sorts of valuable lessons you can learn from dabbling in bleeding edge Web APIs. Most of the time the examples given for Web Component code avoid any thought on how to mitigate their perceived issues (e.g. - users with JavaScript turned off) and instead take the well-trodden path of saying these are non-starters while proceeding to avoid like comparisons to their favorite solution-du-jour - translated: Library/Framework Soup.

HTML, CSS, and JavaScript are the root of Web Components; the best practices we have learned over the years in those realms apply, and probably to a greater extent than with something that is extra-platform. Don't rule out the declarative nature of web components (DOM elements just like the rest of your HTML) in lieu of snazzy class hooks or other, more magical (translated - less obvious to debug), methods.

Consider what mental overhead a developer would need to debug functional issues with these two examples, which would both progressively enhance the experience with JS available, and be accessible without JS enabled:

<a target="_blank" noreferrer href="..." class="svelte-1jnfxx">Tweet this</a>

<twitter-share text="..." url="..." via="..."/>
<a target="_blank" noreferrer href="...">Tweet this</a>
</twitter-share>

In the first case, there is the initial understanding that the svelte-xxx class tells you that there is some code somewhere to handle this thing, but the only context is in the text that it is a "Tweet", so see if you can figure out what to search for or maybe you know where the code is for that. Compare that with a blatantly obvious web component that has a searchable tag name to likely take you to, or close to, the definition.

There is a lot more to say on the topic of those vocal opponents of Web Components, but just be aware that there are some and they are not without bias that affects their accurate portrayal of Web Components.

Web Components properly done are an effective way to progressively enhance your HTML while gracefully degrading to the core elements that all browsers can understand. It also allows you to clean up some of the less savory markup that is often functional, but ridiculous:

<div class="pf-l-grid__item pf-m-8-col-on-lg pf-m-7-col-on-md pf-m-6-col-on-sm pf-u-display-flex pf-u-justify-content-center pf-u-flex-direction-column pf-u-pt-lg-on-sm pf-u-pb-lg-on-sm pf-u-pt-2xl-on-md pf-u-pb-2xl-on-md">

Enterprise Component Stakeholders

The volume of stakeholders for things in the enterprise generally get more expansive than your run-of-the-mill-and-fly-by-the-seat-of-your-pants start-up or small business does (NEOs). Instead of targeting niche or innovative 'new' markets, enterprises usually have to accommodate for both internal and external stakeholders that cover a significant portion of the global population. Here is a list of typical stakeholders and their common stakes in a given project:

• Internal

  • Legal - naming, licensing, and other legal stuff
  • Brand/Marketing - naming, messaging, hashtags
  • Product Owners - naming, features
  • Project Managers - naming, deadlines, acceptance
  • QA/QE/Q Continuum - naming, tests, performance
  • IT - naming, hosting, infrastructure
  • Co-workers interested in your stuff - naming, better ways to do it
  • Potential Employees/Associates - naming, cool factor

• External

  • Existing Clients/Users
    • See Internal
  • Potential Clients/Users - naming, features, cost
  • Other developers - naming, security, compatibility, support, documentation
  • Trolls (they exist!) - naming

Enterprise Component Technical Considerations

Web components at the enterprise level need to check off a lot of feature boxes to really measure up. If you are considering adopting or integrating web components at your enterprise here are features to consider:

• Compatibility - there are two audiences to consider: users and developers. Does using web components allow you to provide your users something that can't be done, or can't be done easily, using standard HTML elements? Browser compatibility is a solved issue, and although the polyfill solutions for older browsers are not without their gotchas, they are not what I would call the majority case like they once previously were. Sensible fallbacks and style defaults can accommodate those without modern browsers when necessary.

Developers will be concerned with whether the components integrate with your existing code. In the vast majority of cases this should be true since web components are part of the web platform, but in some cases there may be small adjustments to make the integration seamless (e.g.- your favorite libraries or frameworks: React, Vue, Angular

• Accessibility (a11y) - even though web components are mostly implemented in JavaScript that doesn't mean that your site should break if you use them. An enterprise-grade component should handle both graceful degradation (provide a sensible and functional alternative if the component cannot run) as well as progressive enhancement (in cases where the component runs it should improve the experience for all users). Additionally, enterprise components should follow common a11y practices, and in the best cases should handle these concerns out-of-the-box without user intervention.

A11y is where a lot of the sample code for, and more simple understanding of, Web Components goes completely off the rails. I am also guilty of doing things like this in a production environment, and I have little remorse about it because nobody complained. However, recent litigation has shown that the lack of complaints doesn't mean that you won't be held liable when someone does.

<awesome-link-previewer url="..." effect="ease-in"></awesome-link-previewer>

The reason this is used as an example is because you can write all the HTML content of the component within the component itself. However, as noted above, this is not the correct way to do things. Enterprise-grade web components balance the fine line of doing awesome things, while not getting in the way of the regular flow of the web. If you have a component that does cool things to an existing HTML element, that existing element should be rendered to the page and not hidden within the Shadow DOM. It would be like populating a <select> with <option>s using JS. We know that type of code doesn't always fly for a11y.

• Scalability - concerns about scale are frequently left until the end (like in this post), but should really be an up-front consideration. An enterprise-grade component scales well in engineering effort (to create, maintain, and extend them), in performance (one works fine on a page, but what about one thousand? Ten thousand? One billion?), and in usage (written once, but usable around the enterprise). There are occasions where you just need that one-off thing to do a thing, but make sure that if it is a web component that you at least have a thought towards someone else using it, even if it is just the next person to maintain your code.

• Internationalization (i18n) - I haven't seen much effort put towards this, but if your enterprise is a global organization you'll either need hooks for this or a mechanism to provide translation services. The easiest way for this to work is for the text content to be handled by something other than the web component itself, but a simple flag and translation file would probably work in a pinch.

• Stability and Support - The upcoming release of Microsoft's new Chrome-based Edge means that most/all major browser vendors will have a stake in enhancing the web platform. There is little to no trickery in getting a web component to work, but in the event things don't work, there is a large, and ever-growing community of developers who have likely gone through the same struggles or know how to solve your problem.

Conclusions

Web Components are here to stay, and if I can make a bold claim, they will be around long after your favorite library/framework. Enterprises seeking to consolidate their eclectic mix of frameworks and libraries can benefit from developing a web component library. Web components allow an organization to provide on-brand elements for building sites, apps, or just small parts of a page. There are very few reasons left for why an enterprise would not take advantage of this web standard. You should use web components today.

Feedback and critique are always welcome.

Enterprise-grade Web Component Resources

• https://github.com/patternfly/patternfly-elements
• https://github.com/SAP/ui5-webcomponents
• https://github.com/salesforce/lwc

translated:
Not at all translated. Let's be honest, you didn't actually believe that for a second, did you? Better actual translation: "Rome wasn't built in a day."

enterprise-y:
organization or business stuff typically not targeted to small businesses or start-ups because of factors like cost, scale, governance, or some other fancy words that someone might use

stuff:
technical term for just about anything that makes sense in the context; may replace with random words for humor (e.g. - business monkey, legal cheesecake, your hiccups)

NEO:
Non-Enterprise-y Organizations; aka - cool kids, hipster businesses, and vc fodder

open source:
You know, that code you use all the time, but also add great features to on your projects, which you then commit back to the community so everyone benefits? What?! You don't do that?! For shame...