3 ms·
Historically, client-side-rendering came about at a time when server-side compute was expensive. You have to remember what CPU limitations were like prior to ar
by gspencley 2y ago
Historically, client-side-rendering came about at a time when server-side compute was expensive. You have to remember what CPU limitations were like prior to around 2010. Website load times were often slow, and scaled poorly with traffic, because anything dynamic needed to be rendered before it could be served. Caching was common fare but load spikes when caches expired were common and personalized content (along with an industry trend towards more and more personalization at the time) added a lot of additional expense.
It's funny how we have come full circle. We are now doing so much on the client that we are often reaching client-side resource limitations. In a typical pendulum swing that our industry likes to go through, many people are saying that the answer is server-side rendering. Many younger developers who weren't working in the industry prior to the shift towards CSR even repeat this sometimes while thinking that SSR is some new tech that's going to save us, unaware that SSR has its own trade-offs and that CSR was itself initially seen as a solution to scalability pains.
- tharmas 2y agoYes, and wasn't mobile a big part of the shift to client side? If mobile users lost their connection, for whatever reason, CSR was thought to be a good remedy for the user experience (UX).
- gspencley 2y agoInitially mobile network bandwidth was very limited and so CSR + single-page web apps was a way to cut down on full page loads. Lean RESTful endpoints could be optimized to only return what the client actually needed in a given context in order to update runtime state without having to fetch and re-render anything superfluous.