Is there some low level checking by the js engine to see if it should stop processing the function if there is no return?
Or, to put it another way, does adding the return explicitly tell the engine, "ok we're done here", as opposed to a small amount of processing required by the engine to determine that for itself?
Always return on events is faster, but why?
21–30 of 52 posts
Re: Always return on events is faster, but why?
#22Re: Always return on events is faster, but why?
#23Doesn'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:
Re: Always return on events is faster, but why?
#24Revision 22 revealed that something went terribly wrong...
Re: Always return on events is faster, but why?
#25Revision 3 revealed that it's not the `return` that made the difference -- it's the jsperf runner failing to introduce sufficient time gap between testsuites for it to "settle down"...
eulerphi: FYI you're hellbanned
Re: Always return on events is faster, but why?
#26Revision 3 revealed that it's not the `return` that made the difference -- it's the jsperf runner failing to introduce sufficient time gap between testsuites for it to "settle down"...
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.
Re: Always return on events is faster, but why?
#27Maybe because "some_el_2" is lower down in the DOM tree? I think at least the experiment should be run with reversed IDs.
Re: Always return on events is faster, but why?
#28In fact it's not really faster, if you run the test several times the results are similar.
It's the same thing if you compare the selectors $(this) and $((((this))));
I don't know why, but the problem must come from jsperf. Thats why when I use this tool I always run it at least 5 times to be sure.
Re: Always return on events is faster, but why?
#29Earlier 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.
Not sure what previous action caused him to get hell banned but his comment was trying to contribute something to this thread. Think it would be nice to know if I was banned and still trying to contribute.
Re: Always return on events is faster, but why?
#30Earlier 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.
Sure, that's the idea. The comment looks totally legit and relevant, though.
Looks like their last comment sucked, and it's easier for a mod to ban someone than to reply, “that comment sucked” and hope they get better. Mods are never perfect, they have a big job, and people can (successfully) appeal hellbans.