Concerning the 1 file vs many files, one common approach is to combine your files on production but develop the files separately. You can use Squishit (http://www.codethinked.com/post/2010/05/26/SquishIt-The-Friendly-ASPNET-JavaScript-and-CSS-Squisher.aspx) for an asp.net site and it will even include separate files when building debug and then combine when you build release. Last week you could get it from NuGet, but this week I can't seem to find it. Either way, the blog post above points to the github repo.
-----Original Message----- From: jsmentors@googlegroups.com [mailto:jsment...@googlegroups.com] On Behalf Of Free Spirited Software Sent: Wednesday, December 15, 2010 7:20 PM To: The JSMentors JavaScript Discussion Group Subject: [JSMentors] Best practices for using Javascript 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/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
