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 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.
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.
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:
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.
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:
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:
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:
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: