New Android development technologies get hyped relentlessly, from Gradle to the Architecture Components to Kotlin to MotionLayout and now to Compose. This very newsletter contributes to that hype. Usually, the technologies being hyped are positive developments, solving key problems in Android app development. Many thought leaders in Android rapidly latch onto how these technologies solve problems and, as a result of their enthusiasm, feed the hype engine.
The problem is that hype is not always a positive thing, even if what is being hyped is positive.
Not every developer is in position to drop everything, learn the new technology, and apply it. Worse, developers deal with wave after wave of hype in different ways, including “tuning out” the hype or simply getting out of Android app development. Developers who think they can never catch up may simply drop out.
The “drop out” approach gets exacerbated when hyped technologies get forced onto developers. Gradle is a vast improvement over prior Android build systems, such as Ant and the one intrinsic to the Eclipse IDE. However, Google went from “we will continue to support Eclipse indefinitely” to “we are not supporting Eclipse” in little over a year, effectively forcing the hands of developers to switch to Gradle whether they were ready to or not. Similarly, Google has stated that they will continue to support Java indefinitely… but technologies like Compose will be awkward fits at best with existing Java-centric code bases.
To counteract this, we need to ensure that we provide lots of levels for adopting Compose, beyond a “smash cut” rewrite of an entire app. To date, and to some level, we have this: key Compose developers have pointed out that incremental adoption of Compose is possible, with a smattering of examples.
By the time Compose ships its first stable release, we will need a lot more of this, from Google and from the community. We need developers to feel confident that they can migrate to Compose, and do so on their own timetable. Developers need to believe that Compose can be added incrementally to an app, without a full app rewrite. It is insufficient for this ability to merely exist — developers need to believe in it, which means that they need to find out about progressive Compose adoption and how to implement it.
I hope to be able to do what I can to help with this. And if you are writing a lot about Compose, it would be good if you could focus a portion of your time on the progressive-adoption problem. Let’s not lose Android developers who get overwhelmed with the technology churn — let’s instead help them not only learn how to use Compose, but how it can work alongside what they already have built.