Does anyone know if there's something I was missing about Lottie if I needed to choose between them in the future?
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
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.
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.
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.
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.
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.
- 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
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.
What is really bad that it is based on W3C technologies and requires a browser to display.
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.
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.
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.
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.
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.
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.
But really need browsers to expose their current CBOR decoders / encoders via a web accessible API
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.
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.
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.
For me that has pretty much been my go to tool for generating online flourish.
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.
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.
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.
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.
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.
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?"
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.
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.
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
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!
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.
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...
Telegram uses it for animated stickers, Samsung itself uses it for icons on their smart watches
*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")
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.
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?
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.
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.
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/
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.
herrherrmann•1mo ago
I’m sure it is a good fit for usage on native mobile apps, though.
throwanem•1mo ago
I've worked with Lottie animations as a mobile app dev, but never authored one.
pavlov•1mo ago
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•1mo ago
JusticeJuice•1mo ago
herrherrmann•1mo ago
echelon•1mo ago
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.
bsimpson•1mo ago
It really was a wonderful tool that is still unmatched for creative coding.
Benanov•1mo ago
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•1mo ago
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.
robertoandred•1mo ago
rchaud•1mo ago
atemerev•1mo ago
Same goes for Java applets.
It's always politics.
WorldPeas•1mo ago
DidYaWipe•1mo ago
Aurornis•1mo ago
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”.
echelon•1mo ago
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.
brulard•1mo ago
detritus•1mo ago
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.
brulard•1mo ago
robertoandred•1mo ago
ascorbic•1mo ago
rixed•1mo ago
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.
satvikpendem•1mo ago
hbarka•1mo ago
dagmx•1mo ago
From energy use, to security and accessibility, it was very problematic.
hbarka•1mo ago
throwanem•1mo ago
hbarka•1mo ago
throwanem•1mo ago
As though a rich kid channer ever impressed anyone.
ofrzeta•1mo ago
dagmx•1mo ago
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.
darzu•1mo ago
miohtama•1mo ago
dylan604•1mo ago
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•1mo ago
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
dylan604•1mo ago
cwillu•1mo ago
echelon•1mo ago
satvikpendem•1mo ago
rchaud•1mo ago
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•1mo ago
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.
afavour•1mo ago
panstromek•1mo ago
nine_k•1mo ago
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•1mo ago
throwanem•1mo ago
hbn•1mo ago
interludead•1mo ago
codedokode•1mo ago