Website JavaScript Strategy - What to Include?

Question

I've been using the jQuery library in our company website for a few weeks longer than its "official Microsoft endorsement". As we find ourselves applying it more and more throughout the site, questions are now being asked about our design vision and implementation strategy for jQuery. Currently, we have none.

I've put some initial thought into what this formal strategy might include, but I want to know if anyone else out there already has an example? Does your company have any such strategy / vision / roadmap documented? What did you include?

What should I include as a common-sense set of criteria? My initial thoughts are:

• where and when to apply jQuery;
• what it aims to achieve (i.e. rationale for using it instead of other comparable frameworks);
• expectations around coding standards (namespacing, chaining, selecting, etc);
• how to socialise its use around business stakeholders (i.e. helping the business / client understand the difference between jQuery and Flash)

Answer 1

• Where and when NOT to apply jQuery

A little goes a long way. If every div animates and resizes and you have modal popups for every button I click on, I'm going to not like using your website.

I suggest mentioning some cases where using JavaScript doesn't make sense and how to use jQuery modestly to overall enhance the websites interactivity without making the experience distracting.

Answer 2

With regards to these questions that are now being asked, who is doing the asking and what do you believe is their intention?

Why do I ask about this? Because terms like strategy, vision, and roadmap are the kind of terms used in Enterprise Architecture. If that's what they are interested in, then they are not looking for a developer or UE guidelines document.

Answer 3

For your first point, it should only be applied after the application/website already works without it. Use it as window dressing, not the window itself.

Answer 4

I find it a bit unusual that people regard jQuery merely as a big JavaScript library. They're disregarding the fact that it's also a framework, that is, you already have a structured approach towards developing your javascript architecture right there.

So my basic answer would be to use jQuery everywhere. You've got a feature rich monad at your disposal to develop various components of your system, ranging from front-end models to visual components coupled with back-end code. It simplifies organizing your JS files, they can be properly documented, referenced in an IDE and minimized before deployment automatically.

Once you also commit yourself to having jQuery be a core part of your total web application, you'll be amazed how easy it is to get rid of the handling mess surrounding javascript consuming when you structure your files and develop some dynamic loading approaches. Web app frameworks will start maturing around proper JS consumption.

And I don't think it's entirely hard to popularize the use of javascript and a framework. Hell, JS is what made Gmail possible and frameworks are there to make it even easier. With just some ingenuity with your templating engine and using jQuery to add functionality to your interface if javascript is enabled, you can have a completely functional web application, plus all the goodness if jQuery is enabled and semelessly update parts of your application without having to directly access a certain URI.

Answer 5

I am not exactly sure what you mean by having a roadmap around jQuery. Roadmaps are usually associated with products that you are building out. There should, however, be consistent usage of jQuery throughout the company so code is maintainable and reusable.

1. Have all developers read jQuery for Programmers so they know the correct way to apply jQuery. Or derive from that document and publish it as a Wiki so it evolves.
2. Have a style guide for best practices and patterns to use. Things like promoting the Module Pattern, leveraging noConflict() or (function($) { /*code here */ })(jQuery); idiom and things of that nature.
3. Stick to progressive enhancement

4. Do not use javascript for styling--this is a common trap:

   $(".btn").onclick(function(){ this.css('color' : 'red') // avoid css $(".btn").onclick(function(){ this.toggleClass('clicked') // use classes

5. Create your own library and consistent themes

Once you seed the initial document/wiki, it should continue to evolve.

Answer 6

Thanks for the input to all who answered, however I don't feel that any one answer really satisfies what I was actually after in this question. I've upvoted those who made helpful contributions, though.

I've created a strategy document for my company which has been accepted and a sanitised version of this is available on my public SkyDrive folder for comment (.docx format only at this stage - let me know if you want it in a different format).

Answer 7

The key concept with jQuery is using it as a complete visual framework, not just for some special effects

The web server should only serve static resources (.js, .css, .png) and web service endpoints (WCF or .ashx etc) for the jQuery code to consume

This process is a radical departure from traditional (.asp, .php) and more contemporary web sites (.aspx, microsoft MVC (not MVC as a general pattern)) frameworks

If you go this far, why not consider full screen SilverLight, even more fun! Smaller code files than html+js, faster, and more dynamic

You can also leverage your SilverLight code into WPF apps to make complete desktop version of web apps. very handy in corporate environments