Lottie is an open format for animated vector graphics

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

Sounds like a build system, not a file format. Does it work inside any container format that supports audio with it?

It seems like you're quite knowlegdeable about all of this.

Can we see what you've built?

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

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

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.

The point of Lottie is not simple animations like CSS transitions, but complex arbitrary animations, more like a cartoon than a minor piece of motion.

A good example is the Telegram messenger that uses Lottie as the format of animated stickers, e.g. https://tlgrm.eu/stickers/Princess (click to animate).

Where it really excels IME is as a target format for design authoring tools, most notably After Effects, which is discussed above the fold in the linked article as the original motivation for the library and the file format. No one is writing stuff like that by hand to begin with.

I've worked with Lottie animations as a mobile app dev, but never authored one.

Shouldn't it be possible to compile Lottie-animations down to SVG+JS? Is that maybe just something that's still missing?

> instead of learning more about CSS- and SVG-based animations

Contrarian opinion: Flash was one of the best things about Web 1.0.

The forced move to CSS and the constellation of other "standards" still hasn't caught up to what Flash once offered us.

Flash was all at once a video format, animation format, programming environment, video player, interactive UI system, game programming engine, multiplayer MMO game dev engine, infographics system -- actually, it was literally everything you wanted it to be. And it was so simple that even kids could use it.

If Adobe had opened everything - the format, the player, etc. - it could have become something tremendous that is still with us.

I think there's space for this to be rethought and redone. We shouldn't be so dogmatic that CSS and SVG and HTML and Javascript are the only way. They've had nearly 40 years to shine and we're still struggling with the same issues.

We should be trying to reinvent the wheel.

Not to mention CSS animations (and the newer Web Animations API) allow hardware acceleration while libraries like this do not.

I haven’t used Rive myself, but have been following its progress. Notably, the creator of Lottie joined the Rive team a couple of years ago. It’d be on my shortlist for tools to evaluate in this space.

I’ve personally pushed against the use of Lottie in projects I’ve worked on due to the file sizes being very difficult to justify for the kinds of animations that our designers wanted to use it for. SVGator was another alternative we had success with.

One thing I’ve been very frustrated is the amount of places I see Lottie pushed with no mention of file size. ie tools like Webflow, and general advocacy from prominent figures in the tech community. I’m sure there is a sweet spot for Lottie, but I’m also convinced that there are better choices for use cases most people are using it for.

I had never head of Rive before and it looks like something I can use in one of my projects. Thanks, this is the kind of stuff that keeps me addicted to HN.

Do not under any circumstances use rlottie for your application if it consumes untrusted animations. It is not secure software and Samsung does not service security issues.

*I will add though if you absolutely need to, use Telegram's fork. They've at least fixed most of the known issues (with very great commit messages like "fix bug")

raster images are also supported asset types for input

Why would rive website use video instead of their binary format and performant js?