Recently, Flipboard has released the web version of its social-network aggregation magazine-format reader. This release aims to bring to the browser the same reading experience users have on Flipboard native applications. To accomplish it, the team responsible for the development had to push boundaries in web technologies to match its native apps counterparts. Michael Johnston, engineer at the development team behind the web version detailed at Flipboard's official blog, some of the problems faced and how they tried to overcome it.
One of the first decisions they had was this version should scroll instead of having the normal page flip because according to them, scrolling seems more natural to users in a web environment. They also wanted users to have a 60fps experience, which means keeping paint times below 16ms and limit reflows and repaints. This is especially hard on mobile devices because of the phenomenon known as jank. In their opinion, the DOM is very slow and any interaction with it would end up exceeding the threshold.
With that in mind, they decided to use the Canvas because in Michael's words:
Canvas is an immediate mode drawing API, meaning that the drawing surface retains no information about the objects drawn into it. This is in opposition to retained mode, which is a declarative API that maintains a hierarchy of objects drawn into it. Canvas benefits from the immediate mode approach by allowing drawing commands to be sent directly to the GPU
Working with Canvas is hard, especially compared to HTML+CSS for many reasons such as: it can only draw a single line of text at a time, handling images can be complicated and overlapping elements does not consider any z-index. Even with all the drawbacks and difficulties, the decision was to go forward because as Michael put it:
You cannot build a 60fps scrolling list view with DOM. In contrast to the DOM, most devices today have hardware accelerated canvas implementations which send drawing commands directly to the GPU. This means we could render elements incredibly fast; we’re talking sub-millisecond range in many cases.
The fact that the Canvas has a very small API reduces the surface area for bugs or inconsistencies between browsers. It was however necessary to create an abstraction layer where developers could deal with a tree of nodes rather than a strict sequence of drawing commands. To complete the library the team implemented their own scrolling algorithm (with some optimizations like redrawing layers using an off-screen canvas) and packed everything under React Canvas, which is a React component that allows working with the Canvas in a more natural way.
The reaction of the community to this release was a mix. Everyone praised the amount of effort put into this project and how they shared their decisions, even the more controversial ones. Some liked the clean design or the smoothness of React Canvas, but others dislike the decisions made by the team mainly concerning accessibility. Faruk Ateş, the creator of Modernizr, wrote on his blog:
Flipboard is a product focused heavily around text-based content, which is why it’s so deeply regretting that Accessibility was thrown completely out the window by the engineering team. The entire “Web” version was written in a pseudo-DOM (Document Object Model) inside an HTML5 Canvas element. I’m also hopeful that Accessibility is the next big project to tackle for the engineering team. A 2.0 release, if you will.
Christian Heilmann criticizes the 60fps obsession and the endless scrolling:
Of course, we need goals to aspire to and some things to measure against. But defining something like 60fps as a baseline is pretty naive considering the fragmentation of hardware and the amount of abstraction layers an HTML5 app has to go through.
A lot of solutions have endless scrolling. Also true, many a time that is more annoying than a pagination would have been.