Maybe because "some_el_2" is lower down in the DOM tree? I think at least the experiment should be run with reversed IDs.
It shouldn't matter because if you swap the execution order, the 'no return' can be faster too in that test.
Always return on events is faster, but why?
31–40 of 52 posts
Re: Always return on events is faster, but why?
#32Earlier quoted context omitted.
eulerphi: FYI you're hellbanned
Isn't the idea of hellbanning that people don't realize they are? Kinda defeats the purpose if you notify them of it. If HN wanted people to know they've been silenced, they would be given an error message. So, don't tell people. It's also spamming the comment with offtopic remarks.
Using hellbans when you should be using normal bans or even temporary bans is a horrible system.
Most people that are hellbanned on HN have not at all deserved it. Ignoring spambots, I've seen perhaps two users that got a hellban for consistently problematic posts rather than a single post annoying someone. And one of those has actual mental issues.
Re: Always return on events is faster, but why?
#33Doesn't a return without argument return false and thus have the same effect as preventDefault()? That would explain the difference, since the events are not "bubbling up".
As many pointed out, I was wrong. An empty return doesn't equal a false return. Neither does jQuery interpret a return of undefined as a stopPropagation, as this fiddle shows: http://jsfiddle.net/6UGN8/
Have you been explicitly returning true all this time?
Re: Always return on events is faster, but why?
#34I posted it on the page as well: Doesn't just calling return from an event equate to returning boolean false, which means you are invoking the effects of preventDefault() and stopImmediatePropagation() thus explaining why with return it's faster as the event stops bubbling immediately?
FWIW, the underlying jQuery code explicitly tests for false with ===:
https://github.com/jquery/jquery/blob/a5037cb9e3851b171b49f6...
So returning undefined does NOT stop propagation.
Re: Always return on events is faster, but why?
#35Answer is simple: you are adding more and more listeners as jsPerf runs your test case.
One of the most important things to remember while using jsPerf is that setup phase can and will be executed multiple times. As the result the list of listeners attached to the DOM node is growing and this in turn slows down the event dispatch.
"No return" case is run second so the list of listeners is already large and thus it is slower than "return case".
You should either unregister listeners in tear down phase or register them only once at global initialization time. Here is the fixed variant:
http://jsperf.com/always-return-on-jquery-events/28
[also from the JavaScript VM point of view function () { } and function () { return; } are completely the same]
Re: Always return on events is faster, but why?
#36Earlier quoted context omitted.
eulerphi: FYI you're hellbanned
Isn't the idea of hellbanning that people don't realize they are? Kinda defeats the purpose if you notify them of it. If HN wanted people to know they've been silenced, they would be given an error message. So, don't tell people. It's also spamming the comment with offtopic remarks.
Maybe, but it's pretty obvious when it happens. And of course if that weren't enough, every time you post people tell you that you're hellbanned.
Re: Always return on events is faster, but why?
#37Earlier quoted context omitted.
eulerphi: FYI you're hellbanned
Isn't the idea of hellbanning that people don't realize they are? Kinda defeats the purpose if you notify them of it. If HN wanted people to know they've been silenced, they would be given an error message. So, don't tell people. It's also spamming the comment with offtopic remarks.
I browse with showdead on because frankly, apart from the occasional commentspam, pretty much none of the comments I see from hellbanned users are from users who persistently make comments that would seem to justify a ban of any kind. Most of them appear to just have made a single stupid comment at some point or other that perhaps deserved some downvoting. It seems to me that hellbans are overused.
And the answer to it being overused is for people to call it out whenever a user is trying to contribute but hellbanned, and we don't agree with the ban after taking a look at their comment history.
Re: Always return on events is faster, but why?
#38Answer is simple: you are adding more and more listeners as jsPerf runs your test case. One of the most important things to remember while using jsPerf is that setup phase can and will be executed multiple times. As the result the list of listeners attached to the DOM node is growing and this in turn slows down the event dispatch. "No return" case is run second so the list of listeners is already large and thus it is…
Also another mistake here is the classical "if you want to measure x, don't measure y".
If the OP wanted to measure function with or without return , even without realizing how futile that is, they still should not include things like jQuery.
Re: Always return on events is faster, but why?
#39Earlier quoted context omitted.
return without return false is just like breaking out of a method i think.. The events would still bubble since false isn't returned
An empty return statement has the return value undefined which is falsy. As lukashed said jQuery most likely interprets this as false and stop propagation of the event, however using an empty function also has the return value undefined so both cases stops propagation. Both versions have the same return value as illustrated by this fiddle http://jsfiddle.net/QHxJ3/
Interesting, I would have never thought the js interpreter would interpret both as being === even though the two functions are different.
Re: Always return on events is faster, but why?
#40Earlier quoted context omitted.
eulerphi: FYI you're hellbanned
Isn't the idea of hellbanning that people don't realize they are? Kinda defeats the purpose if you notify them of it. If HN wanted people to know they've been silenced, they would be given an error message. So, don't tell people. It's also spamming the comment with offtopic remarks.
Can't really recall a single hell ban I agree with. So the fact that everyone tries to warn the posters who have been banned kind of shows it is being misused. I would prefer it only be used on spammers and intention trolls/personal attacks. On HN it gets used far more, however. So I agree with everyone who warns people, basically.