6 ms·

Excellent point! I can see that getting confusing quickly. Edit: I was confused about how this could work, so I dug through [1] for a bit. It appears that for

by genrez 5y ago

Excellent point! I can see that getting confusing quickly. Edit: I was confused about how this could work, so I dug through [1] for a bit. It appears that for each object of that class created, an arrow function will be created on that object and its this will indeed be bound to the same scope that the constructor function is bound to. This is really cleaver and I applaud whoever thought it up! It is interesting to note that this creates a new arrow function on each object as opposed to the normal definitions which create a single function which is stored in the prototype of the class. (its easier to check this in a browser's dev console then it is to decode the spec) This would suggest that one should use different approaches for different types of objects: It makes sense to use arrow functions for "resource" or "actor" objects, of which there are few but they may have callback functions. It makes sense to use normal method definitions for "plain old data", of which there may be many, (which would make the arrow functions too expensive) but they should not have callback functions. [1] https://tc39.es/proposal-class-fields/unified.html https://tc39.es/proposal-class-fields/unified.html

pwdisswordfish0 5y ago
> This is really cleaver and I applaud whoever thought it up! Not really. It's contortionist and wasteful and one of the many reasons why mainstream web apps are one big celebration of bloat on a boat. The neophyte programmers who have turned into expert Modern JS programmers are always recommending arrow functions like this because they've never actually looked at the event listener interface. What happens is they try to make things more complicated than they need to be and bodge their event registration. So they apply a "fix" by doing what they do with everything else: layering on even more. "What we need," they say, "are arrow functions." No. Go the other way. Approach it more sensibly. You'll end up with a fix that is shorter than the answer that the cargo cult NPM/GitHub/Twitter programmers give. It's familiar to anyone coming from a world with interfaces as a language-level construct and therefore knows to go look at the interface definition of the interface that you're trying to implement. Make your line for registering an event listener look like this: `this.button.addEventListener("click", this)`, and change the name of your `addSum` method to `handleEvent`. (Read it aloud. The object that we're dealing with (`this`) is something that we need to be able to respond to clicks, so we have it listen for them. Gee, what a concept.) In other words, the real fix is to make sure that the thing we're passing in to `addEventListener` is... actually an event listener. This goes over 90% of frontend developers' heads (and even showing them this leads to them crying foul in some way; I've seen them try to BS their way through the embarrassment before) because most of the codebases they learned from were written by other people who, like themselves, only barely knew what they were doing. Get enough people taking this monkey-see-monkey-do approach, and from there you get "idioms" and "best practices" (no matter whether they were even "good" in the first place, let alone best).
- genrez 5y ago
  I'm learning all sorts of things today! handleEvent certainly seems like the language certified way to do this. It does seem like that means you need a case statement in handleEvent if you want to listen for multiple events, which I guess is not the end of the world. It does solve the "redefine the function for every object" problem though, provided any third party apis understand the EventListener interface.
  - pwdisswordfish0 5y ago
    > handleEvent certainly seems like the language certified way to do this It's a platform API (the browser DOM). It's a completely separate matter from JS the language. It has, though, been the "correct" way to work with events since at least as far back as 1998 or so. It's the official platform APIs that had to change to accommodate the function-as-a-listener pattern (requiring an entire revision to the interface definition language itself so that it would have the power to express it), since so many browsers implemented that non-standard extension, and so many programmers insisted on using it. And that pattern is also directly responsible for why arrow functions and Function.prototype.bind were added to the language itself. If only it had been addressed differently, writing programs for the web browser might look a lot different than the way it does today.
- ctidd 5y 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.

by genrez 5y ago

pwdisswordfish0 5y ago

> This is really cleaver and I applaud whoever thought it up! Not really. It's contortionist and wasteful and one of the many reasons why mainstream web apps are one big celebration of bloat on a boat. The neophyte programmers who have turned into expert Modern JS programmers are always recommending arrow functions like this because they've never actually looked at the event listener interface. What happens is they try to make things more complicated than they need to be and bodge their event registration. So they apply a "fix" by doing what they do with everything else: layering on even more. "What we need," they say, "are arrow functions." No. Go the other way. Approach it more sensibly. You'll end up with a fix that is shorter than the answer that the cargo cult NPM/GitHub/Twitter programmers give. It's familiar to anyone coming from a world with interfaces as a language-level construct and therefore knows to go look at the interface definition of the interface that you're trying to implement. Make your line for registering an event listener look like this: `this.button.addEventListener("click", this)`, and change the name of your `addSum` method to `handleEvent`. (Read it aloud. The object that we're dealing with (`this`) is something that we need to be able to respond to clicks, so we have it listen for them. Gee, what a concept.) In other words, the real fix is to make sure that the thing we're passing in to `addEventListener` is... actually an event listener. This goes over 90% of frontend developers' heads (and even showing them this leads to them crying foul in some way; I've seen them try to BS their way through the embarrassment before) because most of the codebases they learned from were written by other people who, like themselves, only barely knew what they were doing. Get enough people taking this monkey-see-monkey-do approach, and from there you get "idioms" and "best practices" (no matter whether they were even "good" in the first place, let alone best).

genrez 5y ago
I'm learning all sorts of things today! handleEvent certainly seems like the language certified way to do this. It does seem like that means you need a case statement in handleEvent if you want to listen for multiple events, which I guess is not the end of the world. It does solve the "redefine the function for every object" problem though, provided any third party apis understand the EventListener interface.
- pwdisswordfish0 5y ago
  > handleEvent certainly seems like the language certified way to do this It's a platform API (the browser DOM). It's a completely separate matter from JS the language. It has, though, been the "correct" way to work with events since at least as far back as 1998 or so. It's the official platform APIs that had to change to accommodate the function-as-a-listener pattern (requiring an entire revision to the interface definition language itself so that it would have the power to express it), since so many browsers implemented that non-standard extension, and so many programmers insisted on using it. And that pattern is also directly responsible for why arrow functions and Function.prototype.bind were added to the language itself. If only it had been addressed differently, writing programs for the web browser might look a lot different than the way it does today.
ctidd 5y 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.