The Three Unattractive Pillars™ of Web Dev #

I have this idea that there are three underpinning concerns every developer should have when they build their projects: accessibility, security and performance. You can immediately see how one could affect the others, but their relationship is nuanced. They're not appealing, though, because you're never going to persuade the people paying for your project (unless they're savvy) that these unseen aspects are critical. Security is probably the easiest, I'd wager, but typically only FUD powers their inclusion.

There are two further things I notice about them:

• They're only a problem when they're missing. Ship something which lacks one or more of the Three Unattractive Pillars™ and you're going to have a bad time.
• They're not unit tests. Try and retrofit any of them to your project and you're going to have a bad time.

They're basic building blocks of building well and they're more a mindset every good developer should have than anything else.

The "promise" of Web Components #

Firstly, let me say that I'm excited about Web Components. I think they're likely the Next Big Thing™ for the web. I also genuinely think the term "Web Component" implies that the three aspects of web development I outlined have been taken care of, and I think that fundamental mismatch of implication vs. reality is a problem. As a developer I would expect, to a large degree, that I can trust that these components will in no way hose my project.

Some of it comes down to the component developer's choices and some of it to the way in which the browser deals with components. Unfortunately, however, there's very little in the specs (as far as I know) that directly speaks to the three pillars, largely because you can't really "enforce" them directly. After all they're just elements, and so how different are they from other elements you already get provided by the browser?

HTML Imports are interesting in that the current implementation treats them like stylesheets, which means browsers will wait on them before rendering. That may or may not end up being an issue, depending on whether or not a developer realises imports can be render blocking. (If they weren't then we'd be talking about how you get FOUC when HTML Imports get parsed, which would also be bad.) For sure this is a nuance of Web Components, but I think it at least illustrates that there's no silver bullet here; developers need to understand the mechanics of what's going on.

Go Go Gadget Community! #

I believe we need some open and community-driven way of vetting and ensuring Web Components are accessible, secure and performant.

No issue is insurmountable here, but my point here is that since by default there is very little that enforces good accessibility, security and performance, we'll end up with a load of components that are terrible, with no way for developers to sort the wheat from the chaff. We've seen that happen with npm, Bower, and jQuery UI and, as it stands, I don't see any reason to think Web Components will be any different.

In any case the scalable solution is definitely not to expect developers to assess the quality of each component; they have better things to do, and in some cases it's not all that easy. I'd be the first to confess my knowledge of accessibility and security could be significantly better, and I doubt I'm the only one!

I believe we need some open and community-driven way of vetting and ensuring Web Components are accessible, secure and performant. While we figure out what that means, let's not be fooled into thinking that Web Components can fix bad development; we're going to need something very different for that.