61–70 of 134 posts
Earlier quoted context omitted.
did you ever consider that you might not be doing something right ?
Not really, I'm the consultant people hire when they need to solve issues like this. There are some screenshots of what we're doing here: http://www.hyperfiddle-consulting.com/ http://hyperfiddle.net/ As I said, our app is sophisticated
Is this how you get your kicks?
I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?
Correct, except that initial app load time for un-cookied users with cold browser caches is a critical metric, since it largely determines whether they'll keep using your app. Fortunately, those are the scenarios where server-side caching can have a decent benefit, since you're essentially rendering the same view to all such users.
Isn't the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML/JS/CSS assets using a static webserver?
That's one use case. The other is for performance/seo where the initial markup for the app is generated and served to the client as HTML, then the React app bootstraps on the client and takes over managing the DOM.
1. Initial load using client-side vs server-side rendered. (Server-side should be faster.)
2. Warm load using client-side vs server-side rendered. (Client-side should be faster.)
Comparing to static is interesting, but not really an option if you're serving dynamic content.
Earlier quoted context omitted.
did you ever consider that you might not be doing something right ?
Not really, I'm the consultant people hire when they need to solve issues like this. There are some screenshots of what we're doing here: http://www.hyperfiddle-consulting.com/ http://hyperfiddle.net/ As I said, our app is sophisticated
Isn't the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML/JS/CSS assets using a static webserver?
Earlier quoted context omitted.
did you ever consider that you might not be doing something right ?
Not really, I'm the consultant people hire when they need to solve issues like this. There are some screenshots of what we're doing here: http://www.hyperfiddle-consulting.com/ http://hyperfiddle.net/ As I said, our app is sophisticated
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.
Earlier quoted context omitted.
Does anyone actually use vanilla JavaScript string literals for all their backend rendering?
I do this. It’s surprisingly effective, both in actual performance and developer productivity. The one area where it is useless however is for mutating DOM. It’s easy enough to create DOM using template strings, but if you say need to render something and then mutate it later on in you render function, it becomes terrible since you either have to do tricky string manipulation, actually create the DOM and use methods…
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 i…