I'm Matt, author of Framer Motion and Popmotion. Today I'm launching my new side-project, Motion One.
It's a new animation library built on the Web Animations API (WAAPI). I actually started this project as a book, but repeatedly found myself explaining some odd concepts (like fill mode) that I felt quite strongly that users shouldn't have to care about. I also discovered the state of WAAPI's implementation is very inconsistent across browsers despite green lights across caniuse [1].
Motion One smooths over these inconsistencies and adds an opinionated API that makes it easier to use [2]. In addition, it adds all the features you'd want from a modern animation library, like a timeline, independent transform animations, and soon, springs.
Being built on WAAPI means you also get hardware accelerated animations in a bundlesize thats around half that of Anime.js and a fifth of Greensock [3].
You mention here and on the homepage you are the author of Framer Motion and Popmotion but in neither place are there links to those projects. I'd love to check them out so if they still exist it may be worth making that text on the homepage a link?
Ah apologises I just wanted to reduce the number of "off ramps" and as the other comment says, I am sort of assuming that people might be familiar with them but indeed they might be more fitting to your project (Popmotion if you want very low-level JS animations that just outputs values and Framer Motion if you want a high level React library that handles gestures and layout animations)
But hezags comment below has kindly provided the links.
To be fair, Framer Motion and Popmotion are really big names in the web animation space, so it is probably safe to assume most people with even a passing interest in the past few years will have heard of them.
- hitting 'play' on your site's demo animations is adding pageviews to my history, which made getting back here to leave feedback unusually tough :)
- for some reason, even the basic demo animations on your site have BIG delays/stutter -- every one of them, every time I play them. For context, I'm running Chrome 93.0.4577.63 (Official Build) (x86_64) on macOS Mojave 10.14.6 on a 2018 MBP, and have ~60 tabs open.
1. Thanks for pointing out the play button bug - I'll look into how I can stop that.
2. That is really odd. I'm on a similar machine with no problems. Are these the same demos with the iframe or do you also have problems with the homepage?
oh interesting! I didn't realize they are iframes -- the homepage ones (e.g. the hero animation, the scale animation, the hardware-accel one) all seem fine, even right after pageload. It's the iframe demos that have the stutter/jump issues.
I also just noticed my mac is a bit slow across the board right now, so it may be my own issue, a bad case of "uptime-itis" that can only be solved by a restart.
Framer Motion is very high level, declarative API. It works out when to fire animations based on state and gesture changes. It also has a very advanced layout animations engine.
This is more of a classic JS library like Greensock or Popmotion where you say when you want to fire animations. I do want to move into declarative animations too but this is just the first release.
Hi there Matt - this looks like an amazing library - thanks for posting.
I’m part of the Blink Animations team that work on WAAPI (along with a bunch of folks from other browsers), and wanted to touch base on a few of the issues you raised.
First, I agree that fill behavior[1] is messy, and should probably be considered to be a spec bug. Moving web specifications forward often involves “compromises” to ensure that new functionality works alongside existing work, and this is a good example of that. There’s a discussion on this at github.com/w3c/csswg-drafts/issues/5394.
You raise a few issues with the current implementation/compliance/interop. Getting compliant and consistent implementations of the spec is critically important, so appreciate your feedback on this. I’m seeing two items that (might) relate to chromium here:
individual transforms[2] - agree that this is important - currently working on it - see crbug.com/696374. Note: You can already get some of this working using composite:add.
.finished Promise[3] - mostly working in chromium AFAIK, with one minor glitch - crbug.com/1141935
If there are other chromium issues we’d love for you to file them (use Blink>Animation component so they land on our triage). Other browsers look for feedback as well - there’s a good guide/walkthrough at https://web.dev/how-to-file-a-good-bug/
On the topic of browser compliance, you cited caniuse.com, which is a good starting point. More detailed tracking can be found at https://wpt.fyi/results/web-animations - might be more detailed than you’re looking for, but this is what our team measures against.
Some of your suggestions relate to the spec. Durations as seconds[4], and Simplifying cubic bezier definitions seem fairly straightforward, while others like cancelling and interrupting might be a little more complicated. In any case you can file issues against the spec if you want to move those forward - https://github.com/w3c/csswg-drafts/issues, tag with [web-animations-2].
To reduce the challenges of adopting the new API, there’s a published polyfill that you seem to be using already. You noted that there’s some inconsistency with keyframing across browsers - perhaps you could file an issue against the polyfill?
I think it's fair enough that there's "spec bugs" and understand the constraints you/they were working in trying to cover both CSS transitions/animations. I prefer browser APIs low level enough to build opinionated libraries around!
Individual transforms for me doesn't go far enough, I haven't been involved in spec discussions but I'm surprised they stopped at transforms and not axes. Think throwing an element - x/y would want different animations based on the gesture velocity. I'm not sure composite works well with transform as its order-dependent, the behaviour is itself not well supported cross browser, though maybe composite+individual transform offers promise in the future.
On the state of implementation in general, I am using this project to file bugs to help get some eyes on WAAPI and so far I've opened 4 in Webkit and none in Blink so there's no worries there :)
Thanks for wpt.fyi - I have bumped into it but I should use it to pre-empt some of these bugs.
The polyfill is just for running tests in Jest. It's actually a little beaten up in terms of implementation and this has worked quite nicely as Chrome even in modern phones seems to not support finished so its helped my polyfill(er)s target those bits too.
Imperative JS libraries are more convenient to schedule and dynamically generate animations, but above and beyond that this offers timeline sequencing for long animation orchestration, independent transform animations, and will soon offer spring animations.
Edit: And that CSS Tricks article covers more stuff well.
How exactly does that work with the MIT license? If someone sponsors and gains access to the repo, they're permitted to fork and redistribute the code, right?
Nothing in the MIT license prevents you from doing that. But the author could disable your access to the repo any time, and once that happens, your fork would be forever out of date I'd expect.
Of course, doing so would make me question why the author released this under a permissive license to begin with.
I'm not looking to block anyone. I want this to be open. And I don't want a confusing license. The code is pretty unobscured on npm so its less convenient but the source is free for anyone who can be bothered to go that route.
My reasoning is more that this is my side project, and I have limited time, and this seems like a good experiment to see if I can make OSS sustainable for once and also allow me to target help (my free time) towards users who are most invested in the project.
In the future I would like to open the repo but it might be tied to hitting a sponsorship amount or perhaps an extra service/product on top for those that want it.
Yeah that's fine. But repo access is more a convenience upsell, you can always get the source code (or pretty close transpiled code) from the npm distribution.
Given that the repo is private, I wondered if only the compiled version would be available. Looks like the published source is split up into multiple files, so this is a bit different from Mattermost, where the MIT license only applies to the compiled version: https://github.com/mattermost/mattermost-server/blob/master/...
That's an interesting approach but no the MIT license applies to everything and I don't want to stop anyone from knowing what they're installing and distributing. Github access is more of a convenience perk for sponsors at this early stage.
https://motion.dev/guides/performance: some of the information here is incorrect or inapplicable for Firefox these days: with WebRender, which I think is now enabled by default for everyone with the old pathway going away altogether soon, paint and composite are merged, with what were formerly paint operations no more expensive than what were formerly composite operations—so things like background-color, clip-path, box-shadow and border-radius are all cheap to animate in Firefox.
It’s not a big deal by any means, because the underlying concepts of caring about performance and some things being slow still hold, but my loyal Firefox heart yearns for at least a mention of it.
If you eschew layout-affecting properties (which are an actual defined concept that you can readily reason about, unlike the paint/composite divide where you’re left guessing which things are fast and which will slow you down today), it’s extremely difficult to get browser-managed animations (as distinct from requestAnimationFrame-driven ones) below 60fps in Firefox. Servo had a nice stress test demo back five years ago where production browsers managed 5–15 frames per second and Servo a few hundred; that particular demo is roughly useless now because everyone’s improved to at least 60fps (yay!), but WebRender can still handle a broader variety of things and cope with much heavier documents and animations.
Yeah I think this is fair, in the development of Motion One I have been very impressed by Firefox when I have looked at it, though I've concentrated on Webkit and Chrome for obvious reasons.
At the same time I have noticed that although background-color animations are hardware-accelerated, things like box-shadow actually still aren't, which I was surprised by. Or if they are, blocking the main thread somehow still pauses these animations. At some point I'll do a more extensive example to hash out what is/isn't supported.
I don’t really know what I’m talking about with all this stuff in much depth; I’m mostly reporting what I’ve heard and learned over the years of watching from the outside and keeping half an eye on things, but never quite learning about them in detail.
The "pay to source" is an interesting approach. I am not sure what my opinion is, but I will follow closely if this model will get used more often in future. Also, I would actually consider paying for this if I was in need of an animation framework at the moment (so maybe I do have an opinion?).
I've found that the baseline filesize (65.5kb gzipped) for Lottie makes it somewhat unsuited for "website" animations, though perhaps more suitable for apps.
In the past, when I've vetoed Lottie on this basis, designers have achieved decent results using SVGator instead.
I think the latter is possible and desirable especially as more browsers support SVG animation on the compositor. But Lottie animations are usually pretty big and this library focuses more on UI animations and small filesizes. Never say never though.
Very cool! But can you add more examples with blocking JS or layout threads? I am asking because I have been testing to achieve this and performance really depends on the browser and not all browsers are performant when using WAAPI.
https://motion.dev/guides/waapi-improvements#durations-as-se...: I did a double take on seeing .currentTime as milliseconds in the Web Animations API, because HTMLMediaElement.currentTime (that is, on <audio> and <video>) is defined in seconds! But what really struck me as curious on reflection is that if I hadn’t been presented with currentTime, I think I would have expect times to be in milliseconds, because that’s what things like setTimeout and Date.now use, and they’re the sorts of things you’d use before the Web Animations API was a thing (well, except that requestAnimationFrame supplanted setTimeout years ago). So from the perspective of the web platform that WAAPI was building on, I think milliseconds made sense.
CSS doesn’t have this issue: times require a unit, so you can say 1s or 1000ms as you desire. Unfortunately you can’t really do united quantities in JavaScript; the ergonomics would be terrible for arithmetic and such, and so just using numbers and declaring them to be either seconds or milliseconds is the only sane option. Unfortunately, some things work in seconds and others in milliseconds.
In the end, people are sure to make mistakes in one direction or the other, but the factor of a thousand is big enough that it should normally be noticed promptly and fixed.
Very nice! I recently updated my website traveldays.com with an SVG path animation. The effect is bound to the scroll progress. It looks like you don't support scroll animations (yet)?
I looked into anime.js and GSAP, but in the end I went with the naive approach of just updating the animation in js. It works well on mobile, but when scrolling with a mouse the animation could be smoother.
Yet indeed! As someone who has always built animation libraries based on rAF, this project has been a nice change of pace to limit myself to WAAPI. And I want to continue that with making other browser APIs easier to use, which will include the upcoming ScrollTimeline. Doing this should solve the smoothness you describe, it's not great with sync JS in some browsers.
Suggestion: it would be great if we could use this to animate a value rather than requiring it to be on a DOM object (or selector).
When using this with Vue, it would be great if we could animate a data value and use the Vue template layer to handle the actual DOM manipulation part.
I agree. Currently, to support independent transform animations, there's a tiny numbers-only animation library under the hood. I would like to figure out a nice API for this, along with a tree-shakable keyframes function, that will allow you to animate numbers or more complex values out to JavaScript functions.
The last three examples in the guide don’t work on my iOS Safari. “Options” and “Keyframes” don’t respond, and “Stagger” shows the boxes instantly teleporting. Also, the home page hey animation shows 2 boxes and an empty space for the 3rd until it pops in at the start of each loop.
I’m not surprised though, at least once a week I come across some cool website that doesn’t work on iOS. I’m constantly disappointed by how terrible Apples browser implementation is.
It really is appalling. It’s caused me the most headaches with this project. I’m on iOS too though and not seeing any issues though (apart from the typical 30fps in battery saving mode) - which version of iOS?
Looks very interesting -- it would be nice to have more playground/demos. Both of the front page and in the documentation (like what is on the Quick Start page, essentially).
That's not intended at all - which page were you on when you tried to go back? What did you use to go back (back button/key shortcut)? I can't imagine what is doing it but will fix.
Another poster has pointed out the play button in examples (which reloads the sandbox iframes) is pushing pages to the browser history. I'll take a look.
Last time I had to deal with lots of animations, I used tweenjs. Granted, that was a long time ago. Didn't even know about the Web Animations API. Thanks.
I'm Matt, author of Framer Motion and Popmotion. Today I'm launching my new side-project, Motion One.
It's a new animation library built on the Web Animations API (WAAPI). I actually started this project as a book, but repeatedly found myself explaining some odd concepts (like fill mode) that I felt quite strongly that users shouldn't have to care about. I also discovered the state of WAAPI's implementation is very inconsistent across browsers despite green lights across caniuse [1].
Motion One smooths over these inconsistencies and adds an opinionated API that makes it easier to use [2]. In addition, it adds all the features you'd want from a modern animation library, like a timeline, independent transform animations, and soon, springs.
Being built on WAAPI means you also get hardware accelerated animations in a bundlesize thats around half that of Anime.js and a fifth of Greensock [3].
Feedback and suggestions are welcome!
[1] https://caniuse.com/web-animation [2] https://motion.dev/guides/waapi-improvements [3] https://motion.dev/guides/feature-comparison