DEV Community: Luke

Painless Web Components: Naming is (not too) Hard

Luke — Mon, 20 Feb 2023 17:51:25 +0000

This post is the first in a series focused on reducing the perceived pain of creating, using, and maintaining web components. The main focus will be web standards and "vanilla" methods, but we will look at how comparable libraries or frameworks are doing things too.

Two Types of Custom Elements

Naming isn't really the first decision in the process of creating web components. The first task is to choose which of the two types of custom elements you are making. The options are:

Autonomous custom element¹ - the standalone types of elements (e.g. - <my-cool-element>, <useful-tool>, <fly-away>)
Customized built-in element² - the elements that inherit and extend the semantic functionality of existing elements (e.g. - <button is="bouncing-button">, <strong is="bold-and-beautiful">).

The difference lies in whether or not you are extending an existing element of HTML in your constructor (e.g. - HTMLButtonElement,HTMLInputElement,). In my experience, when people are talking or thinking about web components they're usually talking about the former, but the naming conventions for either one are the same.

Two Name Considerations

When building a web component there are at least two items to name: the custom element (tag name), and the constructor (usually a JavaScript class). Both deserve appropriately thoughtful names as they are the required parameters to register a custom element with the browser using the customElements.define() function:

customElements.define('your-tag-name', YourConstructor);

customElements.define('your-tag-name', YourConstructor, { extends: "input" });

in the case of a customized built-in (in this case extending an HTMLInputElement)

The constructor is probably the easiest of the two to name, because you will utilize the same conventions you have for any other class names (you are defining a standard naming convention, right?). In most cases, I will make an attempt to match the constructor's name to the tag name, but it isn't required other than for lowering cognitive load. I am also a little more liberal on the use of upper-case abbreviations, but not for any justifiable reason other than I like how it looks next to HTMLElement. Some examples:

CPXCookie <=> cpx-cookie
DPSearch <=> dp-search
MyMatchMeetBookOverflowPlusSong <=> mmmbop-song⁰

There is a nice "Note" on the Custom Elements living standard³ that lays out the standard for valid custom element names. Most of these are to accommodate existing HTML parser rules. In my simplified words:

Starts with a lower-case letter
No upper-case letters allowed
One or more hyphens
Not one of a small list of existing tag names that include a hyphen that it is unlikely you'd use anyway (unless you're dying to make an annotation-xml or missing-glyph component, in which case you're going to be really let down)

Interestingly, the wide constraints on this means you can have some fun with the tag names. Emojis, latin, and any valid characters in the list of potential custom element name characters⁴ are valid (even if I wouldn't recommended doing so because it makes actually typing the element name a little harder).

Namespacing and Organization

Element names can also be used to namespace or organize your components. Namespacing with a prefix can help denote ownership or library membership. A few examples:

cpx- (my Chapeaux components, which we'll look at more as the series progresses)
pf- (Patternfly Elements from Red Hat⁵)
sp- (Spectrum components from Adobe⁶)
bp- (Carbon components from IBM⁷)
fast- (Fast components from Microsoft⁸)
lion- (Lion components from ING⁹)

After the namespace prefix, you can also leverage the hyphenated nature of the names to do natural grouping for related components. Variants or parent-child components can be grouped with a consistent name to denote their relationships.

Referencing the custom element name

How the tag name gets into your code can vary based on the method you are using to write your components. If you load up a few of the templates over on WebComponents.dev you'll see that many examples just use a string value typed into the define function directly.

customElements.define('my-tag-name', MyTagName);

In some templates, like Lit and Stencil for example, they leverage decorators that handle passing that string value along.

// Lit
@customElement('my-tag-name')
// Stencil
@Component({ tag: 'my-tag-name' })

In my vanilla components, I like having this little blurb near the top of the defining class to set a class-level value:

static get tag() { return 'my-tag-name'; }

When I register the element it looks something like this:

customElements.define(MyTagName.tag, MyTagName);

Registering your element

Once you have your two names, you are able add your element to the CustomElementRegistry by using customElements.define(). Putting it all together, it might look something like this:

class MyTagName extends HTMLElement {
  static get tag() { return 'my-tag-name'; }
}

customElements.define(MyTagName.tag, MyTagName);

<script src="mytagname.js"></script>
<my-tag-name></my-tag-name>

Your custom element is now registered, but doesn't really do much of anything at all except exist. Next up we will look at the various features that are made available to developers beyond component registration.

[0] - An out-dated web component overview repo used for a talk - Luke Dary - https://github.com/KamiQuasi/wc-overview/blob/master/index.html (YouTube recording of talk)

[1] - "4.13.1.1 Creating an autonomous custom element" - HTML Living Standard - https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-autonomous-example

[2] - "4.13.1.4 Creating a customized built-in element" - HTML Living Standard - https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-customized-builtin-example

[3] - "4.13 Custom elements" - HTML Living Standard - https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements

[4] - "4.13.3 Core concepts" - HTML Living Standard - https://html.spec.whatwg.org/multipage/custom-elements.html#valid-custom-element-name

[5] - "PatternFly Elements" - https://patternflyelements.com/

[6] - "Spectrum Web Components" - https://opensource.adobe.com/spectrum-web-components/

[7] - "carbon-web-components" - Introduction / Welcome - Page ⋅ Storybook - https://web-components.carbondesignsystem.com/?path=/story/introduction-welcome--page

[8] - "Adaptive UI System, Utilities, and Tools" - https://www.fast.design/

[9] - "Fundamental white label web components for building your design system" - https://lion-web.netlify.app/

The Emperor's New Library

Luke — Tue, 14 Feb 2023 05:08:49 +0000

This post is the expansion of a lengthy Mastodon thread I posted ⁰ in response to blog posts from Alex Russell (@slightlyoff)¹ and Laurie Voss (@seldo) ²

delete you.React;

Many promises and flashy demos have been made over the course of the prior decade using React. There is no denying that adoption of React is widespread. What is concerning is the bait-and-switch technique of promotion that React engenders where conference speakers, tutorial makers, or bootcamp instructors flaunt bells-and-whistles that are ill-suited to production. Confirmation bias, due to the popularity of React, has blinded people to the reality that React should not be the foundational basis for hiring developers, starting new projects, nor performing frontend training and bootcamps. The reality is that developers and companies can remove React from their tooling and be better off for it.

A Decade Apart

Alex speaks a lot about the last decade, and when I look back, his claims resonate a lot with my experience. I can look at things happening in February 2013, and it makes me think he may have even been a little too kind limiting it to a decade. Issue #76 of "HTML5 Weekly" from @cooper had a great (at the time) link to a Simple Frontend Boilerplate³ useful as a historical record of the apps at the time.

What we see, a decade ago, are that many of the "popular" libraries, frameworks, and methods, not surprisingly, have gone by the wayside, a lot that have remained in current code as difficult-to-~~remove~~modernize legacy cruft (Bower, Gulp, Grunt, Backbone, Angular 1, ...), and then we have the small minority that are still here. Some that remain have had their utility lessened/questioned by platform and language improvements (jQuery, lodash, ...), but very, very few exist that are the same now as they were then. Another fun historical reference: issue #118 of "JavaScript Weekly" (February 22, 2013) includes a first link out to asm.js.

People were even "predicting" the rise of Single Page Apps (SPAs)⁴. Given the broader historical context, my personal experience was taking over leadership of a Google Developer Group in 2013. So I was knee-deep in what Google was promoting for the open web (with an emphasis on mobile web performance): WebP, WebM, and the first look at Web Components⁵. Web components transformed and reignited my passion for the web platform.

The Rise of React

What followed in the years after, however, was a marketing blitz of React promotion. I know this quantitatively, by looking at my relatively neutral web development newsletter subscription emails (general web dev topics) and comparing "React" (the library) versus "Web Component(s)" occurrences (example: after:2012/12/31 before:2013/12/31).

Email Newsletter Subscription Mentions

Columns: the year searched, the number of emails received mentioning Web Components (WCs) or React (R), and the percent difference between Web Component emails and React emails.

Year	WCs	React	WC Diff
2013	33	7	+371%
2014	57	54	+5%
2015	28	108	-74%
2016	24	167	-86%
2017	18	142	-87%
2018	19	121	-82%
2019	24	120	-80%
2020	11	157	-93%
2021	15	153	-90%
2022	33	161	-80%
2023	6	17	-65%

What do I perceive as being the catalyst for the rise of React? React.js Conf in January of 2015⁶ and also a few months later the release of React Native⁷. The first gave validation to the ability to run, or speak at, a conference with React topics, and the second gave developers a way to do "native" mobile development in a way much smoother than offerings available at the time. Thus began in earnest, in my view, "The Shill Wars". This is also when I started to notice that it had become more and more passe to discuss things other than React in my dev circles. Even significant platform updates fell by the wayside or went relatively unnoticed or unacknowledged.

A Tale of Two Blogs

My experience and subjective observation affirms every point in Alex's post. Unfortunately, that means that there were/are individuals, real people, ignorantly or intentionally continuing to regurgitate the same 'ol framework and library narratives with zeal. What has always been lacking, is accountability for the "complexity merchants". Instead of mea culpa, they went full Order 66 on the Web Platform Jedi when confronted with the less savory realities of their libraries or frameworks.

I came into Laurie's post with an open mind and relatively few expectations, but making a hasty generalization⁸ (intentionally or implicitly due to the proximity of the two statements) that of the "tens of millions" of software developers, a majority (71%) use React. I felt unseen, and the claim tripped me up, and misrepresented the 9.993 million other devs out there that may or may not use or know React.

There is Always Money in the React Stand

This is not new ground we're treading. This is the same type of result we've seen year after year from the "State of JS" surveys. The network effect within the web development world reached a critical mass in favor of React in 2015, and due to the ever-present ability to make money off of training, conferences, media, and ephemera within the industry we've reached the point where confirmation bias runs so rampant that nobody is willing to accept that the Emperor's new library is not a net good for developers, for users, or for the web. There is a growing number of people who are trying to help those too afraid to appear inept or stupid to realize they have been duped (or so the folktale goes).

Money, and the assessment of costs, is something I think Laurie also gets horribly wrong. Let's take a look at the February 2022 update to all the ways to make a web component⁹ to do some calculations and blow up the mainstream React narrative some more.

Developer, Storage, Performance Costs

Legend: Items are based off of implementations or data from the ways to make a web component⁹. Minified size, 30x (30 components), 50x (50 components). Comparison is between the HTMLElement implementation and the React with Hooks implementation. Diff is the percentage difference between the React and HTMLElement item.

Item	HTMLElement	React	Diff
Lines of Code	54	41	+32%
Web Platform Concepts	11¹⁰	8¹¹	+38%
Node/Library Concepts	0	6¹²	-100%
Dependencies	0	3	-100%
Minified Size	1009	131515	-99%
30x Components Size	30270/0	23760/130723	+27%/-100%
50x Performance	17.38/19.37	34.55/38.11	-50%/-49%

The truth is, React costs more in every way, it necessarily has to, because it is built off of the platform that natively runs web components. React also can't scale well, because it always carries around the specter of larger dependency overhead.

Developers have to learn more to be productive with React, they have to manage more dependencies with React, the bandwidth used is higher, the performance is slower. If you strip portability and compatibility from the equation you may see gains with going with an all-React ecosystem, but then reuse and compatibility necessitate using React despite whether it is the best tool for the job. I've also seen this break down just between different versions of React being incompatible (with React or even vanilla JS; see import.meta issues), which is not something you get with native platform code.

Yet, React proponents always seem to start with big claims but then are never held to account by the community when they are forced to backtrack on those claims. In some cases, there are attempts to distract with some new shiny claim that reposition the old claim either as wrong or more likely "less right" (looking at you create-react-app).

The biggest fallacious claim of the framework and library zealots is this statement from Laurie: "We want an open, accessible, world wide web." What part of a library of choice actively working against existing W3C web standards and resisting acceptance of PRs to help devs trying to use those standards with your library seems open and accessible?

The solution is NOT more frameworks, the solution is what Alex, myself, and many others have been advocating all along: use the platform. If it doesn't do what you want, make proposals, participate in the standards process via working groups or other open communities.

"Your path you must decide" - Yoda

Good news! You can start adding things like web components to your existing apps without a complete rewrite or much concern for compatibility or build process. Easing into web components can be as simple as adding a custom element (no Shadow DOM) to handle string formatting.

We started with a date/time formatter to solve an issue we had with search results not matching a user's locale date formatting when they searched for things between specific dates. We grew from there to make an entire search page made with vanilla web components (no libraries, no frameworks, no dependencies; including Shadow DOM): https://developers.redhat.com/search?t=openshift

You can take small steps to end the naked parade of unchecked power that React has enjoyed for a decade just by leveraging the standards that the platform already provides more often, and telling others about your experience with them.

[0] - https://w3c.social/@lukedary/109851919543348747
[1] - "The Market for Lemons" - Alex Russell - https://infrequently.org/2023/02/the-market-for-lemons/
[2] - "The Case for Frameworks" - Laurie Voss - https://seldo.com/posts/the_case_for_frameworks
[3] - "Simple Frontent Boilerplate" - Cody Lindley - https://github.com/codylindley/simple-frontend-boilerplate
[4] - "HTML5: 10 Provocative Predictions For The Future" - Todd Anglin - https://readwrite.com/html5-10-provocative-predictions-for-the-future/
[5] - "Web Components: A Tectonic Shift for Web Development - Google I/O 2013" - Eric Bidelman - https://www.youtube.com/watch?v=fqULJBBEVQE
[6] - "React.js Conf Round-up 2015" - Steven Luscher - https://reactjs.org/blog/2015/02/18/react-conf-roundup-2015.html
[7] - "Introducing React Native" - Sophie Alpert - https://reactjs.org/blog/2015/03/26/introducing-react-native.html
[8] - "What Is the Hasty Generalization Fallacy?" - Lindsay Kramer - https://www.grammarly.com/blog/hasty-generalization-fallacy/
[9] - "All the Ways to Make a Web Component - Feb 2022 Update" - Many Authors - https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/
[10] - HTML, CSS, JS - Variables, DOM, Template Strings, Classes, Custom Element Lifecycle Callbacks, Shadow DOM, Events, Custom Elements Registry
[11] - HTML, CSS, JS - modules, variables, functions, Destructuring, Template Strings, Custom Elements Registry
[12] - JSX, Node modules, React, useState, ReactDOM, reactToWebComponent

I want to express my utmost gratitude to Alex, Benny, and Steven for giving my drafts of this post some much needed feedback and direction.

5 Practical Activities for Exercising Your Patience

Luke — Wed, 20 Nov 2019 15:25:19 +0000

Hurry Up and Be Patient

I don't think of myself as a patient person. When I am driving it takes very little delay, whether red lights or the speed of other drivers, to really get my blood boiling. However, in different contexts I have been told I am patient and have had people ask me how I can be so patient. My secret, if you can call it that, is to practice being patient in easy ways so that when I really need to be patient in tougher situations it is second nature, or at the very least, less difficult.

Impatience can be costly in every aspect of life. Rushing in can cause your code to be full of bugs, your relationships to burn too hot and flame out, your finances to evaporate, and your mode of transportation to crash. The most obvious benefit of patience is the avoidance of all those negative consequences, but usually patience also comes with peace-of-mind and some amount of serenity even when things are not that way around you.

Timing is Everything

In some cases we need patience to endure; in other cases we need patience to appropriately react. Consider two very different situations:

Sitting on a tractor in the middle of hundreds of acres of alfalfa with nothing but your thoughts and the job at hand to pass the time; you could anxiously await the end of the work or take the time to observe, ponder, or maybe just sing a song to yourself.
You're the coach of a baseball team with nine players aged from four to seven who are all hot, thirsty, needing to go to the bathroom, and moving like electrons while you try to get them to play the game properly; you could be that person (you know, the one in the news) and let your temper get the best of you or you can yell out positive and corrective instructions repeatedly without ceasing and "praise a good effort, despite the outcome of the game".

In both scenarios patience leads to an arguably better outcome. The expression of that patience is different. One is passive engagement within the constraints of a circumstance, and the other is active engagement to change the circumstance.

Ridiculously Impatient

I watched in stunned silence one morning recently on my drive to work as two lanes merged to one and two drivers in front of me were so impatient that neither would concede space to the other even though traffic at the time was plodding along no faster than 10 miles per hour. It ended in a literal slow-motion bump of the cars, which meant both drivers had to pull over and spend time dealing with something that a little patience by just one of them would've prevented.

Do you even wait, bro?

Building up our ability to be patient is no different than exercising our bodies to gain strength or stamina. In the same way you start with less weight or less time and build them up over time; you can do the same thing with purposeful acts of patience to build up your tolerance for larger efforts.

5 Practical Patience-building Activities

Lines/Queues - Let someone in front of you for a completely arbitrary and unselfish reason. This could be waiting to order a meal, at the grocery store, even just holding a door open. I did this while waiting to submit my information for a passport and ended up having a delightful conversation with a woman about her godchildren while the postal service worker was looking for her mail. The reason I gave was, "This stuff will probably take a while." Continue to find ways to increase the number of people or the frequency at which you do this when you've found it easier
Traffic - similar to lines, but without the potential for interpersonal interaction or much thanks. This is nuanced, because you have to balance slowing traffic behind you with allowing someone to come in. Typically it doesn't make sense to let a whole line of traffic in, so one or two cars is probably the max unless there is some reason to allow more. The big thing to remember is what does and doesn't save you time. Keep speed in perspective, because if you're going to gain a measly five miles per hour for a trivial amount of time you really didn't get much benefit. If traffic in front of you is stopped, or the person has been waiting as long as you then you won't be saving any time by not letting them in. Big rig semi-trailer trucks are an easy win here; let them in, and don't be angry when they don't accelerate as fast as you would like to.
Children - On the surface, what appears to be a heightened level of impatience is usually just a more rapid perception of time than you are used to. Holding the attention of a young person for five minutes feels like an eternity to them. However, on the other end of that, sometimes talking with a young person for an extended period of time can seem like an eternity when they rail through their opinion, what they ate, and how their dog likes to chew on sticks within 30 seconds. Try carrying on a relatively meaningful (to them) conversation with a child. Obviously this comes with some caution as you can't just go hitting up the nearest child with conversation, but use your best judgment. This one really builds up tolerance for long corporate meetings, by the way.
Lead/Coach/Teach - Nothing can be more fulfilling and also more disheartening than being a coach, a teacher, or a leader; taking responsibility for the performance of others is a huge task. If you have skills, abilities, or just time that you can share or pass on to others, seek out opportunities to do so no matter how inconsequential they may seem. There will be frustration, but if you work through it with positive, corrective feedback rather than anger and disappointment it will enrich you and those in your charge. Be strategic and calculated in how you respond. There are huge patience gains to be had if you can combine leadership or instruction with children; coach a youth sports team or teach a short class on a skill and you'll find that coming out the other side you will see a lot of other situations as pretty trivial by comparison.
Early-ness - Do things with a mind to being early when possible; the result is time to spend on things you probably wouldn't spend time on otherwise: thinking, observing details, watching people, enjoying a few moments of life with no specific course of action required. We don't do these types of things enough. We fill our schedules up with ease but we often neglect to have some time to do whatever we want. Examples: get to a doctor's appointment early, wake up early, get to dinner reservations early, finish (or just stop) a task early.

Patience for fun and profit

Hopefully you can adjust these tips to your context. More patience in the world will always be a good thing, so if you have other tips or tricks to pass on I would love to hear them. I'd also love to hear about complete failures and breakdowns where impatience was clearly not a winning decision.

Enterprise-grade Web Components

Luke — Mon, 04 Nov 2019 21:27:51 +0000

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

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...