This is roughly translated as:
"Your 'enterprise' should start using web components today".
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.
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.
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>
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">
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:
- 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
- Existing Clients/Users
- See Internal
- Potential Clients/Users - naming, features, cost
- Other developers - naming, security, compatibility, support, documentation
- Trolls (they exist!) - naming
- Existing Clients/Users
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
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
<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.
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.
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
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...