In search of the perfect JavaScript framework

I would argue that a parent component listening to events on its child is an unnecessary level of indirection. The parent creates the child (or at least it should, in my opinion). The parent should just give the child the callbacks it wants directly.

I've become more or less convinced that over-reliance on events is a big anti-pattern. Combined with mutable state, you get a lot of difficult to track changes in state. Some describe it as COMEFROM-based programming, the dual of the much-maligned GOTO paradigm. The COMEFROMs are your listeners and event triggers are labels they reference. The downfalls of each are pretty much the same: code that becomes increasingly difficult to reason about as it scales, because you have arbitrary global movement in control flow. COMEFROM is even worse because it introduces concurrency. Concurrency + shared mutable state is a recipe for subtle bugs.

So much of the time in a web app, an event only really has one listener. In these cases, a simple callback passed to the child component suffices. But even when you might need to have more than one component react to an event in a child component, I would argue that whatever is responsible for creating the child should still pass a single callback, which might simply be an entry point to dispatch logic on a controller whose only job is to mediate that behavior. Said controller might use or something else as its mechanism.

I don't think people use frameworks and abstractions because they have a smoothier learning curve, or because they are simpler, but because of DRY. After repeating the same pattern twice, the programmer turns it into a module and abstracts it. After having a lot of modules, the programmer packages them all in a framework. This is good for the author of those modules and the framework, because he understand them, but not always for the outsider who just looks at the complete framework and don't know what's inside.

Looks like someone things "dangerous" and "useful" are mutually exclusive. See also electricity, automobiles, consuming food, etc. No one is saying "don't use abstraction ever."

Maybe this metaphor will help:

"Using other people’s code is like surfing. You control and surrender. You’ve got to trust the wave to carry you, but stop paying attention, and the first abstraction leak will throw you under the water."

https://medium.com/@dan_abramov/youre-missing-the-point-of-r...

Sure, you could say "bad abstractions are bad." And it's true there's a spectrum. Some are much less leaky than others, of course, some have the boundaries of what they do and their interface outside more elegantly shaped than others. But saying "well, we just don't want bad abstractions" doesn't capture well the fact that all abstractions either leak to some degree or are awkward coverings for some problem domains.

Nor does it really get us where we want to go in terms of "exactly what abstractions we want." We want useful ones. We want minimally dangerous ones. And the way you get the latter is to understand how abstractions are dangerous.