[HN Gopher] Lottie is an open format for animated vector graphics
___________________________________________________________________
Lottie is an open format for animated vector graphics
Author : marcodiego
Score : 230 points
Date : 2025-05-25 14:45 UTC (8 hours ago)
(HTM) web link (lottie.github.io)
(TXT) w3m dump (lottie.github.io)
| herrherrmann wrote:
| 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.
| throwanem wrote:
| 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 wrote:
| 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 wrote:
| Shouldn't it be possible to compile Lottie-animations down to
| SVG+JS? Is that maybe just something that's still missing?
| JusticeJuice wrote:
| That's exactly what the library does for its web renderer.
| There's a svg renderer and a web renderer.
| herrherrmann wrote:
| 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).
| echelon wrote:
| > 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.
| bsimpson wrote:
| 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.
| Benanov wrote:
| 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.
| atemerev wrote:
| 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.
| WorldPeas wrote:
| 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 wrote:
| 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.
| Aurornis wrote:
| > 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".
| echelon wrote:
| > 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.
| brulard wrote:
| 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.
| detritus wrote:
| 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(tm) 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 wrote:
| 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.
| rixed wrote:
| > 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.
| satvikpendem wrote:
| 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.
| hbarka wrote:
| 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.
| dagmx wrote:
| 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.
| hbarka wrote:
| 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.
| throwanem wrote:
| 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.
| hbarka wrote:
| >> on dialup
| throwanem wrote:
| > >> on dialup
|
| As though a rich kid channer ever impressed anyone.
| ofrzeta wrote:
| I've worked with RealNetworks tech in the 90s and think
| it is much better now with open source techology and HLS.
| darzu wrote:
| 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.
| dylan604 wrote:
| 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.
| cwillu wrote:
| Ruffle exists: https://ruffle.rs/downloads#website-package
| echelon wrote:
| Ruffle is great! But there's no great, well-maintained tool
| to author SWF files.
| satvikpendem wrote:
| 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
| afavour wrote:
| Not to mention CSS animations (and the newer Web Animations
| API) allow hardware acceleration while libraries like this do
| not.
| panstromek wrote:
| 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).
| nine_k wrote:
| 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 wrote:
| 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 wrote:
| 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.
| zdragnar wrote:
| 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?
| cjbgkagh wrote:
| 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 wrote:
| 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 wrote:
| They say on https://rive.app/pricing that the Format is OS
| and MIT, perhaps I have missed something?
| euvin wrote:
| 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
| DidYaWipe wrote:
| 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.
| andrewingram wrote:
| 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.
| victorbjorklund wrote:
| I dont like that you cant really SSR (the starting frame) the
| animations. At least as far as I know.
| mpeg wrote:
| 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.
| victorbjorklund wrote:
| In an easy way just using the lottie-file? That is cool! Have
| to check it out.
| WorldPeas wrote:
| 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
| panstromek wrote:
| 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.
| chrisldgk wrote:
| 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 wrote:
| I haven't worked with Rive either, but those I've known who
| did have seemed pretty over the moon about it, fwiw.
| k__ wrote:
| Rive players are open source, so I assume the format is
| too?
| jszymborski wrote:
| Yes, so is the runtime and the renderer (per their
| website)
| mrcartmeneses wrote:
| Or worse! You get handed off something unrealistic that won't
| compile to lottie but "client has signed off"
| echelon wrote:
| 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
| burdibox wrote:
| 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...
| phkahler wrote:
| Sounds like a build system, not a file format. Does it work
| inside any container format that supports audio with it?
| crazygringo wrote:
| 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.
| IshKebab wrote:
| 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.
| crazygringo wrote:
| 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.
| jlouis wrote:
| Zipped JSON is just massive waste of energy in a battery.
| We don't want that.
| _kblcuk_ wrote:
| 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.
| moralestapia wrote:
| It seems like you're quite knowlegdeable about all of this.
|
| Can we see what you've built?
|
| Edit: Huh? What's wrong with wanting to know more?
| micromacrofoot wrote:
| do you also think movie critique should be limited to
| directors with better rated films
| moralestapia wrote:
| Sorry but, what?
|
| This is just nonsense.
| karaterobot wrote:
| Your comment reads like you're questioning their right to
| have an opinion based on demonstrating their qualifications
| to your satisfaction. That, and they have to reveal their
| identity on the internet to satisfy your requirements. I
| don't know if it was clear to you that that's how it sounds.
| moralestapia wrote:
| Then you should read the rules of this site [1].
|
| Perhaps you're new here, but that's not the spirit :).
|
| 1: https://news.ycombinator.com/newsguidelines.html
| checker659 wrote:
| Using something like MXF would've been perfect.
| Wowfunhappy wrote:
| When I've used Lotte, the choice has been between Lotte and an
| mp4. Compared to the mp4, Lotte is much smaller.
| filcuk wrote:
| That comparison makes no sense. Apples and oranges.
| Goz3rr wrote:
| 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
| foooorsyth wrote:
| Does Lottie do no temporal compression? Is it just a sequence
| of p-frames with a json manifest?
| userbinator wrote:
| _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.
| 65 wrote:
| 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!
| mpeg wrote:
| 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
| mmooss wrote:
| It won't export as SVG?
| personality1 wrote:
| I prefer rive.app, it is a lot lighter and easier to work with
| imo, plus, it has a great editor
| terpimost wrote:
| Why would rive website use video instead of their binary format
| and performant js?
| neurowave wrote:
| 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.
| gervwyk wrote:
| 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.
| poyhen wrote:
| 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
| sergiotapia wrote:
| I hate working with Lottie, it's json just a terrible format.
| What are alternatives in the react native world?
| vyrotek wrote:
| https://rive.app/docs/runtimes/react-native/react-native
| b3ing wrote:
| 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 wrote:
| raster images are also supported asset types for input
| ComputerGuru wrote:
| 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.
| nokeya wrote:
| 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
| landr0id wrote:
| 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")
| shmerl wrote:
| How does it compare to SVG?
| Tade0 wrote:
| 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 wrote:
| Those are all gifs of animations on that page.
| Tade0 wrote:
| That is a huge indictment towards my company laptop. Or
| perhaps it was a different page. I will have to establish
| that on Monday.
| Dwedit wrote:
| Isn't Flash an open format?
| itsthecourier wrote:
| been using it for years, our apps look awesome because of it
| nye2k wrote:
| 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.
| zhyder wrote:
| 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. O personally think there's enough of a
| market for GenAI Illustrator with After Effects.
| userbinator wrote:
| 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.
| aramattamara wrote:
| Lottie hogs CPU in browser like crazy.
___________________________________________________________________
(page generated 2025-05-25 23:00 UTC)