5 ms·
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 st
by kennu 9y ago
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?
- OoooooooO 9y agoHow do you do that with dynamic content?
- kennu 9y agoIn my view the user-specific parts and frequently updating data should be rendered on the client side. The pre-rendered HTML should contain the less-frequently changing information that is important for SEO.
- always_good 9y agoGiven the option, and pretending it were just as easy to implement either, why would you wait until the document loads to fetch resources via Javascript when you can render the content on the server? The article points out one downside: React's render-to-string faculties are slow.
- abritinthebay 9y agoThat would be one way of using it. Though practically speaking a very limited way of doing it and not very useful for a lot of dynamic sites.
- andrewwharton 9y agoThat'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.
- richdougherty 9y agoThis is what I'd like to see a performance comparison for. 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.
- paxy 9y agoMore and more sites are using React for general purpose server-side rendering, even if the site isn't a single page app. I believe that's what the article is targeting.
- deleted 9y ago[deleted]