Last week, I wondered where are the other Google Play composable SDKs
. That was with an eye towards Compose UI eventually “eating the world” — if Compose UI will become dominant in Android app development, then you will want your UI SDKs to be Compose-friendly.
The countervailing pressure comes from Android retroprogramming.
For the past several years, numerous developers have complained about the pace of change within Google’s recommendations and libraries. A subset of those developers have taken to abandoning much of the Jetpack outright, which presumably includes ignoring Compose UI. Their argument is that the quality of the Jetpack libraries is not great — combine that with forever chasing Google’s changes, and there is too much churn for too little value.
I appreciate their position. For years, I was anti-AppCompat, as it added a ton of bloat to solve a problem (“Material all the things!”) that Google itself invented. My concern was with low-end devices and the practical impacts of AppCompat on users. Eventually, AppCompat became all but mandatory, and I wound up moving through the “N stages of grief” (for some value of N) and reaching “acceptance”.
Saying that you don’t want to use Compose UI today is reasonable. It still has plenty of issues, and it has been stable for less than a year at this point. While Compose UI is gaining popularity, it has not yet “eaten the world”, and so there is plenty of time before adopting it becomes more pressing. And, even if Compose UI becomes dominant, if you want to ignore it for your own personal projects, that is your choice.
My concern is more in the commercial realm and development teams.
Some teams are big on creating their own app development frameworks that bear little resemblance to conventional Android app development. From a technical standpoint, that may make sense. However, if you wind up with staff who are expert in your custom framework and not so much in conventional Android app development, those developers will have difficulty working for other firms in the future. Some companies no doubt view that as a feature, not a bug: if developers have difficulty switching jobs, that can help reduce staff churn. However, it also may impede your ability to hire developers. Plus, from an ethical standpoint, companies have a responsibility for developing the skills of their employees, despite the risks of those employees leaving. After all, companies might shed those employees for any number of reasons, including layoffs and closures, and companies should not be leaving those employees worse off from a skills standpoint than when those employees started.
Similarly, saying “not yet” for Compose UI is reasonable, but “not ever” probably is not. You may think Compose UI is a buggy bloated bombastic bundle of bits. However, it is becoming a popular bundle of bits, regardless of bugs or bloat. Eventually, it is likely that developers who do not know Compose UI will have trouble getting jobs, just as Java-only developers do today. Conversely, your ability to recruit and retain talent may be curtailed if you are off on your own technology tangent. Some firms can get away with that, but not all.
Make sure that as you make technical decisions (“down with Jetpack! up with, um,
ListView!”), that you take into account the flow of time and the flow of talent. In other words, technical decisions have ramifications beyond the technology itself.