Non Standard Practices vs Web Standards
Off-spec hacks versus building on the open web platform. One scales, one rots. Eunice picks the boring winner.
The short answer
Web Standards over Non Standard Practices for most cases. Standards outlive your framework, your job, and your cleverness.
- Pick Non Standard Practices if prototyping something disposable, targeting a single controlled runtime, or the standard genuinely doesn't exist yet and shipping this week beats shipping correctly
- Pick Web Standards if want code that survives browser updates, onboards new developers without tribal knowledge, and degrades gracefully across the unknown clients of the open web. Which is to say: almost always
- Also consider: Standards are slower to adopt and occasionally lag real-world needs. The honest move is to use the standard and polyfill the gap — not to invent a parallel universe and call it pragmatism.
— Nice Pick, opinionated tool recommendations
What we're actually comparing
This isn't two products on a shelf — it's a discipline versus the absence of one. Web Standards means building on the specs ratified by the W3C, WHATWG, and TC39: semantic HTML, the DOM, fetch, ARIA, the platform APIs every browser is contractually marching toward. Non-Standard Practices is the catch-all for everything off that path: framework-specific magic that only renders in one runtime, custom attributes nobody else reads, div soup wearing onclick handlers, vendor-prefixed dead ends, and 'it works on my machine' shipped to production. People reach for non-standard because the standard felt verbose or arrived late. Fine. But understand the trade you're making: you are betting that your private convention will be cheaper to maintain than the one a thousand engineers across five browser vendors agreed to support indefinitely. That bet almost never pays. The standard is the boring road, and the boring road is paved.
Where Non-Standard Practices actually win
Credit where it's due — non-standard isn't always stupidity, it's sometimes a year early. Every standard that exists today was a non-standard hack first: XMLHttpRequest was a Microsoft oddity before fetch was a gleam in anyone's eye; flexbox-style layouts were table abuse and float hacks for a decade. If the spec doesn't cover your case yet, going off-road is the only road. Non-standard also wins on raw velocity in a closed environment: an internal tool that only ever runs in one Chromium build you control can lean on bleeding-edge or proprietary behavior and ship faster without the ceremony of graceful degradation. The danger is forgetting it was a hack. Non-standard practice earns its keep when it's deliberate, documented, and fenced — a known shortcut with an exit plan. It becomes a liability the moment someone mistakes it for the architecture and builds three more floors on top.
Why Web Standards wins the decade
Standards win because they're the only thing that compounds instead of decays. Write semantic HTML and accessibility, SEO, and keyboard navigation come mostly free — the platform does the work your custom widget would force you to reimplement, badly, forever. Standards are a hiring multiplier: a new engineer who knows the DOM is productive on day one, while your bespoke abstraction needs a tribal-knowledge onboarding doc that's already stale. They're forward-compatible by design — browsers move heaven and earth to not break the spec, which is exactly the promise your non-standard hack can't make past the next Chrome release. And they're portable: standard code runs on the phone, the screen reader, the watch, and the client you haven't heard of yet. The cost is real — standards are wordier and sometimes trail the cutting edge by a year or two. But verbosity you can read beats cleverness you can't maintain. Boring scales.
The verdict, plainly
Web Standards. Not close. The entire history of the web platform is non-standard hacks getting absorbed into standards and then dying as their own dialects — the spec is where good ideas go to become permanent, and off-spec is where they go to become technical debt with a shelf life. Default to the standard. Use semantic markup, the real platform APIs, progressive enhancement, and feature detection over assumption. When the standard genuinely doesn't cover you, go non-standard — but do it on purpose, polyfill toward the spec, and write down why so the next person can delete your hack when the platform catches up. The failure mode isn't using a non-standard practice once; it's letting 'just this once' calcify into your house style until the whole codebase only runs in one browser on one good day. Pick the road that's still there in five years. t. NicePick
Quick Comparison
| Factor | Non Standard Practices | Web Standards |
|---|---|---|
| Longevity / forward-compat | Breaks on the next runtime update; tied to one vendor's whims | Browsers fight to never break the spec — code survives for years |
| Time-to-ship (closed env) | Faster — skip ceremony, lean on proprietary behavior | Wordier, occasionally lags real-world needs by a year |
| Onboarding / hireability | Needs a tribal-knowledge doc that's already stale | Anyone who knows the DOM is productive day one |
| Free platform wins (a11y/SEO/keyboard) | Reimplement it all yourself, usually worse | Semantic HTML gets it mostly for free |
| Portability across clients | Works on the one client you tested; unknown elsewhere | Runs on phone, screen reader, watch, future clients |
The Verdict
Use Non Standard Practices if: You're prototyping something disposable, targeting a single controlled runtime, or the standard genuinely doesn't exist yet and shipping this week beats shipping correctly.
Use Web Standards if: You want code that survives browser updates, onboards new developers without tribal knowledge, and degrades gracefully across the unknown clients of the open web. Which is to say: almost always.
Consider: Standards are slower to adopt and occasionally lag real-world needs. The honest move is to use the standard and polyfill the gap — not to invent a parallel universe and call it pragmatism.
Non Standard Practices vs Web Standards: FAQ
Is Non Standard Practices or Web Standards better?
Web Standards is the Nice Pick. Standards outlive your framework, your job, and your cleverness. Non-standard practices win the sprint and lose the decade — every off-spec shortcut is a debt your future maintainers pay with interest.
When should you use Non Standard Practices?
You're prototyping something disposable, targeting a single controlled runtime, or the standard genuinely doesn't exist yet and shipping this week beats shipping correctly.
When should you use Web Standards?
You want code that survives browser updates, onboards new developers without tribal knowledge, and degrades gracefully across the unknown clients of the open web. Which is to say: almost always.
What's the main difference between Non Standard Practices and Web Standards?
Off-spec hacks versus building on the open web platform. One scales, one rots. Eunice picks the boring winner.
How do Non Standard Practices and Web Standards compare on longevity / forward-compat?
Non Standard Practices: Breaks on the next runtime update; tied to one vendor's whims. Web Standards: Browsers fight to never break the spec — code survives for years. Web Standards wins here.
Are there alternatives to consider beyond Non Standard Practices and Web Standards?
Standards are slower to adopt and occasionally lag real-world needs. The honest move is to use the standard and polyfill the gap — not to invent a parallel universe and call it pragmatism.
Standards outlive your framework, your job, and your cleverness. Non-standard practices win the sprint and lose the decade — every off-spec shortcut is a debt your future maintainers pay with interest.
Related Comparisons
Disagree? nice@nicepick.dev