Choosing a React stack
I'm sure this has been asked before, but I'm struggling to find any comprehensive answers / advice. Apologies if this is very old ground.
I'm trying weigh up the dis/advantages of various different toolchains within the React ecosystem. The big ones are Next, Remix, Astro. There are also more lightweight tools such as Vite, combined with the new Tanstack Router and something like Convex.
Rather than delve into the details of each of the tools per sé, I wonder if people would be able to provide any guidance on what to look for when choosing a setup. Obviously this will depend on the product that's being built, but general questions, things to ensure are covered etc. would be really appreciated.
Apologies if that's a little too vague, there are a lot of tools out there, and even with the experience I've had, choosing a tech stack isn't something I'm particularly familiar with within the React ecosystem.
P.s. Obviously there is the T3 Stack, which is amazing, but I don't think anyone is pretending that Next is perfect for all situations, so would be good to know what to consider.
34 Replies
Greetings. Imo, you should start with Theo’s video on how to choose a framework. Even though, I disagree with some things, he basically answers your question on almost every framework besides, at that time, app router next js
That should give you some sort of solid ground to try and form your personal opinion and taste
If you don't know what to go with - I'd say go with Next. It's the easiest setup with the biggest community, so if you need help you should be able to find it pretty easily.
Astro might be a good choice if you're focusing on small static sites. But I'd argue that Next is the most general purpose one, so it makes sense to start with it.
Yeah I think Next is the 'default', but I feel like it can be quite heavy for smaller use cases (as you sort of hint at with the Astro comment). One thing I'm not entirely sure on is when to use Next vs something like Vite with React Router / React Query, and perhaps a backend-as-a-service offering like Supabase or Convex.
For sure, I perhaps forgot about that video (I'm pretty sure I've seen it before but it was a while ago). It's probably worth a re-watch with this question in mind though, thanks.
That sounds like “if I don’t pick Next, I’ll build my own one, but with other pieces”
I agree on the part, where Next is a gigantic overkill. If you don’t have any signs of project going crazy in scale, stick with Astro
With it you are always able to inject React components, in case client reactivity is needed
Are there any situations where something like plain Vite would work? Something between the bells and whistles of Next but that requires more than the SSG of Astro?
I don't really see how Next is gigantic overkill? If your website has only static data, it will end up building a static website. Do you mean just by the features it provides, or...?
Don't go down this rabbithole. There's no need to roll your own framework, especially if you're just starting out.
You can do it, but I would advise to stick with the big boys in the beginning, until you get a handle on things.
It's not so much rolling my own framework, I'm just hesitant to throw everything and the kitchen sink at a simple blog site. It's a sliding scale of complexity vs. requirements, and so there is presumably a middle point somewhere?
Basically, the last sentence. What’s the point of using it, if you’ll end up opting out of like 60-70% of the features? That’s just a personal opinion
Ok, fair enough. I default to it, because clients usually end up wanting more than just a static site, even though they claim otherwise.
I mean, it depends. Just for sake of the example, project that feeds me is heavily reliant on a ton of client interactions like sliders, clicks & drag’n’drop. Thus why I’ve chosen Qwik over Next there
Maybe try building it with a few different frameworks, and see what fits for you? If it's a small blog site, you should be able to set it up with pretty much anything. And you'll gain some perspective on picking the right tool for the job.
Yeah I was thinking that.
^word. As I’ve said, you can always use something like @astro/react, you feel like plain Astro doesn’t provide you enough ways of handling client interactivity
Yeah I've recently built something in exactly that. I guess I'm trying to more generally figure out what to consider in terms of a tech stack, given project X has Y requirements.
I usually start from figuring out the amount of client interactions the app has to deal with.
Pretty few of them and they’re simple -> Astro
Kinda dynamic app with more stuff, than a simple like button -> prolly Next
A ton of them -> definitely go with Qwik
So you don't see any other technologies being a better fit somewhere between Astro and Next?
Between these two? Not really, since you can use other frameworks/libraries inside of Astro templates
I’m trying to find the interview with Dan Abramov, where he explains, what and why they suggest as a React team
Yeah that's true. I remember in the Tanstack Router video, Theo points out it's not particularly useful for most Next applications, but is probably very worth considering for Vite projects. Which to me suggests that there are situations where Vite would be a good fit for the requirements.
@bythewayitsjosh https://youtu.be/Fctw7WjmxpU?si=PqVbj51Y6R1tuOIn&t=1331
Ben Holmes
YouTube
⚛️ Dan Abramov explores React Server Components with us! [VOD]
Dan Abramov and I were on a mission to explain React Server Components. We came away with diagrams, code, and a real-world app!
👀 Code repo: https://github.com/bholmesdev/simple-rsc
00:00 Intros
00:30 How did we get to React Server Components?
09:40 XHP? Are we back to PHP??
15:50 What does "server" mean really?
22:08 create-react-app is dead....
Amazing, thanks.
'CRA is dead, Now what?' 22:10 — 31:25, in case it didn't catch timestamp from mobile
Figure out what you type of technology you need for your project. Do you need to benefit from ssr/rsc and SEO? Maybe a plain CSR React app is good enought with a separate backend if you're building some sort of dashboard. Are you building something with a lot of contentful data? Astro is great at that, so is Nextjs if you need more complex logic. Also remember that Next.js/Vercel is the most successful dev locki-n ever, so you should think about where you want to host this as well.
Good point too. Btw, you're able to host Astro app as easily as the Nextjs one on Vercel, just add on that
The best thing you can do is to read up on each of the stacks you want and make up the decision yourself.
That makes sense. However, to take one example, pretty much all applications would benefit from RSC in some capacity. It's about deciding when there's enough of a benefit to justify making Next the framework of choice. And the same can be said for most other aspects. Again, I don't want to kitchen sink.
I have no idea what you're trying to build, so I'm not going to say one or the other 😄
Me neither! There's no particular project on the go at the moment, but I don't want to have this discussion with myself / others when I do have something that I actually need to build. 😅
I see! Well, RSC adds a lot of complexity as well for applications that realistically could be a CSR/SPA app and written faster. I've experienced that first hand and for my current project building a dashboard, I regret not just going with a CSR app - as we're moving anything with complex logic to trpc
That's kind of what I mean. It's about understanding when the additional complexity is worth the performance / DX / UX improvements etc.
Speaking for myself here - when switching from mainly rsc to just trpc/client-side rendering, the development has been easier, faster to write and the performance diff is unnoticeable in production - and the best part is that the user has no clue nor give a fuck what you use
Note: This is nextjs specific
I imagine at least part of that is familiarity, however I know what you're saying. It really does feel like Next is bulky, but I can't quite put my finger on why.
For example - if you're building an ecommerce application, nextjs would be a good candidate where you can really benefit from ssg/ssr + easy SEO and where most of the shit can be solved with forms/form data. Kinda boils down to how much you want to use node for everything as well in that case though.
Yeah absolutely, makes sense. I did just re-watch Theo's video where he basically says "It doesn't matter, just f***ing build something and learn what to do next time". Which is fairly valid. 😅
Yeah, basically
There is no right answer