|
"However, you are throwing the baby out with the bathwater. Client-side rendering saves server resources, and allows a single API to power web and mobile apps." I don't believe I am. There are certainly uses where I openly acknowledge that using a React is a good idea. If you're building something that needs to be a single-page application, for example, then I grant you that concerns of SEO and URLs and whatnot are superfluous. If you have a totally dynamic site, coupled with a Facebook-esque guarantee that your assets are nearly always in the user's cache, and a huge team of front-end engineers to optimize your code, great. But again, that's a tiny minority of teams. All webpages are "client-side rendered", so that's a bad use of words. That said, JS-based rendering only "saves resources" if you don't count the bandwidth of the user, the amount of code needed to display a page, render speed, time to first render, and so on. I can't count the number of Reactionary sites I visit on a daily basis that hang for 10+ seconds before rendering or peg my CPU -- and nine times out of ten, they're rendering static content. It's an epidemic, caused by people making bad technical decisions, and even big sites like Instagram get it wrong on the regular (Instagram, in particular, pegs my CPU so often while looking at photos that I believe their secret business model is to mine bitcoin in my browser.) A pure API may be easier to optimize, but unless you've transferred the time you're saving to front-end optimization, I guaranteed that you're punishing your users -- particularly those who are on low-bandwidth connections and/or mobile devices -- with lower performance and higher system demands. |