-5

What is more efficient between these two sets, and why. Thanks :)

<button data-target="1" class="target-buttons'>Target</button> 
$(document).on('click', '.target-buttons', function() {
    alert($(this).data('target'));
});

<button onclick="alertTarget('1')" class="target-buttons">Target</button>
function alertTarget(value) {
    alert(value);
}

Thanks very much!

wuzz
  • 364
  • 3
  • 10
  • 3
    It was downvoted (most likely) because this isn't a review site and you're not really asking anything. – jdmdevdotnet Mar 06 '18 at 19:11
  • `$(document).on('click', '.target-buttons', function(){});` will bind every click event in the `document` here and then check if the click was on `'.target-buttons'` or not. This is not very efficient. This needs to be used only if you are dealing with dynamic elements with the selector `'.target-buttons'`. – rrk Mar 06 '18 at 19:11
  • 1
    This question belongs at: https://codereview.stackexchange.com/ – Scott Marcus Mar 06 '18 at 19:12
  • Also `onclick="alertTarget('1')"` this is not preferred as well because this increases the html size and wont be pretty to look at the code. It is better to define a function and bind the event every time you create an element of the type `'.target-buttons'`. – rrk Mar 06 '18 at 19:14
  • 3
    Define "efficient" – j08691 Mar 06 '18 at 19:14
  • 1
    @ScottMarcus This question would likely be downvoted or off-topic on Code Review as well. See [A guide to Code Review for Stack Overflow users](https://meta.codereview.stackexchange.com/q/5777). – 200_success Mar 06 '18 at 19:16

2 Answers2

1
<button onclick="alertTarget('1')" class="target-buttons">Target</button>
function alertTarget(value) {
    alert(value);
}

Would be more efficient since it's more re-usable than the former. With this, you don't have to set up a bunch of click events and it's streamlined via html. Technically you do have to set up the click event, but it's more obvious than the former IMO.

jdmdevdotnet
  • 1
  • 2
  • 19
  • 50
  • This is sarcasm. Or not o_O ? – Jonas Wilms Mar 06 '18 at 19:19
  • @JonasW.: I don't know if he's being sarcastic, and the description isn't great, but the inline handler is clearly more efficient than the alternative given. –  Mar 06 '18 at 19:24
  • 1
    @doidle meister please prove that ... – Jonas Wilms Mar 06 '18 at 19:25
  • @JonasW.: If you understand what's happening with the jQuery version, then the difference is self evident. –  Mar 06 '18 at 19:27
  • Nope not sarcasm, not even sure how you came to that? Do you usually ask if something is sarcasm on an opinion based answer you disagree with? – jdmdevdotnet Mar 06 '18 at 19:28
  • No but because i doubt every statement of you. Thats why i commented to understand your reasoning. – Jonas Wilms Mar 06 '18 at 19:31
  • @doodle meister seems like you know more than i do. – Jonas Wilms Mar 06 '18 at 19:32
  • Wow my day is ruined some random guy on the internet "doubts every statement of me" (whatever thats supposed to mean) – jdmdevdotnet Mar 06 '18 at 19:32
  • I just wanna have some evidence based discussion. `Would be more efficient since it's more re-usable than the former.` if you mean the use of a non anonymous function? Well then yes its certainly more reusable but that depends on the actual usecase if its better. `With this, you don't have to set up a bunch of click events and it's streamlined via html.` i just see one event listener in the other snippet. – Jonas Wilms Mar 06 '18 at 19:35
  • 1
    @JonasW.: If the inherent overhead in selector-based event delegation on the `document` alone doesn't scream inefficiency to you, especially as compared to a direct function call, then you probably shouldn't be treating such questions with the kind of flippancy you've shown here. –  Mar 06 '18 at 19:36
  • Right and you'd have to set up click events on any page you have. This way is more streamlined because it's fairly obvious to other developers how to init what he's trying to do. And "evidence"? This is opinion based. Chill out. – jdmdevdotnet Mar 06 '18 at 19:37
  • @doodle meister fair enough. But im not sure if thats really measurable ... – Jonas Wilms Mar 06 '18 at 19:41
  • @JonasW.: It would be difficult to measure in a sense, because the inline version would only need to measure a single function call when it takes place. The jQuery version would need to measure the accumulation of every click on the document, and not just the handler call, but the jQuery code running its selector engine against every element from `event.target` to `document` just to check if each element has that class. Yet even just measuring a single click, there will be a substantial difference. –  Mar 06 '18 at 19:53
1

Efficiently doesn't particularly matter in this case I don't think.

In general you don't want to mix HTML with JavaScript so the former would be best.

Cisco
  • 20,972
  • 5
  • 38
  • 60
  • Exactly. Another good reference: https://en.m.wikipedia.org/wiki/Program_optimization ( especially the Knuth quote) – Jonas Wilms Mar 06 '18 at 19:24
  • @JonasW.: It's important to understand that Knuth quote, not as advice against optimization (especially in light of the second half of the quote), but rather to not too eagerly compromise the understandability and maintianibility of the code. Doing `data-target='1'` is nearly identical to `alertTarget('1')`. –  Mar 06 '18 at 19:47
  • @Francisco: There's nearly always some mixing. Clearly the `data-target='1'` is meant for the JS code no less than the function call. There was a time many years ago where people used to mix long lines of JS in their HTML. *That* was the basis of arguments against embedding like that. It doesn't disqualify *all* JS code, especially with so much of todays HTML being machine generated. –  Mar 06 '18 at 19:49
  • @doodle meister _premature optimizations_ means that the code isnt mature yet. And three lines are definetly not. – Jonas Wilms Mar 06 '18 at 20:04
  • @JonasW.: Nobody should be posting a whole program here, so obviously this isn't going to reflect reality in full. A person can write optimized code as they go based on the knowledge they've already obtained. If prior experience has led to certain understanding of efficiencies, it only makes sense to apply that knowledge up front. Premature optimization is making decisions that may severely restrict the understandability and ease of maintenance of your program before knowing if there's any benefit. Even if the above code had no benefit, there's no real compromise being made. –  Mar 06 '18 at 20:28