5 ms·

If you're on the fence about server-side rendering being needed for your webapp don't do it! As a team of two with one engineer, I decided YAGNI and instead foc

If you're on the fence about server-side rendering being needed for your webapp don't do it! As a team of two with one engineer, I decided YAGNI and instead focused on the responsiveness of the React and Redux-based web application. It is very snappy to load and our (paying) customers are happy. You might not need SSR. I don't. I expect there will be more work to optimize it and eventually it'll be obviously a good idea. But you don't need it right now if you're working on a SaaS product.

spinlock 9y ago
Also, if you _need_ SSR, rails might be a better approach. It's too bad the author didn't include it in the benchmark.
- lucaspiller 9y ago
  We did this recently with a small app that needs to be fast. The relatively simple page that you see when you first visit the site is rendered with plain old Rails, then when the user interacts with the page (based on DOM addEventListener hooks) it causes additional React components to be mounted and rendered. Originally I’d hoped to be able to render a basic version of the page with Rails, then ‘enhance’ it with React - ie render <button>For</button> with Rails, then when React has loaded, replace it with a React component. But I couldn’t find any details on using it this way, and given time constraints choose the simplest option.
  - styfle 9y ago
    > then when React has loaded, replace it with a React component What you described is basically `hydrate` which is how to enable React event handlers like onClick after a server-side render. https://github.com/styfle/react-server-example-tsx/blob/4586f3431b4bfd424179da3aad2c6adbddb0de10/src/browser.tsx#L11 https://github.com/styfle/react-server-example-tsx/blob/4586...
  - scaryclam 9y ago
    This is something we've done in the past, and it works well. In fact, the ability to do this (usability is important to us so progressive enhancement is a lifesaver) is why we looked at react in the first place.
timr 9y ago
It's the other way around: you might not (in fact, probably do not) need React. Start with server-side rendering, and move to React if your application's dynamism demands it. Most applications don't. It's painful to see so many websites building huge, slow, JS-rendered monsters for one or two dynamic elements per page. Unless you are Facebook (and have your JS cached within one hop of every internet POP in the world), server-side rendering is going to yield performance wins for nearly all visitors.
- mottomotto 9y ago
  Well that is a whole other debate. The best thing about React is common patterns. Second best is the availability of components. I've worked with JavaScript for a long time -- the Backbone.js days were painful. It was easy to accidentally leak event binds, code yourself into a corner, etc. The jQuery days were almost better in some ways but still had some real pain points. You missed that I'm working on SaaS and a web application. Client-side state is important -- each of my customers can load up most of their state to client-side and the performance is great. This is the whole point of client-side apps. Get rid of all that round trip latency sending HTML to the client of every click. Get rid of your complex server-side framework. Client-side is simpler if you learn and embrace it (and don't need server-side rendering). It's also much easier to have a consistent UX with client-side state. So use what is appropriate for you use case. For mine, that is 100% client-side no doubt. You can't beat the performance for an application.
  - timr 9y ago
    "You missed that I'm working on SaaS and a web application" I didn't miss that. SaaS means "software as a service", and doesn't imply anything about the complexity of your UI. Plenty of SaaS companies use server-side rendering. Likewise, "web applications" were being written long before React was a thing. Also no, you don't have to do a full server round-trip for every click, any more than you have to send JSON back to your Reactionary UI for every click. So sure, if you can truly load all of your data in one big JSON blob and do everything else client side, then I guess you're in the 5% of people who can benefit from React. The other 95% should use a good server-side rendering framework and get things like low latency, URL routing, progressive enhancement and SEO-friendly pages for free, and build the few dynamic elements on their pages with a simpler, more robust technology. I never said that React isn't useful, just that it shouldn't be the default choice for most people.
shams93 9y ago
No matter what system you use for server rendered pages most likely you will have to hit a database just to render out the site. These days that's a bad idea when we should be building progressive web apps that can fetch and cache content as needed from services but the entire app can live offline and even cache data in local storage to enable it to have at least limited offline functionality.
- mottomotto 9y ago
  That really is dependent on use case though. In my current project, I want the most up to date data possible so no caching. In reality, it is cached locally in the browser state and soon, I will be pushing data to update that browser state (based on other users activity in the same tenancy). I think generalizing to "we should be building progressive web apps" is harmful. You should do what is appropriate for your use case.
  - moogie 9y ago
    > I want the most up to date data possible so no caching This seriously doesn't mean "no caching" and shows a real lack of understanding about caching. You state that people should so what is appropriate for use case, though your other comments here go completely against that and are cargo cultist in the extreme. I think perhaps, when you say "should do what is appropriate for your use case" you actually just mean "what I think you should do".
    - mottomotto 9y ago
      It is not the kind of caching that the post I'm replying to is advocating ("the entire app can live offline and even cache data in local storage"). I mentioned the caching I am doing to point out things aren't so simple. I do mean quite literally that none of my API HTTP responses have a caching header (assets are coming from CDN with very long cache life). It might be more fruitful to try to explain why I go against that instead of simply saying I do without a rational argument that can be responded to. If anything, the thread pretty clearly revealed someone is extremely biased to server-side web frameworks and is unaware of the progression of client-side web APIs.
sandGorgon 9y ago
unless your startup's life and death depends on SEO - in which case, do it !

spinlock 9y ago

Also, if you _need_ SSR, rails might be a better approach. It's too bad the author didn't include it in the benchmark.

lucaspiller 9y ago
We did this recently with a small app that needs to be fast. The relatively simple page that you see when you first visit the site is rendered with plain old Rails, then when the user interacts with the page (based on DOM addEventListener hooks) it causes additional React components to be mounted and rendered. Originally I’d hoped to be able to render a basic version of the page with Rails, then ‘enhance’ it with React - ie render <button>For</button> with Rails, then when React has loaded, replace it with a React component. But I couldn’t find any details on using it this way, and given time constraints choose the simplest option.
- styfle 9y ago
  > then when React has loaded, replace it with a React component What you described is basically `hydrate` which is how to enable React event handlers like onClick after a server-side render. https://github.com/styfle/react-server-example-tsx/blob/4586f3431b4bfd424179da3aad2c6adbddb0de10/src/browser.tsx#L11 https://github.com/styfle/react-server-example-tsx/blob/4586...
- scaryclam 9y ago
  This is something we've done in the past, and it works well. In fact, the ability to do this (usability is important to us so progressive enhancement is a lifesaver) is why we looked at react in the first place.

timr 9y ago

It's the other way around: you might not (in fact, probably do not) need React. Start with server-side rendering, and move to React if your application's dynamism demands it. Most applications don't. It's painful to see so many websites building huge, slow, JS-rendered monsters for one or two dynamic elements per page. Unless you are Facebook (and have your JS cached within one hop of every internet POP in the world), server-side rendering is going to yield performance wins for nearly all visitors.

mottomotto 9y ago
Well that is a whole other debate. The best thing about React is common patterns. Second best is the availability of components. I've worked with JavaScript for a long time -- the Backbone.js days were painful. It was easy to accidentally leak event binds, code yourself into a corner, etc. The jQuery days were almost better in some ways but still had some real pain points. You missed that I'm working on SaaS and a web application. Client-side state is important -- each of my customers can load up most of their state to client-side and the performance is great. This is the whole point of client-side apps. Get rid of all that round trip latency sending HTML to the client of every click. Get rid of your complex server-side framework. Client-side is simpler if you learn and embrace it (and don't need server-side rendering). It's also much easier to have a consistent UX with client-side state. So use what is appropriate for you use case. For mine, that is 100% client-side no doubt. You can't beat the performance for an application.
- timr 9y ago
  "You missed that I'm working on SaaS and a web application" I didn't miss that. SaaS means "software as a service", and doesn't imply anything about the complexity of your UI. Plenty of SaaS companies use server-side rendering. Likewise, "web applications" were being written long before React was a thing. Also no, you don't have to do a full server round-trip for every click, any more than you have to send JSON back to your Reactionary UI for every click. So sure, if you can truly load all of your data in one big JSON blob and do everything else client side, then I guess you're in the 5% of people who can benefit from React. The other 95% should use a good server-side rendering framework and get things like low latency, URL routing, progressive enhancement and SEO-friendly pages for free, and build the few dynamic elements on their pages with a simpler, more robust technology. I never said that React isn't useful, just that it shouldn't be the default choice for most people.

shams93 9y ago

No matter what system you use for server rendered pages most likely you will have to hit a database just to render out the site. These days that's a bad idea when we should be building progressive web apps that can fetch and cache content as needed from services but the entire app can live offline and even cache data in local storage to enable it to have at least limited offline functionality.

mottomotto 9y ago
That really is dependent on use case though. In my current project, I want the most up to date data possible so no caching. In reality, it is cached locally in the browser state and soon, I will be pushing data to update that browser state (based on other users activity in the same tenancy). I think generalizing to "we should be building progressive web apps" is harmful. You should do what is appropriate for your use case.
- moogie 9y ago
  > I want the most up to date data possible so no caching This seriously doesn't mean "no caching" and shows a real lack of understanding about caching. You state that people should so what is appropriate for use case, though your other comments here go completely against that and are cargo cultist in the extreme. I think perhaps, when you say "should do what is appropriate for your use case" you actually just mean "what I think you should do".
  - mottomotto 9y ago
    It is not the kind of caching that the post I'm replying to is advocating ("the entire app can live offline and even cache data in local storage"). I mentioned the caching I am doing to point out things aren't so simple. I do mean quite literally that none of my API HTTP responses have a caching header (assets are coming from CDN with very long cache life). It might be more fruitful to try to explain why I go against that instead of simply saying I do without a rational argument that can be responded to. If anything, the thread pretty clearly revealed someone is extremely biased to server-side web frameworks and is unaware of the progression of client-side web APIs.

sandGorgon 9y ago

unless your startup's life and death depends on SEO - in which case, do it !