another very good tool to compress javascript files is jammit, we have been using it to manage projects with many files around 300
On Dec 16, 2010, at 3:34 PM, Joel Dart wrote: > 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: [email protected] [mailto:[email protected]] 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/[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] > > -- > 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] -- 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]
