Show HN: Motion One – New animation library, built on the Web Animations API

by SirHound • 5 years ago

327 58 5 years ago

SirHound21• 5 years ago

Hi HN!

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

lbotos• 5 years ago

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?

hezag• 5 years ago

1 - https://www.framer.com/motion/

2 - https://popmotion.io/

oefrha• 5 years ago

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.

SirHound21• 5 years ago

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.

seph-reed• 5 years ago

I'm confused about what this does above & beyond css animations/transitions.

cyral• 5 years ago

https://css-tricks.com/css-animations-vs-web-animations-api/

SirHound21• 5 years ago

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.

neolander• 5 years ago

What's the difference between this and something like Framer Motion?

SirHound21• 5 years ago

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.

wcarss2• 5 years ago

This looks really nice!

2 bits of feedback:

- 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.

SirHound21• 5 years ago

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?

Guidii• 5 years ago

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?

Cheers!

[1] https://www.w3.org/TR/web-animations-1/#fill-behavior [2] https://motion.dev/guides/waapi-improvements#individual-tran... [3] https://motion.dev/guides/waapi-improvements#finished-promis... [4] https://motion.dev/guides/waapi-improvements#durations-as-se... - this might already be addressed through CSSOM? [5] https://github.com/web-animations/web-animations-js [6] https://github.com/web-animations/web-animations-js/issues

SirHound21• 5 years ago

Hi Guidii!

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.

Thanks for reaching out, I appreciate it.

RobLach• 5 years ago

Nice website.

andrewstuart• 5 years ago

My primary measure of interest in animation libraries is demonstrations/showcases of the library in action.

I could see nothing like this on the front page so I closed it.

I'd love to see what this library can do so I'll come back to it when there's demonstrations.

swlkr• 5 years ago

I think sponsorship to access the github repo is smart.

This is similar to what the alpinejs creator did with his "sponsorware" approach.

The animations api looks very simple as well, will definitely try it out!

jaredchung• 5 years ago

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?

mritchie712• 5 years ago

Also, once I npm install, what prevents me from using that code?

jamestanderson• 5 years ago

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.

SirHound21• 5 years ago

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.

beebeepka• 5 years ago

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.

Bookmarked

jansan• 5 years ago

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?).

tartoran2• 5 years ago

What Im getting is:

Application error: a client-side exception has occurred (developer guidance).

SirHound21• 5 years ago

That's weird, what browser/device are you on?

tartoran2• 5 years ago

Safari on IOs

yunusabd• 5 years ago

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.

SirHound21• 5 years ago

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.

SwiftyBug• 5 years ago

Here's a HN thread on traveldays.com: https://news.ycombinator.com/item?id=28617541

benatkin• 5 years ago

Here's the contents of the npm module: https://unpkg.com/browse/motion@10.0.1/dist/

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/...

SirHound21• 5 years ago

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.

andrewnc• 5 years ago

The website hijacked the "back" functionality of my browser. Not a fan of that.

SirHound21• 5 years ago

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.

flixic• 5 years ago

In many cases, "animations on the web" has become Lottie animations. Or, at least, Lottie raises the bar for animation expectations.

I'd love to see two things:

- A decent free or one-time payment editor for Lottie (don't make me use AfterEffects)

- Perhaps a Lottie implementation using Web Animations API, if that is even possible.

andrewingram• 5 years ago

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.

mkl• 5 years ago

The lack of format documentation is an obstacle to both of those: https://github.com/airbnb/lottie-web/issues/575

SirHound21• 5 years ago

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.

ex3ndr• 5 years ago

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.

cdubzzz• 5 years ago

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).

SirHound21• 5 years ago

I agree, I’d like to provide them deeper in the docs too but it was a bit of a last minute addition

gugagore• 5 years ago

Could it be used with Theatre.js (https://github.com/ariaminaei/theatre) posted a few days ago?

kennethh• 5 years ago

Pretty cool and nice documentation. I liked the sandbox to run the samples, anyone know what library that is used for it?

SirHound21• 5 years ago

The sandbox was me and the editor is react-simple-code-editor

chrismorgan3• 5 years ago

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.

SirHound21• 5 years ago

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.

chrismorgan3• 5 years ago

I don’t know the current situation especially as regards WebRender in Firefox, but WebRender did box-shadow in a shader back in 2015: https://pcwalton.github.io/2015/12/21/drawing-css-box-shadow....

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.

Since we’re talking box shadows and performance, https://raphlinus.github.io/graphics/2020/04/21/blurred-roun... is also some fun work in the space.

chrismorgan3• 5 years ago

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.

cristicismas• 5 years ago

This looks great! I've used framer-motion in the past and it was great. Could you tell us how Motion One compares to framer-motion?

drewrbaker• 5 years ago

Hi Matt, loved to see this.

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.

SirHound21• 5 years ago

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.

FractalHQ2• 5 years ago

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.

SirHound21• 5 years ago

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?

FractalHQ2• 5 years ago

v14.7 on 11 Pro Max

Show HN: Motion One – New animation library, built on the Web Animations API

Related Stories