Well sure, you could do so much better with a small library like Vert.x (which I love). But getting an entire app framework with config/routing/db connectivity/etc is just so easy with Spring Boot. Plus, you get a vast ecosystem. Now the memory usage and compile times? Yeah, youmightnotneedspringsmemoryoverhead.
If someone can buy this argument but not then immediately understand why a library like jQuery or React is popular, that’s a shame. It’s the exact same reasons: maturity, flexibility, and community/precedent.
It's basically a hard no from me on adding a dependency that buys me next to nothing, and bloats my payload to a customers/users mobile device. In that industry, every byte counts. In backend Java/Kotlin apps? I can pay the extra money for memory usage. I cannot ask my users to do the same.
Bundlers these days are very good. Any code that isn’t used is removed with tree shaking/dead code elimination, and React can be swapped with Preact which has a lot smaller bundle size as well.
I mean that it's not usually the language or the framework, but what overall interactions look like. If static HTML loads slowly, yes, it's the backend, but that's not what most sites look like these days; they're rich, client-side apps making lots of API and resource requests, not to mention overhead something like React adds.
It’s extremely app-dependent. For example, lots of heavy analytics, data crunching type apps can easily have multi-second (or longer) backend requests. For these, the BE tends to dominate perf issues.
However, for your standard CRUD type app, honestly round trips of 100-200 ms for backend requests are really common/standard. On the FE, loading and evaluating big JS bundles, rendering, etc., can be way slower. For CRUD apps I’ve worked on, perf issues on the FE have been more common than on the BE. Especially with the common React/Redux stack, it’s very easy to make perforce mistakes and end up with a lot of unnecessary component updates when things aren’t really changing.