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.
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
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.
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
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.
> 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.
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
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.
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.
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.
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.
We need a long documentary about that era. We had video, audio, animation in a web app without the friction of the Netscape browser. There was a burgeoning ecosystem of content producers. Major networks were broadcasting news live in Flash. There was also RealNetworks with real-time audio streaming. This was in late 90’s early 00’s. It was exciting, then http-based everything took over and it felt like media took a ten-year step backwards.
I've worked with RealNetworks tech in the 90s and think it is much better now with open source techology and HLS.
I think you’re viewing that era with significantly rose tinted glasses.
Yes, people were using that Flash for that but it came at a great expense. Flash was a massive battery drain, and to get better performance it required punching massive security holes in the browsers.
Flash is only really great as a content creator/developer who doesn’t care about the specifics of delivery.
But it would have phased out anyway regardless of the iPhone. HLS would have killed it for streaming video, advancing JavaScript and web standards would have killed it for more advanced websites.
The only thing we took a step back on was web game delivery.
Eh. I was on dialup in the age you describe and none of that stuff ever worked for me anyway, even for low-bitrate radio the jitter was a killer. HTTP as transport coincided with wide democratization of access, and I don't think that is at all coincidental; by the time bandwidth penetration made broad access to packet-switched ~realtime (ie broadcast equivalent) streaming feasible, HTTP had achieved the required penetration to represent a local minimum.
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.
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.
Apple famously included a web browser on the iPhone, which puts a hole in your theory.
The Internet of 2007 was more than Flash, so of course it had a web browser. It was designed to compete with Nokia, Blackberry and Windows Mobile, all of which had web browsers. The App Store didn't even exist before the second iPhone model came out in 2008.
> 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.
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.
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.
Ruffle exists: https://ruffle.rs/downloads#website-package
Ruffle is great! But there's no great, well-maintained tool to author SWF files.
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.
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.
> 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
if you're trying to emulate a Flash element, why would you use CSS relative positioning and not define the position:absolute, at least for the element being used as the stage. That would turn any of the child elements much more sprite-like
You might be interested in this document submitted to HN, by the creator of the HTML 5 spec: https://news.ycombinator.com/item?id=34612696
> The forced move to CSS and the constellation of other "standards" still hasn't caught up to what Flash once offered us.
Hard disagree. Modern web apps can be amazing within the browser alone. Look at Figma or OnShape as class leading examples.
I think you’re also misunderstanding Lottie: For web use it is compiled down to those browser primitives you were talking about. It works well, too, so I don’t understand why you’re claiming we’re “still struggling”.
> so I don’t understand why you’re claiming we’re “still struggling”.
Because we are.
If you've ever used Flash, you know how easy and accessible it is to create.
The results were 100% portable and even downloadable. You could treat flash files like gifs or pngs.
The web document standards don't work that magically. They have never lived up to what you once could do.
> For web use it is compiled down to those browser primitives you were talking about.
Gross. I want a single, self-contained file that I can open on my computer without having to open a browser. Not an assortment of JavaScripts and css files.
Anything can be a "standard". The web standards are way too big. And they've accumulated decades of baggage.
Didn't you need proprietary flash player to play your flash file? I would rather run my animation/app/game in a browser than install something like that again.
The problem, as I see it, is that the Flash editing environment doesn't have a widely-accepted descendant, and the person you're responding to is right - there's not really a contemporary editor that is as easy - and more importantly: as potentially deep (as it was also shallow) - for non-techies to pick up and work with.
There are plenty of options today for technically-minded or 'computer people' to work with, but there's a dearth of options for the 'merely' creative to play around with and investigate.
A lot of the magic from the 'old' (mid?) web came from people who had very little initial interest in the technical nature of the solution from just going ahead and making Cool Shit™ anyway. Some of those people might then relish getting their hands grubbier and delving deeper into the technical guts (eg. Praystation et al).
- ed : for the record, at the time i was also critical of the proprietary nature of Flash.
I was a "flash developer" for some time around 2005, but the Flash environment (what was it called, Macromedia Flash?) never really "clicked" for me. I was able to put together some interactive visualizations and even little games, but it was not simple for me. That changed when Adobe Flex and ActionScript came along. That's where I felt right at home. But I'm fully aware Flash made much more sense for others than it did for me.
It needed a browser plugin, but as a developer you just needed to reference it in your object/embed tag. It wasn't something you needed to handle yourself. Most people had it installed already anyway.
Funny that you mention Figma because they literally built their own browser around the browser with C++, Rust and WASM because the current browser situation was untenable to the types of applications they wanted to make.
> within the browser alone
What do you mean by that? My understanding of the above suggestion is that the author dreamed of a world where something like flash would have become the standard, so part of the browser, without the (proprietary) extension.
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).
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.
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.
Amazing how many of those are using it to animate unrealistic, exaggerated boob physics
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.
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.
Shouldn't it be possible to compile Lottie-animations down to SVG+JS? Is that maybe just something that's still missing?
That’s exactly what the library does for its web renderer. There’s a svg renderer and a web renderer.
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).
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.
Yep, for web, unless you really need After Effects-level complexity, native web animation tools are still way more elegant and efficient
Not to mention CSS animations (and the newer Web Animations API) allow hardware acceleration while libraries like this do not.
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).
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?
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.
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
They say on https://rive.app/pricing that the Format is OS and MIT, perhaps I have missed something?
Oh, my mistake. I shouldn't have used the word "proprietary", but too late to edit. There does seem to be community-made runtimes: https://rive.app/docs/runtimes/community-runtimes
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.
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.
Rive definitely looks promising... Curious to see if it lives up to the hype once it matures more.
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.
Those are all gifs of animations on that page.
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?
That is a huge indictment towards my company laptop. Or perhaps it was a different page. I will have to establish that on Monday.
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.
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!
The real killer feature of lottie is that there is an after effects plugin that exports as a lottie JSON. It doesn't always work 1:1 especially with things like AE filters on certain layers but when it works it saves a ton of time
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.
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.
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
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.
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...
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.
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/
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.
There is an independent C++ library by Samsung called rlottie: https://github.com/Samsung/rlottie
Telegram uses it for animated stickers, Samsung itself uses it for icons on their smart watches
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")
There is also the ThorVG project, which has better support for Lottie and is a more robust graphics library and was created by the same people. https://thorvg.github.io/
See this project as well. https://github.com/thorvg/thorvg
We can make use of a very useful library. ThorVG supports the widest range of the Lottie specification and is an extremely portable and lightweight engine.
What's the SOTA for generating animated vector graphics these days? The text-oriented LLMs don't seem to be able to draw aesthetic SVG paths, and the image diffusion models do bitmaps rather than vectors. I think there's a big market for a GenAI Illustrator with After Effects so hope someone cracks it.
Saw a demo for this a while ago on here and lost it, been thinking about it ever since. Now that visual models are getting a lot better at vectors and reasoning in general I wonder if we could reach a point where it is at least possible to translate part of an cartoon into a scalable vector for preservation or remastering
I prefer rive.app, it is a lot lighter and easier to work with imo, plus, it has a great editor
Why would rive website use video instead of their binary format and performant js?
Mostly to show projects on-device/being interacted with. We also designed this version of the site back before we had responsive layouts, dynamic text, data binding, etc. We will eventually update it to be designed entirely in Rive, but we're first prioritizing launching features like Libraries, Scripting, and a better way to handle Accessibility features.
in their recent summer release airbnb created a new video format called lava. considering they also created lottie its really interesting they had a need for something new. i hope they will open source it in the future
Note: they didn’t create lottie, they sorta acquihired the developer who made it and brought the project under their umbrella
From my point of view, on paper, Lottie seems like the perfect bridge between designers and devs, but once you start poking under the hood, the trade-offs pile up fast
Lottie is also used by native applications like Telegram. Despite flaws like using JSON I guess there is no alternative.
The LottieFiles team is doing some amazing workflows for the Lottie format. They also work on streamlining the size too.
The only use case Lottie solved for me was for displaying a video with a transparent background.
I hate working with Lottie, it's json just a terrible format. What are alternatives in the react native world?
I dont like that you cant really SSR (the starting frame) the animations. At least as far as I know.
You can simply load in the first frame of the animation as a static image on SSR, then replace with the animation
This can also be used for progressive enhancement, since if the user has requested reduced motion you can simply leave the first (or last) frame of the animation, or hide it altogether.
In an easy way just using the lottie-file? That is cool! Have to check it out.