How does Litho (Kotlin API) compare to Compose?

[cable729]

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!

[astreet]

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!