The JavaScript blog.


design interviews animation ui authors

Interview: The Future of Web Animation with Julian Shapiro

Posted on .

Developer and startup founder, Julian Shapiro, has had an impact on the JavaScript world. We've covered a few of his web development accomplishments in the past: we wrote about the launch of Julian's text manipulation library, Blast.js, in addition to the work he's best known for: Velocity.js and Velocity.js' UI pack. The Velocity JavaScript animation engine is a top-ranked library on GitHub, with users including WhatsApp, IBM, Tumblr, Yahoo! and many others.

After receiving a grant from Stripe for his work on Velocity, he also built the fascinating Libscore, the community goodwill project that helps developers compare the relative popularity of web frameworks and third-party libraries. Recently, Julian wrote Web Animation using JavaScript for Pearson.

In our interview with Julian, we address the future of web animation, and the role JavaScript might play in it.

Julian Shapiro

DailyJS: What makes animation exciting in 2015—compared to the older Web 2.0 animation libraries?

Julian: We have faster browsers today, and they're only continuing to get faster at an impressive rate. The Chrome team, in particular, also happens to be aggressively pushing to standardize browser behavior on Android. Those two factors, combined with the increasing computing power of mobile devices, means that Web animation performance will continue to improve -- even if developers' implementations stay stuck in old ways. The other predominant trend in web development performance is simply its broader awareness, along with the increased importance being placed on it. Fortunately, performance is no longer a second-class citizen in web development education and industry news outlets. With broader awareness comes broader implementation and deeper understanding of best practices. Since there is a lot of low-hanging fruit that can be picked in web performance, this too will result in significant gains in site performance and usability in the coming months.

All of this leads to a performant base web development platform upon which beautiful and fluid animations can be layered. The higher we can push animations to perform -- across all browsers and devices -- the sooner the slick motion design commonly found in mobile apps will exist without compromise on the Web.

DailyJS: What trends will we see in the future of Web animation?

Julian:We might see a wave of too-clever and overused motion design in web user interfaces. Are you familiar with those awesome-yet-crazy After Effects-produced motion design examples on Dribbble? Those will become a technical reality on web pages soon enough. Like all things, however, I think the wave will peak then collapse, and we'll settle into a happy medium of quality user experiences bolstered by motion design that doesn't detract from usability.

In terms of trends, the inevitable growth of React Native might mean we'll also see a large shift in the tooling landscape toward the React ecosystem. I wouldn't be shocked if React is the future of web programming as we know it. If this turns out to be the case, animation engines will have to follow suit or they'll otherwise become irrelevant.

DailyJS: What type of animation works best in JavaScript, and what type works best with CSS?

Julian:In terms of common interface animations, CSS is best suited for simple element state-based animation, e.g. hovering, clicking, etc. As for intricate loading sequences, JavaScript animation is typically better suited.

When it comes to more complex motion design, such as page and element scrolling, physics-based motion, and touch and drag capabilities, JavaScript is the only realistic solution. I don't foresee this dichotomy changing any time soon.


Animation may very well permanently shift toward the realm of JavaScript as the ecosystem develops. Animation is too important of a UI design component to be relegated to the minimal programming logic of CSS (as is dictated and updated on an irregular basis by a standards body). JavaScript, in contrast, inherently allows a developer to layer an infinite amount of logical control over animation, and that power will prove valuable in ways we have yet to imagine. (Browser-based VR, anyone?)

DailyJS: What animation anti-patterns should developers and designers be aware of?

Julian: Utility and elegance are the goals of all great Web animation. Great animators deliberately choose every aspect (e.g. easing, target properties, duration, and so on) of their seemingly arbitrary animation sequences -- because they want to reinforce the intentions of a UI, and that's a very calculated decision. Whimsical motion design, in contrast, is not only inconsistent, but it also appears inelegant and diverting to the user.

The sad truth is that -- while there are hundreds of tutorials on the minutiae of UI design -- there is very little education on motion design. They're both very important aspects: Whereas UI design lays the structural foundation for interacting with a web page, motion design enriches that foundation with the furnishing and decoration that make the page usable and comfortable. If you allow me to be metaphorical for a moment, furnishing is the utility that motion design serves, and decoration is the elegance it provides. Great apps leverage both utility and elegance to make the user feel like they're interacting with an interface that's living, breathing, and tangible. In contrast, an interface that's devoid of motion design reminds the user that she's simply dragging a cursor across a screen or tapping her finger on a piece of glass. In other words, a web page without motion design can make the user painfully aware of the artifice before her.

With that context out of the way, common anti-patterns include:

  • Employing one-off motion design interactions that break from convention: The less you copy motion design from existing popular apps and sites, the less familiar your interface will feel to the user, and the less confidence she'll have when using it. While there's utility in novelty, the motion design of everyday UI elements shouldn't be novel. It should be reliably obvious.

  • Allowing complex animation sequences to consume a large total duration: Developers often make the mistake of letting animations run too long, causing the user to wait needlessly. UI flourishes should never slow down the apparent speed of a page. If you have a lot of content fading into view within a larger animation sequence, ensure that both the individual animation steps and the total animation sequence duration are kept short. Don't lose track of the bigger UX picture. Since it's difficult to judge the appropriateness of your animation durations after seeing them play out dozens of times during development, a good rule of thumb is to speed up all animations by 25 percent before you push a site to production.

  • Being frivolous: Interface developers should regularly be downloading the most popular apps, playing with them extensively, and judging whether they feature animation to a greater or lesser extent than their own work does. If they feel that the apps use animation to a much lesser extent, they need to consider toning back the motion design in their UI. Simply, if a particular piece of motion design doesn't provide psychological utility to the overall experience (affordance, clarity, connection, etc.), then its inclusion should be reconsidered. Injecting motion design for its own sake leads to bloated interfaces.

  • Not experimenting: Finding the right duration, stagger, easing, and property combinations for each animation is not a skill that designers are simply born with. It's a skill that every great developer-designer has had to hone. So, remember: your first attempt at a combination of animation properties might look good, but it's probably not the best combination. You should experiment by systematically changing each factor in the motion design equation into you stumble into something sublime. Once you've found a combination you love, experiment even further. Consider cutting the duration in half, switching to a completely different easing type, or swapping out a property. Designers are often averse to repeated experimentation because they believe in the sanctity of their whimsically-derived creative nuggets of insight. But insights have relative value, so it's important to get outside of your comfort zone to see what else you can come up with. Professional developers should strive for greatness, not goodness. Greatness always entails experimentation.

I've written a lot about these theoretical aspects of motion design in my book, which also dives into the topics of animation performance and animation workflow.


libraries ui design

Make Slicker Progress Bars with ProgressBar.js

Posted on .


Kimmo Brunfeldt sent in ProgressBar.js (GitHub: kimmobrunfeldt / progressbar.js, License: MIT, Bower: progressbar.js), a library for creating responsive progress bars. It uses animated SVG paths, so the results look very clean and cool.

The library has some built in shapes: Line, Circle, and Square. You can provide properties that are used to style the elements:

var element = document.getElementById('example-line-container');

var line = new ProgressBar.Line(element, {  
  color: '#FCB03C',
  trailColor: '#aaa'

line.animate(1, function() {  

If you want to include a number in the progress bar, then you can just set the text of a node. There's a clock example in the documentation that does this:

var element = document.getElementById('example-clock-container');  
element.innerHTML = '<header id="clock-seconds"></header>';  
var textElement = document.getElementById('clock-seconds');

var seconds = new ProgressBar.Circle(element, {  
  duration: 200,
  color: '#FCB03C',
  trailColor: '#ddd'

setInterval(function() {  
  var second = new Date().getSeconds();
  seconds.animate(second / 60, function() {
    textElement.innerHTML = second;
}, 1000);

You can also add arbitrary shapes with ProgressBar.Path. There's a really nice example that uses the Plough (Big Dipper) and connects each star together.

Part of the magic behind the animation in ProgressBar.js is powered by Shifty. This is a tweening engine created by Jeremy Kahn which can "tween" numbers or even CSS strings.

I really like the look of the progress bars Kimmo has used in the documentation, so I expect these will start appearing on websites soon.


libraries design articles layouts

Definitive Guide to Generators, Golden Layout

Posted on .

Definitive Guide to Generators

Gajus Kuizinas read through many ES6 generator articles before he understood them properly. I admit I've had the same problem: beyond the basic API, how do you do things like delegate yield statements, or raise and handle errors? And even with a good understanding of the API it can be hard to know when to use generators.

This confusion resulted in Gajus writing a detailed article about generators. It has lots of examples, including a handy gif that illustrates the flow of execution in a debugger.

Gajus' article covers pretty much everything I can think of, but even so I think it would be nice to see more practical examples to show you generators can improve real world code. I've been looking at how Koa projects use generators by searching for open source apps on GitHub, so that can be a useful way to see how people are using them.

Golden Layout

Golden Layout

If someone says "build me an admin area!" or "we need a dashboard!" I immediately reach for Bootstrap. But there are other options, and some may be a better fit depending on what you're working on. Golden Layout is a new "layout manager" for web applications that supports resizable windows.

It reminds me a little bit of an X11 window manager, a concept that has been tried many times in web development but has always felt a little unnatural. The examples in Golden Layout feel fast and precise -- there are no messy gradients or shadows. It may work well for projects that need to adapt to user generated data. This could be something like displaying tables or graphs, like an analytics tool or dashboard.

The examples include Highcharts, SlickGrid, and Angular. The tutorials expand on this further with RequireJS and more complex Angular projects.

This project is CC BY-NC 4.0, so you'll need to license it for commercial use. It's created and maintained by Hoxton One Ltd, a company based in London, and the source is on GitHub: hoxton-one / golden-layout.


libraries design modules chrome lint

fixmyjs, Front-end Development Tools

Posted on .



Sindre Sorhus sent in fixmyjs (GitHub: jshint / fixmyjs, License: MIT, npm: fixmyjs) by Josh Perez. It automatically rewrites JavaScript based on linting rules. There's a command-line tool available through npm, and a web version.

It supports things like semi-colon insertion, case correction, missing curly braces, and removes debugger statements. Sindre said Addy Osmani wrote an article about it, where he points out some important things that fixmyjs can get wrong:

As mentioned earlier, the current version of the module uses Escodegen, which rewrites your source and doesn't take into account original styling information (i.e it will strip it). This makes it easier for the author to support complex new rules as they operate with an AST rather than relying on less reliable approaches like string replacement.

You can avoid this by using the legacy option.

If you use Atom, then you can install Sindre's Atom plugin for fixmyjs. It uses legacy by default, and can be run on a whole file or a selection.

56 Expert's Favourite Front-end Tools

Bauke Roesink sent in a big list of front-end development tools, picked by 56 experts. Coincidentally, I happened to notice Sindre Sorus is on the list.

Several people picked Chrome, probably because the development tools have progressed so much over the last year or so. It's increasingly common to see people testing design ideas or puzzling over CSS quirks by editing HTML and CSS in the inspector. I've recently started using the device emulation tab a lot for responsive designs as well.


design node apps

Pageres: Responsive Screenshots

Posted on .


Sindre Sorhus sent in pageres (GitHub: sindresorhus / pageres, License: MIT, npm: pageres), a command-line tool for generating screenshots of websites.

You can install it with npm install --global pageres, and then run it with a URL and a size:

pageres http://dailyjs.com/2014/02/12/node-roundup/ --sizes 800x600  

It's based on webshot, which is another small module that wraps around PhantomJS. There are other modules like pageres, but what I like about it is the focus on sizes: you could script it to generate screenshots of responsive websites. The command-line options allow you to specify many dimensions at once, so it's easy to generate results for a responsive site.

This will work well if you've got marketing materials that include screenshots, or if your designers want to see useful outputs from a CI server.

Another cool feature is the Node API:

var pageres = require('pageres');

pageres(['todomvc.com'], ['1366x768', '1600x900'], function () {  

I've made a few lightweight wrappers around PhantomJS before -- there's a HTML to PDF invoice generator in production that I made last year that's been ticking over nicely. However, I like the focus on dimensions in pageres, and the command-line interface is very friendly.