Thanks for taking the time to share this - because it's exactly what I feel is happening to webdev as a whole. We're adding unnecessary complexity trying to put

Thanks for taking the time to share this - because it's exactly what I feel is happening to webdev as a whole. We're adding unnecessary complexity trying to put everything on the user's browser vs. rendering a sane and functional blob of HTML that just gets the job done + sprinkling in the JS when needed for more interactive needs! > I'm not sure it will be faster or more stable than the old code even once they finish optimization. The only user-facing benefit appears to be that they replaced the 200-millisecond flash of white as it loads each page with a 5-second spinning beachball in the template as it collects the data a piece at a time. If it's a ton of individual web requests there's very little chance that it will optimize anything because it sounds like a lot of HTTP overhead. I've seen this same anti-pattern 1000 times in my career and frankly would rather take the processing onto a very fast webserver that's optimized to crank through stuff like that with some SQL/joins/etc. (ie: doing a few joins on the server side vs. and sending a "view" of the data is WAY more appropriate than putting the responsibility of lots of web requests on your client and increasing your HTTP overhead)... > I strongly suspect a lot of the motivation was the devs wanting to put some trendier technologies on their resumes. Yep - and often if that's the case they end up creating a mess of an application that has all sorts of crazy constraints that never needed to be introduced. --- That being said, new-era anything can be good. Heck - I needed to do the "shotgun a whole bunch of HTTP requests" approach for a GIS mapping solution that would load chunks of data in at a time based on the map's viewport. It just needs to be justified, and most of the time I feel like people just wanna do what they're comfortable with vs. what's a best-fit for the problem.