It’s February 2026, and I think I’m finally ready to forgive the TC39 committee.
If you’ve been writing TypeScript as long as I have, you remember the “experimental” phase. It lasted forever. We spent nearly a decade with "experimentalDecorators": true in our tsconfig.json, building entire frameworks (looking at you, NestJS and early Angular) on a feature that was technically a draft. But here we are. The standard decorators have landed. They work in TypeScript 5.x (and the 6.0 beta looks solid). Browsers are catching up. And yet, I still see developers treating them like black magic.
They aren’t magic. They’re just functions. Sometimes very annoying functions, but functions nonetheless.
At its core, a decorator is a design pattern where you wrap a piece of code with another piece of code to extend its behavior. That’s it. You don’t need the @ symbol to do this concept in JavaScript. As described in the TypeScript documentation on decorators, they allow you to add annotations and a meta-programming syntax for class declarations and members.
I mostly use decorators today for “meta” logic—stuff that isn’t the core business logic but needs to happen anyway. Error handling, logging, performance tracking.
In a recent project running on Node 22, I got tired of wrapping every single API handler in a try/catch block. It made the actual logic hard to read. So, I used a standard Stage 3 decorator, as described in the TC39 decorators proposal.
But here’s the rub: Standard decorators operate on the definition of the class elements. Let’s say we want a @Reactive decorator that updates a DOM element whenever a property changes. In TypeScript, it looks clean. However, browsers are strict environments. If you strip away the TypeScript build step (say, you’re just shipping a vanilla JS bundle for a lightweight widget), you can’t use that syntax yet without a polyfill or very recent runtime support.
Another area where standard decorators have matured is dependency injection. In the old “experimental” days, we had to hack the prototype. The new context.addInitializer API allows us to hook into the class setup phase cleanly.
Just because we have standard decorators now doesn’t mean you should sprinkle them everywhere. My rule of thumb today? Use decorators for infrastructure concerns (logging, frameworks, DOM binding). Do NOT use them for business logic. If a junior dev needs to read the decorator source code to understand what the calculateTax() method does, you’ve failed.
The ecosystem is finally stable. TypeScript 5.7 handles this beautifully, and the tooling—ESLint, Prettier, VS Code—finally understands the new syntax without complaining. It took us a long time to get here, but the wait was arguably worth it.
