OK from single core $10 VPS you will be able to serve
1,080,000 unique initial loads per hour
and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?
The Performance Cost of Server Side Rendered React on Node.js
11–20 of 134 posts
Re: The Performance Cost of Server Side Rendered React on Node.js
#12[deleted]
Re: The Performance Cost of Server Side Rendered React on Node.js
#13well wasn't that clear? Isn't something like a Template Engine quite CPU intensive? Things were node.js performce poorly?
They include a comparison with using ES6 Template literals (native JavaScript string interpolation), and saw 10x increase over React. The native string interpolation actually came out just behind serving straight static files. JavaScript CPU performance is actually quite high among interpreted languages.
So to answer your question more specifically, no I don't think it is clear. What this is specifically isolating as the performance problem is that using React as a template renderer on the backend is not performant, not because of NodeJS performance, but because React is realistically not really specialized for this.
Re: The Performance Cost of Server Side Rendered React on Node.js
#14Earlier quoted context omitted.
But they're going to have to wait for the initial page load either way, whether it's rendered server side and sent over or they're shown some static content until its rendered client side?
They do, but the load will be spread among clients. The issue here is the load on the server.
I guess it depends on which direction you're coming from. From a traditional server side point of view, you're reducing the server work to just that first page load and making the client do the rest.
Re: The Performance Cost of Server Side Rendered React on Node.js
#15OK from single core $10 VPS you will be able to serve 1,080,000 unique initial loads per hour and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?
The issue is that it could be ~14,040,000.
Re: The Performance Cost of Server Side Rendered React on Node.js
#16Earlier quoted context omitted.
Sure, but every user has to do that initial page load. If all initial page loads are slow and expensive, it affects the user experience and costs money. Also, if you start getting requests faster than you can do the initial render, each subsequent user has to wait in line longer than the one before. Your server-side framework won't even show you how long people waited for a TCP connection.
But they're going to have to wait for the initial page load either way, whether it's rendered server side and sent over or they're shown some static content until its rendered client side?
[deleted]
Re: The Performance Cost of Server Side Rendered React on Node.js
#17well wasn't that clear? Isn't something like a Template Engine quite CPU intensive? Things were node.js performce poorly?
They include a comparison with using ES6 Template literals (native JavaScript string interpolation), and saw 10x increase over React. The native string interpolation actually came out just behind serving straight static files. JavaScript CPU performance is actually quite high among interpreted languages. So to answer your question more specifically, no I don't think it is clear. What this is specifically isolating as…
Does anyone actually use vanilla JavaScript string literals for all their backend rendering?
Re: The Performance Cost of Server Side Rendered React on Node.js
#18Earlier quoted context omitted.
They include a comparison with using ES6 Template literals (native JavaScript string interpolation), and saw 10x increase over React. The native string interpolation actually came out just behind serving straight static files. JavaScript CPU performance is actually quite high among interpreted languages. So to answer your question more specifically, no I don't think it is clear. What this is specifically isolating as…
Does anyone actually use vanilla JavaScript string literals for all their backend rendering?
All no, but quite a bit, in our prototype for our next gen codebase. Was quite nice because we had a lot of 'legacy' JSPx code that we transformed into JS code using a bit of one off programming with some clean up afterwards.
Re: The Performance Cost of Server Side Rendered React on Node.js
#19Earlier quoted context omitted.
They include a comparison with using ES6 Template literals (native JavaScript string interpolation), and saw 10x increase over React. The native string interpolation actually came out just behind serving straight static files. JavaScript CPU performance is actually quite high among interpreted languages. So to answer your question more specifically, no I don't think it is clear. What this is specifically isolating as…
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 to mutate it, or use some framework at which point you may as well just give up on template strings altogether.
But for any case where you’re basically going in the one direction, i.e. data -> DOM and not changing things once rendered it’s great.
Re: The Performance Cost of Server Side Rendered React on Node.js
#20Render on write, not on read.