3 ms·

There are still many use cases where server side rendering makes sense. For example, I work on a large, enterprise webapp, it has the frontend UI, which users

There are still many use cases where server side rendering makes sense. For example, I work on a large, enterprise webapp, it has the frontend UI, which users interact with heavily: this, we have built out using clientside Javascript which interacts with the Rails backend via an API. However, we also have an admin area -- many of those pages are used very rarely and are quite complicated. I initiated a change to build these panels using traditional server-side rendered ERB views. In the context of our codebase, it takes less code and it's easier to iterate on these without bothering with the Javascript framework. In other cases, like my personal blog, I use Jekyll to generate a bunch of static HTML and, essentially cache all this on Github pages. Javascript frameworks are amazing and can provide a much richer, much better experience. But, I don't necessarily think they're appropriate for all problems. One other big reason why, it just the inherent "experimental-ness" and, the churn / quick obsolescence you may find in this area. Some problems don't need to be re-solved every year or two. :)

shortstuffsushi 10y ago
> Javascript frameworks are amazing and can provide a much richer, much better experience. I think this is the point worth inspecting if you're considering server side rendering. If you're making a page that just displays content, I don't see any reason to throw Javascript in front of it. Just render your HTML and send it. If you want to make changes to the content dynamically, if it's going to take super long to load and you want to show users a loading screen, if they can interact with the content, etc, that may be a case to throw Javascript into the equation.
- aclimatt 10y ago
  This is incredibly true and something you don't realize until you're browsing the web on a slow connection. I was travelling with 2G and using most client side apps was near impossible. One app sent down a 1.9MB `components.js` file, and because it was a JS app, all scripts had to be loaded until anything rendered. Obviously server-side apps are in no way immune from this, but by default, unless you really do need a rich client experience, it's often not worth the bundle size and CPU load. Just send down HTML. You know which website works fabulously over 2G? Hacker News.

shortstuffsushi 10y ago

> Javascript frameworks are amazing and can provide a much richer, much better experience. I think this is the point worth inspecting if you're considering server side rendering. If you're making a page that just displays content, I don't see any reason to throw Javascript in front of it. Just render your HTML and send it. If you want to make changes to the content dynamically, if it's going to take super long to load and you want to show users a loading screen, if they can interact with the content, etc, that may be a case to throw Javascript into the equation.

aclimatt 10y ago
This is incredibly true and something you don't realize until you're browsing the web on a slow connection. I was travelling with 2G and using most client side apps was near impossible. One app sent down a 1.9MB `components.js` file, and because it was a JS app, all scripts had to be loaded until anything rendered. Obviously server-side apps are in no way immune from this, but by default, unless you really do need a rich client experience, it's often not worth the bundle size and CPU load. Just send down HTML. You know which website works fabulously over 2G? Hacker News.