3 ms·

Historically, this example is the reason why the Web evolved into jQuery and from there forked into the world of Angular and React mainly. Event handling is ge

Historically, this example is the reason why the Web evolved into jQuery and from there forked into the world of Angular and React mainly. Event handling is getting messy very easily. If you want to get deeper into it, have a look at event bubbling and propagation. Large applications need a robust event handling. This is the nowadays hidden benefit of frameworks like Angular, Vue etc. Believe me, you don’t want to use the standard event handling API without a framework. Adding, deleting, cloning, firing, removing, fire once etc on many elements can have serious unwanted side effects.

beezlewax 3y ago
What kind of side effects specifically?
- doomroot 3y ago
  I believe memory leaks to start
  - falcor84 3y ago
    Are you implying that there are memory leaks in browsers' internal implementation of events? Because my take is that the problem is with "user space" scripts not cleaning up after themselves, and I don't see how that would get better by adding yet another API to be mindful of.
    - gibbitz 3y ago
      I believe this would be more related to something like memoizing a DOM structure in a "Live" listener that is later removed from the DOM but not garbage collected due to the reference in the event listener. As the poster mentioned, developer error -- not a fundamental language or browser implementation flaw.
      - naasking 3y ago
        If a language or browser implementation can't reclaim this unused memory thus creating a memory leak, that arguably is a flaw. It's literally a DoS attack vector that can be exploited by the untrusted scripts that run in the browser sandbox.
  - Klonoar 3y ago
    This is one of those points where you need to link to some kind of data or conclusive result actually showcasing this, because you're arguing against a pattern that's been in browser ecosystems for decades. I've done this for larger applications and haven't experienced issues. Being charitable, the best I can imagine right now that'd cause memory leaks is someone running into the old school JS scoping issues and capturing something in handlers that they shouldn't. That's not the handler itself that's the problem, though - that's the developer. (Yes, we could rant on and on about the poor design decisions that JS has built in, but that's been beaten to death)
  - unemployable 3y ago
    Memory leaks can occur when a component adds events to an element outside of the component (such as the window) and then gets removed from the DOM without removing the event handler from the window. This is solved in native Web Components by the mount/unmount methods where you can run code to remove event listeners when the component has been unmounted. For other event listeners, they get removed when the DOM element is removed. The frameworks do not solve this to any greater degree. They also just make everything invisible and behind-the-scenes and hard to debug due to their declarative nature, but that is another topic.
    - pcthrowaway 3y ago
      Removing event listeners upon some component being removed actually sounds like a great use case for the new FinalizationRegistry API[1] [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - ngc6677 3y ago
      Example with web components in all frameworks https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/ https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co... and an other version to experiment with https://jsbin.com/yiviragiba/8/edit?html,css,js,console,output https://jsbin.com/yiviragiba/8/edit?html,css,js,console,outp...
andrewstuart 3y ago
I use events extensively in large applications and its never been a problem. In fact they solve complexity.
unemployable 3y ago
>If you want to get deeper into it, have a look at event bubbling and propagation. In this example, the event is on the Window. There is no bubbling. It is already at the top level. >Believe me, you don’t want to use the standard event handling API without a framework. Adding, deleting, cloning, firing, removing, fire once etc on many elements can have serious unwanted side effects. I don't know what this means. The frameworks do not have much to do with this topic.
- pquki4 3y ago
  I think the previous comment discusses events in a general sense. Frameworks batch changes so that updates are efficient, and in many cases figures out the "correct" order of doing things. If you do all of those yourself in a large and complex UI, very likely you are updating the DOM less efficiently than what frameworks are doing, and very likely you introduced some subtle bugs. Speaking of that from my first-hand experience.

beezlewax 3y ago

What kind of side effects specifically?

doomroot 3y ago
I believe memory leaks to start
- falcor84 3y ago
  Are you implying that there are memory leaks in browsers' internal implementation of events? Because my take is that the problem is with "user space" scripts not cleaning up after themselves, and I don't see how that would get better by adding yet another API to be mindful of.
  - gibbitz 3y ago
    I believe this would be more related to something like memoizing a DOM structure in a "Live" listener that is later removed from the DOM but not garbage collected due to the reference in the event listener. As the poster mentioned, developer error -- not a fundamental language or browser implementation flaw.
    - naasking 3y ago
      If a language or browser implementation can't reclaim this unused memory thus creating a memory leak, that arguably is a flaw. It's literally a DoS attack vector that can be exploited by the untrusted scripts that run in the browser sandbox.
- Klonoar 3y ago
  This is one of those points where you need to link to some kind of data or conclusive result actually showcasing this, because you're arguing against a pattern that's been in browser ecosystems for decades. I've done this for larger applications and haven't experienced issues. Being charitable, the best I can imagine right now that'd cause memory leaks is someone running into the old school JS scoping issues and capturing something in handlers that they shouldn't. That's not the handler itself that's the problem, though - that's the developer. (Yes, we could rant on and on about the poor design decisions that JS has built in, but that's been beaten to death)
- unemployable 3y ago
  Memory leaks can occur when a component adds events to an element outside of the component (such as the window) and then gets removed from the DOM without removing the event handler from the window. This is solved in native Web Components by the mount/unmount methods where you can run code to remove event listeners when the component has been unmounted. For other event listeners, they get removed when the DOM element is removed. The frameworks do not solve this to any greater degree. They also just make everything invisible and behind-the-scenes and hard to debug due to their declarative nature, but that is another topic.
  - pcthrowaway 3y ago
    Removing event listeners upon some component being removed actually sounds like a great use case for the new FinalizationRegistry API[1] [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - ngc6677 3y ago
    Example with web components in all frameworks https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/ https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co... and an other version to experiment with https://jsbin.com/yiviragiba/8/edit?html,css,js,console,output https://jsbin.com/yiviragiba/8/edit?html,css,js,console,outp...

andrewstuart 3y ago

I use events extensively in large applications and its never been a problem. In fact they solve complexity.

unemployable 3y ago

>If you want to get deeper into it, have a look at event bubbling and propagation. In this example, the event is on the Window. There is no bubbling. It is already at the top level. >Believe me, you don’t want to use the standard event handling API without a framework. Adding, deleting, cloning, firing, removing, fire once etc on many elements can have serious unwanted side effects. I don't know what this means. The frameworks do not have much to do with this topic.

pquki4 3y ago
I think the previous comment discusses events in a general sense. Frameworks batch changes so that updates are efficient, and in many cases figures out the "correct" order of doing things. If you do all of those yourself in a large and complex UI, very likely you are updating the DOM less efficiently than what frameworks are doing, and very likely you introduced some subtle bugs. Speaking of that from my first-hand experience.