Hi Sam,
I'm going to add one idea:
If using DOM queries to attach behavior to the page, it's essential that all
selectors are defined in a single place (preferably at the top) and not
scattered in the code, which is maintenance hell.
My approach is to always have a cacheDOMElements() method in each JavaScript
module, which assigns the DOM elements I retrieve from the page to some
variables (usually packed into an 'elem' object). So I would have:
module.elem.button1 = $("#button1");
module.elem.button2 = $("#button2");
and that would be the last I'd see of HTML IDs and classes.
Have a nice day,
Dan Burzo
On Wed, Dec 8, 2010 at 03:18, Sam Stephens <[email protected]>wrote:
> Hi all, this is my first post. I’ve been enjoying following the list so
> far, and learnt a few things.
>
>
>
>
>
> 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.
>
>
>
> *Sam Stephens*
>
> Senior Developer
>
>
>
> [image: cid:[email protected]]
>
> [image: cid:[email protected]]
>
>
>
> *DDI *04 462 7997 *EXT *49097 *
> **www.kiwibank.co.nz*<http://www.kiwibank.co.nz/>
> * *
>
> Kiwibank Limited, Level 6, 155 The Terrace, Private Bag 39888, Wellington
> 5045
>
>
>
> This email, including any attachments, is confidential. If you are not the
> intended recipient, any use, distribution or copying of this email
>
> or the information contained in it is prohibited. If you have received this
> email in error, please notify us immediately and delete it.
>
> Please consider the environment before printing this email.
>
>
>
>
>
> _______________________________________________
> JSMentors mailing list
> [email protected]
> http://jsmentors.com/mailman/listinfo/jsmentors_jsmentors.com
>
> List Archive:
> http://jsmentors.com/pipermail/jsmentors_jsmentors.com/
>
_______________________________________________
JSMentors mailing list
[email protected]
http://jsmentors.com/mailman/listinfo/jsmentors_jsmentors.com
List Archive:
http://jsmentors.com/pipermail/jsmentors_jsmentors.com/
