Is it better to use
document.createNode();
or plain text like
var foo = '<div> bar </div>';
to create HTML markup with JavaScript?
There is no "better" in this particular case, it is going to boil down to what is most easily maintained. and programmer preference.
In some browsers, using DOM to create elements and nodes is, in terms of performance, faster than others. Some user agents process strings faster, for example by setting the innerHTML property.
I personally prefer to use DOM objects always, but I use the mootools framework which lends itself to this approach. jQuery encourages string-based creation.
Check out this benchmark: http://jsperf.com/string-vs-createelement/3, but also consider these articles: http://www.quirksmode.org/dom/innerhtml_old.html and http://karma.nucleuscms.org/item/101
It is better to use the DOM node functions. If you want to create it using a string, look into jQuery, as it has ways to parse it correctly into DOM nodes for you.
var foo = $('<div> bar </div>');
Using DOM manipulation functions you can have a reference to the created elements, one by one, and will be easier to modify the code later on, for example modify the tree order, adding or removing an element, and also for debugging purposes.
This said, there are some times I experienced myself in which the DOM manipulation functions are not the best way.
For example I had the necessity to modify real time the content of a style tag, to control the style of the elements directly via text css rules, something you can't achieve in all browsers using the various JS style objects, because they contain read-only properties.
In this case the style tag html was read-only for IE (or at least IE didn't like to modify it via innerHtml or similar), the only solution I found was to read the old html value, change it, remove the element and create a new style tag element with the new html directly typed in the string when creating the element.
This said, I would go with the DOM node functions whenever possible.
Related
I'm looking to inject HTML via JavaScript into a page at work.
What I'd like to know is if injecting a re-write of the page is more or less efficient than injecting snippets throughout the page with methods like getElementById().
For example:
document.getElementById("Example").innerHTML = '<h2 id="Example" name="Example">Text</H2>'
document.getElementsByClassName("Example").innerHTML = '<H1>Test</H1>'
...etc. Is this more efficient/effective than simply injecting my own version of the entire page's HTML start to finish?
Edit: Per Lix's comment, I should clarify that I likely will be injecting a large amount of content into the page, but it will affect no more than a dozen elements at any time.
If your project can manage it, it could be better to create DOM Elements and append them to the tree.
The big problem with efficiency would be that setting .innerHTML property would first remove all the nodes and only then parse the html and append it to the DOM.
It's obvious that you should avoid removing and the re-appending identical elements, so if you're sure the "Example" elements would always remain on the page, your way of setting them seems to be a nice optimazation.
If you want to optimize it even further, you could parse the html you want to append to nodes and have a function that checks which ones should be appended and which one shouldn't. But be aware that accessing the DOM is costly. Read more about the ECMA-DOM bridge.
Edit: In some cases it might be better to let the browser do the html parsing and injecting through innerHTML. It depends on the amount of HTML you're inserting and the amount you're deleting. See #Nelson Menezes's comments about innerHTML vs. append.
Depends on the context. If it was only decoration of existing content, then your proposal would suffice. I'd use jQuery anyway, but that's only my preference.
But when injecting the actual content you have two concerns:
maintainability - Make the structure of your code readable and subject to easy change when you need (and you will need).
accessibility - When javascript is disabled, then no content will be visible at all. You should provide a link to desired content in <noscript/> tag or ensure accessibility to everyone any other way you prefer. That's a minority of internet users at the moment, but for professional webmasters they make it count.
To address both of above concerns I prefer to use ajax to load a whole page, some part or even plaintext into existing element. It makes it readable, 'cause the content is sitting in another file completely separated from the script. And since it's a file, you may redirect to it directly when javascript is disabled. It makes the content accessible to anyone.
For plain javascript you'd have to use XMLHttpRequest object, like here.
With jQuery it's even simpler. Depending on what you need you may use .load, .get or .ajax.
Best practice today is using JQuery Manipulation functions.
Most time you'd use one of this 3 functions :
Replace existing HTML node:
$("div").html("New content");
Append a sibling node:
$("div").append("New content");
Remove a node:
$("div").remove();
So in my app, the user can create some content inside certain div tags, and each content, or as I call them "elements" has its own object. Currently I use a function to calculate the original div tag that the element has been placed inside using jquery selectors, but I was wondering in terms of performance, wouldn't it be better to just store a reference to the div tag once the element has been created, instead of calculating it later ?
so right now I use something like this :
$('.div[value='+divID+']')
but instead I can just store the reference inside the element, when im creating the element. Would that be better for performance ?
If you have lots of these bindings it would be a good idea to store references to them. As mentioned in the comments, variable lookups are much much faster than looking things up in the DOM - especially with your current approach. jQuery selectors are slower than the pure DOM alternatives, and that particular selector will be very slow.
Here is a test based on the one by epascarello showing the difference between jQuery, DOM2 methods, and references: http://jsperf.com/test-reference-vs-lookup/2. The variable assignment is super fast as expected. Also, the DOM methods beat jQuery by an equally large margin. Note, that this is with Yahoo's home page as an example.
Another consideration is the size and complexity of the DOM. As this increases, the reference caching method becomes more favourable still.
A local variable will be super fast compared to looking it up each time. Test to prove it.
jQuery is a function that builds and returns an object. That part isn't super expensive but actual DOM lookups do involve a fair bit of work. Overhead isn't that high for a simple query that matches an existing DOM method like getElementById or getElementsByClassName (doesn't in exist in IE8 so it's really slow there) but yes the difference is between work (building an object that wraps a DOM access method) and almost no work (referencing an existing object). Always cache your selector results if you plan on reusing them.
Also, the xpath stuff that you're using can be really expensive in some browsers so yes, I would definitely cache that.
Stuff to watch out for:
Long series of JQ params without IDs
Selector with only a class in IE8 or less (add the tag name e.g. 'div.someClass') for a drastic improvement - IE8 and below has to hit every piece of HTML at the interpreter level rather than using a speedy native method when you only use the class
xpath-style queries (a lot of newer browsers probably handle these okay)
When writing selectors consider how much markup has to be looked at to get to it. If you know you only want divs of a certain class inside a certain ID, do one of these $('#theID div.someClass') rather than just $('div.someClass');
But regardless, just on the principle of work avoidance, cache the value if you're going to use it twice or more. And avoid haranguing the DOM with repeated requests as much as you can.
looking up an element by ID is super fast. i am not 100% sure i understand your other approach, but i doubt it would be any better than a simple lookup of an element by its id, browsers know how to this task best. from what you've explained I can't see how your approach would be any faster.
I don't know what it's called, but I know that there's a way to get elements based on their tags without getElementsByTagName. It returns the same thing, but it's shorter and I'm using tags a lot in my project. What I'm talking about is document.frames[x] and document.images[x], but with other elements, like document.b[x] or document.a[x]. Seeing as document.images isn't the same as the <img> tag, it seems like if there are more they'd be named differently as well. Would anyone happen to know what it's called when using this method and/or have a list of accepted tags? Thanks.
P.S. Please do not suggest using a library such as jQuery. This project is meant to be a learning experience, so I want to use regular JavaScript.
As mentioned elsewhere in the answers, this doesn't have anything to do with JavaScript really, these are DOM properties and methods accessible via the JavaScript language binding for the DOM.
With reference to addressing elements such as document.frames[x] (note that this is incorrect, it should be window.frames[x]) and document.images[x] - these are Document Object/HTML Collections and the W3C standard includes only images, applets, links, forms and anchors.
So unless I'm looking in completely the wrong place, from what I can tell from the DOM-1 and DOM-2 specs, there doesn't seem to any way of arbitrarily addressing elements by tag name the way that you remember doing.
Update
The MDC entry on HTMLCollection is more understandable; it reads
The following lists each item (and its specific properties) which return an HTMLCollection: Document (images, applets, links, forms, anchors); form (elements); map (areas); table (rows, tBodies); tableSection (rows); row (cells)
Other than other JavaScript libraries creating these shorthands, I am not aware of any that are built into the language. It would be trivial to map this to your own shorthand:
var $ = document.getElementsByTagName;
// you can then use it like so:
$('SPAN').// and so on
Other than this, there is no built-in array-like access to all of the tags in the document:
http://www.javascriptkit.com/jsref/document.shtml
Create your own reference,
document.tag = document.getElementsByTagName;
or a wrapper,
function tag(name) {
return document.getElementsByTagName(name);
}
The only APIs I know of that support querying by element name are,
DOM
getElementsByTagName
CSS Selectors
querySelectorAll
XPath
evaluate
E4X
(mozilla only, and doesn't work with the DOM yet)
A jQuery best practices question.
I am writing a very jQuery intensive web page. I am new to jQuery and notice its power, but as I come with heavy javascript experience and knowledge, my question is: What should be done in jQuery and what in plain javascript.
For example, there are callbacks that send a plain DOM object as an argument. Should I use that or should I wrap it ( like $(this)).
Does it matter if I do this.x=y or $(this).attr("x", y).
If your function receives a DOM object and you don't need any jQuery functionality for that DOM object, then there is no need to make convert it to a jQuery object. For instance, if you receive a checkbox object, you can examine the checked property without any use of jQuery.
However, if you need to navigate to a different element from that checkbox, it might be worthwhile to convert it:
function yourCallback(cb) {
cb = $(cb);
var sel = $(cb).closest('td').next().find('select');
// For example, update the options in a neighboring select field
...
}
jQuery (as do other libraries) blend in smoothly with native JS. If you need extra functionality, augment the object in question.
As for your last question: You might find the data function useful to avoid nonstandard DOM attributes. If your property x in your question is in fact a valid DOM attribute, you can write either this.x = y or $(this).attr('x', y), IMO it does not matter much. However, if x is not a DOM attribute, use
$(this).data('key', value)
That way, you can store arbitrary key-value pairs with the DOM element, where value can be an arbitrary primitive value or object.
I think it's a judgement call. Use your common sense.
For instance, if you have 1000 div's on the page, you probably wouldn't want to wrap it inside $(..)
$('div').click(function() {
this.id = Random.guid(); // instead of $(this).attr('id', Random.guid());
});
As for other assignments, as long as you understand what jQuery is doing, you can stick with it just for consistency, but be aware of performance issues like in the above example.
As #colinmarc mentions, at times jQuery blurs the distinction between element attributes and object properties which can be misleading and buggy.
When your using jQuery, it always returns an instance of jQuery unless obv your using a function like val();
the reason we use $(this).value instead of this.value is to make sure that this is an instance of jQuery.
if somewhere in your code you set a variable called my_link witch is equal a DOM Object and not a jQuery function.. further in your application my_link.val() would result into an error, but by doing $(my_link).val() will assure you that the function val will be available. as $() returns an instance of jquery.
Sorry for the miss understanding in my previous post.
Since jQuery objects have richer functionality than nature JS DOM nodes, if you're on the fence, you might as well wrap in jQuery. JQuery is so lightweight, there's not really much reason not to use jQuery objects.
Does it matter if I do this.x=y or $(this).attr("x", y).
The native will be slightly faster, but you'll probably spend more time in other code-- DOM traversal or building. In this specific example, the former is more concise, so I'd choose that. Since jQuery is so lightweight, I tend to switch back and forth fluidly.
Here are other guidelines we follow:
For callbacks, like a click handler, you'll need to follow the API-- usually a DOM node. Code you write that is similar should probably just take DOM nodes as well. But if you have a list of items, always use a jQuery object.
For most code, I try to see if you can structure the code as a jQuery plugin-- applying some transformation to a set of DOM nodes. If you can do that, you'll gain some guidance from the plugin architecture.
I use jQuery's bind/trigger mechanism as it is quite flexible and low-coupling.
To keep code straight, I'd recommend name prefixing jQuery objects with a dollar sign. For example, var $this = $(this);. Although it's really no big deal to call $() excessively, it does end up looking a sloppy if you call it too much.
Hope this helps.
Following up on my question about jQuery.get() I was wondering if there is a list of DOM properties and methods that aren't available in jQuery that can only be accessible if you were working with the raw DOM object (i.e. $("#someID").get().scrollHeight; )
I haven't encountered a list but if one existed it would probably be quite lengthy. In addition to browser-specific (proprietary) properties there's a bunch of other less useful properties and methods not currently abstracted by jQuery. But then, I don't really see this as a problem, or even a valid point of discussion because jQuery IS JavaScript; if you need access to something beyond what jQuery provides then you can use get() or access a specified element within one of your "jQuery collections" like an array:
jQuery(elem)[0].someDOMProperty;
Plus jQuery provides absolutely no support for non-element nodes within the DOM. If, for whatever reason, you need direct access to comment nodes, text nodes etc. then you'll need to use the "raw" DOM.
I don't know of a compiled list of DOM operations/properties that are NOT available in jQuery (and a quick google search didn't turn anything up), but if you go to http://api.jquery.com/ you can see the entire API, and even download it as an Adobe AIR app in case you don't have internet when you need it.
No. JQuery is just JavaScript. If you can do it in JavaScript, you can do it in jQuery. Some properties and methods are overwritten in the context of a jQuery object and that's where you would want to us the get() method--to 'get' (i.e. access) the standard property/method.
That's really as complicated as it is.
Every attribute of every element is accessible through the attr() function. If you could do a document.getElementById() on that element and then access a property, you can also do it using the attr() function. However, some properties are accessed more easily in other ways when using jquery. For example, to see if an element is hidden or visible, you could do:
var isVisible=$("#el").is(":visible");
instead of using the attr() method. Similarly, you can find the selectedIndex of dropdowns and the text of the selected option, in easier ways than using the attr() method. This pdf outlines some of these easier approaches.
To access a css property, you are better off doing:
var fontWeight=$("#el").css("fontWeight");
rather than using get() or attr(). You can also set the css properties in this way, e.g:
$("#el").css("fontWeight","bold");
I could be wrong, but I think you can access any properties via the attr method.