There is always an implied performance expectation. If anyone thinks that performance is irrelevant for their use case, consider having 1-hour response times when a user tries to interact with the UI. Most people that reference the premature optimization quote don't understand what that's actually referring to as it doesn't mean to ignore best practices, Big-Oh complexity, data structures, or proper engineering. That quote was actually referring to low-level micro-optimizations like introducing bitwise manipulations, pointer arithmetic, etc. to try to reduce CPU cycles.
That's a great presentation, but still fascinating to me how much justification there is. One thing that really stuck out was how she mentioned that some types of applications just don't need to care about performance because the user is captive. While true, that feels weird to me as a developer who has always pushed the performance aspect of applications. Although I will always push correctness and reliability first, the ultimate goal is always going to be to then make it fast. If performance becomes a hard wall, it seems to me like the wrong approach. The other thing that stood out to me was when she mentioned UDF. At the last company I was at, when we began a new project from the ground up, we committed to UDF. Three years later, we did not have UDF. I've never been a big fan of trying to use a single architecture perfectly, because I find even the most tried and true architecture breaks down in some cases, but that tends to be OK. With MVC or MVVM, it's a guide for the overall architecture, and when you deviate from it in niche cases, that's OK because it's usually obvious why and there's very little disadvantage (and often a good advantage) to doing so. But both MVC and MVVM work well as overall application architecture. UDF seemed to be the opposite. As an overall application architecture, it quickly began to break down. We sank months into trying to make it work. It worked fine in niche cases, but eventually for the sake of shipping, we had to just push passed and get things to work, and we incurred a huge cost in both performance and code cleanliness in order to do so. So one of the big takeaways from this video for me was actually very unexpected, and that is a new question; is the efficacy of Compose tied to the efficacy of UDF, and if so, might there be a significantly harder line to cross than even I expected? I actually think this might be the "code smell" I've been trying to put my finger on. I don't like the Compose API because to implement it fully requires a fundamentally different implementation of the core application architecture that comes with significant and possibly insurmountable pitfalls. One of the core concepts I tried to take when guiding my team on the app we were making was "for now get it working, as long as you keep your implementation contained, we can always improve it later without a cost to the rest of the app". To that end, I pushed heavily to define interfaces and encapsulate functionality in utilities. That worked well, and it let us move quickly and choose when we addressed performance without causing an upset in the app. But while UDF was nice in some of these cases, we simply could not afford to let it guide the overall architecture largely because it made it extremely difficult to have *separate* utilities and components that handled themselves. It seems that Compose takes the biggest hit in exactly the same way. Each point at which Compose is compartmentalized compounds the performance cost. Despite the supposed point of this video being "it only didn't work for Pinterest, but it's still great", I actually felt like the real point is "it didn't work for an incredibly encompassing and representative use case" -- full stop. Landing page, lists, forms, navigation. Isn't that pretty much every app? Maybe there are apps that aren't, and maybe in one of those cases it will work well. But it actually sounds like the case where Compose and UDF are the right choice is an *exception*, not the norm. I think this was incredibly comprehensive, and a video that should be a required watch for anyone considering Compose.
I think they still haven't solved their problem and will face it again in the future. The proper way to solve this kind of situation is to have a reference architecture (example app) and transform it into what you want to achieve. Unfortunately, most org can't produce a reference architecture any way
I don't see why choosing to use View tech instead of Compose would be considered "stagnation", when it's effectively proven that adding Compose would create a statistically significant performance hit. Wouldn't that make it "adopting for the sake of adopting"? This is the same reason why we went back to Views/layout XMLs after trying Compose on multiple projects, if you want something stable, you just don't add something that ruins it.
@@keif6594 Evidently if the org actually ensures certain launch time and scroll performance metrics, the performance hit stops being negligible (the whole talk is about this)
Best conference talk I've heard in a while! Nice job Christina!
There is always an implied performance expectation. If anyone thinks that performance is irrelevant for their use case, consider having 1-hour response times when a user tries to interact with the UI.
Most people that reference the premature optimization quote don't understand what that's actually referring to as it doesn't mean to ignore best practices, Big-Oh complexity, data structures, or proper engineering. That quote was actually referring to low-level micro-optimizations like introducing bitwise manipulations, pointer arithmetic, etc. to try to reduce CPU cycles.
That's a great presentation, but still fascinating to me how much justification there is. One thing that really stuck out was how she mentioned that some types of applications just don't need to care about performance because the user is captive. While true, that feels weird to me as a developer who has always pushed the performance aspect of applications. Although I will always push correctness and reliability first, the ultimate goal is always going to be to then make it fast. If performance becomes a hard wall, it seems to me like the wrong approach. The other thing that stood out to me was when she mentioned UDF. At the last company I was at, when we began a new project from the ground up, we committed to UDF. Three years later, we did not have UDF. I've never been a big fan of trying to use a single architecture perfectly, because I find even the most tried and true architecture breaks down in some cases, but that tends to be OK. With MVC or MVVM, it's a guide for the overall architecture, and when you deviate from it in niche cases, that's OK because it's usually obvious why and there's very little disadvantage (and often a good advantage) to doing so. But both MVC and MVVM work well as overall application architecture. UDF seemed to be the opposite. As an overall application architecture, it quickly began to break down. We sank months into trying to make it work. It worked fine in niche cases, but eventually for the sake of shipping, we had to just push passed and get things to work, and we incurred a huge cost in both performance and code cleanliness in order to do so.
So one of the big takeaways from this video for me was actually very unexpected, and that is a new question; is the efficacy of Compose tied to the efficacy of UDF, and if so, might there be a significantly harder line to cross than even I expected? I actually think this might be the "code smell" I've been trying to put my finger on. I don't like the Compose API because to implement it fully requires a fundamentally different implementation of the core application architecture that comes with significant and possibly insurmountable pitfalls.
One of the core concepts I tried to take when guiding my team on the app we were making was "for now get it working, as long as you keep your implementation contained, we can always improve it later without a cost to the rest of the app". To that end, I pushed heavily to define interfaces and encapsulate functionality in utilities. That worked well, and it let us move quickly and choose when we addressed performance without causing an upset in the app. But while UDF was nice in some of these cases, we simply could not afford to let it guide the overall architecture largely because it made it extremely difficult to have *separate* utilities and components that handled themselves. It seems that Compose takes the biggest hit in exactly the same way. Each point at which Compose is compartmentalized compounds the performance cost.
Despite the supposed point of this video being "it only didn't work for Pinterest, but it's still great", I actually felt like the real point is "it didn't work for an incredibly encompassing and representative use case" -- full stop. Landing page, lists, forms, navigation. Isn't that pretty much every app? Maybe there are apps that aren't, and maybe in one of those cases it will work well. But it actually sounds like the case where Compose and UDF are the right choice is an *exception*, not the norm.
I think this was incredibly comprehensive, and a video that should be a required watch for anyone considering Compose.
Thank you for your sharing!
Not sure if it's Google or Jetbrains created Jetpack Compose?
Google created Jetpack Compose. JetBrains was porting it to desktop and iOS and called it Compose Multiplatform.
I think they still haven't solved their problem and will face it again in the future. The proper way to solve this kind of situation is to have a reference architecture (example app) and transform it into what you want to achieve. Unfortunately, most org can't produce a reference architecture any way
I don't see why choosing to use View tech instead of Compose would be considered "stagnation", when it's effectively proven that adding Compose would create a statistically significant performance hit. Wouldn't that make it "adopting for the sake of adopting"? This is the same reason why we went back to Views/layout XMLs after trying Compose on multiple projects, if you want something stable, you just don't add something that ruins it.
In my experience, performance hit has been negligible, and dev time is drastically reduced
@@keif6594 Evidently if the org actually ensures certain launch time and scroll performance metrics, the performance hit stops being negligible (the whole talk is about this)
@@Zhuindenthe whole talk is about one company's negligible being different to other company's negligible
@@BigCarso evidently it wasn't negligible for them
@@Zhuinden yes that's what I said
Only in Android development: the more experience a person has, the worst his life is.
The more experience, the harder he works and the less he gets.
I hate jetpack compose. It is awful.