> Decorators are the only way to metaprogram over class fields in JS.

I can think about few other ways, such as using higher order functions/classes, using getOwnPropertyDescriptor or doing stuff at construction.

> As mentioned by skrebbel, decorators are optional

This is not a pro, it's a con. The more ways there are to achieve the same result the more inconsistent projects become IRL.

Also, do you really want to metaprogram at all? What's the huge benefit of that approach?

There really is no way to metaprogram against class fields except with decorators.

Class fields aren't on the prototype. They're essentially Object.defineProperty() calls that occur right after the super() call of a constructor. You can't get at them at all from the class declaration.

I know more than one way to do something is sometimes a downside, but we have a large audience an a huge portion of it wants to use TypeScript and declarators, and another huge portion of it wants to use vanilla JavaScript. We factored things to give the best DX we could to each group with relatively little cost to us.

As for why metaprogramming, we want a component to update when it's state is changed. Like plain web components, Lit uses classes.

So here, we want setting `el.name` to cause the component to re-render:

    class MyElement extends LitElement {

      name = 'World';

      render() {
        return html`<h1>Hello ${this.name}</h1>`
      }
    }

Decorators actually do the replacement for us, we just have to build the thing to replace it with:

    class MyElement extends LitElement {

      @property() accessor name = 'World';

      render() {
        return html`<h1>Hello ${this.name}</h1>`
      }
    }