Keyframes: Delivering scalable, high-quality animations to mobile clients
code.facebook.comHey, everyone!
I'm one of the developers at Facebook who worked on this library since its conception! Really excited to be able to share this library today! I'll be checking up here periodically and can help answer any technical questions that you have!
Why does the software license [1] include the following clause:
> provided Your Software does not consist solely of the Software
Why didn't you guys choose MIT or BSD? It feels like the custom Facebook license is close to the intent of these, but it has that mysterious gotcha.
In any case, thanks for the software! It looks really slick, and I definitely have a use case for using it to replace the sprite sheet I used for Donald Trump on jungle.horse.
[1] https://github.com/facebookincubator/Keyframes/blob/master/L...
Note that, by publishing this repo publicly on GitHub, there is a right to fork granted by GitHub's ToS[0], which this license seems to conflict with (though IANAL of course...). Not sure what "fork" means in this context, whether it's just duplicating a repository or also modifying it.
[0] https://help.github.com/articles/github-terms-of-service/#f-... Section F.1: "By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."
Agreed. I've already contacted GitHub to report abuse.
This license seems to directly contradict GitHub's Terms of Service. It says:
> [...] you are hereby granted a non-exclusive, worldwide, royalty-free copyright license to (1) use and copy the Software; and (2) reproduce and distribute the Software as part of your own software ("Your Software"), provided Your Software does not consist solely of the Software; and (3) modify the Software for your own internal use. Facebook reserves all rights not expressly granted to you in this license agreement.
Where as GitHub's Terms of Service state:
> By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
It seems impossible for me to fork this software without violating Facebook's license. To fork it on GitHub would require that I make the repo public (meaning I would be distributing the Software as "My Software" even though it consists solely of the Software). And any commits I made to the forked repo would violate their license because I am only licensed to modify the Software for my own "internal use".
(2) only seems to apply if you publish the fork yourself - "reproduce and distribute"
"reproduce and distribute the Software as part of your own software ("Your Software"), provided Your Software does not consist solely of the Software;"
If you click on the "Fork" button from GitHub's website then that is exactly what you'd be doing.
If the folks who uploaded it can't grant that right, github's TOS does not actually suddenly grant that right. It just makes it a TOS violation.
Interesting, thanks for the actual-lawyer perspective! So is it that ToSes are less legally binding than copyright law? Or is there special meaning behind "can't grant that right"?
Seems like a clear abuse of GitHub's goodwill towards real open-source projects, though. Luckily, it looks like they're going to change the license: https://github.com/facebookincubator/Keyframes/issues/24
They aren't less legally binding, necessarily, it's a question of "what is the end result".
The TL;DR is: You can't grant more rights than you have or can sublicense, no matter what the TOS does.
The same is true of most property. You can't gain an interest greater than the one the person who gave it to you had.
Otherwise, you'd be able to create greater title out of thin air (IE a guy with a life interest can't grant you a fee simple)
Imagine instead github's TOS said "by uploading, you grant the right to use the software under the BSD license". Bob, who has no rights at all, uploads your commercial software. Is it suddenly BSD licensed? No, because Bob didn't have the right to grant "the right to use the software under the BSD license". Even if Github made Bob sign the contract with his blood, it doesn't give away any rights Bob doesn't own.
Here's the truth table version. Note: We assume the validity and bindingness of the TOS, which would certainly be a serious issue in any litigation.
A has necessary rights to grant right to fork. A uploads thing to github with license that prevents forks.
end result -> You probably have right to fork.
A has does not have necessary rights to grant right to fork. A uploads thing to github with license that prevents forks.
end result -> You probably do not have right to fork. Any TOS violation is a separate contractual issue.
A has necessary rights to grant right to fork. A uploads thing to github with license that is silent on forks.
end result -> You probably have right to fork.
A does not have necessary rights to grant right to fork. A uploads thing to github with license that is silent on forks.
end result -> gray area. You probably do not have right to fork. You may or may not be able to argue an implicit license.
Note that this gets even more complex if A is a member of a corporation, as you have actual and apparent authority issues.
That makes a lot more sense, thanks.
We've fixed the license for the project and merged it in: https://github.com/facebookincubator/Keyframes/pull/32
And how about https://github.com/facebook/transform/blob/master/LICENSE?
Hello all, I'm on the open source team at Facebook. We're about to fix the license file for the project so stay tuned. - Thanks
This is a huge overpromise.
Why not say something like "We're asking the legal team to consider whether we can still publish our projects on GitHub"
I'm not sure why it's a huge overpromise. It's the same as when i fix screwups on behalf of Google. You are assuming a lot about the authority structures of the company that may or may not be true :)
I generally would assume that if someone makes that comment, and you can verify that they are who they say they are, that they will in fact, be able to accomplish what they say.
You are misreading it.
Software = Keyframes software.
Your Software = Whatever you are releasing.
So basically they are saying you can't redistribute just the Keyframes software library by itself. Which also means, if I understand this right, you can't fork it and modify it either.
I agree however, not a good license.
I'm not misreading it. The license says we cannot fork the software. That's not open source.
They had better start paying their lawyers overtime. You can't do a PR without forking and people fork on Github for a multitude of reasons (I often fork into a group as a lazy form of bookmarking or collecting projects).
Hell. I just clicked the 'fork' button. Where's my cease and desist?
I would argue that GitHub should remove this software. It just runs counter with their TOS.
A PR isn't the only way to contribute. You can also check out the repo and send in patch files.
Just wondering: for lazy repo bookmarking, why fork rather than star?
For me, forks are like super stars. I have an order of magnitude more stars than forks.
Isn't a different interpretation that a fork is, presumably, their software _plus_ your modification(s)? Thus, a fork is not "solely" their software anymore and is allowed.
The issue people are (rightly, imo) pointing out is that forking without modifications—say, to remain locked to a particular commit for whatever reasons one may have—appears to directly violate the terms of the custom license (which itself appears to directly violate the terms of Github's TOS.
Yes, but forking on GitHub means that initially it will be just their software.
If I understand right, you can fork it and even redistribute it, as long as your software isn't a blatant plagiarism of this repo. So technically, taking this library and putting it together with some other library yielding some meaningful application is enough to satisfy that clause.
I read it as only allowing you to redistribute unmodified copies, because clause 3 only permits modification "for your own internal use."
Also, even if were to improve on it and release it as a fork, as an example, it still falls into the definition of "software" and is in violation of the terms.
Do you have access to the source? Yes? It's open source.
Open Source need not be free as in beer, nor as in freedom.
No. Call that "source available", "source access" or something, but "Open Source" is pretty much established to be defined by the OSI definition of the term: https://opensource.org/osd
The OSI should trademark the phrase "open source". License it for anyone claiming their software is open source (as defined by OSI), and send cease and desists to anyone who is using the phase incorrectly.
They can't:
We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark "open source"; the mark is too descriptive. Ironically, we were partly a victim of our own success in bringing the `open source' concept into the mainstream.
https://news.slashdot.org/story/99/06/17/0213251/esr-on-the-...
> ... but "Open Source" is pretty much retconned to be defined by the OSI definition of the term
"Open source" as a term or development methodology is older than both the OSI definition and the Debian manual it is based on.
what is the motivation to release the library on github with such a license? If you can't fork it you can't improve it.
They want the user adoption, without giving up control, presumably.
this might be silly, but why? what does Facebook gain by getting this library user adoption (beside some bug-reporting). I would think that for fb user adoption of the open source projects is not the goal, but getting OSS developers attracted and getting fixes/features etc. developed from them. Or is it some kind of pride? Fake internet point for having repositories on github?
My long-time-range guess is that this is FB's play for becoming a standard replacement/upgrade for GIFs. From the post:
"Initially, we looked at common static image formats such as PNG sequences and GIFs, as well as even more compressed formats like WebP. It quickly became clear that these wouldn't work without drastically simplifying the animations for file size, and that we'd have to accept the drawback of static images not scaling up or down very well."
So, reading between the lines, they've made what they think is a better GIF. And perhaps it is, and if so, that's big business[1], and so having a first-mover advantage on mobile could be highly profitable. (They're a public A-corporation, after all.)
But who knows; I could be reading too far into it or just flat-out wrong, too!
[1] http://www.popularmechanics.com/technology/a21457/the-gif-is...
I don't think any vector imaging format could ever replace a raster one (regardless of whether it's animated). Each has their own pros and cons.
Keyframes competes with animated SVGs, but not GIF/APNG/WebP.
But what is equivalent After Effects tool for creating animated svg's? I'm not aware of any existing simple/robust tool to animate svg's in a traditional manner. And definatly not with a tool many already know how to use, as well as tutorials for accomplishing anything one might come up with. Is there anything?
Dev mindshare.
I find clause 3 of the license bad also, since it says that you can only use changes internally. Taken together, I read the license as saying that you may only release unmodified copies of the code and only as part of a larger project.
I take it as reading you may only release modified copies as part of a private project, but may not publicly release a modified/improved copy and call it your own project without violating the license. Which is, if right, insanely anticompetitive, and a gross violation of the spirit and purpose of releasing open-source software.
It's not the first time they've used this license: https://github.com/facebook/transform/blob/master/LICENSE
(in that case, they even used it to distribute a patch to ffmpeg, which is LGPL)
From your jungle.horse "more info" panel:
> Word of warning: while I'm not a vampire, I may or may not be a night owl.
That totally sounds absolutely non-suspicious... Also, you may or may not be having a HN-driven traffic spike.
Oh no, I've been outed. ;p
Well it sounds like the MO of a modern vampire: "let's meet for an artistic collaboration -- after the sun has settled" :P
What's the rationale behind putting this on github and asking for contributions, but having the code under a proprietary (non open source) license?
The project author and Facebook legal appear not to be in sync. The license does not grant the right to distribute the software as-is (a fork) or publicly with modifications, but the CONTRIBUTING.md file asks potential contributors to do both of these things:
> We actively welcome your pull requests. Fork the repo and create your branch from master.
Any plans to wrap this in a React Native Component (either as custom component or a part of the RN distro?)
I get grey flashes over the animations/text in my HN reader (Materialistic).
Is there any way you can share a part of the composition, or something that produces a similar bug?
I can only replicate it in that app, I don't see it elsewhere.
Also on materialistic. Worked fine on Nexus 6P
I wouldn't be surprised if this was perf-related, I have a 5X and it's worse when I scroll.
Hi, I'm new to this, does it work with 3d animations ? Like something generated with blender ?
Thanks.
I'm not actually familiar with blender or how that works with AE. I didn't work much on creation of the different compositions, just the end product, so I'm not sure what technologies our designers and animators may have worked with.
Presumably, if blender formats the composition in the supported structure and doesn't drift outside what the library recognizes and supports, it should work.
https://github.com/facebookincubator/Keyframes/blob/master/d...
I have a question: how do you feel working for a company that actively works on censorship and suppression of information in countries where political opponents have to face death?
http://www.nytimes.com/2016/11/22/technology/facebook-censor...
This is really slick, and I'm going to investigate using it for the Donald Trump animation on jungle.horse.
The license [1] doesn't look to be as encumbered as some of Facebook's other open source licenses, but does include a clause I found to be strange:
> provided Your Software does not consist solely of the Software
So if I'm reading this correctly, it means only Facebook can redistribute this software? Wat.
[1] https://github.com/facebookincubator/Keyframes/blob/master/L...
That restriction makes this quite blatantly not open source or free software, under the accepted definitions. Why couldn't they just release this under the MIT license or something else like that?
>Why couldn't they just release this under the MIT license or something else like that?
I don't mean to be unpleasant (really!), but I don't understand what kind of answer you are expecting to get.
The only non-trivial answer one can give is also the most obvious: Facebook doesn't want to make free software.
Stated differently: why the assumption that Facebook is in the business of Free software? Or are you just expressing the desire for all companies to produce Free (in the Stallmanian sense) software? Or are you reacting to the implication that Facebook's software qualifies as free?
I only bring this up because these kinds of loaded questions have a way of devolving into flame-wars.
> Today, we’re excited to open-source and share this library more broadly, so that others can work together to build more delightful products.
Facebook's post explicitly states they view this as an open source library. So, while I agree that we cannot assume Facebook is in the business of free software, their post says they are releasing an open source library under a license that does not appear to follow OSI definition of open source.
Apparently facebook uses this restrictive license on other so-called open source projects as well (FBMemoryProfiler, etc).
Presumably if you added a unique feature it might not "consist solely of the Software". But that clause isn't the troublesome one -- "modify the Software for your own internal use" makes it crystal clear that this is absolutely not Open Source.
I wonder how that affects creating a fork of it. At what point does it become different enough that you can safely distribute it
IANAL, but it reads to me like they don't think that point exists. "You can use it, but you can't publish a fork of it." Definitely not open source in my eyes.
Are you even allowed to redistribute a modified version at all? Modification is only allowed for "internal use".
that's true, it's a bit of a gray area.
the way I read it is, I can't put a new name on it under my name and then redistribute it. But I can use it in a library or app and then open source and distribute that
I've reproduced Keyframes and am distributing here: https://github.com/jjt/Keyframes
I think you're doing this in jest and that's fine. But the only value of a fork would be one who's license is less restrictive. But the Keyframes license would prevent this, so it's fruitless.
Cool project. I first saw your domain mentioned on a post about TLDs.
Question: I assume you have some corpus of the recorded speeches of DT. How are you mapping those to words? A broader discussion about how you implemented jungle.horse would be interesting...
Thanks!
I was totally down with this - a tight, efficient vector graphics format with After Effects integration, super - up until the point they said these animations were JSON files.
Huh?
Didn't I just read a whole blog post saying that one of their requirements was fast loading from disk, small bandwidth usage, etc? And that's what justified creating an entirely new image format from scratch, not something the internet is really suffering a shortage of already?
I know JSON is fashionable but that ending just seems kind of ridiculous. What's wrong with a binary format? Use Cap'n'Proto and mmap it! Saying numbers represented as text compresses well was the icing on the cake. No shit!
While a binary format would be better over the wire, once it's put into memory the format really doesn't matter. In fact I would argue that the decision to use JSON versus XML versus a binary format is entirely immaterial as it'll get cached once and likely never downloaded again (essentially). At least as far as Facebook's usage is concerned (they load these 6 once and never again).
Also I think you have to pick something human readable here. One of the great things about SVG is that it's in XML so you can read it, tweak it, etc. It's super handy when you want to make small changes that only affect the image. So I see using JSON as pretty handy.
Don't forget there are many types of formats out there that have 2 types: a binary and human readable type. One used typically during debugging and one used for optimal over-the-wire transport. I don't see why this couldn't be possible at a later time.
Edit: I don't understand the downvotes. Over-optimizing is a thing. For a one time download I don't see the handfuls of milliseconds you're saving mattering. In either case of receiving a binary or JSON you will store it in an optimal format on the device...
As someone who has to deal with mobile perf issues, JSON serialization/deserialization can take a lot more of a perf budget than you realize. A flatbuffer version would definitely be faster hands down.
With gzip sizing is about the same, but processing speed wise it is not.
Also if you gzip the binary version and the json version, the gzipped binary is still going to be much smaller.
Same with csv data, for download size it really pays off to preprocess and pack into arrays of binary structs before compression.
This is part of a bigger class of effects in preprocessing data before compression, it is often surprisingly effective. For example delta coding or columnar format (SoA vs AoS) can yield big improvements depending on data.
See: precomp, lrzip, srep
> As someone who has to deal with mobile perf issues, JSON serialization/deserialization can take a lot more of a perf budget than you realize. A flatbuffer version would definitely be faster hands down
With something that's grabbed once and cached likely forever I think the tiny bit of overhead for JSON won't make any difference. I've done this too and yes, of course a flatbuffer would be faster but the speed is just related to the initial download and caching. Beyond that you'd keep it in whatever structure is more efficient for the app to re-use.
Unless they store the cached version as a flatbuffer or similar format, you will suffer a penalty every app startup. And startup is where a lot of mobile perf is focused on. I haven't heard of SVG renderers storing SVG XML files in a more efficient format. It's like using jpeg2000 compressed images vs. PNG. And if you use a lot of them, it will add up.
> Unless they store the cached version as a flatbuffer or similar format, you will suffer a penalty every app startup. And startup is where a lot of mobile perf is focused on.
Why would you pull in data from one format and keep it in the same format forever if it's not optimal for the device AND it doesn't need to be modified and sent back? Whenever I work on mobile apps and I have to cache data coming over as JSON or XML I store it where I can quickly re-access and NOT in its original format.
This thread seems like a conversation about how you can shoot yourself in the foot when it's very easy to avoid.
> I haven't heard of SVG renderers storing SVG XML files in a more efficient format.
Me neither. Sounds like it could be doable. Not sure how this related to our conversation though.
Hey, zigzigzag! The reason we went with JSON initially was for ease to work with, debug, and general ability to tweak and make the development process for this project much easier. That's definitely not to say there aren't some notable improvements we can make to this library!
For those who use JSON regularly and aren't familiar with Protobufs (or one of the variants like Cap'n'Proto), they're an amazing binary serialization format that is tightly packed, encoding and decoding efficient, and designed around supporting protocol changes.
Fields are serialized to tag numbers instead of field names in the binary format, so it's easy to rename fields. This also saves a ton of space versus JSON.
Proto "messages", analagous to structs in other languages, are typesafe, negating the need for a separate schema definition language. They support optional and sum types too.
So many languages have great protobuf libraries available. (I'm hoping one becomes available for Rust soon--as well as gRPC.) It would be amazing if the browser vendors would come together and standardize it as a first class browser serializarion format. It'd save so much bandwidth to emit protos instead of JSON.
https://crates.io/crates/protobuf exists; though I haven't used it.
Cap'n'Proto has pretty great support for Rust, from what I hear.
Oh awesome! I'll check this out.
btw, I love all the work you do for Rust, Steve! :)
Thanks :)
My reaction exactly...JSON seems a horrible choice to encode numeric data. Protobuf will be much better.
tl;dr - A plugin/library for exporting vector animations from After Effects and using them easily in iOS/Android apps.
Previous options were exporting SVG animations, rendering to bitmap spritesheets or png sequences - or having to write a spec for the AE animation and recreate it in iOS/Android.
Correct me if I'm wrong. It sounds like Keyframes is like "Flash runtime", the differences are you author your animation in After Effects, and the output is JSON (instead of SWF).
Yes, that was also my first thought. Keyframes animations were pretty much one of the earliest features of Flash. Used those nearly 15 years ago. However Flash was/is not limited to that, since it's also a completely programmable.
Since Adobe moved quite some effort away from Flash and towards HTML I'm pretty sure that they would now also support exporting keyframe animations from one of their standard tools into a native browser format.
It would be great to finally get back the true programmable animations that we had with Flash so many years ago. It took a while, but things to be coming full circle--for the better.
It's bascially the same as for UI components. Adobe had the great MXML based Flex framework back then.
The web world only slowly catched up, and I think it took until the current gen of frameworks (angular2, etc.) to be at the same level. However the good thing (as you also pointed out) is that the new variants are based on standards.
Doesn't hurt to have competing standards. Also the major issue with Flash was the execution environment, not the file format. Running Flash inside the browser opened up all sorts of security holes. This just uses javascript to manipulate shadow DOM elements. Pretty standard practices in a modern JS framework.
Well, it's missing the interactivity part.
This is a powerful idea. I've looked for tools to do this exact thing. I'm the sole animator on a team of software developers and currently when I want to create an animation in an iOS app I usually start by mocking up the animation in a tool like after effects, and then recreate that animation using my graph editor as reference in core animation. Svg works well for storing shapes. Having a similar standard for storing animation curves is really powerful.
How do you directly render SVG in your mobile apps currently?
Have you tried font-iconification services like http://fontastic.me/ ?
Why can't this just be MIT licensed?
I've made the exact same thing, basically. A tool to convert AE animations to iOS. Has some other features, but it's also AE -> JSON -> code: http://www.squall.no Cool to see what the folks at FB came up with!
very well polished... will check it out
Neat! Where's the react-native port? I know there's gotta be one since FB uses it in their apps ;)
Exactly!
This should be wrappable by a React Native Component, it really is screaming for somebody to do that...
Is there a way to also use it on the web? Presumably FB is also using it in their desktop site.
Tell me again about how bad flash was for everything, please?
The bad part of Flash was the Adobe binary which besides needing to use the messy plugin interface (separate process using an ancient interface, ugh) seemingly always contained tens/hundreds of unresolved security issues.
I wonder what this means for animation studios, or edit houses. Obviously most dev shops don't have a need for full time animators, but just as obvious is that a lot of devs don't know animation fundamentals outside of how to implement an animation without jank.
> I wonder what this means for animation studios, or edit houses.
It means nothing
> A library for converting Adobe AE shape based animations to a data format and play it back on Android and iOS devices.
You still need to be able to produce the animation at first place.
Any "export-paths/pipelines" available to use the lib with After-Effects alternatives?
I'm reminded of this: https://youtu.be/pAEAbqrE5Zw
Does it represent a lot of work by skilled technicians? Undoubtedly. Is it interesting in it's own right? Frankly I think not.
The surrounding question of the socialization of the internet is interesting, to be sure, but at the end of the day these are just animated emojis...
> Does it represent a lot of work by skilled technicians? Undoubtedly. Is it interesting in it's own right? Frankly I think not.
You don't think having an easy way to create high quality animations for any purpose that work on multiple platforms is interesting...? You might not find the current application of it interesting but that's like saying React isn't interesting because someone used it to make another Flappy Bird game.
This is a fair point. I'm more so reacting to the tone of the article, which suggests technological or social innovation.
I see neither.
Analogously: TCP is pretty amazing, but I don't expect an app that uses a simple TCP socket to self-aggrandize on the pretext of technological innovation.
> You don't think having an easy way to create high quality animations for any purpose that work on multiple platforms is interesting...?
It would be more if they'd have created an extension to the SVG standard that they'd just parse out via JS. Then it'd just be a polyfill, and could easily be integrated natively in the future, and gain support on other platforms, too.
This will change the world for a few months, modifying the standard would change it for years.
But react isn't interesting because they could have just modified custom elements via a polyfill and javascript extension. It would work mostly natively on newer browsers. Keyframes is just after effects animation in HTML5, a feature that could be implemented more natively using svg and a solution similar to this for older browsers. Facebook seems to want to dominate with single-use, clunky libaries.
Yeah and on mobile devices you can waste a lot more battery running animations in HTML5. I'm sure your users will appreciate that. Surely the most important thing is to optimize programmer time and comfort without regard to the end-user experience and that thinking has lead to a world filled with wonderful well-designed software that properly handles error conditions and never presents users with useless choices or non-actionable obscure error messages.*
Snark aside, if you have a native mobile app it is a much, much nicer experience to have native animations integrated rather than trying to mash an HTML view into the app just for some animations.
*Because programmers are the worst kind of pedants: Yes I know sometimes you can't afford to write native apps, sometimes a partial solution is better than no solution, etc. Just don't lie and tell me a web app is as good as (or better than) a native app, or that Cordova is a great way to write mobile apps. Those are compromises. Sometimes you make compromises to get shit done. It doesn't magically transform a compromise into an ideal solution.
> Keyframes is just after effects animation in HTML5, a feature that could be implemented more natively using svg and a solution similar to this for older browsers
That's another approach which has it's own pros and cons. The approach from the article is obviously good if you have Affect Effects experts on hand. I'm not understanding why this isn't interesting to programmers who on a daily basis have to weigh up the pros and cons of different technology/library choices.
>I'm not understanding why this isn't interesting to programmers who on a daily basis have to weigh up the pros and cons of different technology/library choices.
Perhaps I'm showing my age, but this feels like this problem was solved a long time ago, forgotten or unused to a large extent and now re-invented. Flash was the clever web version back in the day but I can't see anything really new in this.
I could absolutely be missing the point though. I never count that out.
Flash isn't supported on mobile browsers (now), native Android or native iOS though.
Oh, absolutely. It was a heavy implementation of a similar solution and the mobile ecosystem is better off without it.
It might not be novel but it looks to be useful and well supported, which is really what counts in JS libraries
It's been a while since I've seen that episode, but ... wasn't that _the_ product in SV? This represents a small bit of UX that may be compelling enough to keep users engaged in new ways on their primary product (a relatively large social media site, ftr).
Yes. It's an analogy.
The purpose of an analog is not to be exactly identical, otherwise it would be called an equality.
I'm sorry, it doesn't seem remotely comparable. Huge, complicated products are often made of seemingly inconsequential pieces. That SV piece was about an entire product made of an inconsequential piece of tech.
It was interesting enough for FB to strip down and repackage https://github.com/bodymovin/bodymovin
Your example speaks to my point: there's nothing new, innovative, technically challenging (beyond the norm).
I really don't see what there is to write home about. This article reads as a PR announcement (which is okay) disguised as a technical achievement (which it isn't).
They're "just" animations.
Maybe not the biggest breakthrough ever, but it does fill a gap. Animations like this on the web really weren't possible without either using Flash or SMIL. A completely JavaScript based solution is very welcome.
I think the annoyance is the slightly smug tone of "Look what I invented. Vector animation and keyframes!"
It's a cool implementation but it feels like they are claiming to have broken amazing new ground. To people that don't understand much of the background technology that's exactly how it reads.
is facebook okay? how many developer hours went into making their emojis animate properly? i don't want to say it's a waste of time/shareholder value but it might be.
still interesting though. gonna check it out.
Facebook spending a developer year on it is like your average dev shop spending 5 minutes of your time on the daily stand-up.
Related - YouI.tv is a commercial product that exports animations and assets from AfterEffects in order to build whole apps: http://www.youi.tv/youi-engine/
Or, be a winner and use GSAP.
Just saying.
Why not APNG?
APNG files are normally smaller than GIFs (about 30% smaller) but they're still going to be big for high quality animations. SVG/vector animations can be tiny in comparison.
It's a raster format and they state pretty clearly why they don't want raster images.
Size constraints and the need to be able to smoothly scale to a wide variety of screen sizes.