Why I Use Web Components

Twitter Hot Drama

I am functionally incapable of being part of the in-crowd cool kids when it comes to hawt hawt JavaScript trends, so here's my entry in the ongoing Twitter flamewar over native Web Components (aka Custom Elements, Shadow DOM, etc.).

The Reasons I Use Web Components

1. I want to use the platform.

   "But [my framework] is the platform! It's all just JavaScript eventually!" you say.
   
   Ugh.
   
   I kind of can't believe that people have to counter these kinds of maliciously bad-faith arguments, but here goes: Yes. Yes, your favorite framework does use the platform, eventually.
   It does so in the same way that jQuery's $( [selector] ) function and "My text {{interpolation}}" "use the platform." I'm not seeing any of the framework people going to bat for going back to jQuery and Handlebars.

   I've seen the rise and fall of more frameworks than I can remember the names of, and the commonalities of them all are: A) You have to do it our special way and B) Whoops, we've dropped support for that. Time to rewrite your entire application.

   Use the platform isn't just a meaningless phrase we throw around (despite the big names in the frameworks trying to undermine it by doing so). It actually means something. It means building low-risk, high-resiliency applications and websites that leverage standardized, native features first, enhanced by proprietary code later. It means shipping less code that the end user has to pay the price to download and run.

   I genuinely believe that Use The Platform (not, Use The Parts of the Platform We, Corporations, Have Decided To Grant You Access To) is fundamental to software professionalism. Knowing the right time to reach for proprietary tooling (spoiler: it's as late as possible; later than you're imagining) is a sign of being an engineer.

2. I want the product of my effort to last longer than I care about the result.

   This is another way of talking about craftspersonship.
   Have you seen a job posting for BackboneJS or KnockoutJS developers? How about AngularJS? .NET 3?
   I have. I've seen these job postings in the last month and when I do I shudder and click away. I also feel bad for these companies, because they're in this position because they employed coders who convinced the people around them that "this is the future." It's our responsibility as people who are ostensibly professionals to avoid locking the companies that we work for into vendor-specific code and library-specific coders.

   This is why the very first thing I ever wrote on this blog was about Convention Syndrome and it's cure, the web a la carte. It's not necessarily bad to use proprietary code. It is necessarily bad to tie your entire product to it. It's necessarily bad to tie your entire identity to it.

   By using native Web Components, I give future developers the gift of no learning curve. I give them the gift of "It's just built into the web browser, you don't have to ship any third party code." I give them the gift of standards-compliance - borne out of the fires of standards committees - baked into the tool that every consumer uses to run the application.

   When I ship native Web Components at the companies I work for, I'm giving them the gift of a job posting in the future that just says "You need to be really good at JavaScript and HTML and pretty good at CSS" instead of listing a litany of old libraries that just aren't what the cool kids are into these days.

   When I stop caring about the product of my craft, the product itself should be able to carry on without me for decades without input. That means fewer libraries, fewer build and compile steps, and less code.

3. I want to use components.

   Not all of the time, but most of the time. Not for everything, but for most things.

   Here again, I see bad-faith arguments like, "But component-based designs are a solved problem!"
   
   No, they're not.
   
   The argument that - as long as you use [my favorite framework] - components are a solved problem is so boundlessly illogical I'm actually struggling to come up with a metaphor so ridiculous it fits.

   It would be like saying "America doesn't need a solution to the healthcare crisis because if you live in the UK you already have government-provided healthcare!" This is such a patently absurd statement that I'm again struggling to explain why it's so stupid.

   The point of a standardized component model is to free the web from framework churn. Building applications using these native APIs means that no matter what I layer on top, the application still fundamentally runs on a common component model. This frees libraries and application developers to innovate where it actually matters: at the very last edge where users interact with things.

   I want a component model. I want to encapsulate simple styles that only apply to small chunks of DOM. I want to be able to iterate over a list and stamp out clones of a small chunk of code and presentation for each item.
   I want these things, most of the time.

   What I don't want is to have a set of library authors or a multibillion dollar company tell me how and when I should do so, and how I should pass data, and all the other things the frameworks have decided is their responsibility.

   I just want the component model, and that's what Web Components gives me.

4. I want free, backwards-compatible future upgrades.

   You can still use <marquee></marquee> tags, because web standards last practically forever.

   If you started using fn( ...[] ) back when spread was first standardized instead of Lodash's _.spread(), you got a performance upgrade on the scale of orders of magnitude. You may not have noticed, but you did. The browser engines began optimizing for in-the-wild use cases and it got incredibly fast.

   By using native, standardized Web Components, I'm shipping products that will last for decades and will get better over time. Critically, these improvements require no maintenance from me. No updating the library, fixing the regressions, re-compiling, re-bundling, and re-deploying. A static HTML file built with Web Components inline will just get better over the years.

So...

I use Web Components because I think it's the right thing to do.