Priority of constituencies; or, one way to evaluate a library

When evaluating a library or framework for possible adoption, the “priority of constituencies” principle can be one useful frame. That’s the one from the HTML Working Group that states:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

The purpose of basically all frontend libraries is to make the developer’s life easier. Some gap exists between the intention and the actual implementation of the Web platform, and a library comes along that tries to fill it. (I’m riffing off of Dmitri Glazkov here.) This is all well and good—paving the cowpaths and whatnot—but a library created to impact the developer’s experience will invariably, whether directly or not, be felt by the user. And the more opinonated the tool, the more negative that impact is likely to be. That effect can come in the form of larger bundle sizes, more security vulnerabilities, or diminished reliability due to increased complexity.

I see many frontend libraries that generate a ton of buzz for their DX either be silent on the issue of UX or suggest that their incredible DX will have trickle-down benefits for users. It’s important to be honest about who these tools are primarily for: developers. There is nothing inherently wrong with that fact. The priority of constituencies principle doesn’t say that DX is unimportant. It only states that the experience of the user matters more.

So if you’re trying out a new library or framework, take a hard look at what its impact on users will be. Is there actual benefit? Is the impact at least net neutral? Don’t assess based on the author’s word alone. (But do try to gauge where the author’s priorities are at; you’re going for a long ride with them, aren’t you?) And maybe choose something that’s not too opinionated. Your users (and your future self) will thank you.