Financial Times' HTML5 development
Read this really interesting articles by an engineer from the Financial Times on developing their new app using HTML5. I have summarised my learning points and added some comments below.
Avoiding Javascript for rendering tasks permalink
Use pure HTML and CSS wherever possible, and gracefully degrade to using Javascript using shims only for platforms which do not support this. e.g. Flexbox vs pure CSS for layouts
Views as a composition of layout elements permalink
They call this “modularizing the views” Conceptually, this is a good principle, but I think that the implementation could be improved:
Original:
Improved:
This version gets rid of the unnecessary empty CSS selector - clutters the code, and wastes a few CPU cycles during the parse phase - although this is not really a big deal as it would have no effect on rendering and the rendering engine would likely optimise-discard it.
This version also gets rid of the prefix “apple_” in front of each class names within the article. The selector “.x .y” will match any element of class “y” that is a child of any element of class “x”. If you wish to match -only- direct children of “x”, then use “.x > .y” instead.
Now add semantics:
This version is about semantic HTML. If we know that that a “h2” element that is a child of an element of class “apple” will always be a heading, a “h3” a sub-heading, then use that.
Make sure to also avoid using “div” elements for everything. In this case, I think that “article” and “section” could be appropriate - after all it is a newspaper app! See Semantic HTML5for the full list. Of course, to render correctly in engines not supporting these elements, new in HTML5, we should also include a CSS reset:
(See the same Semantic HTML5 articlelinked above for a more comprehensive exploration of this)
Open source your libraries permalink
Their main app is not open source, and fair enough, they are a for-profit organisation. They have, however, open sourced the utility libraries that they have created and used in this app. Good on them for doing so!
Vector graphics permalink
What is interesting here is that they have had to use Font Glyphs (storing vector images in TTF’s and WOFF’s), in order to be backward compatible with older versions of Android. There’s one way of getting around platforms lacking SVG support!
Do not reinvent the wheel permalink
… except when you really need to. When they needed a means to provide touch-screen compatible scrolling capabilities to their app, they exhausted the possibilities trying out the existing libraries, before building their own.
Optimise to acheive native performance permalink
When scrolling, keep the adjacent pages cached. Discard and replace with the new adjacent pages upon scrolling. This is similar to a technique used in games programming where the map/ level and the textures in the surrounding areas are loaded in anticipation of the player about to enter them in ordert to avoid frequent cut scenes.
Use LocalStorage to cache and store almost the entire app. I found this “preload” technique to be quite interesting, not just from a offline app point of view, but from a performance point of view.
"Our approach to offline is to store as little in the AppCache as possible. We use it for … things that we know will rarely or never need updating. Our JavaScript, CSS and templates live in LocalStorage. This approach gives us complete control over serving and updating the most crucial parts of our application. When the application starts, the bare minimum required to get the app up and running is sent down the wire, embedded in a single HTML page; we call this the preload."
They also cache their images offlinein the local database, and compress it using a rather cool technique.
Fin permalink
This articles gives a real all round overview of the nuanced trials of making a HTML5 app. Learning points all round!