views:

74

answers:

6

I'm in the middle of building a web app with heavy use of jQuery plugins and lots of bindings.

The backend was developed with a template system which only allows (as of now) to place all scripts in that one HTML file. We will use YUI compressor to merge all these into one.

Now, for bindings, how bad is it to have binds in an HTML file (which now is a template for the whole site) for elements that may not be present on a particular page?

Any advice is greatly appreciated

A: 

Biggest problem for using all bindings on all pages is that you can get bindings that you did not intended to have, causing troubles...

And of course you will have some performance issues in the page load, but if that is a problem is of course depending on how many bindings you have and how the code looks like.

bang
A: 

You might lose some performance on the client side (parsing the file, executing the document-ready handler), but it improves caching on the client (i.e. the file doesn't need to be transferred more than once). That saves server lookups as well. I think this is rather an advantage than a disadvantage as long as you can ensure you're not accidentally modifying objects.

mnemosyn
A: 

I think the selector engine is fast enough that you, or anyone else, shouldn't notice a difference.

Obviously this is not a "best practice," but if you're binding to ID's and classnames and you won't have any conflicts or unintended bindings then I don't see the harm.

peterp
+1  A: 

Be careful with your selectors if you've got some large pages. For example, if you've got some pages with big, but inert (no bindings) tables, but other pages where tables are small but have controls in them, you probably don't want to do this:

$('td.bindMe').bind('whatever', function() { ... });

(Set aside the live() issue here; sometimes you need to do element-by-element work and that's what I'm talking about.) The problem is that Sizzle will have to look through all the td elements on the page, potentially. Instead, you can put some sort of "marker" container around things like the "active" table with controls, and work it that way:

$('table#withControls').find('td.bindMe').bind(/* ... */);

That way Sizzle only needs to figure out that there's no table called "withControls", and then it's done.

Pointy
+2  A: 

One of the biggest problems with doing this is one of performance - the selector will be evaluated and the DOM searched for each binding not intended for a specific page. At the very least, perhaps set up an object literal to run appropriate ready binding code based on a page identifier, which could be the window.location.href or a substring of. Something like

// avoid global pollution!
(function() {

    var pages = {

        pageX : {

            ready: function() { /* code to run on ready */ },
            teardown: function() { /* code to run on teardown */ }

        },

        pageY : {

            ready: function() { /* code to run on ready */ },
            teardown: function() { /* code to run on teardown */ }

        },

    }

    // set up ready event handler 
    $(ready);

    // handler function to execute when ready event raised
    // Note: Access to pages through closure
    function ready() {
        var location = window.location.href;
        pages[location].ready();
    }

})();
Russ Cam
+2  A: 

I've been using Paul Irish's markup-based solution pretty extensively on larger sites.

Mark Hurd
This is Excellent!!!! I'm already implementing it and so far the app is feeling much smoother.
Sam3k