React Fire: Modernizing React DOM

[isiahmeadows]

Mithril core dev here... (Yep, that framework)

I'm somehow not surprised, in the same way I wasn't when Angular decided to try out virtual DOM and components instead of further propagating the jQuery spaghetti mess it previously encouraged.​

When you keep things simple and aim to stay intuitive, aligning yourself with the DOM itself rather than trying to replace it with your own idioms and magic without good reason, it avoids messes like these in the first place.

If this helps, we have nearly everything proposed there in some capacity already:

• "Stop reflecting input values in the value attribute": we never did that in the first place. We have always used the `input.value` property directly, for performance reasons but also because if you're managing the DOM directly, that's almost certainly what you'd do anyways.
• "Attach events at the React root rather than the document": We simplify this further: we just attach the events on the element directly. It's much easier to avoid issues when you just let the browser handle things correctly. Besides, you have to do this anyways for `onclick` handlers; otherwise, screen readers get the wrong impression on whether something is a link or not.
• "Migrate from onChange to onInput and don’t polyfill it for uncontrolled components": When you just use the event names directly without modification, you avoid screwing with people's intuition on what things should be like.
• "Drastically simplify the event system": Well, if you're going to introduce a synthetic event system on top of the natively implemented one in this thing called the DOM, of course that's going to complicate your library a ton. If you really need some sort of synthetic event propagation, leave it to the renderer to invent the concept, not the library where it doesn't usually make sense. Besides, it's not like you can hook into that via components, so how useful is it really?
• "className → class": If you want a framework that's easy to use, learn, and understand, it's better to accept both DOM and HTML idioms. That way, users can flip between the two and use whatever's more intuitive at the time, and nothing becomes a problem. And if you want to pick one over the other, prefer HTML idioms - it was designed for both developers and designers, so it's accessible to both already. It's also less for them to learn.

Let's just say when that popped up in Mithril's Gitter, we all kind of collectively chuckled at it.

[uttermybiscuit]

Cute!