16

Like many folks I learned JavaScript by learning jQuery.

Lately I have been replacing bits like:

$(this).attr('title') with this.title

$(this).attr('id') with this.id

$(this).val() with this.value

$(this).parent() with this.parentNode

$(this).attr('class') with this.className

Not only is my code cleaner but technically faster.

  1. Is this type of reduction acceptable and encouraged?

  2. Are there any other common practices I should be doing in raw plain JavaScript instead of jQuery?

  3. Are there any potential cross browser issues with this type of reduction-ism?

iambriansreed
  • 21,935
  • 6
  • 63
  • 79
  • 3
    Yes, it's encouraged. Making (usually) two function calls to get something you already have immediate access to is pointless. – Anthony Grist Aug 03 '12 at 15:54
  • 1
    I wouldn't call Javascript "raw". –  Aug 03 '12 at 15:54
  • 10
    It's a bitch trying to remember which ones are safe to call without jQuery and which ones aren't. It also looks inconsistent when you sometimes have to use the jQuery versions because of the bug fixes for edge cases and additional features such as taking a callback function. I doubt you will have performance problems, you don't usually operate on thousands of elements at a time for it to make a difference. – Esailija Aug 03 '12 at 15:55
  • @Hassan I used plain. That better? – iambriansreed Aug 03 '12 at 15:55
  • haha "Raw Javascript" just sounded like an oxymoron to me, but it worked fine for your question. –  Aug 03 '12 at 15:57
  • I agree with Esailija. Moving back to plain javascript can help in some cases when your performing a large set of actions but for operations that may only perform once or twice I'd stick with jQuery just because you get the benefit of the doubt that some browser is going to handle it differently. Where you will find better performance is when dealing with a large set of data or something that runs often enough that you need to make sure it execution is short and sweet. At that point you could move some of the cross browser support out of jQuery into your own logic to help speed things up. – travis Aug 03 '12 at 16:04
  • duplicate of [When to use Vanilla JavaScript vs. jQuery?](http://stackoverflow.com/questions/4651923/when-to-use-vanilla-javascript-vs-jquery) – Bergi Aug 03 '12 at 19:04

3 Answers3

6

Whilst using native Javascript functions are generally faster than their jQuery counterparts it does expose you to any browser compatibly issues that may arise from their use. this.value and such is unlikely to cause problems but other similar attributes / functions may well not work in all browsers. Using a framework like jQuery means you dont have to deal with, or worry about, such things.

I would only ever use plain Javascript if performance is an issue i.e. you have a lot of tight loops and repeated operations.

Chris
  • 26,744
  • 48
  • 193
  • 345
  • 3
    You are correct sir. On the other hand, I would look at jQuery as an absolute necessity over a specific period of time. Its like, the "age" of jQuery should be over "soon", since all major browser vendors getting closer and closer to common W3C specifications. jQuery was (and still is of course) a good tool under many, to circumvent those browser differences. But it should not be the ultimate and final answer. The final answer is, `ECMAscript`. – jAndy Aug 03 '12 at 16:03
  • I strongly agree with jAndy ! There *should* be a death of jQuery. – Jashwant Aug 03 '12 at 16:28
  • @jAndy Quite like Flash (for video mainly) is becoming part of the internet's sordid history. – iambriansreed Aug 03 '12 at 16:30
  • 1
    @jAndy: While I don't use jQuery, I don't think libraries that wrap browser APIs are going away or should go away. There will always be new APIs and therefore new browser bugs to work around. – Tim Down Aug 03 '12 at 16:30
  • @TimDown: well, I'm more optimistic there. I honestly hope and think, that browser vendors eventually will agree and work on original W3C specs (which they already do of course). So huge librarys to abstract bugs/errors/wrong implementations should not be necessarry in the future. – jAndy Aug 04 '12 at 11:52
  • @jAndy: well, jQuery offers a lot that goes beyond W3C, such as its animation capabilities. Here jQuery often offers a really neat syntax. IMHO in general JavaScript should be given a cross-browser available standard library. The strength of Java and C# is that they come with a huge library; JavaScript is totally lacking here, which is why there is jQuery, Dojo, Mootools, prototype and so on. – Has QUIT--Anony-Mousse Aug 04 '12 at 15:35
4

I would recommend using the DOM properties wherever possible. Nearly all of them will cause no problem, performance will improve and you become less reliant on jQuery. For properties like checked, for example, you're much better off forgetting all about jQuery, which only serves to add confusion to a simple task.

If you're in any doubt for a particular property, you could have a look through the jQuery source to see whether it has any special handling for that property and view it as a learning exercise.

Tim Down
  • 318,141
  • 75
  • 454
  • 536
  • 1
    +1 For checking the source code. The source is the best source of information for information about the source. – chucksmash Apr 17 '13 at 13:22
2

While many people reject such claims, I have also observed that avoiding/minimizing the jQuery usage can yield significantly faster scripts. Avoid repeated/unnecessary $() in particular; instead try to do things once e.g. a = $(a);

Things that I have noticed as being quite costly are in particular $(e).css({a:b}).

Google's optimizing Closure Compiler supposedly can inline such simple functions, too!

And in fact, it comes with a rather large library (closure library) that offers most of the cross-browser compatibility stuff without introducing an entirely new notion.

It takes a bit to get used to the closure way of exporting variables and functions (so they don't get renamed!) in full optimization mode. But at least in my cases, the generated code was quite good and small, and I bet it has received some further improvements since.

https://developers.google.com/closure/compiler/

iambriansreed
  • 21,935
  • 6
  • 63
  • 79
Has QUIT--Anony-Mousse
  • 76,138
  • 12
  • 138
  • 194