[whyonearth]

Feedback:

1. Parser prohibits literal "@click", there is no escape mechanism.

2. Only click, what about other DOM events?

3. Leaking: Event listeners not removed in destructor (your clean() function?)

4. No XSS protection, ow.

5. No tests, might want some.

6. Based on innerHTML assignment with nothing to guarantee valid HTML.

7. No error handling.

[orizens]

1. '@click' is replaced with a valid 'data-af-click' attribubte.

2. click was a poc - all events are added.

3. 'clean' is using "node.remove" ad removes any references to functions - so - no detached references are left then.

4. correct - not taken into consideration at the moment.

5. agree.

6. innerHTML is a valid assignment - the browser validates it.

7. to be discussed

[whyonearth]

I think you're being somewhat defensive of what appears to be a prototype, just offering the feedback you requested.

1. What I mean is that <span>@code</span> becomes <span>data-af-click</span>.

2. Where? Not seeing them.

3. You're mistaken about event handler cleanup: https://dom.spec.whatwg.org/#dom-childnode-remove

6. My point here is that relying on strings is brittle. HTML builders, declarative APIs like JSX/React.createElement, and template-based approaches (where the template is a DOM node) are more robust.

[BrandoElFollito]

This is probably obvious, but just in case : for point 4 this is DOM-based XSS protection that is missing.

[orizens]

added a more robust and better event listeners handling - which prevent leaking completely.