A modern programming language that makes developers happier.

kotlinlang

We have stated to build a Design System Library which will be consumed by multiple apps. Are there any good articles, tutorials or such to get inspiration from? I am opting for Compose but the POs (and teams to consume this lib) thinks its too early to to use Compose. Anyone built a proper DSL with Compose yet?

This is a tough position to be in. Both sides of the argument have good points.
The business wants stability and longevity. But the developer wants to modernize and stay current. The developer needs to speak to the company's wallet and convince them that it will save them money by adopting new tech.

Ultimately the code belongs to the company and as developers it's easy to get attached to the things we create. But the reality is it does not belong to us.

Square is using compose to build our new design system library. There’s some risk, sure, but we had already decided the library would need to have a declarative API before deciding to use compose, so the alternative was to build our own declarative UI toolkit from scratch which would be a lot riskier. 

<@U3BTCCC2W> Yes that's exactly how it is. So even though the guys on my side of the fence are backing me up some the teams down the line are still using Java and some have just started to migrate to Kotlin. So the spectrum is quite broad. We have a long way to go until we're ready on our side so ETA a first beta after summer and a 1.0 early 2022. 
Is there any point of building components in both AndroidView and Compose. My opinion is a clear NO.

<@U0KMMQA20> any more info on Squares DSL? It would be nice to read a bit more on what they are thinking.

If you’re only starting now, building in both seems like a huge waste. If you end up needing to use the compose components in Android views, you can always create lightweight wrappers. 

I assume you meant early 2022? We’re hoping to start shipping at least basic compose components around Q3/4 of this year, so a 2022 timeline seems very doable. 

Probably the biggest risk in general is that compose is so new we don’t really have a lot of industry practices built up around it yet (although we can inherit a lot of intuition from the react world). Especially if your team hasn’t even ramped up on kotlin, that’s a _very_ steep learning curve (kotlin + coroutines + compose). Not impossible to do, but you’re gonna probably have to invest in a lot of education. 

But compose is the future. We’re all gonna have to learn this stuff at some point, and it would be a shame to invest a year of engineering work into building a system in a legacy view system that, probably, none of your new hires will want to use by the time you’re done and that won’t be getting all the nice polish and features that compose is likely to see in the next few years. 