If you mean going into a functional paradigm I’d say it’s definitely a matter if taste.
However my biggest gripe is that the ECMAScript board seems intent on being all things to all people. So they half implemented classes. And they added some neat data types. But god for bid you want to override their constructors yet if I make a class I can override my constructors as one would expect in a class based language. Though forcing the new keyword onto classes wasn’t a great paradigm to keep imo. Nor do I like how static methods and properties are treated.
Also decorators are only for classes? Why does that make any sense?
It’s really screwy.
At least going the opposite direction would’ve forced correctness on a baseline.
If they want to be an OOP langsuge with classes the Standards need to embrace it more fully and I see little evidence of that
The reason that's critically concerning for the language and its ecosystem is that since 'vanilla JS' has no opinion, all the libraries created for it tend to have to form their own opinion. This then means that when binding to many ES libraries, you're torn between a hundred flavors of functional, half-baked OO, procedural, or just bit buckets of inconsistency.
If the language can't make up its mind, you're guaranteed to see fragmentation by its users.
The generally thought is that you technically only need them for classes (and really, only for class members and properties). For anything else you can just use a higher order function. Not as pretty, but JS decorator arent about syntax sugar, they're about filling one of the bazillion gaps in the language that opens when you introduce a class keyword.
Of course, the spec for decorator has been thrown away and started over once already (so basically no one using typescript/angular/mobx/whatever with decorators are actually spec compliant these days), and the new spec has been in limbo for years. Decorators aren't part of JS at all right now.