Attaching events in JavaScript - javascript

As comment to one of the questions here a commenter wrote (emphasis mine):
... By using an inline "onclick" you are doing a similar thing, but it is harder to maintain and more prone to issues. The JavaScript community as a whole has been moving away from inline JavaScript for a while now.
This was referring to attaching events to HTML elements using:
$("#someID").click(function(){
do something here...;
});
rather than:
<a id="someID" onclick="someFunction();">
Has there really been a shift away from the old school way of declaring events inline, and if so, what are the benefits of one of the other?
EDIT I guess it may be helpful to include a reference to the original question. It asked about attaching a different click event to each tab. Is my answer crap and do I owe FallenRayne an apology =).

The big benefit is the separation of content (html) and action/behavior (javascript). This is known as Unobtrusive javascript. Keeping these separated makes it easier to change either without affecting the other.

Yes, there has, at least in some portion of the community, not sure how you'd measure it overall.
There are definitely advantages, off the top of my head:
Cleaner / Less code
Easier to debug
Easier to change
Easier to package
Performance
From sheer volume, think of this:
<a onclick="someFunction();">
<a onclick="someFunction();">
<a onclick="someFunction();">
<a onclick="someFunction();">
<a onclick="someFunction();">
Or this once:
$("a").click(someFunction);
You can do this with most frameworks via a css selector, etc, handles many elements at once. This means in server code you're just assigning IDs and classes, the client side is easier to handle separately. It's easier to debug as well, for example: in the console I can do $('a').unbind('click').click(...something new...);
Another benefit is performance. If I can split this into a separate .js file, cached by the client, that's thinner webpages and extra data I'm not sending every time. Smaller web page = faster load.
Here's one more example, thinks about how simple it is, granted some framework action via jQuery going on, but how would this look with inline events?
$("li").hover(function() {
$(this).children().slideToggle();
});
Comparatively, that's a tremendous amount of inline code, even if you leave out the animation portion it's messy (think mouseenter/mouseleave, not mouseover/mouseout...the former, which .hover() uses, is more complicated)

Has there really been a shift away from the old school way of declaring events inline
Yes, definitely, especially with the rise of the JS Frameworks like jQuery, Prototype and so on, all of which encourage declaring events the "new school" way.
and if so, what are the benefits of one of the other?
One of the main reasons is the separation between the HTML structure and the JavaScript programming intelligence (which arguably do belong separated). It makes the markup much, much cleaner and easier to maintain, while all the programming logic is kept in separate files, which has loading performance advantages as well as better maintanability - you have proper libraries that contain the code, instead of fragments of JS code all over the place.

With inline declaration you can assign only one event handler while from code you can assign as many as you wish. Also if you need to assign same event handler to multiple elements doing it with javascript is easier and shorter and you comply to DRY principle.

Related

Which technique is better?

Which technique is better:
<span onclick="dothis();">check</span>
or:
<span class="bla">check</span>
<script type="text/javascript">
$('.bla').click(function(e) {} );
</script>
Are there any differences according to usability, performance etc.?
Thank you!
The second is better from a code quality standpoint since it is considered to be unobtrusive. I am not certain if either approach has measurable performance benefits.
My advice is to stick to the unobtrusive approach - it will save you a lot of time when you are doing maintenance down the road.
The second is much better. See Unobtrusive JavaScript
Always better to keep your script OUT of the DOM.
Technique 1 is intrusive or obstrusive JavaScript: Your markup is intermixed with your JavaScript calls, which can be really messy and is not a separation of concerns.
Technique 2 is unobstrusive: Your JavaScript is kept separate from the markup, keeping both clean but adds a lot of boilerplate code.
Neither is better, although Technique 2 works better for larger projects for me, but always requires looking in two places and can introduce bugs by changing the markup but not the JavaScript.
You should always try and do the best thing which, for most scripts is to put it in a separate file. If it's a small script, like your example, then it's actually going to be quicker to put it in <script> tags in the document head.
Always steer clear of onClick="" and friends; it makes for messy, sometimes repetitive code and can be hard to maintain/debug.
Another note: if your script is huge (100s of lines), the extra time it takes for the browser to fetch the external file is compensated by the fact the script isn't in the HTML, so it will load the same or faster. For small scripts that won't go beyond say a maximum of 50 lines will be fine in the <head>.
In my opinion, the first approach is easier to debug, it is very clear that dothis() is called when you click on the span; it is harder for the second especially when you put the event handling code into a javascript file. For performance, i think it is tiny, although the first one absolutely have better performance.

When to use Vanilla JavaScript vs. jQuery?

I have noticed while monitoring/attempting to answer common jQuery questions, that there are certain practices using javascript, instead of jQuery, that actually enable you to write less and do ... well the same amount. And may also yield performance benefits.
A specific example
$(this) vs this
Inside a click event referencing the clicked objects id
jQuery
$(this).attr("id");
Javascript
this.id;
Are there any other common practices like this? Where certain Javascript operations could be accomplished easier, without bringing jQuery into the mix. Or is this a rare case? (of a jQuery "shortcut" actually requiring more code)
EDIT : While I appreciate the answers regarding jQuery vs. plain javascript performance, I am actually looking for much more quantitative answers. While using jQuery, instances where one would actually be better off (readability/compactness) to use plain javascript instead of using $(). In addition to the example I gave in my original question.
this.id (as you know)
this.value (on most input types. only issues I know are IE when a <select> doesn't have value properties set on its <option> elements, or radio inputs in Safari.)
this.className to get or set an entire "class" property
this.selectedIndex against a <select> to get the selected index
this.options against a <select> to get a list of <option> elements
this.text against an <option> to get its text content
this.rows against a <table> to get a collection of <tr> elements
this.cells against a <tr> to get its cells (td & th)
this.parentNode to get a direct parent
this.checked to get the checked state of a checkbox Thanks #Tim Down
this.selected to get the selected state of an option Thanks #Tim Down
this.disabled to get the disabled state of an input Thanks #Tim Down
this.readOnly to get the readOnly state of an input Thanks #Tim Down
this.href against an <a> element to get its href
this.hostname against an <a> element to get the domain of its href
this.pathname against an <a> element to get the path of its href
this.search against an <a> element to get the querystring of its href
this.src against an element where it is valid to have a src
...I think you get the idea.
There will be times when performance is crucial. Like if you're performing something in a loop many times over, you may want to ditch jQuery.
In general you can replace:
$(el).attr('someName');
with:
Above was poorly worded. getAttribute is not a replacement, but it does retrieve the value of an attribute sent from the server, and its corresponding setAttribute will set it. Necessary in some cases.
The sentences below sort of covered it. See this answer for a better treatment.
el.getAttribute('someName');
...in order to access an attribute directly. Note that attributes are not the same as properties (though they mirror each other sometimes). Of course there's setAttribute too.
Say you had a situation where received a page where you need to unwrap all tags of a certain type. It is short and easy with jQuery:
$('span').unwrap(); // unwrap all span elements
But if there are many, you may want to do a little native DOM API:
var spans = document.getElementsByTagName('span');
while( spans[0] ) {
var parent = spans[0].parentNode;
while( spans[0].firstChild ) {
parent.insertBefore( spans[0].firstChild, spans[0]);
}
parent.removeChild( spans[0] );
}
This code is pretty short, it performs better than the jQuery version, and can easily be made into a reusable function in your personal library.
It may seem like I have an infinite loop with the outer while because of while(spans[0]), but because we're dealing with a "live list" it gets updated when we do the parent.removeChild(span[0]);. This is a pretty nifty feature that we miss out on when working with an Array (or Array-like object) instead.
The correct answer is that you'll always take a performance penalty when using jQuery instead of 'plain old' native JavaScript. That's because jQuery is a JavaScript Library. It is not some fancy new version of JavaScript.
The reason that jQuery is powerful is that it makes some things which are overly tedious in a cross-browser situation (AJAX is one of the best examples) and smooths over the inconsistencies between the myriad of available browsers and provides a consistent API. It also easily facilitates concepts like chaining, implied iteration, etc, to simplify working on groups of elements together.
Learning jQuery is no substitute for learning JavaScript. You should have a firm basis in the latter so that you fully appreciate what knowing the former is making easier for you.
-- Edited to encompass comments --
As the comments are quick to point out (and I agree with 100%) the statements above refer to benchmarking code. A 'native' JavaScript solution (assuming it is well written) will outperform a jQuery solution that accomplishes the same thing in nearly every case (I'd love to see an example otherwise). jQuery does speed up development time, which is a significant benefit which I do not mean to downplay. It facilitates easy to read, easy to follow code, which is more than some developers are capable of creating on their own.
In my opinion then, the answer depends on what you're attempting to achieve. If, as I presumed based on your reference to performance benefits, you're after the best possible speed out of your application, then using jQuery introduces overhead every time you call $(). If you're going for readability, consistency, cross browser compatibility, etc, then there are certainly reasons to favor jQuery over 'native' JavaScript.
There's a framework called... oh guess what? Vanilla JS. Hope you get the joke... :D It sacrifices code legibility for performance... Comparing it to jQuery bellow you can see that retrieving a DOM element by ID is almost 35X faster. :)
So if you want performance you'd better try Vanilla JS and draw your own conclusions. Maybe you won't experience JavaScript hanging the browser's GUI/locking up the UI thread during intensive code like inside a for loop.
Vanilla JS is a fast, lightweight, cross-platform framework for
building incredible, powerful JavaScript applications.
On their homepage there's some perf comparisons:
There's already an accepted answer but I believe no answer typed directly here can be comprehensive in its list of native javascript methods/attributes that has practically guaranteed cross-browser support. For that may I redirect you to quirksmode:
http://www.quirksmode.org/compatibility.html
It is perhaps the most comprehensive list of what works and what doesn't work on what browser anywhere. Pay particular attention to the DOM section. It is a lot to read but the point is not to read it all but to use it as a reference.
When I started seriously writing web apps I printed out all the DOM tables and hung them on the wall so that I know at a glance what is safe to use and what requires hacks. These days I just google something like quirksmode parentNode compatibility when I have doubts.
Like anything else, judgement is mostly a matter of experience. I wouldn't really recommend you to read the entire site and memorize all the issues to figure out when to use jQuery and when to use plain JS. Just be aware of the list. It's easy enough to search. With time you will develop an instinct of when plain JS is preferable.
PS: PPK (the author of the site) also has a very nice book that I do recommend reading
When:
you know that there is unflinching cross-browser support for what you are doing, and
it is not significantly more code to type, and
it is not significantly less readable, and
you are reasonably confident that jQuery will not choose different implementations based on the browser to achieve better performance, then:
use JavaScript. Otherwise use jQuery (if you can).
Edit: This answer applies both when choosing to use jQuery overall versus leaving it out, as well as choosing whether to to use vanilla JS inside jQuery. Choosing between attr('id') and .id leans in favor of JS, while choosing between removeClass('foo') versus .className = .className.replace( new Regexp("(?:^|\\s+)"+foo+"(?:\\s+|$)",'g'), '' ) leans in favor of jQuery.
Others' answers have focused on the broad question of "jQuery vs. plain JS." Judging from your OP, I think you were simply wondering when it's better to use vanilla JS if you've already chosen to use jQuery. Your example is a perfect example of when you should use vanilla JS:
$(this).attr('id');
Is both slower and (in my opinion) less readable than:
this.id.
It's slower because you have to spin up a new JS object just to retrieve the attribute the jQuery way. Now, if you're going to be using $(this) to perform other operations, then by all means, store that jQuery object in a variable and operate with that. However, I've run into many situations where I just need an attribute from the element (like id or src).
Are there any other common practices
like this? Where certain Javascript
operations could be accomplished
easier, without bringing jQuery into
the mix. Or is this a rare case? (of a
jQuery "shortcut" actually requiring
more code)
I think the most common case is the one you describe in your post; people wrapping $(this) in a jQuery object unnecessarily. I see this most often with id and value (instead using $(this).val()).
Edit: Here's an article that explains why using jQuery in the attr() case is slower. Confession: stole it from the tag wiki, but I think it's worth mentioning for the question.
Edit again: Given the readability/performance implications of just accessing attributes directly, I'd say a good rule of thumb is probably to try to to use this.<attributename> when possible. There are probably some instances where this won't work because of browser inconsistencies, but it's probably better to try this first and fall back on jQuery if it doesn't work.
If you are mostly concerned about performance, your main example hits the nail on the head. Invoking jQuery unnecessarily or redundantly is, IMHO, the second main cause of slow performance (the first being poor DOM traversal).
It's not really an example of what you're looking for, but I see this so often that it bears mentioning: One of the best ways to speed up performance of your jQuery scripts is to cache jQuery objects, and/or use chaining:
// poor
$(this).animate({'opacity':'0'}, function() { $(this).remove(); });
// excellent
var element = $(this);
element.animate({'opacity':'0'}, function() { element.remove(); });
// poor
$('.something').load('url');
$('.something').show();
// excellent
var something = $('#container').children('p.something');
something.load('url').show();
I've found there is certainly overlap between JS and JQ. The code you've shown is a good example of that. Frankly, the best reason to use JQ over JS is simply browser compatibility. I always lean toward JQ, even if I can accomplish something in JS.
This is my personal view, but as jQuery is JavaScript anyway, I think theoretically it cannot perform better than vanilla JS ever.
But practically it may perform better than hand-written JS, as one's hand-written code may be not as efficient as jQuery.
Bottom-line - for smaller stuff I tend to use vanilla JS, for JS intensive projects I like to use jQuery and not reinvent the wheel - it's also more productive.
The first answer's live properties list of this as a DOM element is quite complete.
You may find also interesting to know some others.
When this is the document :
this.forms to get an HTMLCollection of the current document forms,
this.anchors to get an HTMLCollection of all the HTMLAnchorElements with name being set,
this.links to get an HTMLCollection of all the HTMLAnchorElements with href being set,
this.images to get an HTMLCollection of all the HTMLImageElements
and the same with the deprecated applets as this.applets
When you work with document.forms, document.forms[formNameOrId] gets the so named or identified form.
When this is a form :
this[inputNameOrId] to get the so named or identified field
When this is form field:
this.type to get the field type
When learning jQuery selectors, we often skip learning already existing HTML elements properties, which are so fast to access.
As usual I'm coming late to this party.
It wasn't the extra functionality that made me decide to use jQuery, as attractive as that was. After all nothing stops you from writing your own functions.
It was the fact that there were so many tricks to learn when modifying the DOM to avoid memory leaks (I'm talking about you IE). To have one central resource that managed all those sort of issues for me, written by people who were a whole lot better JS coders than I ever will be, that was being continually reviewed, revised and tested was god send.
I guess this sort of falls under the cross browser support/abstraction argument.
And of course jQuery does not preclude the use of straight JS when you needed it. I always felt the two seemed to work seamlessly together.
Of course if your browser is not supported by jQuery or you are supporting a low end environment (older phone?) then a large .js file might be a problem. Remember when jQuery used to be tiny?
But normally the performance difference is not an issue of concern. It only has to be fast enough. With Gigahertz of CPU cycles going to waste every second, I'm more concerned with the performance of my coders, the only development resources that doesn't double in power every 18 months.
That said I'm currently looking into accessibility issues and apparently .innerHTML is a bit of a no no with that. jQuery of course depends on .innerHTML, so now I'm looking for a framework that will depend on the somewhat tedious methods that are allowed. And I can imagine such a framework will run slower than jQuery, but as long as it performs well enough, I'll be happy.
Here's a non-technical answer - many jobs may not allow certain libraries, such as jQuery.
In fact, In fact, Google doesn't allow jQuery in any of their code (nor React, because it's owned by Facebook), which you might not have known until the interviewer says "Sorry, but you cant use jQuery, it's not on the approved list at XYZ Corporation". Vanilla JavaScript works absolutely everywhere, every time, and will never give you this problem. If you rely on a library yes you get speed and ease, but you lose universality.
Also, speaking of interviewing, the other downside is that if you say you need to use a library to solve a JavaScript problem during a code quiz, it comes across like you don't actually understand the problem, which looks kinda bad. Whereas if you solve it in raw vanilla JavaScript it demonstrates that you actually understand and can solve every part of whatever problem they throw in front of you.
$(this) is different to this :
By using $(this) you are ensuring the jQuery prototype is being passed onto the object.

What is the proper use of the anchor tag?

I've read how the anchor tag is holy, it should not be used with javascript:
Popup
that it should ONLY be used for a link to another page:
Take me over there
So what is the proper use of the anchor tag with javascript? Should I be using:
Energize!
or some other variant? I'm somewhat confused by different views on the subject. Also is it only SEO that I should be worried about if making the href a javascript piece? Or is it more of a proper web standards compliance deal?
Thoughts? Hopefully I'm not the only one confused.
You are not alone Jakub; even the biggest WWW companies use different approaches.
However based on experiences since Netscape days I wouldn't use :
Popup
which can make some troubles on some browsers, like opening an empty page or breaking the event order on the current page.
However;
Energize!
or;
Link
don't make a serious trouble and are ok to use. Note that the prior one may reset the scroll to the top.
You should use meaningful link targets and unobtrusive javascript wherever possible, but this is not always possible in real life examples. It's not a defined standard, but a method highly agreed by most of the web developers.
When it comes to standards, there is one related with this situation:
You should consider using a 'button' for inputs which doesn't really send the visitor to a page, but does an operation. This is also important for SEO.
As #Sime says (and it should be an answer really), it is considered "bad practise" to now directly reference javascript in any HTML object. So in these cases you attach the event using something like jQuery using the concepts laid out in "unobtrusive javascript".
As you mention another consideration is SEO and accessibility. If SEO is important to your site, make sure that the site is fully navigable using just standard links. Again you can manage this using "unobtrusive javascript", etc.
I've always gone with using an anchor as normal (i.e. specify either an alternate url that is another location where the user could perform what's being done through javascript, or use javascript:void() / #) then use the onclick event for anything you want executed.
You could also use a <span> if you're that worried about conformance, just would need to perhaps style it (change cursor, perhaps color as well) to make it visually obvious you're making it an action.
I think Facebook is the best-case example. Almost all of their links are javascript tied in, but they also have a "backup" page for those that either have disallowed javascript or don't have it (the later, in this day and age, being far less common). Take a look at a module that reacts like you'd like yours to and see how they've done it. They also invested a bunch of work in best-practices that you can benefit from.
If anything, you should bind your anchor links to javascript methods only by using unobtrusive javascript like Paul mentioned.
This means, using separation of concerns and leaving your markup being just that, html markup:
<a id="Jolter">Energize!</a>
and later
<script type="text/javascript">
$(document).ready(function(){
$("#Jolter").click(function(){
// doStuffHere ...
});
});
</script>

Are there any drawbacks to class-based Javascript injection?

A phenomena I'm seeing more and more of is Javascript code that is tied to a particular element on a particular page, rather than being tied to kinds of elements or UI patterns.
For example, say we had a couple of animated menus on a page:
<ul id="top-navigation">
...
</ul>
<!-- ... -->
<ul id="product-list">
...
</ul>
These two menus might exist on the same page or on different pages, and some pages mightn't have any menus.
I'll often see Javascript code like this (for these examples, I'm using jQuery):
$(document).ready(function() {
$('ul#top-navigation').dropdownMenu();
$('ul#product-selector').dropdownMenu();
});
Notice the problem?
The Javascript is tightly coupled to particular instances of a UI pattern rather than the UI pattern itself.
Now wouldn't it be so much simpler (and cleaner) to do this instead? -
$(document).ready(function() {
$('ul.dropdown-menu').dropdownMenu();
});
Then we can put the 'dropdown-menu' class on our lists like so:
<ul id="top-navigation" class="dropdown-menu">
...
</ul>
<!-- ... -->
<ul id="product-list" class="dropdown-menu">
...
</ul>
This way of doing things would have the following benefits:
Simpler Javascript - we only need to attach once to the class.
We avoid looking for specific instances that mightn't exist on a given page.
If we remove an element, we don't need to hunt through the Javascript to find the attach code for that element.
I believe techniques similar to this were pioneered by certain articles on alistapart.com.
I'm amazed these simple techniques still haven't gained widespread adoption, and I still see 'best-practice' code-samples and Javascript frameworks referring directly to UI instances rather than UI patterns.
Is there any reason for this? Is there some big disadvantage to the technique I just described that I'm unaware of?
First of all I agree with you that using the class approach is better, in general.
But I don't think I'd go so far as to say it's less coupling of the code to the UI. If you think about it, if the code assumes ID "foo" vs. class name "foo", you still have to know that when working with the UI. There's still a 'contract' between them -- whether you meet it through ID or class is not really different.
One disadvantage to using the class approach I'd imagine is speed -- it should be faster to find a particular element by ID than find potentially multiple elements by class. The difference is probably completely negligible though.
But, in the case where your code is designed to attach multiple behaviors, as in your two-dropdown example, using class certainly makes more sense. That is less coupling since your code is a bit more generalized, and your UI more likely to be customizable w/o changing the code.
One thing I'd change in both of your examples... why have the UL in the selector? If the code knows it can only possibly work if the target is a UL, well, that's one thing -- but in that case, it'd be better to avoid the UL in the selector and let the code throw a meaningful error if the target is found not to be a UL, lest the page just do nothing without any indication as to why (e.g. because the UI put the ID/class on a OL).
So in other words, just "#foo" or ".foo" not "ul.foo", etc.
I should point out that in case someone thinks the UL somehow makes the selector more efficient, it doesn't, since selectors are evaluated from right to left.
Your approach is preferred.
The reason people do things in different ways is because they can and it still works.

How to organize JS loading?

I have a serious project with big JS file with many functions, and now I have some questions about it.
Of course, I will stick together all my js files and gzip it, but I have a question about functions initialisations. Now I have many, many simple functions, without any classes. I heard that it is better to separate my code into many classes, and I want to do it, and on page generation step mark in my script, which classes I need on specific page. For example, I don't need a WYSIWYG editor at the main page, and so forth, so I will create special var with array of js classes which I need. Is this the best practice? Will clients get performance and memory savings?
Suppose that I have many links with onclick actions. What is better: leave them as <a href="#" onclick="return smth();"> or rewrite as <a href="javascript:void(0);"> and create jquery .bind in document.ready section? But what if the client wants to click something before the document is ready?
After a click on something I must create a div with specific static html. Where is it better to store this content? In some var in my class? Or maybe in some template?
I usually organize my JavaScript using namespacing to prevent function name clashing and further add each object into it's own .js file for organization purposes
var MyObject = function() {
return {
method_1 : function() {
// do stuff here
},
method_2 : function() {
// do stuff here
}
};
}();
MyObject.method_1();
MyObject.method_2();
I then import whatever is needed on my pages. Having a few extra global functions that aren't used on a page won't make a noticeable change in performance.
Some people turn the whole onclick in HTML into a grand philosophical debate... for me, it's dirty, yet easy to read and quick to implement. Binding events works great and completely separates JavaScript from HTML but sometimes can be difficult to maintain if your HTML being maintained by many developers gets very sloppy
Keeping the HTML bits in JavaScript has worked fine for me
You might also be interested in looking at the Google Closure JavaScript compiler.
Also: If your JS is large enough to affect performance, you may actually end up getting better performance out of separate files and load depending on what your page initially needs or load-on-demand (via jQuery getScript).
You might also want to look into what kinds of actions you expect users to be using before the DOM is ready.
As for HTML in JS (or vice-versa). It depends. How much HTML are you building? I usually don't put more than one line of HTML in a .html() statement. If it's really more than that, I look at a different solution (like pulling it from another source on-demand or putting it somewhere, hidden, in the page and yanking it over).

Categories