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?

Improve this question
7
  • 3
    Yes, it's encouraged. Making (usually) two function calls to get something you already have immediate access to is pointless. Commented Aug 3, 2012 at 15:54
  • 1
    I wouldn't call Javascript "raw". Commented Aug 3, 2012 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. Commented Aug 3, 2012 at 15:55
  • @Hassan I used plain. That better? Commented Aug 3, 2012 at 15:55
  • haha "Raw Javascript" just sounded like an oxymoron to me, but it worked fine for your question. Commented Aug 3, 2012 at 15:57

3 Answers 3

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

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.
I strongly agree with jAndy ! There should be a death of jQuery.
@jAndy Quite like Flash (for video mainly) is becoming part of the internet's sordid history.
@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.
@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.
|
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.

Improve this answer

1 Comment

+1 For checking the source code. The source is the best source of information for information about the source.
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/

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.