Lazy front-enders are lazy
It's common knowledge that programmers are lazy.
This shouldn't be considered as a negative characteristic, because in most cases it makes them more productive.
However, there are cases where this laziness makes programs/scripts execute way slower than they could. Let's take jQuery as an example. jQuery enables programmers to manipulate the DOM without much knowledge of what is happening on the background. This is not bad in most cases, because it makes the learning curve less steep, but in other cases degrades performance.
Most programmers tend to use jQuery for everything concerning DOM manipulation/element selection, but in some cases they should rather use the native JavaScript methods which are available in most browsers. A couple of examples:
Element selection based on id (jQuery)
$('#awesome-div');Element selection based on id (native)
document.getElementById('awesome-div');Element selection based on id (native + jQuery)
$(document.getElementById('awesome-div'));As you might guess, the native method is the fastest, while jQuery was the slowest one.
The combination of the two methods (native + jQuery) is still twice as fast as only using jQuery.
See: http://jsperf.com/tschuermans-jquery-id-selector-vs-native-id-selector for a benchmark.
Element creation (jQuery example 1)
$('<div>');Element creation (jQuery example 2)
$('<div/>');Element creation (jQuery example 3)
$('<div></div>');Element creation (Native)
document.createElement('div');Element creation (Native + jQuery)
$(document.createElement('div'));Native methods beat jQuery again! The first three examples are similar in performance, while the native method is 3-4x faster. The combination of the two methods (native + jQuery) is still twice as fast as only using jQuery. See http://jsperf.com/tschuermans-element-creation for a benchmark.
While jQuery is easy to use, sometimes native methods or a combination of jQuery and native methods are a better alternative. So stop being lazy and learn some JavaScript instead of always using jQuery :p
Written by Tom Schuermans
Related protips
10 Responses
Hahaha the last comment made me laugh a lot, however good tips bro, but you know the performance issues takes a lot to get out behind scene, I'll take this as a code refactoring tip
I know these are what you might call "micro-optimizations", but that's not the point of my protip ;-). The point is that you don't always have to rely on jQuery to handle basic DOM manipulation/selection, Thanks for the comment though, I appreciate it.
You're saying: "native code is better than libraries". Yes, it's true. Even writing a website in assembly is faster than everything but I said yes to the life.
Libraries and frameworks are slower than the native language and they are made to simplify your work: the trade-off between performance and comfort it's just a choice, a personal choice.
In my honest opinion, doing $('<div>') instead of $(document.createElement('div')) is better because it won't tear down the performance of my web app and it's easier and faster to write it down.
@wilk I totally agree with you, it's all a personal choice.
But as you can see in my previous comment, this protip is not about performance, it's about learning native methods, so you have an idea what happens in the background. When you ask front-end developers if they know JavaScript, 80-90% say they do, while they only know how the libraries are supposed to be used and not how everything is processed in the background.
Created by a coworker of mine http://vanilla-js.com/
When ever I read stuff like this, I just think to myself "Why would you ever use jQuery or a large framework to do such easy stuff like element creation.". At least some frameworks make it easier (MooTools for example) than jQuery.
If I am using jQuery already as my library
I would write this over
$('<div>');
over this
$(document.createElement('div'));
Code readability/Code familiarity is a lot more important then performance.
@ericraio I'm not sure any sensible developer would willingly impact performance purely for readability/familiarity. A good developer is always looking for ways to improve their existing code and future code, especially if it brings the bonus of performance improvements.
The end-user doesn't care how readable/familiar the code is to you if the site/app is too slow.
@ericraio maybe the gain is small in a singular one-off element creation, but the benchmarks provided suggest that you could get quite a significant gain in certain situations.
In terms of revisiting the code, that's why code should be well commented so that it's easy for anyone to jump in and immediately know what's going on with the code.
It's probably down to the individual and what they find comfortable in most cases, but I can see the sense in what Tom says in his tip.
Benchmark any real web page and it's highly unlikely the kind of examples shown here are anywhere close to the bottlenecks causing a page to be slow. You can always make code faster by adding more handling of specific cases, but it's only worthwhile to do that when it has a significant effect on bottlenecks. That's especially true in JavaScript where size can be just as much of a performance enemy as execution time.
Running to my car in the garage is four times faster than walking to my car, but it makes no real difference in time when I get in and drive 500 miles.
