JS onclick or jQuery .click in general and for delete button in particullar?

General PHP
1

First, question goes in general. What are the main pros and cons of using either JS approach:


<a href="go.php" onclick="alert('Go!')">go</a>

or jQuery way:


<a href="go.php" id="go-link">go</a>


<script type="text/javascript">

/*<![CDATA[*/

	jQuery(function($)

	{

		$('#go-link').click(function(){alert('Go!')});

	});

/*]]>*/

</script>

More writing in second approach – of course – but this is pure code, while using Yii this is simplified and code length is comparable.

So, I’m not asking about answers in style of “less/more coding”, but some standards, good practices etc. When using jQuery approach is better?

And in particular… Let’s say that I bind delete button’s click event using jQuery way. And inside click’s code there’ll be confirmation dialog returning false (preventing click) if user cancels deletion. Then, what happens if jQuery for some reasons fail to load? Will user be able to invoke delete action without seeing confirmation? That would be a disaster. If this is true wouldn’t JS approach with onclick just a safer way here?

2

That depends on whether or not you’re using the newest jQuery:

jQuery 1.7 Release Notes

Use ‘on’ / ‘off’ - unless I have misunderstood the whole thing.

3

I think so! :] If jQuery fails to load (no matter, for what reason), both .on, .off, .click and all other jQuery functions won’t be attached. Right?

Let me try to ask the question easier / other way: So, what happens, if you have delete confirmation dialog attached to a delete link (using jQuery’s .click event binding, not HTML onclick parameter) and this attach fails, because jQuery fail to load? Will link work without confirmation?

4

The delete link will fail due to the fact that your corresponding controller action only accepts delete request via POST.

So the link should/would do nothing.

5

At least, the controller should only accept POST data for writing actions.

General pros for jQuery’s attach:

  • you can attach several event handlers (at least I think so…)

  • you can separate presentation (html) from logik/ behavior (javaScript)

  • for me, it feels simpler to write $(selector).click() than to search for all elements in the view manually and then to write down whatever should be done.

General pros for normal attach:

  • doesn’t need jQuery

  • will always be working (with the jQuery aproach, you might run into problems when ajax-loading links - you had to ensure to bind the events to them once they have been injected into the dom).

Just what comes to my mind atm…

I think for your particular use case, you should first elaborate if the confirmation dialog is a must-have or a convenience feature. Should your website work, even if the user has java script disabled? If yes, a “real” button might be better. If you decide it is a must-have, then a scripting language is required, the link’s href should be “#” and the POST request should be sent from the onClick-event handler.

6

Without getting into the jQuery loaded or not problem… (yes, you can bind an event with pure js)

Asking if to use onclick for a javascript code or to put that code in a separate file… is like asking if it’s best to use style for inline CSS or to write that in a separate CSS…

7

Thank you for all your explanation…

I CAN invoke POST request in button’s (or link’s) onClick? How?

I know that this probably is a really dumb question, but after all this forum is dedicated to educate ourselves in the areas, we don’t know! ;]

I have never heard about calling POST-type request directly from onClick. If I make a hidden form with a one or few hidden fields and a normal submit button, then OK - I can easily invoke POST request with clicking button. But you’re writing specifically about calling POST-request from onClick event handler. Up until now I thought that this way you can only execute GET-style request.

8

Well, you’re right, but I was talking about a slight bit different point of view. Both jQuery (binding) and JS (onClick) approaches uses the same file (both bind/call and function declaration are in the same - view - file). Simple, because I’m using this particular function only in this view file. The question was then rather about on how to call the code, not where to place it.

9

OK. But here you’re talking about my specific situation with delete action.

But let’s assume that you have an action that should only be called when user responds “Yes” in some kind of dialog. If I get you and other right, if I bind dialog invoke with jQuery .click function and jQuery fail to load, this dialog will not be shown and link will be executed.

I’m just theorising about concepts at all, not a particular situation.

It looks like, and Ben seems to be agreeing with me, that if you need to do some JS function before link execution (or even more - block link execution if that JS function return false) then using onClick is the only secure way. Just to secure yourself from rare, but possible, situation that jQuery fail to load, binding won’t be created and function fail to execute before link execution.

10

But in the first place… why do you think jQuery would not be loaded?

IMO it’s the same as being affraid that the link that points to the “myfile.php” will not work in the case that “myfile.php” would not be loaded.

And what would you do if th euser has javascript disabled… in that case even onclick is not working…

11

Yeah, I would bind the event in jQuery script. And that effectively solves the issue - courtesy of Mdomba. ;)

12

For example, when you provide jQuery from Google or other CDN and that source fails (sometimes even Google is unavailable).

Or in application developed to be run in localhost, that is using jQuery from remote source (CDN again or other server) and network/Internet connection is down.

I know, that this situations are very, very rare, but possible. And, please, remebmer that this was pure theoretical discussion.

13

That’s totally solvable:





  <!-- Grab Google CDN's jQuery. fall back to local if necessary -->

  <script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.js"></script>

  <script>!window.jQuery && document.write(unescape('%3Cscript src="js/libs/jquery-1.5.2.min.js"%3E%3C/script%3E'))</script>

Courtesy of HTML5 Boilerplate:)

14

I know is theoretical… but as I wrote above… it would make sense to discuss… what if user has javascript disabled… not if jQuery will load… as by this thinking we can discuss about… what if (choose any file of your project) will not load…

if you are affraid that jQuery could not be loaded from CDN… do as I do… load it from your server ;)

P.S. getting back to onclick or bind and the comparation to CSS… again is the same as using inline style on HTML elements… or the <style> tag in one place…

15

About sending POST-requests from JS, please have a look at: http://api.jquery.com/jQuery.post/

To do the same in plain JS without jQuery, you could use the XMLHttpRequest Object: http://www.w3schools.com/ajax/ajax_xmlhttprequest_send.asp

One thing to keep in mind is, that such an action is subject to the same origin policy, which basically means that you can’t post to another domain (or protocol or port).

16

Thank you all for explanations. That ends the discussion.

17

I’m just going to chime in here. Firstly there are general rules of use which most good developers will adopt. The first being the method of using javascript for “progressive enhancement”. The theory goes that your web page should function exactly as intended with javascript on or off.

For example if someone deletes something then the default behaviour should be to redirect them to a thank you page if successful. Javascript can be used to catch that click and provide a better experience for the user but at no point should be used to replace functionality. Once you have these mechanics in place your argument of jQuery not loading or having js turned off is null and void.

As for the other issues the idea of having jQuery being able to bind to dom elements without having to provide inline events is one of its biggest advantages. Most good developers will again never use inline javascript any more. Simple use case would be that if you go through an entire page adding events that do the same thing but you need to 20 anchor tags then you’re going though and modifying 20 anchor tags. If you need to change that at a future date you need go through those 20 tags again to change them. A big pain, however if you use jQuery then you can write the code in a few lines (which would actually end up being less than all the js used in the 20 tags added together) at the end of a file and if you need to update it then you do it on single place.

Another issue is that inline js can be hard to identify and if you need to make changes you could miss something and introduce bugs into your applications. As for the more lines of code vs less that issue quickly falls flat when you consider if you put all your jQuery code in a external file and run it through a minifier (compressor) than all that code can fit on one line.

As for the quote above, its not entirely correct as you can use the JSONP method of jQuery to do cross domain scripting.

18

I am also chiming in to say that sometimes you don’t want to cater for users with javascript off.

And sometimes portions of your site is javascript only.

Like the the convenience delete shortcut action in your grid.

Since a non-javascript delete action is accessible from the item view page, just hide the convenience button if the user has turned js off.

19

Here I have to agree with you completely and furthermore, I must admit that many of us simply forgot (or keep forgetting) about such simple and obvious rule.

Nope, here I will not agree. By placing ask: js-inline or jQuery I was always mentioning about situation if you have one piece of code to be attached to one element – for example one delete confirmation to attach to one delete button. If there are more objects that needs to be attached to the same code, then jQuery approach is the only reasonable way without any arguing.

BTW: Your statement (or argumentation) can also be beaten with using procedures. If I place 20 inlines pointing to the same procedure (which from some point of view is the same as attaching the same jQuery code to 20 elements) I’ll have to only change code of that procedure, not all 20 inlines.

On the other hand, all my arguments can be simple defeated with simple assumption that if there would be any reasonable pros of inline scripting over jQuery, then jQuery wouldn’t ever become as popular as it is! :] I hope this ends this topic? :]

Thank you for good and professional voice in this discussion.

20

It is true but the world of good design and accessibility you should strive to make this a minimum. You’re right that sometimes you just can’t reproduce something’s without js (i’m working on something now that fits into that) but that rule shouldn’t become common when you can achieve it using conventional methods.

yea you kind of ended your argument in the closing lines. If you’re going to use function or procedures then you might as well just use jQuery.