- From: Joseph Pecoraro <joepeck02@gmail.com>
- Date: Thu, 25 Jun 2009 00:34:44 -0400
>> This doesn't break anything in the current spec. So it wouldn't >> break >> any existing implementations. I'm also guessing that the groundwork >> for implementing a feature like this is already in place due to the >> ubiquity of addEventListener. > > To be frank, it seems like a lot of bloat though to avoid a simple > comparison. Its my thinking that the simple comparison shouldn't be necessary to begin with. Thats why I suggested this. This is a probably a bad analogy, but would it make sense to put a "click" function on just the window object and check every time it fires to see if it fired in the <div> you were interested in? Imagine every single "click" listener you register fires every time you click on something... that doesn't scale. (The reason this is a bad is because these "click" events "bubble". Maybe bubbling is appropriate here)? >> - Less Listener Functions Fired - Instead of every registered >> listener >> getting fired on every "storage" event, only those applicable will be >> fired. This may mean overall less listeners getting fired, and code >> that doesn't have to continually check the affected storageArea, >> leading to potential performance improvements. > > Actually, assuming only one of the two solutions would exist the > same amount of events would fire. A change to localStorage causes an > event to be dispatched and likewise a change to sessionStorage > causes an event to be dispatched. Having said that, with your > solutions more events will fire since the legacy event will have to > be dispatched too. What do you mean when you say "more events will fire?" Why not just fire the same "storage" event but now put the if statement that the web developer had to "always write" and put it into the browser's dispatching code. This may be my inexperience with the implementations, but I honestly don't see how this could end up firing more events. I think looking at it this way ("more events") is looking at it sideways and maybe a bit pessimistically. If my first thought is "this is going to be really complex" then my next thought is "how can I simplify this" and if I can't find a way to simplify it I would state why it can't or shouldn't be done. I don't see that here, I just see the "this is really complex" part. I'm guessing that there is a simpler way to look at this, and if not I'd be interested to know why this seems so complex. - Joe
Received on Wednesday, 24 June 2009 21:34:44 UTC