I have spent a little over a decade writing, reviewing, and arguing about standards for user interface (UI) code. Some I helped set are still in use. Some were obsolete within a year. For a long time I assumed the difference was how well they were written. I now think it is what kind of thing they tried to standardize.
The ones that last describe boundaries
The standards I have watched survive one framework after another say things like: every interactive element works from the keyboard, and every image has a text alternative. State flows one direction across a component boundary. A shared component has one owning team, and that team reviews every change to it. Nothing reaches into another module's internals. The design system owns color, spacing, and type.
None of them mention a technology. They describe a boundary, an ownership, or an outcome. They were as true for a jQuery codebase as for a React one, and I expect them to be true for whatever comes after React. A new framework changes how you satisfy the standard, not the standard.
That is my test. If I can imagine the standard surviving a complete change of framework, it describes something real about the software. If I cannot, it describes the framework.
The ones that die name a library
The other kind says: use this library, at this version, in this folder layout, with these settings. Format code this way. Use this state management approach and no other.
Many are good decisions when they are made. The trouble is that they are decisions, not standards. They are the current best answer, and the current best answer has a shelf life. The library gets a major version. The folder layout that made sense at ten components makes no sense at four hundred. And now the standard is either ignored, which teaches people that standards are optional, or enforced past its usefulness, which is worse.
Formatting is a special case. I think formatting rules belong in tooling. A formatter enforces the rule for free and nobody argues about it in review. A standards document that specifies indentation is spending its authority on the one thing a machine can already do.
What a standard is for
I have come to believe a standard exists to make a decision once so a team does not have to make it four hundred times. The decisions worth standardizing come up constantly and cost real time to relitigate: how components talk to each other, who owns what, what accessible means here, where the seams are.
The decisions not worth standardizing come up rarely, or a tool can enforce them, or they will be different in two years regardless. Those are better left as recommendations with a date on them.
My rule: a standard should say why
The rule I apply when I write one is that it has to carry its own reason, in a sentence. “Every component must work from the keyboard, because some of our users cannot use a mouse.” “Shared components have one owner, because changes without an owner break three teams at once.”
If I cannot write the reason, I treat the rule as a preference. Preferences are fine. They just should not have the force of a standard, because nobody can tell when a preference has stopped applying, and everybody can tell when a reason has. The reason also lets a future team retire the standard honestly.
Where this stops being true
A small team on a short-lived product does not need most of this. If three people are building something that will be rewritten in a year, the current answer is the only answer that matters.
There is also a size of organization where naming the library is the right call, not as a standard but as a platform decision, so that forty teams do not each pick a different one. A platform choice with a review date is a decision. A sentence that will still be true after the platform changes is a standard. Both are useful. Confusing them is how a standards document ends up ignored.
Photo source: https://photos.robertstowe.com/iguazu-falls