|
|
|
|
|
|
by ctidd
1882 days ago
|
|
|
I want to respond to this constructively, because you highlighted a useful interface I'd never taken note of previously; maybe we can focus this discussion on a technical level. Meanwhile, if you haven't had a positive response to technical feedback directed to JS engineers about this, I would encourage rereading the comment you wrote. I genuinely hope this is useful feedback, as I very much value insight from other languages and levels of abstraction, and I'd love for you not to get turned off to sharing that insight by a bad response from JS engineers. JavaScript is high level, and it's too easy to get disconnected from all of the work the engine and underlying computer are doing to make a program work in this environment. --- As I understand the interface, practical use of the EventListener interface boils down to the implementer performing a form of event delegation, where you'd wind up delegating from a single `handleEvent()` method on a class to handle different event types and/or events with different target elements -- as opposed to a single click handler in a simple button click example. I'd love to understand and quantify the benefit of this. If it's a significant improvement, it'd be doubly unfortunate, as many callback-based interfaces in JavaScript APIs and libraries at a higher level don't support such a model. Assuming there's a strong benefit, I also wonder if there's an opportunity for build-time tooling to rewrite code from ad-hoc callbacks to more efficient delegation along these lines. Tangentially, I also don't know about `Function.prototype.bind` vs wrapping arrow functions in terms of performance; that's also something I'm curious about, as they're often a 1:1 analog. I'm tempted to test a few of these things out myself, but if you have references, that would be helpful. |
|
|
You're mixing up cause and effect; there's a reason why the perspective laid out in that comment has come to carry the amount of derision evident in its tone. It's wrong to assume things started out like this (and it's wrong to assume that a different tone will achieve better results; experience shows that the difference in results, if any, is worse otherwise).
> Assuming there's a strong benefit, I also wonder if there's an opportunity for build-time tooling to rewrite code[...]
That's another example of "layering on more" approach, and the small matter of changing the actual runtime mechanism in isolation isn't going to solve much. The big, relevant matter at hand is a complete difference in mindset that programmers have when they're approaching a problem with the ultimate intent of solving it with code.
For example, let's say you have a list of items, and M different kinds of events you want to respond to. That's not just a matter of a difference of e.g. 1 listener (implementing `handleEvent`) vs 2 or more (individual arrow functions). If that list is N items long, now we're talking about M × N different objects (worse, closures—each with their own lexical scope, keeping the bindings alive and potentially thwarting the GC's work)[0]. But the programmer who knows not to use arrow functions here doesn't just stop at implementing `handleEvent`, he or she also recognizes that if all of those listeners share common behavior, then the whole thing can be handled by a single event listener—on an ancestor element that just looks at the event target.
Once again, though, this is much bigger than event listeners. This is about a mindset that pervades everything at every level. The mindset of programmers working in "modern", "standard"[1][2] JS is a mindset that fundamentally impacts how they approach everything, from how to decompose a system into its natural parts, to what routines need to be written and what factors to be aware of while implementing them.
Note that unlike the comments elsewhere, this isn't mistakenly misplaced aggression towards JS per se, nor is it an endorsement of other communities/ecosystems like Python, which tends to have programmers that are just as bad, if not worse. A big part of the problems afflicting the world of modern JS for that matter is programmers who have ended up there by way of Python or similar.
0. Runtimes will have some mitigations for this, but eventually that runway ends; the myth of the sufficiently smart compiler although an enduring one, is unattainable
1. https://standardjs.com
2. Let's consider, for that matter, the obnoxious temerity that it takes to decide to anoint one's opinionated, less-than-well-informed set of personal preferences—many of which ironically reek of fighting against the language itself—as "standard"