It's a really good question but I don't know if there is a good answer. I prefer to have one file with common functions for all my pages and use multiple JS files (and multiple CSS files) for specific behaviour. It's easier to develop and debug because there is no file with thousands of lines, it's harder to accidentally use an already used class / id. I think the cache/performance issue is not the most relevant in a web application (especially for intranet applications) : the application probably use 3rd-party libraries, maybe with plugins, and those libraries probably use multiple CSS/JS files and multiple images, so loading one js file per page won't have a real impact on the loading time.
Moreover, multiple JS file reduce the dead code extent in an evolving application. And I don't use inline calls at all. Inline calls is a good method to notice that an handler is bound too many times and could be bind to a parent node (in a list for example). It's a good method too to avoid to bind two (or more) times the same handler to an event but I prefer to have all my JS code in an external file to avoid to have to edit the markup to change the page behaviour. Loïc On Thu, Dec 16, 2010 at 01:19, Free Spirited Software < [email protected]> wrote: > Sorry for reposting this from the old list - I was having such patchy > message transmission I never saw replies to the original thread. > > > I’m trying to formulate some requirements and guidelines about > JavaScript use in a product I’m involved with. I’ve been having > trouble finding advice on best practices that fit our situation. > > As background, the site is an ASP.NET web forms site, so inline > JavaScript from ASP.NET controls is not going away no matter what > guidelines I formulate. > > Also, the site is mandated to require JavaScript. Hence JavaScript is > a core part of site behaviour, not simply an added and optional set of > behaviours, and there is no need to take progressive enhancement into > account. > > This means that while the principles of unobtrusive JS are worth > noting, they are not entirely relevant to us. > > Updates are infrequent enough that there’s no need to consider > splitting JavaScript between files based on volatility. > > With these facts in mind, I see four approaches to consider: > > ---- > > All code served in a single JavaScript file. Element related code > applies itself to elements based on classes and IDs. Page related code > is triggered by the presence of classes on the body element. > > Pros > • Only a single file – less gets, better caching. > • No per page JS code means smaller pages served. It is also best > practice. > • Consistent way of specifying behaviour – always by class/ID. > > Cons > • A lot is going to occur in DOM Ready. Every new piece of > functionality means another DOM search in DOM Ready. > • Have to be aware of the behaviour implied by putting classes and > IDs > on items. With markup being supplied from an external design company > this is especially true. Having behaviour and design classes when > appropriate would make this less of an issue. > • Developer learning curve. Developers are used to declaratively > specifying behaviour for their pages. > > ---- > > Code in multiple files, one common file and then a bunch of files that > are included when specific behaviour is required. Element related code > applies itself to elements based on classes and IDs. Page related code > is utilised by including the appropriate file. > > Pros > • Page rendering is streamlined, as some code is only ran when > required. > • Easier for developers to understand how to specific page level > behaviour and special behaviours – include a JavaScript file, rather > than apply behavioural CSS classes. > • No per page JS code means smaller pages served. It is also best > practice. > > Cons > • Multiple files being served. > • Still some behaviour in DOM Ready. New pieces of common > functionality means additional DOM searches in DOM Ready. > • Have to be aware of the behaviour implied by putting classes and > IDs > on items. With markup being supplied from an external design company > this is especially true. Having behaviour and design classes when > appropriate would make this less of an issue. > • Developer learning curve for usage of common functionality. > Developers are used to declaratively specifying behaviour for their > pages. > • Multiple methods of specifying behaviour – both by class/ID, and by > JavaScript file inclusion. > > ---- > > All code served in a single JavaScript file. Some element behaviour > implied by classes, some assigned to elements by inline JS function > calls within pages assigning behaviour to elements. Page level > behaviour by inline JS function calls within pages. > > Pros > • Only a single file – less gets, better caching. > • Page rendering is streamlined, as some code is only ran when > required. > • Easier for developers to understand how to specific page level > behaviour and special behaviours – inject inline JavaScript function > calls using, rather than apply behavioural CSS classes. > > Cons > • Still some behaviour in DOM Ready. New pieces of common > functionality means additional DOM searches in DOM Ready. > • Have to be aware of the behaviour implied by putting classes and > IDs > on items. With markup being supplied from an external design company > this is especially true. Having behaviour and design classes when > appropriate would make this less of an issue. > • Developer learning curve for usage of common functionality. > Developers are used to declaratively specifying behaviour for their > pages. > • Multiple methods of specifying behaviour – both by class/ID, and by > inline JS function call. > • Pages inflated by JavaScript function calls. > > ---- > > All code served in a single JavaScript file. All JavaScript is > contained within functions. Element and page level behaviour is > triggered by inline JS function calls within pages. > > Pros > • Only a single file – less gets, better caching. > • Page rendering is streamlined, as code is only ran when required. > • Easiest for developers to understand – all behaviour is triggered > via inline JS function calls, the style of code they are used to > writing. > > Cons > • Pages inflated by JavaScript function calls. > > ---- > > In general, I’ve seen plenty saying that inline JavaScript is bad from > a separation of content and behaviour perspective, but nothing that > talks about other reasons why this is bad, or explains if there are > better ways to replace it than a JavaScript files with a Document > Ready function does a set of searches to apply functionality based on > CSS classes and IDs. > > With this in mind, I’m inclined to go with the single file, all > JavaScript explicitly called via inline JS function calls within pages > model. My reasons are that it’ll be easiest for developers to > understand, and because the ASP.NET JavaScript means that there’s > plenty of inline JavaScript no matter what. > > I’d be very interested to know if I’ve missed any approaches worth > considering, or anything from my Pros and Cons. In particular, are > there any issues with calling JavaScript functions from inline code in > a script element at the bottom of the HTML document that I’m not aware > of? > > > Mandates no matter the approach I choose will be > > • No use of event handlers via element attributes. All event handlers > must be attached by JS functions. > • (If inline JS is allowed) No inline JS other than calls to > functions > defined in our JavaScript files. Inline JS should be utterly minimal. > • (If inline JS is allowed) Only very simple data is allowed to be > passed into JS functions. Any structured data must be stored in the > document in HTML5 data attributes, or retrieved from web services via > AJAX. C# code building JavaScript data structures is nasty, IMHO. > • Proper use of namespacing is mandatory. > > Any thoughts on these mandates, or suggested additions? > > > I’d love some perspective and discussion from those who know more than > me. Thanks for any input you may have. > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected]<jsmentors%[email protected]> > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
