[Typo]: Since the build tool you select?

[godmar]

Summary

In the documentation it says here:

Improving Application Performance
Since the build tool you select only support single page apps (SPAs) ...

This struck me as odd because it is not only grammatically incorrect ("only supports" or "build tools you select" - or should it say "you selected?"), but also confusing. Which build tool is it referring to? The ones mentioned earlier, like vite, parcel, rsbuild? I know vite supports SSR, so what is meant here?

Page

https://react.dev/learn/build-a-react-app-from-scratch#improving-application-performance

Details

No response

[rickhanlonii]

Yeah it's missing an "s" for "supports".

It's referring to the build tools mentioned, yes Vite supports SSR, but you have to implement how you use SSR yourself, here are the Vite docs for setting it up, for example. There are also different ways to do SSR that you'll need to decide on (e.g. streaming, per route, etc), and creating the optimal SSR setup is complex. It's not as easy as just srr: true.

[godmar]

Thanks. To be really honest, after having not used React actively for 3 years and now considering getting back into it, I was actually reading this page in the documentation to get some guidance as to what the React team at this point recommends. Do pure client SPAs still have first class support in React? Or is there a strong encouragement to buy into the server-side components next.js and Vercel have been pushing for the last couple of years or so?

I wish the documentation could be augmented to be more clear about that - nobody wants to use a framework (or even something that represents itself as a library like React) and then code against its grain - thus it's important to know what direction it is taking.

[rickhanlonii]

Do pure client SPAs still have first class support in React?

Yes. All of the the frameworks we recommend support building SPAs mostly out of the box. Our recommendation is to avoid locking yourself into one rendering pattern so you can pick a SPA now and add other rendering options as you go without re-writing your app. Most SPAs end up having use cases that would be better served by things like SSR or SSG on at least some pages, but often can't choose to do that without significant effort.

The docs should be clear about this on the Creating a React App page:

[godmar]

Thank you again. The page you linked to seems more clear, and reading between the lines, it seems that in order to earn the React team's "full stack" framework designation, a framework would still need to support a deployment mode that doesn't require running React code on the server in response to requests. That's good to know.

[rickhanlonii]

Awesome, glad to hear it. There's a lot of confusion about this, but our goal is to give you better options to build any kind of app you want out of the box, not to force you to use a server. But for many cases, using a server would result in better performance, which is why every framework (not just in React, but also SvelteKit, SolidStart, etc) at least supports and often recommends using SSR if performance is a priority.

That's also why the Chrome team encourages it:

Broadly speaking, we encourage developers to consider server-side rendering or static rendering over a full rehydration approach.

[PWuttam]

Hi! I noticed the sentence:

"Improving Application Performance Since the build tool you select only support single page apps (SPAs)."

This sentence appears to be grammatically incorrect and a bit unclear.

I’d like to propose rewriting it as:

"Once you select the build tool, you’ll be able to improve application performance. The selected build tools only support single-page applications (SPAs)."

This version separates the ideas more clearly and corrects the verb agreement (“support” → “supports”).
Would this change be acceptable?

If so, I’d be happy to open a pull request!