For reliable multichannel web (mobile, tablet, desktop, etc) it is important to avoid or at least reduce the amount of JavaScript.

There are of course some things that JavaScript is essential for, such as:

• Form Validation (prior to a request)
• Inline Calculation (prior to a request)
• Hijax / Ajax
• Eager Loading
• Interactive design elements

JavaScript should not be used:

• For business logic
• Instead of middle tier logic
• For DB / Service calls to back-end
• To mimic native behavior
• To Complex DOM manipulation

The Problem:

Many sites use excessive JavaScript to behave as if they were a native app or for unnecessary "cool" features that are not cost effective.  There are several disadvantages of doing this:

1. If you pretend to be a native application, you are setting up the users expectations.  Those expectations will not be met from a request response paradigm.

2. Building a mobile / tablet site that looks and feels native means you are building a specific single channel site or at least a specific design for mobile / tablet. Why would you have separate designs / look-and-feel for a single channel unless there is a very strong business reason to offset the significant increase in cost? Design should reflect the product / company and not the platform they appear on and therefore should be homogeneous across all channels (mobile, tablet, desktop, etc). It is possible to use adaptive design to build once and use everywhere across all channels. (Note: this blog fits nicely into all screen sizes, try resizing your window). Adding too much complex JavaScript into a site makes it considerably harder to support multi channel and in most cases is not cost effective.

3. JavaScript runs differently across different browsers and devices, in fact the mobile web is a hostile environment for JavaScript.  For example even devices from the same manufacturer such as iPad and iPhone often behave quiet differently.  This is due to timing differences between JavaScript execution, page reflow and DOM updates.  Between operating systems the differences can be even bigger such as between iPhone and Android.

   How user interaction (i.e. events) is optimised is different on each browser.  The problem is that there is only a single UI Thread (i.e. limited resources) that handles all screen updates and JavaScript execution.  Therefore to ensure that the browser does not lock up and stays responsive each browser takes a different approach to avoiding "unnecessary" work.  For example, when a user triggers an event (i.e. clicks a button) while JavaScript is already executing:

   • that event maybe ignored completely
   • that event maybe ignored partly because multiple similar events (i.e. multiple clicks) get "dropped"
   • that event maybe may fire (i.e. JavaScript handler executes) but the screen update won't happen
   • or some other random stuff depending on the specific browser

   For example Internet Explorer throttles JavaScript tasks triggered by user interaction so that it recognizes only two repeated events in a row and drops subsequent events.

   The questions to ask yourself are:

   • Will the site break on the latest new mobile device?
   • How will I know if the site works on all key devices?

4. The level of testing required is much higher with JavaScript.  In a browser it is not possible to control the execution environment unlike with a Web Server due to the difference combinations of mobile hardware, operating system and browser versions.  Therefore the same functionality has to be tested across a wide range of devices.  Even if this is done, it is not possible to be confident you have covered all devices.

5. Is there a reason to add extra complexity? It seems like too many sites have "cool" features that may look sexy the first time you see it but don't actually improve the user experience. These features are very expensive to build, support and maintain. I would recommend "if in doubt leave it out" and if you can't do without it try using A/B or Multivariate testing to show whether new features actually improve profit. Does the business realise by adding these cool features the site will take longer to build, cost more to support and will be more likely to have bugs? In addition in most cases these extra features reduce performance as they add extra page weight.

In summary putting all the functionality into the Web Server or other middle tier components ensures you control of the execution environment.  This means complexity reduction, increase of reliability and reduction of testing and maintenance costs.  The only hurdle to overcome is to convince the designers to produce a design that is homogeneous across all channels and doesn't behave like a native application.

It is of course possible to build a web application that behaves like a native application. However, the question is not whether it is possible, but whether it is the sensible profitable thing to do.

The Solution:

1. Ensure all features / User Stories work with and without JavaScript, for the following reasons:

   • Encourages all developers to push complexity from the browser where it is expensive into the middle tier where it is significantly cheaper for development, testing, support, and reliability.
   • Allows you to disable JavaScript for a problematic device instead of delaying the release for all devices while you fix bugs for a single devices (i.e. a single problematic mobile).
   • Ensures your site will work across the widest range of devices as you are reducing the capability the device needs for your site to work.
   • Reduces the cost of testing, as it is simpler to test middle tier code using automated tests (i.e. unit tests). Browser code can often only be tested effectively in the context of a web page requiring selenium or some other more complex testing approach.
   • Reduces the number of bugs, it is simpler to find and fix bugs in a type safe language such as Java or C# where the compiler does a lot more checking of the code.
   • Reduces the required skill level of developers. Developing in the middle tier is an easier task and requires a lower level of skill therefore it is possible to employ a less senior (cheaper) mix of developers.

2. Build Mobile First. This will encourage you to reduce complexity. Remember 80% of your customers use the core 20% of your features. These are the features on a mobile site, perhaps these should be the features on all channels?

3. Ask why complexity is required in the browser? Does it warrant the product release being delayed, costing more to build, test and support? Is the correct trade-off being truly considered?

4. Use A/B or Multivariate testing to demonstrate whether "cool" features have a long term impact on profitability.

5. Ensure the Product Owners, User Experience, Designers and Developers understand that complexity increases costs, causes delay, reduces flexibility, and reduces reliability. Decisions need to be questioned using MoSCoW or some similar techniques.

A general principle to follow for multichannel sites is don't try to compete with native applications and when in doubt, leave it out.

“No matter how beautiful, no matter how cool your interface, it would be better if there were less of it.”