Comment by grishka
10 months ago
All of these modern "declarative" frameworks seem to be optimized for hello world kinds of apps. Jetpack Compose, too.
And SwiftUI is just being too smart sometimes: https://tonsky.me/blog/swiftui/
Not sure about other people, but for me, my UI framework making its own heuristic decisions about how to lay out and style my views is the last thing I want. It robs me of the certainty that my UI will look and work the way I intend. And this is why, as an Android developer, I still build my apps with decade-old tried and true technologies.
Yeah that view builder syntax is a perfect example of optimizing for the wrong thing. It makes for nice short examples but in real apps your compile times explode trying to untangle these crazy generics and the compiler very often just throws up its hands and tells you to figure it out. This means you just start commenting out bits of code until you find by trial and error what it doesn't like.
That this is shipping in the native UI framework for a trillion dollar tech company is astonishing.
Except those technologies are now deprecated and you don't know when they might be removed. Jetpack Compose is now the vendor-favored way to build apps, so best practice is to use that.
I don't care what "best practices" are. Seemingly everyone sticks to these, yet here we are discussing that software quality everywhere throughout the industry has taken a dip.
> Except those technologies are now deprecated and you don't know when they might be removed.
Views and activities and XML layout will never be removed, of that I'm certain. After all, Compose does use views in the end. That's the only way to build UIs that the system itself understands. And, unlike SwiftUI, Compose itself isn't even part of the system, it's a thing you put inside your app.
I don't care about deprecations. Google has discredited itself for me and its abuse of the @Deprecated annotation is one of the reasons. The one thing that's very unfortunate is that all tools unquestionably trust that the person who puts @Deprecated in the code they maintain knows what they're doing, and nothing allows you to selectively un-deprecate specific classes or packages; you can only ignore all deprecations in your class/method/statement.
And, by the way, I also ignore the existence of Kotlin. I still write Java, albeit it's Java 17. The one time I had to deal with Kotlin code (on a hackathon) it felt like I'm coding through molasses.