This type of anti-big-js comment does great on Hacker News and sounds good, but my personal experience has always been very different. Every large server-rendered app I've worked on ends up devolving to a mess of quickly thrown together js/jquery animations, validations, XHR requests, etc. that is a big pain to work on. You're often doing things like adding the same functionality twice, once on the server view and once for the manipulated resulting page in js. Every bit of interactivity/ reactivity that product wants to add to the page feels like a weird hack that doesn't quite belong there, polluting the simple, declarative model that your views started off as. None of your JS is unit tested, sometimes not even linted properly because it's mixed into the templates all over the place. The performance still isn't a given either, your rendering times can still get out of hand and you end up having to do things like caching partially rendered page fragments.
The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are more readable and intuitive. You're still of course free to mangle it into confusing spaghetti code, but the basic structure often just feels like a better fit for the domain if you have even a moderate amount of interactivity on the page(s). As the team and codebase grows the structure starts to pay off even more in the extensibility it gives you.
There can be more overhead as a trade-off, but for the majority of users these pages can still be quite usable even if they are burning more cycles on the users' CPUs, so the trade-offs are often deemed to be worth it. But over time the overhead is also lessening as e.g. the default behavior of bundlers is getting smarter and tooling is improving generally. You can even write your app as js components and then server-side render it if needed, so there's no need to go back to rails or php even if a blazing fast time to render the page is a priority.
The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are more readable and intuitive. You're still of course free to mangle it into confusing spaghetti code, but the basic structure often just feels like a better fit for the domain if you have even a moderate amount of interactivity on the page(s). As the team and codebase grows the structure starts to pay off even more in the extensibility it gives you.
There can be more overhead as a trade-off, but for the majority of users these pages can still be quite usable even if they are burning more cycles on the users' CPUs, so the trade-offs are often deemed to be worth it. But over time the overhead is also lessening as e.g. the default behavior of bundlers is getting smarter and tooling is improving generally. You can even write your app as js components and then server-side render it if needed, so there's no need to go back to rails or php even if a blazing fast time to render the page is a priority.