21–30 of 134 posts
So I thought the entire point of SSR was to speed up initial page load - if you pre-render all the static parts of the page, including what happens after routing, but before any API calls, so that your webserver can cache that static HTML for that route and serve it up. What this means is that the user immediately sees much more of a rendered HTML page, rather than seeing a blank page for 2 seconds and having to wait…
Earlier quoted context omitted.
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.
Earlier 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?
It uses tagged template literals to render to the DOM, so on the server side it could fall back to vanilla string interpolation.
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 that the whole point?
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…
Might help with some of those pain points
Earlier 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?
https://github.com/styfle/react-server-example-tsx/blob/4586...
[0]: https://github.com/styfle/react-server-example-tsx/blob/4586...
Earlier quoted context omitted.
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.
If all first time users see the same thing, why not serve a precompiled static html that then gets taken over by React. Isn’t that the whole point?
So I thought the entire point of SSR was to speed up initial page load - if you pre-render all the static parts of the page, including what happens after routing, but before any API calls, so that your webserver can cache that static HTML for that route and serve it up. What this means is that the user immediately sees much more of a rendered HTML page, rather than seeing a blank page for 2 seconds and having to wait…
No, it was to improve SEO and other clients without JS
Earlier 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?