Sebastian Markbåge

As long as we only support attributes. I don't see a problem doing this for the heuristic `if (typeof props[propName] === 'function') element.addEventListener(propName, props[propName], false)`. The only concern would be...

@treshugart Most people seem to find this counter-intuitive but my preference would be to effectively just call `Object.assign(element, props)`. It sounds like you'd be a fan of that approach as...

@nhunzaker Well I think that what is being discussed here would be an alternate strategy. We would not support addEventListener('click', fn). We would instead support element.onclick = fn;

A problem with properties, attributes, events and children is that you have to know which one to use so you end up with heuristics or explicit namespaces. I don't think...

React intentionally went back on that and claims that single event handlers is a better model and the use cases for multiple event listeners is better solved elsewhere since it...

@robdodson Yes, that looks very good to me.

If the only problem is boilerplate, I think that is solvable. Initially in user space in terms of libraries that make it easy to create best-practice custom elements. Later a...

To clarify my conclusion: If @robdodson shows that the proposed "best-practice" above is a feasible direction for the Web Components ecosystem including event listeners as properties. Then React will switch...

There's active work on various ways of approaching this but turns out there are a lot of considerations. For example, how coordination of touch events needs to work for complex...

1) The inlining is important for runtime perf and some parts of the reconciler isn’t used. Perf is at least way less predictable and likely to cause VM deopts due...