JQuery UK 2014 – developing long life web apps with Matt Andrews

On the 16th of May 2014 mso.net frontend developer George Broom attended the annual jQuery UK conference in Oxford. Here’s his report:

The event was really well organised and had a broad range of guest speakers, a must for any front-end web developer. One of the most interesting parts of the conference for me was the insight that was gained into how other businesses in the industry conduct their coding practices; the problems they’ve faced and how they’ve implemented fixes/procedures and resolved them. One of the standout talks from the day was “Long Life Web Apps” by Matt Andrews (@andrewsmatt), a developer at the Financial Times.

Matt began his talk by explaining that he wouldn’t be talking about jQuery, which seemed strange at first considering we were all attending a jQuery conference! Matt explained that the web development team behind the Financial Times (@FTLabs) made the decision to use their own javascript framework in the development of their long life web application.

Reasons for developing a long life web app

Matt explained that the Financial Times originally had an app in the Apple Store but after Apple changed its terms and conditions and began to charge its customers for downloading the app, the Company decided to remove it and develop a cross platform web application for the benefit of its customers.

In making this decision, FT Labs weren’t to know the difficulties they’d face in developing the web app to perform in an efficient and reliable manner across the vast range of platforms that are available today. It needed to be developed in a way that remained scalable and backwards compatible. The main focus of the web app was to allow customers to download a single page application that would work offline and take advantage of the memory and caching on the user’s chosen device.

Making use of the detached DOM

The FT Labs’ developers made use of the detached document object model (DOM) to allow the web app to work offline. The detached DOM can be found using the Google Chrome Developer Tools under Profiles and then Heap Snapshot, if you filter by “detached”, you’ll see the node. You can then hover over the results and be shown the detached DOM elements.

Matt was clear in highlighting the fact that one of the more annoying parts of working with a long life web app was finding and fixing memory leaks. These leaks could come from something as simple as not cleaning up after yourself. He gave the example – if you add an event listener, you need to remove it. Third party components can also be the cause of memory leaks within the web app. Any potential memory leaks should be able to be discovered using the heap profiler, again in the Google Chrome Developer Tools.

Keeping the memory usage under control has allowed Matt Andrews and the other members of the FT Labs team to increase the stability of the web app. It also allows the users’ devices garbage collector to do its job properly.

Issues with rendering within a long life web app

The other major issue with keeping the long life web app performing efficiently is the process of rendering the app. Matt discussed the issue of layout thrashing explaining that DOM operations are synchronous but ‘lazy’ by default. He expressed the need to batch reads and writes, explaining that browsers will batch writes for us but by reading something, you are forcing the browser to perform another write. Matt showed us a code snippet of some javascript written using this idea of batching but he then went on to highlight the fact that nobody writes code like this and it’s much more efficient to use Wilson Pages’ (@wilsonpage) FastDOM library to get an asynchronous DOM which uses the requestAnimationFrame to batch writes.

Handling navigation within a long life web app

Handling links is one of the main things that differentiates a website from a web app; clicking a link within a web app would normally cause your device to open the link in a new browser window. This is obviously not the desired user experience. Matt outlined that links within a long life web app should be handled using the following:

• Listening to clicks and stopping them performing their normal action using preventDefault()
• Save the scroll position of the current page
• Manually updating the user’s address bar using history.pushState()
• Render the new page for the user
• Restore the scroll position of the page, if appropriate
• Use history.back() to go back.

Matt then went on to highlight the fact that some of the points above won’t work in iOS7. For iOS7 it would be necessary to push the new URL into a custom history array rather than using history.pushState() and then load the last item from the custom history array when rendering the page.

Deciding when to load web app content from online or from the users’ cache.

The main advantage to a long life web app over a website is the fact that it will be usable without being online. Matt explained that it would be naïve to load content from the web if the device is online, and if not, use the cache. The issue being that you cannot safely rely on the browser method navigator.online. This was backed up by what Matt referred to as a fun fact:

In Firefox, navigator.onLine is only false when File > Work Offline is ticked.

From experience it would seem that the FT Labs team develops its web apps to assume that the app is offline, it then loads the content from the cache and then loads content from online in the background.

In order to allow a page to load offline it is necessary to use the HTML5 Application Cache. This sounded very straightforward and a quick way of getting started with developing long life web apps. Matt then went on to indicate why it’s not quite as simple as it sounds. The main issues with the HTML5 Application Cache currently are:

• Storage leaks (there are workarounds to fix these)
• Inflexible and unintuitive API
• Makes browser susceptible to man in the middle attacks

Matt also informed us that the HTML5 Application Cache will be replaced by a Service Worker in the near future – with Chrome and Firefox committed to building them. Even though there are obvious issues with the HTML5 Application Cache, Matt highlighted the main advantages to using it:

• It does work and it works across 80%+ of browsers.
• It enables amazing experiences for users

Making an offline web app backwards compatible

In the final part of Matt’s talk, we were introduced to the fact that the web app used by the Financial Times is developed in a way that tries to remain as backwards compatible as possible. The difference between native apps and offline web apps is that offline web apps will only download any updates when they’re open and it will only apply any new updates on refresh.

Matt then brought up a graph that showed the current versions of the Financial Times’ web apps that its users were currently running and it highlighted how important this need to be backwards compatible was. Some of its users were clearly just not updating to the new versions. Even though they try to keep everything backwards compatible, Matt was clear that it’s not always possible. His main guidance for keeping an offline web app backwards compatible was:

• It should be assumed that some users will end up getting stuck. Give users a tool to recover their app if things go wrong
• Always test different client side code against different backend versions in case something has changed
• Add your own monitoring to the app to keep an eye out for any issues
• Add recovery tools after a CSS animation, just in case the javascript that runs the app fails
• Make sure everything related to the web app is versioned.

Summary

This kind of web application clearly has its uses and I’m sure the implementation of service workers to replace the HTML5 Application Cache will encourage more developers to create apps in this way.

It was clear from Matt Andrews talk that he and the FT Labs team have encountered the majority of issues that anyone developing a long life web app for the first time will inevitably have to contend with. I found the subject matter very exciting and my brain was working overtime trying to think of ways that we could apply this technology to projects for clients.

The Financial Times’ web application can be downloaded from here:
http://app.ft.com/webapp