7 ms·

There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Ha

There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Hacker News. In all these cases, you can save on development time by writing just one application instead of two (server and client), and improve performance (no need to load multimegabyte JS applications and make multiple AJAX requests to display a page). Of course, there are cases when SPA-style application is better, for example: (graphic/circuit/text) editors, IDEs, mobile newsfeed-based apps - everything that resembles an app rather than a page with text, menus and images. But in these cases you usually don't need server-side rendering. And sometimes you cannot even use it - for example, if your code needs to know browser windows size to arrange objects on the page. So I think that SSR (running JS on server) is rarely useful.

temp8964 5y ago
LoL. The truth is most sites don’t need tons of js, but we’re in the sad state where normal websites begins with heavy js framework, junky cookies, annoying notifications as a default. Then add more and more junks …
midrus 4y ago
But it is trendy and fashion, so we still do it /s
beaconstudios 5y ago
In my experience (having implemented React SSR a few times for different companies) it's usually applied halfway between the two, on simpler form-driven websites - process-driven screens, marketplaces, the kind of places where you want either the performance improvement of a prerender or the SEO friendliness.
qbasic_forever 5y ago
VS Code is effectively a SSR IDE. Electron and node are the 'server' side of it and are necessary for interacting with the filesystem and all the native things browsers can't access (running processes, terminals, etc.). It has a somewhat complex RPC model (inherent to all Electron apps in general) where JS code on the browser frontend side has to make requests with JS code on the node side and vice-versa, just like most Next.js style SSR apps. It's a very similar ball of complexity for better or worse as mentioned in this gist/blog post, and in general very necessary as browsers are only taking baby steps to give full access to file systems, processes, hardware, etc.
JJMcJ 5y ago
> documentation sites, blog-like sites Sites like those can often be fully static sites. Process the docs or the blog posts into HTML. Nothing is generated at runtime. Of course you can cheat a tiny bit, like putting the date in the footer, or cheat a lot. Life's a lot simpler if you don't cheat at all.
- dymk 5y ago
  Sites like those (e.g. Wikipedia) tend to be driven by a CRM on the backend, with content maintained by a team of people, and so it's not super reasonable for the site to be regenerated and the static HTML file to be reuploaded to the server on every change. Cache the body page, put the timestamped footer on it, and serve it up. Easy peasy, been doing it since 1995.
  - jiggawatts 5y ago
    It's trivial to generate pages statically, irrespective of the update volume. Instead of updating database rows, just save S3 blobs of HTML. The reason this is not done is an accident of history that is no longer required but has become the norm. "Back in the day", browser compatibility issues meant that user agent strings had to be inspected and different HTML content served based on the browser. Mobile browsers especially required vastly different content compared to desktop browser. I don't mean two different kinds of content, but dozens. Similarly, text encoding variations was a huge pain. With HTML5 and modern browser standards this is a thing of the past. The same static HTML can be served to everyone. Any content that needs to vary based on client-side metrics is best implemented by JavaScript or CSS, which can be responsive to display changes like phone rotation. There is literally no benefit to dynamic rendering for many sites. It nearly guarantees scalability issues at the hardest part to scale -- the database. It means that every "moving part" must always be moving, or you get a guaranteed outage. It means that any caching tier like a CDN gets you right back to the pros and cons of static rendering: either you don't cache all of the site OR you have to live with the limitations of static/stale content. CMS products like SiteCore or Wordpress are especially bad, doing everything fully dynamically. I've seen these products struggle to serve 10 requests per second on clusters of VMs that should be able to serve 10 million. The most crazy thing I saw was a plugin that did image compression optimisation dynamically with a fixed-size cache on a per-server basis. If you had more GB of pictures than the cache size, you'd get cache thrashing and the CPU load on all nodes would spike. Scaling up the farm wouldn't help either because the new server would have an empty cache and hence would overload its CPUs for hours. Simply pre-optimising everything and dumping the result in something like and S3 bucket would be orders of magnitude more efficient and scalable. We're talking up to 100 Gbps egress to the Internet, no sweat.
donavanm 5y ago
Your axis here seems to be something like "unique content/personalization per client." From every client sees the same documentation content to every page view/action of an IDE is unique.
noduerme 5y ago
Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React that would automate the Dom update and bind the Dom more closely to the data state on the server. After many years, front end programmers forgot how to build their own hooks and came to rely on automated views. Then they began to forget how to parse models and build controllers. Why not shuffle all that off to the back end anyway? One nice thing about rolling your own front and back ends is that you can determine when or if each individual subcomponent needs to update its visual state. Often this is very useful in managing the actual server load, but it requires understanding who needs this data immediately and who can load it lazily long after a page loads, or the other data updates server-side, not to mention whether it also has to become readable across a distributed or federated data structure. So after all the modern conveniences, server side rendering impoverishes both front and back end coders in the name of curing a problem with data transfer and efficiency that is far less of a problem than that of overly tight bindings between front end states and back end data storage. Anyone can write a tightly bound backend model/view/control.. it's a fun project. It's a horrible architecture.
- nickcox 5y ago
  > Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React I think you skipped a few years there! AJAX, Mootools, prototype, JQuery, etc.
  - noduerme 4y ago
    Totally ;) Between the first and second sentence. I'm still writing a lot of software in that paradigm. Basic AJAX, with nice typescript. JQuery (still super useful for having its own event loop). Underscore JS. Bit of PixiJS to replace the Flash I lost when I need something in canvas. Here's what I won't do: * Move any logic into HTML files * Use any nonstandard tags or inline any code to hook frameworks * Use any frameworks that modify the dom on the fly in any way I'm not 100% in control of. [edit] Here's what I do: Write all data types front/back in NodeJS now, or maintain a 1:1 datatype where PHP is involved that's a perfect mirror of the database table structure; strongly type everything coming in from DB calls before it hits the front end, including types that need to be dehydrated; make outbound objects rewritable to the DB and cached for writing until the time is right, depending on load; maintain high readability without forcing the backend to choke on every single long poler's data update. But hey, take 20 years worth of kids and put them through the same academies and job interviews, eventually they'll be great at answering questions about React and suck at writing useful code.
vecinu 5y ago
> So I think that SSR (running JS on server) is rarely useful. I would disagree for a couple of reasons. The team I work with at a large SV company built a very complex SSR framework for our mostly static app for 2 reasons: - Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend - SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized.
- alkonaut 5y ago
  Does SSR need to be so complex for SEO? Can't the backend basically throw its hands up and render a trivial (e.g. "reader mode" text view) version, as soon as a browser isn't detected properly, or determined to be known a bot/crawler? E.g. you skip all interactivity, layout etc. I assume Google would have to penalize sites that render something completely different to their bot, or else bait and switch would be rampant?
  - vecinu 5y ago
    > I assume Google would have to penalize sites that render something completely different to their bot, or else bait and switch would be rampant? That's correct. They call that "cloaking" when you render different content for a crawler than for a normal user. Google is rewarding sites for making the UX better for the end user. > Can't the backend basically throw its hands up and render a trivial (e.g. "reader mode" text view) version We're actually experimenting with this approach in a couple of different ways. One approach we're testing now is using AWS Lambda to render a fairly static version of the page using puppeteer. So far the results are promising as the page is true to what the end user would see (except for client-side logic / AJAX requests) and it renders much quicker than the standard experience with all the analytics/JS libraries we use.
  - ngrilly 5y ago
    This is what Discourse does.
- 5y ago
uuyi 5y ago
Worth pointing out that SSR scales better for huge surface area applications on very low resource endpoints like Citrix etc. Consider LOB enterprise applications. I’ve worked on ones with 700+ logical endpoints. A few chrome or edge tabs open on a few meg of JS and the client will bite the dust hard.
jefftk 5y ago
> sometimes you cannot even use [SSR] - for example, if your code needs to know browser windows size to arrange objects on the page It's been a very long time since I ran into a situation like that which wasn't best solved with CSS. Describe what you want to the browser and let it handle it for you.
dbbk 4y ago
I have a marketing site and a dashboard SaaS app. For the marketing site I decided to keep it in React for consistency, but I just kept the server rendering and removed the JS tags from the output. Now it's a fully server-rendered site with no client-side JavaScript, and it's super fast cause it's cached on the CDN. I feel like not many people realise this is an option but it can work really nicely.

temp8964 5y ago

LoL. The truth is most sites don’t need tons of js, but we’re in the sad state where normal websites begins with heavy js framework, junky cookies, annoying notifications as a default. Then add more and more junks …

midrus 4y ago

But it is trendy and fashion, so we still do it /s

beaconstudios 5y ago

In my experience (having implemented React SSR a few times for different companies) it's usually applied halfway between the two, on simpler form-driven websites - process-driven screens, marketplaces, the kind of places where you want either the performance improvement of a prerender or the SEO friendliness.

qbasic_forever 5y ago

VS Code is effectively a SSR IDE. Electron and node are the 'server' side of it and are necessary for interacting with the filesystem and all the native things browsers can't access (running processes, terminals, etc.). It has a somewhat complex RPC model (inherent to all Electron apps in general) where JS code on the browser frontend side has to make requests with JS code on the node side and vice-versa, just like most Next.js style SSR apps. It's a very similar ball of complexity for better or worse as mentioned in this gist/blog post, and in general very necessary as browsers are only taking baby steps to give full access to file systems, processes, hardware, etc.

JJMcJ 5y ago

> documentation sites, blog-like sites Sites like those can often be fully static sites. Process the docs or the blog posts into HTML. Nothing is generated at runtime. Of course you can cheat a tiny bit, like putting the date in the footer, or cheat a lot. Life's a lot simpler if you don't cheat at all.

dymk 5y ago
Sites like those (e.g. Wikipedia) tend to be driven by a CRM on the backend, with content maintained by a team of people, and so it's not super reasonable for the site to be regenerated and the static HTML file to be reuploaded to the server on every change. Cache the body page, put the timestamped footer on it, and serve it up. Easy peasy, been doing it since 1995.
- jiggawatts 5y ago
  It's trivial to generate pages statically, irrespective of the update volume. Instead of updating database rows, just save S3 blobs of HTML. The reason this is not done is an accident of history that is no longer required but has become the norm. "Back in the day", browser compatibility issues meant that user agent strings had to be inspected and different HTML content served based on the browser. Mobile browsers especially required vastly different content compared to desktop browser. I don't mean two different kinds of content, but dozens. Similarly, text encoding variations was a huge pain. With HTML5 and modern browser standards this is a thing of the past. The same static HTML can be served to everyone. Any content that needs to vary based on client-side metrics is best implemented by JavaScript or CSS, which can be responsive to display changes like phone rotation. There is literally no benefit to dynamic rendering for many sites. It nearly guarantees scalability issues at the hardest part to scale -- the database. It means that every "moving part" must always be moving, or you get a guaranteed outage. It means that any caching tier like a CDN gets you right back to the pros and cons of static rendering: either you don't cache all of the site OR you have to live with the limitations of static/stale content. CMS products like SiteCore or Wordpress are especially bad, doing everything fully dynamically. I've seen these products struggle to serve 10 requests per second on clusters of VMs that should be able to serve 10 million. The most crazy thing I saw was a plugin that did image compression optimisation dynamically with a fixed-size cache on a per-server basis. If you had more GB of pictures than the cache size, you'd get cache thrashing and the CPU load on all nodes would spike. Scaling up the farm wouldn't help either because the new server would have an empty cache and hence would overload its CPUs for hours. Simply pre-optimising everything and dumping the result in something like and S3 bucket would be orders of magnitude more efficient and scalable. We're talking up to 100 Gbps egress to the Internet, no sweat.

donavanm 5y ago

Your axis here seems to be something like "unique content/personalization per client." From every client sees the same documentation content to every page view/action of an IDE is unique.

noduerme 5y ago

Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React that would automate the Dom update and bind the Dom more closely to the data state on the server. After many years, front end programmers forgot how to build their own hooks and came to rely on automated views. Then they began to forget how to parse models and build controllers. Why not shuffle all that off to the back end anyway? One nice thing about rolling your own front and back ends is that you can determine when or if each individual subcomponent needs to update its visual state. Often this is very useful in managing the actual server load, but it requires understanding who needs this data immediately and who can load it lazily long after a page loads, or the other data updates server-side, not to mention whether it also has to become readable across a distributed or federated data structure. So after all the modern conveniences, server side rendering impoverishes both front and back end coders in the name of curing a problem with data transfer and efficiency that is far less of a problem than that of overly tight bindings between front end states and back end data storage. Anyone can write a tightly bound backend model/view/control.. it's a fun project. It's a horrible architecture.

nickcox 5y ago
> Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React I think you skipped a few years there! AJAX, Mootools, prototype, JQuery, etc.
- noduerme 4y ago
  Totally ;) Between the first and second sentence. I'm still writing a lot of software in that paradigm. Basic AJAX, with nice typescript. JQuery (still super useful for having its own event loop). Underscore JS. Bit of PixiJS to replace the Flash I lost when I need something in canvas. Here's what I won't do: * Move any logic into HTML files * Use any nonstandard tags or inline any code to hook frameworks * Use any frameworks that modify the dom on the fly in any way I'm not 100% in control of. [edit] Here's what I do: Write all data types front/back in NodeJS now, or maintain a 1:1 datatype where PHP is involved that's a perfect mirror of the database table structure; strongly type everything coming in from DB calls before it hits the front end, including types that need to be dehydrated; make outbound objects rewritable to the DB and cached for writing until the time is right, depending on load; maintain high readability without forcing the backend to choke on every single long poler's data update. But hey, take 20 years worth of kids and put them through the same academies and job interviews, eventually they'll be great at answering questions about React and suck at writing useful code.

vecinu 5y ago

> So I think that SSR (running JS on server) is rarely useful. I would disagree for a couple of reasons. The team I work with at a large SV company built a very complex SSR framework for our mostly static app for 2 reasons: - Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend - SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized.

alkonaut 5y ago
Does SSR need to be so complex for SEO? Can't the backend basically throw its hands up and render a trivial (e.g. "reader mode" text view) version, as soon as a browser isn't detected properly, or determined to be known a bot/crawler? E.g. you skip all interactivity, layout etc. I assume Google would have to penalize sites that render something completely different to their bot, or else bait and switch would be rampant?
- vecinu 5y ago
  > I assume Google would have to penalize sites that render something completely different to their bot, or else bait and switch would be rampant? That's correct. They call that "cloaking" when you render different content for a crawler than for a normal user. Google is rewarding sites for making the UX better for the end user. > Can't the backend basically throw its hands up and render a trivial (e.g. "reader mode" text view) version We're actually experimenting with this approach in a couple of different ways. One approach we're testing now is using AWS Lambda to render a fairly static version of the page using puppeteer. So far the results are promising as the page is true to what the end user would see (except for client-side logic / AJAX requests) and it renders much quicker than the standard experience with all the analytics/JS libraries we use.
- ngrilly 5y ago
  This is what Discourse does.
5y ago

uuyi 5y ago

Worth pointing out that SSR scales better for huge surface area applications on very low resource endpoints like Citrix etc. Consider LOB enterprise applications. I’ve worked on ones with 700+ logical endpoints. A few chrome or edge tabs open on a few meg of JS and the client will bite the dust hard.

jefftk 5y ago

> sometimes you cannot even use [SSR] - for example, if your code needs to know browser windows size to arrange objects on the page It's been a very long time since I ran into a situation like that which wasn't best solved with CSS. Describe what you want to the browser and let it handle it for you.

dbbk 4y ago

I have a marketing site and a dashboard SaaS app. For the marketing site I decided to keep it in React for consistency, but I just kept the server rendering and removed the JS tags from the output. Now it's a fully server-rendered site with no client-side JavaScript, and it's super fast cause it's cached on the CDN. I feel like not many people realise this is an option but it can work really nicely.