The @init: feature is not good for developer experience.

[trusktr]

The @init: feature means that end users of a decorator must be concerned with a decorator's implementation so that they will know whether or not such decorator needs to be called with or without @init:. This is not an ideal developer experience.

Ideally, one would simply apply a decorator and that's all.

It would be great for DX if it is a decorator itself that determines whether it is an init decorator or not. This can be done based on the return value of the decorator, or based on APIs that the decorator calls on the passed-in arguments.

Is there something I don't know about @init being statically analyzable that improves performance? I ask because it seems that static analysis and performance was the whole reason the previous spec was rejected.

// user imports an init decorator:
import decorator from 'some-lib'

class Foo {
  // User forgets to prepend "init:" to the decorator name.
  @decorator
  member() {}
}

^ That's not ideal.

[trusktr]

My current custom elements look like this:

@element('my-element')
class Example extends HTMLElement {
  // ...
}

Having to replace them all to

@init:element('my-element')
class Example extends HTMLElement {
  // ...
}

is not ideal, and looks quite ugly; it doesn't read as clean as the former.

Is there some performance benefit of @init: that outweighs the developer hassle?

[ljharb]

Implementations will not accept any form of the decorators feature unless users endure this DX friction, so there’s really nothing much to discuss, unfortunately.

[trusktr]

Closing this one, as I forgot about #380, and can re-join that thread instead. I have too many projects happening at once!