Lottie is an open format for animated vector graphics
181 comments
·May 25, 2025panstromek
chrisldgk
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.
throwanem
I haven't worked with Rive either, but those I've known who did have seemed pretty over the moon about it, fwiw.
k__
Rive players are open source, so I assume the format is too?
no_wizard
Rive has performance problems in my experience
mrcartmeneses
Or worse! You get handed off something unrealistic that won’t compile to lottie but “client has signed off”
_kblcuk_
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.
safety1st
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.
panstromek
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.
safety1st
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.
alecthomas
Why is GIF worse (I'm not a frontend developer, so I'm genuinely curious)?
__jonas
> 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.
panstromek
Thanks, I didn't know about this one. That could work for me, I have to try.
bdelmas
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.
safety1st
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?"
eddd-ddde
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.
braebo
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.
userbinator
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.
rchaud
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.
throwaway422432
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.
cosmic_cheese
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.
echelon
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
bestouff
There is already a very suitable format: SVG. Unfortunately it's not proprietary enough for some people.
codedokode
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.
echelon
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.
burdibox
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...
Wowfunhappy
When I've used Lotte, the choice has been between Lotte and an mp4. Compared to the mp4, Lotte is much smaller.
rchaud
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.
mindhunter
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
filcuk
That comparison makes no sense. Apples and oranges.
Wowfunhappy
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.
ummonk
Can’t use SVG?
panstromek
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.
quitit
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.
herrherrmann
I do like the idea of having a common and open format for animations. That being said, I see quite a few web devs reaching for Lottie (which will add quite a few hundred kilobytes for the library/wrapper, and some extra ones for each animation), instead of learning more about CSS- and SVG-based animations (which would be a multitude smaller and more easily adjustable). In that sense, I also don’t like how they continuously boast about Lottie’s small size on the main website, while only comparing it to gif and png files (and not mentioning SVG/CSS animations).
I’m sure it is a good fit for usage on native mobile apps, though.
echelon
> 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.
WorldPeas
And not just that, it was downloadable. This was huge for me then and even PWAs haven’t caught up (though admittedly are more mutable). It was so nice to be able to download 90% of a webapp for offline use and have it be portable across all my systems as a file. Only JAR files come close nowadays but there’s not really an ecosystem behind that
DidYaWipe
MPEG-4 was supposed to be the solution, and was quite the bandwagon around 2001 or so. But for whatever reason, the momentum petered out and here we are with a retrograde mess two decades later.
hbarka
Here for Team Flash. That was an incredible era during its peak. Apple brought on its demise not because it wasn’t competition and Steve Jobs penned the famous criticism which marked the downfall. Flash was ahead of its time.
darzu
Steve put the nail in the coffin but the downfall started and was primarily caused by Macromedia being purchased by Adobe, IMHO. All the problems of Flash were solvable had it continued to been driven by a team and leadership that understood and cared about product quality. IMO this is one of the clearest cases of tech acquisition making the world worse.
dagmx
Flash was great but it was from an era that brought a ton of baggage that wouldn’t have scaled without a full rethink.
From energy use, to security and accessibility, it was very problematic.
miohtama
Flash was also security nightmare.
Benanov
Flash was one of those things that tried to do too much, and some of its things started being at cross-purposes with each other. The video conflicted with its roots as a vector/animation studio, and that's why Apple famously didn't use it - it ended up being a battery hog.
A lot of interests in web-based video wanted DRM, which meant it was never going to be usable by Free Software.
It was trying to do too much and then the usual corporate mismanagement led to its demise.
rchaud
Apple famously didn't use it because it didn't sit inside their walled garden and they couldn't put any ads in it, take a cut of every sale, nor charge developers annually for the privilege of building on their property. That's 3 revenue sources that users and developers were skipping out on.
Android phones had Flash support and it worked well enough. Was it desktop-level, of course not. But Android native apps themselves were a mess from a power consumption standpoint until they implemented a JIT compiler in v2.3 "Gingerbread" as well as a task manager that freed up RAM by closing inactive applications. I remember specifically choosing an ASUS android tablet over an iPad because I wanted to use the full web, open multiple tabs at a time and play Flash games, rather than deal with iOS' "one app open at a time" philosophy.
rchaud
> We should be trying to reinvent the wheel
Especially now as web browser vendors are openly trying to get you off the web and into their walled gardens. Apple and Google have no interest in pushing web capabilities forward because they don't see any money from doing that. Mozilla has long since given up, they don't even support "save to homescreen"/"save as web app" functionality.
echelon
100%!
We're about to enter into a "post-web" era if the tech giants get their way. Smartphones were the first attempt to redefine and capture computing (and are an area where we desperately need antitrust enforcement). Now we'll see AI search and AI chat attempt to circumvent people from finding and using websites.
Mozilla has been rudderless for a decade. They're not going to fix this. The leadership is collecting paychecks being Google's monopoly sponge - distracting the DOJ from antitrust action and refusing to actually innovate in the places that matter.
Search needs to be reigned in. Mobile needs to be reigned in. The coming era of AI chat and search will probably also need a regulatory framework to prevent just a handful of tech companies from owning everything they touch.
atemerev
Well, that's a part of the problem — it was controlled by a corporation which didn't have any interest in opening it. Therefore it has been excised from the Web.
Same goes for Java applets.
It's always politics.
cwillu
Ruffle exists: https://ruffle.rs/downloads#website-package
echelon
Ruffle is great! But there's no great, well-maintained tool to author SWF files.
bsimpson
Unfortunately doing that many things means the codebase must have been rather big. Big enough that auditing and removing licensed code (for instance, the video codecs) seems to be more than they had the stomach for.
It really was a wonderful tool that is still unmatched for creative coding.
dylan604
How is the modern JS control of DOM elements styled with CSS not the same as ActionScript and Flash sprites. I'd argue that Flash was not a video format. It could play videos encoded in specific codecs, but that's not the same as being a video format. At the end you could wrap MP4 encoded video as an FLV, but that was just a wrapper not a format.
At this point, the only think I see being Flash was the app with its timeline to make the animations visually instead of just with code. I've seen plenty of Show HNs of various apps attempting he animation UI similar to Flash, so I know they are out there. I just have no need for that type of work, so I don't spend too much time with them.
troupo
> How is the modern JS control of DOM elements styled with CSS not the same as ActionScript and Flash sprites.
Because DOM is not sprites. Because everything in DOM is laid out with relation to each other, and as you as much as look at it funny, it will cause a full re-paint and re-flow of the entire page. Because animations are bolted on to CSS/DOM after the fact, and the vast majority them are insanely resource-intensive
nine_k
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).
herrherrmann
Yes, and I think Lottie is very fitting for that use case! I was referring to reaching for Lottie even for simple small animations, because it seems easier to just drop the designer’s Lottie file into the project, rather than building the animation in a more native way. At least I’ve witnessed recommendations like this on Reddit.
throwanem
Oh, I think I see your meaning. Sure, for trivial translation and rotation, even scaling, I wouldn't expect or want to take a new dependency on the library. But if I already have Lottie in the bundle and a completed example of the animation in Lottie format, how much sense in the general case does it make to reimplement instead of using what I have? It will take pixel peeping and I would most likely do better to spend the same time on something a designer can't also do.
hbn
Amazing how many of those are using it to animate unrealistic, exaggerated boob physics
throwanem
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.
pavlov
It’s not trivial to produce a Lottie file in After Effects. 95% of the app’s features are off limits, so it’s practically impossible to take an existing AE project and convert it.
Instead you have to ask an artist to author a project from scratch within Lottie’s limitations, but of course there’s no feedback within AE itself if you’re overstepping the boundaries, so they have to be particularly careful.
I wouldn’t recommend it based on my personal experience. But I guess there are teams who have the diligence to make it work.
legulere
Shouldn't it be possible to compile Lottie-animations down to SVG+JS? Is that maybe just something that's still missing?
JusticeJuice
That’s exactly what the library does for its web renderer. There’s a svg renderer and a web renderer.
herrherrmann
The library does this in during runtime, though, if I’m not mistaken? The original commenter is probably referring to a build step that extracts the Lottie content and only leaves JS and SVG in the final output (which is not the case, as the Lottie web player library itself needs to be included as well, to render the animations and provide interactivity APIs during the rendering of the web page).
codedokode
SVG/CSS needs a browser (SVG doesn't allow embedding fonts, can contains CSS/JS) and it is a flaw. SVG is designed only for embedding into websites. How do I display it in a native application.
interludead
Yep, for web, unless you really need After Effects-level complexity, native web animation tools are still way more elegant and efficient
afavour
Not to mention CSS animations (and the newer Web Animations API) allow hardware acceleration while libraries like this do not.
panstromek
Lottie has canvas and svg renderer (that uses CSS transitions where possible, I believe), so technically it's also hardware accelerated (in most cases at least).
zdragnar
Having had minimal experience with both Lottie and Rive on the implementation / embedding side, I can say that my experience with Rive was strictly better.
Does anyone know if there's something I was missing about Lottie if I needed to choose between them in the future?
andrewingram
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.
cjbgkagh
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.
euvin
I've used Rive in a small personal project before and I really can't imagine creating or editing web animations in any other way. Apparently they also made their own vector-based feathering technique, which is also amazing:
https://rive.app/blog/introducing-vector-feathering
I do understand the appeal for an open format though. Rive seems to have their own proprietary (documented) binary format: https://rive.app/docs/runtimes/advanced-topic/format
cjbgkagh
They say on https://rive.app/pricing that the Format is OS and MIT, perhaps I have missed something?
DidYaWipe
Me neither. Was pretty enthused, and even more so when I found that they have a desktop app instead of being yet another Web-only tool.
Then I downloaded the app and found you can't use it without setting up an "account" and being online.
So in the end, this is more tiresome Web-only crap. Deleted.
lwansbrough
The concept of Lottie is very cool, but what you'll find after using it is that it is very hard to work with.
Rive is a new platform that is trying to solve a lot of the issues with Lottie. In particular, dynamic data updates in Lottie are all but impossible.
We did however manage to make Lottie do it, for Tracker.GG's Valorant Backtrack (like Spotify Wrapped) -- here's a demo: https://tracker.gg/valorant/backtrack/episode6/00d0aa2d-94d3...
To make this work, we're accessing the layers by name as they were named in a source file, created in After Effects. Each slide is its own Lottie file, so care had to be put into creating seamless transitions between the files. IIRC, Lottie doesn't provide any dynamic layer access out of the box, so we had to use a second library to work with the Lottie instance, and then build a better data control layer on top of that library.
This was a pretty intense project that took lots and lots of iteration between our design team and engineering, as the process does not lend itself to collaboration very well. In some cases, layers properties are targeted by other attributes, such as by their actual default value (ie. colour.) Not at all a fun format to work with. I'm looking forward to being able to use Rive for future work.
interludead
Rive definitely looks promising... Curious to see if it lives up to the hype once it matures more.
Tade0
Our corporate UI library uses lottie-web for its animated components like spinners, progress bars etc.
This page:
https://airbnb.io/lottie/#/community-showcase
Absolutely cooks my company-issued laptop and my belief is that had it been done via CSS, it wouldn't have this effect.
bitpush
Those are all gifs of animations on that page.
Tade0
For the record: you were right. It was the same page and I mistakenly took those images for lottie images.
That being said it bothers me that they felt that a 500kB gif is more appropriate here. Perhaps I should just compile my images to gifs then?
Tade0
That is a huge indictment towards my company laptop. Or perhaps it was a different page. I will have to establish that on Monday.
gervwyk
We wanted to create some animations for our site https://resonancy.io, and I’ve built them using lottielab. I must say, they have done an amazing job to create a decent editor which really works with svgs, by far better than any online tool I’ve used before. Smooth experience overall. Then comes export.
Not sure if this is only a problem with lottielab or the lottie format, but if not using their proprietary minimizing hosting the animations are so big that I consider them useless for a landing page. Their compression reduces the size by 400% on average for larger animations. We ended up paying $30 subscription just to host the animations which does not sit right with me. So will be looking for alternatives but not looking forward to recreating them..
In the past I’ve used other react based animation libs and they chore of building animations was so tedious I would not attempt anything complicated. With lottlielab you can really play and build what you can imagine with relative ease.
Have not tried Rive.. Will check it out. Any suggestions on how to better compress lottie format for libs for that would be appreciated.
65
In practice most UIs don't have crazy image based animations and can be done with CSS. Lotties might be good for the one off animated GIF style animations, but in that case why not just use the many tools to create SVG animations?
Many designers I've worked with get really excited about Lottie animations but I usually just make the animations in CSS since it's more performant and easier to work with.
By the way, CSS animations have gotten significantly easier with the @property rule. Simply edit the CSS variable and your animation will update!
nye2k
We’ve been using Lottie for years now for certain PBS KIDS brand animations and it has multiple benefits over other formats. As with any runtime rendering in a 2D plane, it takes performance hits at scale. Lottie implements into all our pipelines and workflows nicely; game, app, video. We run them as idle bg animations on the home layer across many platforms - and then deliver static experience for devices that don’t support them, like Roku.
After Effects is a beast, and with this workflow a single person can animate a loop that we can then export the Lottie/Bodymovin json, Mov for Broadcast & YouTube, and simplify into an SVG for low end users.
Not to mention it has all been a great stop gap after Flash.
Now we use Rive too, and can import those json animations into new workflows. I have personally worked with several core folks in this animation space including Hernan, Mat Groves of Pixi, Matt Karl of CloudKid, all whom tackled these late Flash transitions, with plugins, new export formats and math.
I have learned that all of these efforts have their place, and they all have their own FORMATS which are often incompatible with each other because of the way major softwares organize animation over a timeline.
Choose your battles, pick the right tool for the project.
interludead
Love the pragmatic take. It's easy to get caught up in tool vs. tool debates, but the reality is that every format/workflow has its sweet spot.
b3ing
The problem with Rive (competitor to Lottie) is that it’s built less artistically. You can’t just draw things with a pencil/blob tool. You have to do things a certain way which mostly means importing SVGs. Definitely doesn’t have the Flash simple artistic point of view for a UI, don’t get me wrong it does some interesting things but it’s less intuitive than Flash
higgins
raster images are also supported asset types for input
ComputerGuru
This is the AirBnb format, right? They ditched it for a newer alternative; I’m not sure if this was relying on them for maintenance and development or not, but if so I’d say start looking elsewhere.
mortenjorck
Wait, Airbnb itself stopped using (and presumably maintaining) Lottie? What are they using now?
I’m trying to find any kind of news or blog post about this and I’m coming up empty-handed.
Edit: it looks like you were referring to Lava, which is a video format, not a vector animation format. Airbnb is using Lava micro-videos now in some places where they previously used Lottie animations, but Lava appears to be more a modern approach to animated GIFs rather than Lottie’s modern approach to Flash.
https://medium.com/@waldobear002/airbnbs-new-lava-icon-forma...
ComputerGuru
Yup. They don’t compete technically, but they are realistically competing for attention and support as they’re using one in place of the other.
rogierhofboer
Lot's of flash comparisons in this thread... I'll share some tools I've not seen mentioned before:
Google Web Designer is what Google created to 'replace' flash for ads, but it can also be used for other purposes. It has a WYSIWYG editor, timeline, events and scripting.bl But no Lottie support https://webdesigner.withgoogle.com/
Expressive Animator (paid, but not expensive and with free trial), made for SVG animations, can also export Lottie. https://expressive.app/expressive-animator/
And there is the open source Glaxnimate, which does support Lottie. https://glaxnimate.org/
ress
[dead]
userbinator
What's wrong with SWF? The spec is available and very efficient. Those worried about security paranoically can not implement all the advanced Turing-complete parts. The sibling comment about it being another JSON format is spot-on; being drowned in webcrap means a whole generation of developers which have no idea what efficiency means.
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.