|
Agreed, and so far the replies to your question are (for me at least) deeply unsatisfying. We already had SSR back in the CGI days, and it was awesome when we moved a lot of that stuff to the client. I know this is all a giant Wheel of Time, but I'm not ready for us to go back just yet. :) SSR to help with page loading seems like a poor reason. I'm sure there are exceptions, but so many sites make gobs of requests for bazillions of elements (trackers, ads, etc.) anyway. Seems like there is lower hanging fruit we should check out first. Doing it for SEO just makes me sad - a major architectural change just to try to keep up in the never-ending chase to make Google happy is depressing. The big upside in moving dynamic rendering to the client for me was that it then made it far easier to have a cleaner separation of duties between a web designer and a developer. You take a graphical designer and have them master HTML/CSS and they can then create the initial design, make it into valid HTML/CSS files, be responsible for things like site responsiveness on different screen sizes, browser quirks, most of accessibility tasks, etc. The developer's job is to "wire it up" - things like populating the data, making the site react to user input, and so forth. The big win was that this division of labor is not only enabled at the outset, but it is relatively easy to maintain through the entire life of the site. We had tons of sites where there were design refreshes with little (and in a few cases, no) developer work. When I see SSR tools now (as well as client frameworks that chop up the HTML into chunks and then intertwine them with code) my first impulse is to wonder how that gets maintained and updated. Like, when the UI is redesigned and reorganized, does all of that code have to be rewritten? When something doesn't work right on Safari, can the web designer help much or is it all on the shoulders of the dev? |