this post was submitted on 01 Sep 2023
44 points (100.0% liked)

Programming

423 readers
3 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
44
Why is React, a client side rendering framework, a popular choice for server side rendering? (lemmy.ml)
submitted 1 year ago by cyclohexane@lemmy.ml to c/programming@programming.dev
13 comments fedilink hide all child comments
 

React (and Vue, et al) was built with client side rendering in mind. It just does not seem to fit the server side rendering pattern.

What are the use cases? From my perspective, if your app is a rich web app with a lot of interactivity, you probably want CSR and don't benefit much from SSR.

If you have a content-centric site, or a site with some interactivity but not much, you want a static site generator, or SSR. But in that case, a template engine with some smaller client side libraries (jQuery or AlpineJS or idk what all is out there).

Using React SSR for all of these seems like the wrong tool. What am I missing?

top 13 comments
sorted by: hot top controversial new old
[–] kev_handle 36 points 1 year ago (1 children)

I think you may be missing the concept of 'hydration'. A server side rendered app will deliver the pre rendered markup so that the client has something to immediately display while the framework continues to bootstrap in the background. It makes for much quicker and more efficient first loads, or 'time to first paint'. A SSR website will still be a CSR website after hydration completes.

In addition, many web crawlers are unable to execute JavaScript. So for many single page applications, or CSR as you call them, they appear as a blank screen to less sophisticated crawlers because the content is never loaded. This is an catastrophe for things like SEO. SSR fixes this issue by delivering the content without regard to JS execution for the initial load.

[–] cyclohexane@lemmy.ml 3 points 1 year ago (2 children)

If SEO matters beyond a couple landing pages, I find it unlikely that you would be developing a rich web app with that much reactivity. You are more likely content focused, in which case a static site generator or simpler SSR frameworks are easier and fit the use case much better. Even from a performance perspective, why ship the entire react run time if you do not need it?

And on the other hand, if you are developing a rich web app with a lot of interactivity, then do you really need SEO beyond a couple (or one) landing pages? You should develop the web app in React CSR and build the landing pages as static sites to optimize SEO. That is a lot easier to me.

[–] zevdg@lemmy.one 5 points 1 year ago* (last edited 1 year ago) (1 children)

The biggest issue is flexibility. What if you don't know if a page is going to need SEO or rich client side functionality when you build it, but then it does later? Do you want to rewrite the page from scratch every time that happens? This is especially true when you're trying to maximize productivity for junior devs on a large team. Are all devs working on the site knowledgeable enough to make the static site vs CSR call correctly when they first start working on every new page? Wouldn't a "Use framework X and we'll figure that part out later" approach be easier for everyone?

Also, what about pages that need both SEO and rich client side functionality. You can choose to limit yourself to only one or the other on any given page, OR you could use hydration to have your cake and eat it too. Maybe react or vue isn't the right abstraction, but if we can come up with a strong enough abstraction, hydration is a really useful general purpose pattern.

[–] cyclohexane@lemmy.ml 1 points 1 year ago

I suppose I just cannot imagine a situation where a rich interactive web app needs SEO that is not solved by having a separate landing page (and such solution not being way better and less effort than alternatives).

React has enough flexibility to be added later on to a project and not take over the entire web page, but only the parts it manages. It can act as a separate island or series of connected islands. So if you start thinking you dont need react but then later decide you want to add it to your non-react site, it should still be easily doable.

[–] kev_handle 2 points 1 year ago

There are many scenarios you'd want seo and a csr. Let's say you want a media player. Tons of interactivity, and lots of content. A landing page isn't going to cut it.

But that's the beauty of a framework like nuxt or next - you don't have to choose. You can have your cake and eat it too so to speak.

[–] lightsecond@programming.dev 6 points 1 year ago (1 children)

React and Vue already have lots of libraries, components, and know-how. You can also move from CSR to SSR and back depending on your requirements.

[–] cyclohexane@lemmy.ml 2 points 1 year ago

That's definitely the best argument for it, I don't deny. But I'm glad to see the web components space to be improving as well.

[–] Templa 4 points 1 year ago (1 children)

By my understanding on the matter, it depends on use case. Ecommerce websites benefit greatly from SSR due to the fact that they want to be able to show content as quickly as possible so the user have something to interact with. It also improves SEO.

[–] monad@programming.dev 7 points 1 year ago (2 children)

Well that’s why you would render on the server, not why you would use React to do it instead of the many, many server side frameworks

[–] jcg@halubilo.social 1 points 1 year ago

But then you'd be sacrificing all that comes with React. Unless you mean having the page rendered by another framework and having React components loaded later, but I'd think that would be less maintainable than if the whole thing was just in React.

[–] Templa 1 points 1 year ago

Oh, I just realized I completely misunderstood your post.

[–] Macil@programming.dev 3 points 1 year ago* (last edited 1 year ago)

If you have a content-centric site, or a site with some interactivity but not much, you want a static site generator, or SSR. But in that case, a template engine with some smaller client side libraries (jQuery or AlpineJS or idk what all is out there).

React works well in this role too because it supports SSR. This part seems to assume that React SSR is inferior to other classic backend HTML SSR solutions, which is not my experience. Even for static non-interactive content, the way React has you organize your code into components is a much better setup than most classic HTML template systems I've used. And then React makes it very easy to sprinkle in interactivity where you want, without requiring you to bridge unrelated server-side html templates and front-end code (which can often blow up in complexity and require work to be re-done separately on each side of the codebase). The same React components can be used in server-side rendering and client-side code, so whenever some new page interactivity requires the client to render something that was previously only server-side rendered, you don't need to rewrite the component's code in a new system and maintain two versions of it.

[–] exapsy@programming.dev 2 points 1 year ago

Cozx we went to a full circle. Back to sveltekit now until we find a better solution. Back then Virtual DOM was a feature, now it's more of a bug.