Lottie for me is sadness.
I love the idea, it's really cool that you can generate the animations from what animators already use, but boy, the implementation of it is very disappointing.
The format is probably one of the worst choices they could do for a use case like this - it's JSON, for something that is usually a bunch of numbers and perfect fit for more compact binary format. This JSON can reference external files, so the animation is either
- a folder with bunch of files (sub pictures)\
- or those files are inlined in the JSON as base64
- or it's just a single file, which turns out to be a zipped folder of this amalgamation.
If you imagine loading this on the web, you have to load absolutely enormous SDK (which is not very actively maintained and isn't very well size optimized), and then loading the animation either means loading a bunch of files separately, or loading a single file but processing it through multiple different parsers in multiple passes (JSON, base64, png, lottie, zip). If you use the .lottie file, you have to include zip decompresser in the JS bundle (.lottie player, which is a different library, also uses 2MB wasm blob, not sure why).
It took me a while to squash the footprint of this craziness in our app and I'm glad we don't use it in a hot path, because this is just crazy - it's supposed to be this little cherry on top for special occasions, but it's by far the heaviest part of the codebase. I had to manually tweak tose animations, run them through some optimizers, fixup weird path and inlining issues, fixed issue with those exporters turning vectors to png, all sorts of stuff.
On top of that, the browser doesn't survive playing more than a few of them reliably at the same time (especially on lower end devices), because turns out (who would have guessed?) - animating stuff with JS and DOM is not quite performant.
I kinda want to try a weekend project to turn these into optimized svg sprites and try to play them with a CSS transision, see if this makes it more bearable.
100% what you said. One thing I ran into as well was that horrid after effects -> Lottie workflow. Many layers and styles also just don’t work when you export them, so you have to explain to motion designers which features they’re allowed to use and which they aren’t, which a lot of time they’re not thrilled about.
In many cases just rendering a video and binding playback to interaction is much more lightweight and less work-intensive than using Lottie.
I’ve heard about Rive before and a lot of the choices they make seem to be exact fixes for the issue of Lottie. I haven’t worked with it yet however, so YMMV.
I haven't worked with Rive either, but those I've known who did have seemed pretty over the moon about it, fwiw.
Rive players are open source, so I assume the format is too?
Or worse! You get handed off something unrealistic that won’t compile to lottie but “client has signed off”
I worked in a company, where webapp bundle was 8 megs (so close to 2 megs compressed). Upon brief investigation turned out that it was lottie library (~2 megs) + 4 animations, all of which were shown only to first time users.
Managed to get rid of two animations, and put another two together with lottie thing istelf into lazy loading. Still, I consider that battle lost rather than won, because I couldn't really convince the designer or other developer why having 8 megs for a bundle is a bad thing.
At the moment for me Lottie is a flag and I'm trying to figure out whether it's a red one or a yellow one. I just found out on Friday that one of our designers decided to use it and has provided us a bunch of little animated 150x150 Lottie icons, embedded in a Figma design. I'm like, what on earth is Lottie? And it's explained to me that we're supposed to embed some Javascript app so that we can display these little icons from a CDN. So many random bad smells coming from this.
How much trouble are we in? Can we convert these Lottie things into animated GIFs or something? I have the feeling that this idea of embedding Javascript to animate small, simple icons cannot be good and is going to screw up all the hard work we do on performance and good CWV. I can't believe I'm Googling around for free websites that make animated GIFs right now. It feels like 2003 again. I don't even know who owns or wrote this whole Lottie ecosystem and what all these sub-brands like "Lottie Files" are but I'm expected to embed their code.
Yes, you're right to be worried. It's really not great fit for micro interactions (`like/unlike` buttons etc.). If you're animating a spinner, then that animation will probably take more resources and be more fragile than the thing you're showing the spinner for.
GIF is still probably worse, though, I wouldn't do that. Your best bet is to try to do what I hinted and want to try at some point: extract frames from the animation as svg, put it into a sprite img (and run svgo on it) and then animate that sprite with background-position or css transform.
Extracting the frames can be done with puppeteer, there's a tool for that https://github.com/transitive-bullshit/puppeteer-lottie, it can output video or gif, but I'm not sure if it can do the whole sprite thing, yet. You might need to do that manually.
[edit]: I'm assuming you talk about the web. Mobile lottie might be different and maybe fine, but I don't have experience with that.
Thanks for the ideas. This is indeed the web. The Lottie stuff in question is a couple of decorative, 100x100 animated line art drawings.
When I dug into the Figma file, they were extractable as 450kb, 640x640 animated GIFs.
I ran one of those through some website called ezgif which converted it to a 100x100 animated webp image at 64kb. Think it's lossy but quality looks acceptable for our purposes. Gimp didn't seem to be able to resize an animated GIF properly.
This seems like a roundabout way to get where we want to be, but a 64kb animated webp seems like a much better situation than embedding the Lottie player js.
Why is GIF worse (I'm not a frontend developer, so I'm genuinely curious)?
GIF is a format from the 1980s that has not changed or improved one bit since. It's limited to a 256-color palette per frame, which on top of looking bad, will massively bloat your file size as a common strategy to make it look less bad is to re-select a new palette each frame. It's massively worse than a modern lossless (or perceptually lossless) video codec and there are no real benefits to it except backwards compatibility on account of the whole "unchanged in 40 years" bit.
Most sites and platforms silently swap out uploaded GIFs for re-encoded MP4s with no loss in quality due to how awful GIF is as a format. Telegram reports saving 95% on storing GIFs by doing that instead.
GIF animations will autoplay where video embeds often will not esp on mobile. For a looping low color vector animation it might not be too bad.
Video embeds can be made to autoplay, browsers typically don't block them if the video is muted, and JS can be used to nudge them along if they do.
With the automatic conversion of GIFs into video, this also isn't a property that can be relied on for GIF as an end-user. See Xitter, where their buggy scroll position detection takes over playing and pausing GIFs.
> Can we convert these Lottie things into animated GIFs or something
You might be able to convert them to SMIL (SVG Animations), which is still pretty well supported and does not require any JS dependencies:
https://github.com/bodymovin/bodymovin-to-smil
This is a repo by the original author of the lottie format, it's not super well maintained though, and it only supports limited animation features.
Thanks, I didn't know about this one. That could work for me, I have to try.
Beyond Lottie I think that how your company is making tech decisions is bigger red flag… Just what you described seems crazy they can come up that solution just a few icons. I can’t imagine what it has to be for the rest. It’s unfortunately very hard to change once those type of people are in place and this culture is the norm.
I own the company, and the issue came to my attention in a 1:1 with an engineer last week. I can decide and communicate what the policy will be, and the matter will be settled.
The hard question as always is what constitutes a good policy!
What happened here was that a well-meaning and talented designer passed a Figma along to the dev team and the Figma included these Lottie things and a note about how to embed a chunk of js to display them. It caught the dev & myself off guard because neither of us had even heard of Lottie but I guess it might be getting popular with designers.
Considering that there actually seems to be an animated GIF embedded in the Figma file, I don't really know the intimate details of said designer's workflow and I think we just need to tell them "This Lottie player thing is not going on any website we produce, but an animated image certainly can, so is it prudent for you to alter your workflow? What is the optimal handoff step?"
I've been in one of those... You spend 4 hours removing half of the dependencies that are used in one line of code, the next day there are 20 more.
Take 20 min to read over the source code of the Lottie npm package and you’ll have your answer.
I did this years ago and it was one of the most ghastly piles of vanilla JavaScript I’d seen in awhile. I get the feeling that hasn’t changed.
the browser doesn't survive playing more than a few of them reliably at the same time
In contrast, around the turn of the century there were plenty of webpages stuffed full of annoying animated Flash ads, which as irritating as they were, managed to work well enough on the typical single-core CPU of the time.
Even in the mid-2000s, when most PCs had 512MB - 1GB RAM, you could build complex 3D animations in Flash that ran flawlessly across multiple browser engines including IE6, with nothing more than a plugin.
Don't know why, but I take great pleasure in saying something was something I did "last century" when talking about software or web design.
It varied a fair bit. One of the reasons I started using adblocking measures was because flash ads would pretty often get my single core PPC Mac’s fans spun up and angry.
Lottie demonstrates two things:
- there's still tremendous demand for a product like Flash, an easy interface for non-technical creatives to build animations
- building / compiling to web standards is highly suboptimal and we need binary formats special purposed for animation
There is already a very suitable format: SVG. Unfortunately it's not proprietary enough for some people.
SVG has some serious flaws. How do you preserve fonts when saving an SVG image, and still keep the text editable? Currently as I understand the only way to display text is to convert the text to Bezier path.
Also what I hate about SVG is that it requires a whole browser to display because it can contain CSS and JS.
Both these facts hint that it was designed only for embedding into websites, and is not ready for standalone use. Maybe we need a new format for vector graphics that doesn't require a browser.
It's not performant enough for what we want to do, and the constellation of "standards" around it are ill-fitting, awkward, and difficult to use.
We need a binary format special purposed for the task. Not CSS and literal XML and Javascript.
None of this is accessible to the animator. Some programmer bro can pick it up, but nothing has ever been as simple and as easy to use as Flash.
Why is it "not performant"? It is basically a set of bezier curves, just like other vector standards.
What is really bad that it is based on W3C technologies and requires a browser to display.
my experience on mobile has been a lot kinder to Lottie—mainly because of its runtime-editable text. just imagine full localisation without shipping 15 different assets...
When I've used Lotte, the choice has been between Lotte and an mp4. Compared to the mp4, Lotte is much smaller.
MP4s don't support transparency, so using it would rule out all but a small sliver of animations where the video background matches the web page background. If the webpage background has a gradient, the animation won't blend in. Same if the page has a light/dark mode toggle.
While MP4s don't support transparency, both HEVC and VP9 do and their support is very good these days. I just recently used these formats to add a complex After Effects Animation to a website. It's a bit of extra work to encode two videos instead of just one but the result is great. I used this tutorial: https://rotato.app/blog/transparent-videos-for-the-web
That comparison makes no sense. Apples and oranges.
The designer has created an animation in After Effects which has to play at some location on the web page. I can have the designer export a video and insert it that way, or I can convert the AE file to a Lotte animation. It looks the same to the user, so it's ultimately just a matter of bandwidth.
Are you sure Lottie + SDK is heavier than the mp4? For one or two animations that hasn't been my experience, especially if you can do WebM and fall back to optimized mp4.
This was at least six years ago. At the time, yes I'm pretty sure Lottie was a lot smaller. However, iirc we largely abandoned it in favor of videos anyway because the lottie animations wouldn't render correctly without additional work.
I doubt the designer did any sort of compression on that video. Animations usually compress very well.
The less-abridged process was "the designer exports a ProRes video, and I (personally) spend an hour experimenting with different ffmpeg settings to get it as small as possible while retaining a level of quality the designers will accept."
Can’t use SVG?
Lottie is basically that (at runtime). There are different modes but the most sensible one is SVG + piece of JS that sets transforms on it.
Are there situations where this would be better than what's already possible with a HTML5-based animation tool such as Tumult's Hype?
For me that has pretty much been my go to tool for generating online flourish.
Is there a more compact format that is bidirectionally compatible with lottie? (not just zipping it, some binary format that can be quickly parsed)
Maybe just storing it as JSONB, or reading the json and converting to another format using some serialization library (like Rust's serde) is enough?
I'm asking because Lottie integration is very widespread, and tooling interoperability is important
On the other hand JSON is probably pretty small when compressed, and very efficient to load into the JavaScript VM.
If it requires a JS VM then it is a flaw. Low-level languages like Rust are faster.
Does Lottie do no temporal compression? Is it just a sequence of p-frames with a json manifest?
The last time I worked with them there also was basically no way to render them into any other format easily, and all the available tools I found basically just launched a Chromium instance to copy each frame, messing up transparency in the process
Sounds like a build system, not a file format. Does it work inside any container format that supports audio with it?
On the one hand, I understand your disappointment with JSON due to its gigantic size.
On the other hand, I wouldn't want another proprietary binary format to deal with.
And it seems like zipped JSON is almost the best of both worlds -- text-based so debugging and manual editing in a pinch is easy, but around as small as a binary format would be.
Sometimes I wonder if there shouldn't be a kind of optimized library that translates directly between 1) an in-memory structure based on e.g. class attributes rather than dictionary keys so the repeated keys aren't using up all your memory, and 2) writing out to zipped JSON format but automatically creating zip dictionary entries for keys, syntax like braces, numbers, repeated values, etc. It could be vastly faster than regular zip compression because it wouldn't be creating a dynamic dictionary, but would know the repeated bits and frequencies in advance. (I.e. by default wouldn't compress English text within JSON values, but you could also enable regular slower global zip compression if you wanted.)
So the file format would still just be zipped JSON that any tool can read. But you could use this optimized library to convert directly between a much smaller size on disk and a small size in memory, without ever having to e.g. hold the entire JSON uncompressed string in memory at any stage.
Maybe something like this already exists? I haven't come across it though.
You don't need to use a proprietary binary format. There are plenty of existing options, Protobuf is probably the most obvious.
In my experience zipped JSON is not a magical panacea. It usually isn't as small as a binary format (especially a compressed one), and you usually need to decompress the whole thing in memory before you can use any of it. It's a lazy bodge, not a proper solution.
Working with protobuf has been a huge pain for me, personally -- sites that make API data available only in older versions of protobuf where there's no available library to decode in a popular language. JSON and zip are easy, universal, accessible standards in ways that protobuf simply isn't.
So that's why I'm saying, there's really something to be said for zipped JSON. You point out that you "usually need to decompress the whole thing in memory", and that's precisely what most of my comment was about -- handling it efficiently so you don't.
And it's not like protobuf is inherently any better at that anyways -- if you want to access a record in the middle of the file, you've got to stream the whole file up to that point to get to at it. It doesn't support random access in any native way.
So I'm kind of bummed out my original comment is being downvoted -- I'm making an actual serious proposal in it. I think zipped JSON should actually be taken seriously as a file format in its own right, especially with much more memory-efficient decoding.
> And it's not like protobuf is inherently any better at that anyways -- if you want to access a record in the middle of the file, you've got to stream the whole file up to that point to get to at it.
Not true. Libraries may not commonly expose the functionality but Protobuf uses tag-length-value so you can very quickly skip to the part of a file you want. In the worst case it will still be orders of magnitude faster than JSON.
Your proposal sounds very complicated and fragile, and doesn't solve significant issues with JSON like zero-copy, storing numbers and byte arrays directly, etc.
Protobuf doesn't include any kind of indexing. You can't just jump to a 5,000th record without traversing through the previous 4,999 ones. So no, you can't generally skip to some specific part. You've got to stream from the beginning, just like JSON.
And my proposal is literally the opposite of complicated and fragile. It's just taking two extremely robust and relatively simple existing standards.
It's definitely not perfect, but the entire point is its simplicity and robustness and support, unlike protobuf. And the fact that a library could actually make it much more performant to use, without sacrificing any compatibility with zip or JSON.
Zipped JSON is just massive waste of energy in a battery. We don't want that.
I don't think protobuf is good because it allows reordering fields (which means that the decoder will have to do it too). A good binary format is a format that maps to a C struct, doesn't have field names (or ids or tags) and requires zero decoding.
zipped JSON is basically what every websites uses, the zip is just handled by the network layer.
Now, I understand the general argument for JSON, but for lottie, there's not much to read or edit in it. It's just incomprehensible bag of numbers, or even worse - base64 strings. You need to process it with program anyway. It's not better than any binary format, just bigger.
JSON itself is the least of lottie's problems though. The semantics of is the real issue, because it imposes a lot of work on the implementation.
CBOR (https://cbor.io/) seems the obvious data format
But really need browsers to expose their current CBOR decoders / encoders via a web accessible API