[deleted]
[deleted]
Server-side rendering is a better choice for many applications (2020)
131–140 of 286 posts
Re: Server-side rendering is a better choice for many applications (2020)
#132Lot of bashing of this idea, not sure why. The entire industry has shifted from "web developer" to frontend/backend developers. What used to be a web developer is now called full stack. It seems like a big deal to me and the entire shift is an indicator of how much the IT community is behind front end clients talking to a separate back end. Server side rendering is no longer considered normal. Server site rendering n…
I wouldn't say server side rendering is a "Thiel Truth," because it's a thing that is already popular and uncontroversial and agreed upon by millions. There is an echo chamber where this happened: * Facing massive datacenter costs, Google and Meta realized that if they could hand off rendering to the client, they could have smaller datacenters and save a lot of money. Things like React and Angular were born. Other co…
Is there any evidence, even anecdotally, that reducing datacenter costs had any significant relevance to the development and rise in popularity of single-page apps and JavaScript UI libraries like React and Angular?
My own memory of the history of the web is that early web sites with a lot of client-side interactivity benefited greatly from the huge leap in interactivity, and came out several years before JavaScript libraries were widely available for ordinary developers to build web sites with similar functionality. (I'm not counting arguably "non-web" technologies like Flash and Java applets.) The earliest such web sites I can remember are e-mail, calendar, and mapping apps.
Re: Server-side rendering is a better choice for many applications (2020)
#133Really? This is the most controversial idea in the world according to the author? If the interview was about the largest strawman one could attack then maybe they would pass it, otherwise probably not.
Re: Server-side rendering is a better choice for many applications (2020)
#134Really? This is the most controversial idea in the world according to the author? If the interview was about the largest strawman one could attack then maybe they would pass it, otherwise probably not.
[deleted]
Re: Server-side rendering is a better choice for many applications (2020)
#135The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.
There's definitely at least some truth to this. And even when working on both frontend and backend (on a small team), I find it useful to have a clear separation between client-side code and server-side code, with a well-defined boundary between them. This might be shaped by my experience with ASP.NET and .aspx templates, though; I struggled to understand when and how the client-side code would call the backend to send input or get updated data.
Re: Server-side rendering is a better choice for many applications (2020)
#136Really being stated is SSR is far simpler (less moving parts, less latency, less things to break, 100% control of environment, etc) and therefore superior, which should make it the first and best choice for nearly all web applications.
Re: Server-side rendering is a better choice for many applications (2020)
#137This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency management and builds, and any dev team who knows what's up is going to include a frontend build for their app. So, given that the frontend build is baked into _any_ application build, if you decide to do template rendering in any language other than JS/TS, you are adding another build to your project. That means you need to configure that build for all environments, configure CI, and support that build going forward. Save yourself the trouble and just render everything server-side in JS.
As for speed concerns, server rendering is almost never the bottleneck for any application. DOM rendering can be slow, but even JS renders several magnitudes faster than any network action. So your latency to the server alone is always going to be much, much slower than your render. Same with any network calls your app has to make, DB access, etc. In my many years of building SSR apps I have never had to optimize a render.
Re: Server-side rendering is a better choice for many applications (2020)
#138Lot of bashing of this idea, not sure why. The entire industry has shifted from "web developer" to frontend/backend developers. What used to be a web developer is now called full stack. It seems like a big deal to me and the entire shift is an indicator of how much the IT community is behind front end clients talking to a separate back end. Server side rendering is no longer considered normal. Server site rendering n…
I wouldn't say server side rendering is a "Thiel Truth," because it's a thing that is already popular and uncontroversial and agreed upon by millions. There is an echo chamber where this happened: * Facing massive datacenter costs, Google and Meta realized that if they could hand off rendering to the client, they could have smaller datacenters and save a lot of money. Things like React and Angular were born. Other co…
That doesn't match what I saw. What I saw was people hammering on latency because of its effect on conversion and other forms of engagement, and believing that the best way to control latency when consumers often had slow, unreliable connections was to avoid round trips and/or push them into the background. I.e., avoid page loads. SPAs allowed developers (at a cost, granted) to control how a web page's functionality degraded when dealing with slow or spotty connections, and that was seen as having immense ROI for anything consumer-facing.
Naturally after years of investment in building consumer-facing sites like this, the skills and tools became ubiquitous and arguably overused.
Re: Server-side rendering is a better choice for many applications (2020)
#139The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.
> a clear separation between frontend and backend devs
I love the 'CHAMP' stack, which stands for CSS, HTML, Apache, MySQL and PHP. ;) Clear separation between frontend and backend.
I'm almost happy that I started webdev in the 90's. This 'ancient' technology is still going strong, with websites and a whole lot of webapps.
Re: Server-side rendering is a better choice for many applications (2020)
#140All this noise around "back to the roots" template rendering seems to ignore the elephant in the room that FE devs DON'T want to work with jinja2, django templates and all this jazz as it is perceived as a devaluation of the role + they need to learn specific syntaxes instead of having a "one size fits all" approach like with js frameworks.
[deleted]