5

I'm a very beginner to jQuery, and I'm having some basic questions:

  1. Is it advisable to use jQuery whenever it is possible to replace something by using it? For example, is it prudent to bind all events to elements using it, instead of through HTML?

  2. Is it better to host the jQuery .js file and all other relevant files (like JQuery UI) myself, or is it perhaps a better choice to use Google's link (they seem to host it for others too)?

  3. When it comes to executing a script when the page is done loading, what way is preferred?

    1. $(document).ready(function() {})
    2. $(function() {})
    3. $().ready(function() {})

    They seem to all do the same thing, but what is the preferred way of scripting?

pimvdb
  • 151,816
  • 78
  • 307
  • 352

6 Answers6

2

  1. Yes. This way your JS is cleanly separated from your html. You can look at your file and in one glance, see how it is affecting your HTML. If it was embedded in the HTML, you would have to look for onClick, onLoad etc and it can get pretty messy for large applications.

  2. Client browsers will cache files, so if you use the google version of JQuery, it will not have to download it off your server. Saving you bandwidth.

  3. $(document).ready(function() {}) Is the preferred choice. $(function() {}) Just defines the block for execution, it will only execute after the page is ready if it is the last thing on the page to get executed.

Chris Kooken
  • 32,730
  • 15
  • 85
  • 123
  • I think it would be nice to elaborate on #3. I haven't seen any difference in using 1 or 3 (I think 2 runs the second it's hit, rather than when the document is loaded, but I'm not 100% sure) and while I prefer using the option you specified, is it really only because of the syntax (which makes it obvious when it's called) or are there other differences? – Kris Jan 18 '11 at 15:07
  • It is more readable...you know what its doing without looking it up. Almost every JQuery plugin and site shows document ready. Every company I have worked for that uses JQuery uses Document.ready. Its the most commonly used for sure. Which i think makes it the preferred choice. – Chris Kooken Jan 18 '11 at 15:07
2

1.) Yes and No. It is considered best practice to bind events unobtrusive regardless of using jQuery or not (this means, strictly separate javascript, html and any other language). Since jQuery allows to easily bind events it's a better way to use inline-handlers.

2.) You should use a CDN (like google) to deliver static files like jQuery for Caching purposes + they have a huge server network which may even be faster than your own host.

3.) I would stick to the first two calls. Anyway, basically they all will do it, but the best readability probably has $(document).ready(function() {});

jAndy
  • 231,737
  • 57
  • 305
  • 359
2

1) Keep all your event binding in your script. This makes it easy to change later. You'll also appreciate having a single place to look for all event-related logic.

2) This has been answered very well already.

3) I prefer #2 for its brevity, but really the ideal way to do it is like this:

jQuery(function($) {
  // Your code using failsafe $ alias here...
});

That avoid conflicts if you are using other frameworks that define $.

Community
  • 1
  • 1
MikeWyatt
  • 7,842
  • 10
  • 50
  • 71
1

1: no this is completely up to you. generally jQuery incurs a performance penalty, because it is an extra layer of abstraction. Only use it, if you feel it helps you do your job easier. However, unless you truely need to optimize for performance the benefit in using it will far outway the cost. jQuery gives you tried and tested crossbrowser compatibility, which, if you wish to cater to all the different browsers out there, can be a costly affair to implement yourself.

2: Use Googles version: that way there is a chance that your users already have it cached and don't need to load it again from your site.

3: 2nd option, the shortcut is very widely used to a point where i'd say it's prefered even though 1st option is nice and specific. I'd never use 3rd option

Martin Jespersen
  • 25,743
  • 8
  • 56
  • 68
  • I see you do not complete agree to Chris. Is the time penalty negligible or should I really be aware of it? – pimvdb Jan 18 '11 at 15:07
  • 1
    i think the OP in point 1 was referring to $().click() vs. onclick="", and i think you answered jQuery vs. pure javascript. If so, I also understood it like you, although other answers think differently, and on second thought, I think theyre right. Although maybe i misunderstood you – davin Jan 18 '11 at 15:08
  • @pim: It depends what you need. jQuery is there for convenience and it can seriously cut down development time. If the application you are building isn't handling huge amounts of data, chances are the performance penalty of the abstraction layer is a non-issue. If you like me work on a huge project that handles very large data amounts, jQuery can become a bottleneck you try to avoid whenever the increased development time-cost is low enough – Martin Jespersen Jan 18 '11 at 15:10
  • @davin: I did indeed, sorry for not being fully clear. @Martin: I'm creating a rather small project myself, so no issues with large data handling. I guess I would be better off separating so as to make the code clear than struggling with time issues which are not really important. – pimvdb Jan 18 '11 at 15:18
1

For the 3d point, none of them. it is generally recommended, for performance reasons, to place your scripts just before the closing </body> tag. Thus you will not need to wait for the ready event: at this stage, the page is already loaded.

Check Jquery Cookbox (O'Reilly), Chapter 1.2: Executing jQuery/JavaScript Coded Ater DOM Has Loaded but Before Complete Page Load (that book is a must read all in all)

To have a quick idea about this technique, check Move jQuery to the end of body tag? (there are many other posts on SO about this subject)

Community
  • 1
  • 1
Maxim Gueivandov
  • 2,370
  • 1
  • 20
  • 33
0
  1. I personally don't subscribe to the "cleanly separate JS from HTML" philosophy. I rarely see real world use cases where that has any benefit. Separating HTML from JS often leads to buttons that say "click here to do X" in the HTML but do nothing unless the appropriate javascript is with them. Kind of misses the point. With the case of jQuery and events... I find it much easier to debug an app if I can inspect an HTML button in firebug and see what that button does (by looking at the onclick attribute).
  2. Using the google version can aid with caching, but don't link directly to jquery.com. We did that here once and they went down, took us with them.
Mike Ruhlin
  • 3,546
  • 2
  • 21
  • 31
  • Maintainability nightmare. If you want to know what a button does, use descriptive ID/class names. Your "click here to do X" scenario is simply bad design, there is no proper no-JS fallback. – kapa Jan 18 '11 at 15:22
  • That is the direction my company has gone, but searching through multiple javascript files for the ID of an element, only to find out that somebody attached an event using the class name instead of the ID, is way more of a maintainability nightmare than having to edit both HTML and Javascript files to make a UI change... Most of that probably does come from poor design, but unfortunately I don't choose the people I work with or the deadlines that drive them to get things done fast instead of right. – Mike Ruhlin Jan 18 '11 at 15:35