How does Litho (Kotlin API) compare to Compose?
cable729 opened this issue · 4 comments
I do not see this documented anywhere. I've searched the Litho docs, Github Issues, StackOverflow, and Googled for blogs.
I think an in-depth comparison would be useful for many people considering using Litho. I hope you consider adding one!
Sorry this has taken a while, I wrote a long answer but it didn't cover everything I wanted so ended up putting it on the backlog, and well... 18 days later.
First-off, I'd recommend folks evaluate the two for themselves to see which meets their needs for product quality, perf, devx, integration with existing code (if applicable), etc: that's going to give a clearer picture most relevant to their specific context than anything I'll write below.
Second, both frameworks are moving targets due to both being under active development, so who knows how long much of the below will stay accurate after posting :)
As far as similarities go, both are declarative UI frameworks in which you write Comp(onents|omposables) which are effectively special static functions which should have no direct side effects while executing. They both 'resolve' down to some primitives - Views/Drawables in Litho and drawing commands in Compose for Android (I believe!). Both introduce a new way of thinking about writing UI, which solves many problems (e.g. bugs in managing UI state) and introduce fun new ones ('why is this update recreating so much of the tree?').
Both frameworks take React as a degree of inspiration, and have many of the same concepts (though litho uses the React names still): e.g. useEffect in Litho and SideEffect in Compose exist to accomplish approximately the same thing - in the same way I think someone wrote a cheatsheet for React/Compose, you could write one for many concepts between Litho/Compose. I'm not trying to say the APIs are interchangeable though - Compose has made some very cool innovations on things like gesture handling, composable functions with and without return, @composable modifiers, etc.
At time of writing, some of the main differences I see are:
- On the core API front: Litho's Kotlin API is currently implemented without codegen or compiler plugins - it's plain old Kotlin code you can go read and step through in the debugger. Compose's semantics are realized via a compiler plugin can allow it to enforce some constraints and do some very clever things for fast updates, among other things, at the tradeoff of a bit more magic.
- A main selling point of Litho (Kotlin and Java) is performance: this comes from granular (per view/drawable type) recycling, view flattening (removal of layout-only views), incremental mount (views/drawables are only materialized as they enter the viewport, with more granularity than RecyclerView), and background/ahead of time layout. This latter one imposes restrictions on code used from Litho (it must be threadsafe!) but has shown to improve scrolling, interactions and navigation. I know less about analogous optimizations in Compose, but currently composition/recomposition happens on the main thread: however I believe the team is currently working on adding parallel/ahead of time layout.
- Beyond initial rendering, Compose is able to perform very granular updates in response to data changes via read tracking: Litho doesn't have this and generally gets by with coarser update boundaries, bridging out the Views/Drawables when necessary, and the use of DynamicProps and a Transitions API for animations.
- Compose encompasses a larger ecosystem, across multiple libraries: for instance, at the moment Litho Kotlin doesn't publicly provide APIs around navigation, material design, alternate layout systems (Litho is flexbox or bust atm, but hopefully changing soon), or a data system (snapshot state). Compose also is being positioned to target Desktop, KMP, and web (though I can't speak to the state of those myself)
- Compose inspection and tooling lives in Android Studio, Litho's is with Flipper (fbflipper.com)
- Litho Kotlin components are fully compatible with our Spec-generated (Java) components: not super relevant to new adopters but important for incremental migration of the API.
In some ways this is just scratching the surface, but I think it covers the broad strokes. I'll end with saying that Compose is a really amazing set of libraries built by some very clever people, so major props to the team at Google!
Hey @astreet, thanks a lot for such a good comparison / explanation.
I'm considering litho for a project at my current employer despite having used compose at my previous employer primarily due to performance reasons.
It's been 2 years now since you wrote this answer. Can you be kind enough to update this answer comparing how litho compares to jetpack compose now?
I believe litho might be better because of the ahead of time layout computation. I don't think compose internally does that, although not sure.
Would love your input here. Couldn't find much information on the web about litho and compose performance. TIA!
@Damercy Not a lot has changed from my answer. I know the Compose team has improving performance as a top priority, but performance still is our biggest blocker to greater adoption at Meta as well. My team is actually collaborating with Google on Compose performance with the goal of being able to use it more widely even in places where Litho is currently used. You're right that Compose doesn't currently do ahead of time composition - and we see better performance from Litho because of this - though some features/explorations are planned in that realm that will come out with Compose 1.8. (Also if you haven't already, make sure you're following Compose best practices like applying baseline profiles and using R8! There are decent online resources about improving compose performance)
Re: Litho. At least at this moment, I wouldn't recommend you all starting to use Litho. There are some companies out there who are already successfully using Litho, but you should be aware that you're going to get a lot less out of the box than with Compose, including ready to use widgets and community support/documentation, and that the open source experience for Litho is not a top priority for the company right now. I'm not sure whether there are any slack channels for community members to help each other. Things can always change but just want to be honest with where things stand right now!