Flipboard Just Wants to Be Jank Free – InApps 2022

Flipboard Developer Michael Johnston wrote in a post to Hacker News on February 10th about the problems that come with using the Web as a platform for what has historically been a mobile service. The two don’t jive, especially when it comes to the ways that mobile apps perform in comparison to their web counterparts. As Johnston writes:

The DOM just works. But we need a better option on the Web in order to achieve the kinds of experiences that people have come to expect from native applications.

Johnston’s team is responsible for the functionality of one of the most successful news integration platforms outside the Web. Flipboard began its life in 2010 as an iOS app, with a finalized Android version generally released in the spring of 2012. Even a Windows “Metro” app version came the following year. Its signature move is described perfectly by its own name: it smoothly flips from page to page in 3D — like a magazine, except without the vertical gutter down the middle. Because Flipboard is primarily an aggregator, it’s the flip — the way you use the app — that gives it value. Otherwise there would be nothing to distinguish it from, say, Memeorandum.

Last week, for the first time, Flipboard migrated to the minority platform of the Web. But quite literally, it doesn’t do flips there yet.

To Scroll with Flare

In a “mobile first” world, the Web needs to at least be a decent follow-up act. But in a separate Flipboard blog post on February 10th that looked, almost surprisingly, like any other corporate blog post, Flipboard’s Johnston explained why the Web version doesn’t behave like native mobile versions.

Reason one is arguable: users expect the Web to scroll, so Flipboard on the Web should scroll too. But if it scrolls in a land of scrolling, Flipboard’s developers feel it should do so with distinction. What stands in the way is a phenomenon that has come to be known as jank, which could describe the feeling of trying to scoot a Rubbermaid placemat across a linoleum table.

There is even a Web site (albeit not an app) devoted to the study of the phenomenon: jankfree.org. “Jank is the result of frames taking too long for a browser to make,” reads an explanation from some contributors to the Chromium browser project, “and it negatively impacts your users and how they experience your site or app.”

Typical screen refresh rates are about 60 hertz (Hz). So if an animation being delivered to such a screen is 59 fps or less, there will be eyeballs somewhere that notice.

As Flipboard’s Johnston puts it, “We wanted to match the polish and performance of our native apps, but in a way that felt true to the browser.” Technically, the problem was this: to keep up with 60 Hz, page redraws need to take less time than 16 ms. “If you touch the DOM in any way during an animation,” he writes, “you’ve already blown through your 16 ms frame budget.”

You can imagine Flipboard’s predicament, not unlike a pizza franchise expanding to a continent where the oven hasn’t been invented yet.

They could either wait for someone to work out the patent rights, or else they could strike a match and light a fire.

Equal and Opposite Reaction

If game developers can make HTML5 rendering work smoothly for them, the Flipboard team reasoned, why can’t they do the same thing for themselves? So Flipboard decided to build methods on top of Facebook’s React.JS library, which has garnered considerable attention in the past year for its ability to render only the updated portions of pages — even though from the coder’s perspective, it appears the entire page is being re-rendered with each alteration.

Flipboard’s innovation will apply this new methodology to the <canvas> element — the geographic plotting system of HTML5.

These are coordinate schemes that harken back to the days of 16-color graphics mode on the Apple II.

Anybody who attempted to program serious business applications or even games during those heady days of the late 1970s and early ‘80s will recall that graphics modes for early microcomputers were not object systems. You plotted pixels on the canvas either by poking specific values directly into memory, or invoking commands that were re-interpreted to do that for you.

Essentially, the HTML5 Canvas bears very little conceptual difference besides resolution. It’s a 2D platform that doesn’t retain any “knowledge” of its contents besides the colors of pixels in rasters. There is layering…kind of. Even plotting text is actually a re-interpreted form of drawing graphics that ends up looking like text. It’s what we had to work when we first considered rendering online pages using VT220 terminal emulation.

The assembly, in-memory, of what text appears where on this Canvas will likely require a home-spun method of storing and recalling graphic objects — again, not unlike making a Space Invaders clone roundabout 1981. Flipboard’s library for establishing this system is called React Canvas. Arranging visual elements for React Canvas uses a language that merges CSS with an hierarchical scheme of markup code inside JavaScript, rather than the other way around.

Johnston explains, “Our canvas rendering engine was born out of the need to drive pixel-perfect layouts with multi-line ellipsized text. This cannot be done with conventional CSS, so an approach where everything is absolutely positioned fit well for us.”

The result, at least so far, is the capability to drive a theoretically infinite scrolling page with any amount of content, always scrolling at 60 fps. The reason is because React’s virtual DOM (HTML5 Canvas is an element of DOM, not a replacement for it) will always focus on rendering just the visible portion of the contents.

It’s the same solution that game designers discovered back in the days of Zaxxon.

“The hope is that by pushing the browser beyond its limits,” writes Flipboard’s Johnston, “we can make progress in this area.”

Feature image via Flickr Creative Commons