Context
There's a heated discussion on Twitter around the new CSS Modules standard. The discussion is here and here. It spans anything from merits of the standards themselves to the processes around the standards.
One of the small sub-threads included me and Daniel Ehrenberg aka @littledan
This post is a response to the final tweet because it is longer than Twitter's format would accommodate.
The tweet
I am agreeing with you that people should reach out, and disagreeing with your combative way to present it. It is very hard to do this outreach effectively and then modify the proposal as a result. This work is very important and should be done more, but I understand why it isn't
A response
Unfortunately, that’s the easy way out: it’s hard, so we won’t do (much of) it. This, however, presents a very skewed process: Standards committees and browser implementors who have all the power don’t reach out. Framework developers, and individual developers can’t reasonably be expected to follow and engage in the development of the standards as there are just so many of them (Chrome added over 400 new APIs in 2020 alone).
So, when developers do learn about a new standard, it’s very often very late in the process. And here’s where the ugly part starts, and it’s been getting uglier and uglier in the past several years.
Developers raise their concerns, point out the downsides, show how standards break or ignore existing (often better) solutions. The response is almost invariably: “we know what we’re doing”, “you should’ve engaged in the process”, “it’s part of platform now”, “go read discussions”.
So, there’s next to no engagement during the process. There’s next to no engagement after process.
It gets worse. I can’t describe this as anything other than gaslighting. Highly visible people (many of whom are on standards committees) constantly and incessantly gaslight:
other browser vendors for not implementing their standards (many of which are poorly specified, have known trivially reproducible issues, or are simply considered harmful),
frameworks and framework authors for not being the platform (whatever that means) and for not engaging in the standards process (even though developers of those frameworks don’t have the luxury of working on standards)
regular developers for the same reasons as framework developers.
Sometimes this has become so bad that I know of at least one instance when Ryosuke Niwa (a core developer on WebKit) had to publicly rebuke Domenic Denicola (a spec/standards writer from Chrome) for grossly misrepresenting his words and position.
This has created an atmosphere of mistrust and hostility, and I squarely blame standards committees and browser implementors for that.
And then there’s the whole platform thing and web components.
We’re not just as far from the original vision for Web Components from 12 years ago. We are steadily moving farther and farther away. They are very broken, and too many of the new standards aim to not improve the platform, but to fix the problems that Web Components introduced in the first place. Improving the platform and fixing Web Components are not the same thing. Yes, it’s a mess that has to be cleaned up, but we’ve now been cleaning it up for 12 years, and there’s no end in sight.
There’s literally no end in sight. There’s no coherent vision for what web components are and what they will be presented by anyone. It’s just a patchwork of increasingly more complex standards many of which, once again, exist only because web components introduced a problem where no problem existed before. And many of which are barely above "we don't know what to do with it, let's fix it with more javascript".
So in the end, the combative stance is precisely because standards committees do not want to spend the time and reach out. Standards end up presented as fait accompli with no criticism allowed.
Top comments (0)