Julian Shapiro is a technical startup founder. His first company, NameLayer.com, was acquired by Techstars. His current focus is on UI animation. He hopes to bring us one step closer to Minority Report. Read more about him at Julian.com.

Julian's articles

  1. Incredibly Fast UI Animation Using Velocity.js

    Performance affects everything. Increased performance — apparent or real — improves user experience. In turn, improved user experience boosts the bottom line.

    Several major studies have proven that increases in latency drastically decrease revenue. Bing reported that a 2,000ms increase in latency results in a whopping 2% decrease in revenue-per-user. Similarly, Google found that a 500ms delay causes a 20% drop in traffic.

    Thus, at the heart of my journey toward building a performant UI engine, I was simultaneously building a user experience engine. This article serves to contextualize the current web performance landscape, and to dive deeply into the performance optimizations underlying Velocity.js—an animation engine that dramatically improves UI performance and workflow across all browsers and devices.

    Before diving into Velocity, let’s answer the pressing question. How is it possible that the browser has secretly had tremendous performance potential for years, but that it’s remained largely untapped by front-end developers?

    The short answer: There’s a fundamental lack of web performance awareness among developers. Let’s explore.

    Web Performance Landscape

    From the perspective of UI design, there’s no shortage of articles extolling the virtues of building mobile-first, responsive sites. By now, developers get it. Conversely, from the perspective of UI performance, most developers will admit that they don’t know what they’re doing. While advocates from Google, Mozilla, and Microsoft have written countless articles on performance best practices, most developers simply aren’t reading them.

    Compounding this lack of awareness is the dynamic that, with UI design, artistic skill can be confidently iterated upon throughout years of experience. However, while the principles of performance (data structures, latency, and rendering pipelines) are subject to the same process of iteration, the specifics of their front-end implementations can change regularly. To put it bluntly, performance-minded developers are often held captive to browser quirks and device capabilities. Such a landscape necessitates that developers be astutely aware of the underlying architectural layers of the web (the rendering stack, garbage collection, and networking), so that they can broadly abstract their approach to performance problem solving.

    But with the workload developers already have on their plates, the current ethos suggests that it’s unreasonable for the average dev to master this domain. As a reaction to this, the web’s predominant performance advocate, Google’s Ilya Grigorik, recently wrote a point-by-point analysis of the myths surrounding browser and networking performance: High Performance Browser Networking. (Additional web performance resources can be found at the bottom of this article.)

    The current web performance landscape is analogous to staying abreast of IE8 quirks—after a while, you throw in the towel and simply raise the cutoff point for your site’s legacy browser support.

    The situation is nearly identical on mobile: Developers tell themselves, “Well, devices are getting faster. So throughout the coming months, my site will naturally become more performant as users continue upgrading their devices.”

    Unfortunately, the truth is the polar opposite: First, the smartphones that the developing world is adopting fall short of the performance of the iPhones in our pockets—do you really want to forsake building products for the next two billion people coming online? If your gut reaction is, “It’s not my problem,” rest assured that your evil web developer twin is sitting a thousand miles away cackling at the thought of getting to market before you do by putting effort into developing a solution that’ll be blazing fast even on low-powered devices.

    The upcoming Firefox OS initiative is poised to bring capable smartphones to hundreds of millions of people. The future is already here. We are not talking in hypotheticals. Ericsson reports that the global smartphone subscriber count will rise from 1.9 billion to 5.9 billion in the next five years — fueled almost exclusively by the developing world.

    The second danger of the set-it-and-forget-it mindset to web performance is that developers systematically make the mistake of testing their mobile pages on devices undergoing ideal performance loads. But, try opening up a couple more apps and web pages. Now, re-test your site. Yikes, you’ve just artificially recreated having a relatively “ancient” Android 2.3 device. Plus you’ve stumbled into the heart of our second problem: Browser-based apps are sensitive to device load—CPU, GPU, and memory usage. Add in the variability of device hardware, and you start approaching the reality of mobile performance: You should always develop the fastest site you can, not just a site that works fine on your iPhone.

    Performance is complex, and performance matters. That much is clear. But, what can we actually do about it? That’s what I set out to answer over a three month deep-dive into open source development.

    Web Animation Landscape

    Whereas jQuery—which doubles as the web’s predominant animation tool—began development in 2006, Velocity was built in 2014. As such, it incorporates the latest performance best practices from the ground-up.

    In short, Velocity is a lightweight CSS manipulation library with an animation layer on top. It’s powered entirely by JavaScript, not CSS transitions. It exposes the same API as jQuery’s $.animate() in order to ease the transition from $.animate() to $.velocity().

    Prior to Velocity, the DOM animation landscape primarily consisted of jQuery, Transit (the go-to library for controlling CSS transitions via JavaScript), and GSAP (the first performant JavaScript animation library).

    Here are the drawbacks of those libraries:

    • jQuery’s native $.animate() is slow and relatively light on UI animation design features—even when paired with jQuery UI.
    • Transit is considerably faster than jQuery, but is even lighter on features, is occasionally buggy due to its nature of shimming CSS transitions via JavaScript, and does not support IE8 and IE9 (which continue to have an enormous global browser share.
    • GSAP is a full-fledged animation platform with tremendous power. Its features are nearly limitless; it animates anything from the DOM to WebGL. (Velocity, in contrast, is solely focused on being a lightweight tool for drastically improving UI animation performance and workflow.) Whereas GSAP requires a licensing fee for various types of businesses, Velocity is freely open-sourced via the ultra-permissive MIT license.

    Velocity drastically outperforms jQuery at all levels of stress, and Transit beginning at medium levels of stress. GSAP performs similarly to Velocity. For head-to-head UI performance comparisons, refer to Velocity’s documentation.

    Timer Optimization

    We’re ready to dive into the juicy performance details. How do you make an animation engine fast? Is it micro-optimizations? Nope.

    There are zero micro-optimizations in Velocity. This is a trend I made sure to buck. Stack Overflow is full of jsPerf.com comparisons that well-meaning developers use to determine which JavaScript-based implementation is the most performant. However, developers often fall prey to these face-value comparisons without considering their context. If one implementation can already reach a few million operations per second, it is irrelevant how much faster its alternative implementation is. Your JavaScript code will likely never run at the scale of millions of operations per second.