Taking the load off of your server, and making the user's PC/tablet do more work, as well as greatly simplifying the server code to focus on data flow, business

Taking the load off of your server, and making the user's PC/tablet do more work, as well as greatly simplifying the server code to focus on data flow, business logic and data integrity, rather than mixing in presentation and minor U/I workflow complications. Having much of what you give to the remote client be static/cacheable content, with minimal data such as JSON passed rather than ballooned out JSP/JSF (etc) templated HTML, helps bring down bandwidth requirements, as well as server processing. Of course, now you have A LOT of event handling in a client app on top of your middleware / micro-services, but I feel it is a helpful separation of concerns. I suppose in my case it helps that I would rather do more of the app in Javascript, and less in Java. YMMV, substantially - I'm pretty sure I have a minority view at work :-) We are working on a rewrite of a largish app (for a small team, anyway) at work. We already have a second, alternate, client app for our back end for a pilot project that we can now easily tackle with the new architecture. There were very few changes required on the server, just an alternate login method to automate an initial connection to a third party app (which then runs our alternate U/I in a frame), rather than an interactive SSO form. We have a "Few Pages App", rather than Single Page App. By design, we reload a small number of alternate pages after a longish task, just in case (e.g. - resource leaks, whether from our own mishandling, or some library) - not because of known issues, mind you, but just out of my own paranoia that I would rather plan to allow for minor errors rather than requiring perfection.