https://wasp-lang.dev/blog/2023/03/17/new-react-docs-pretend-spas-dont-exist Skip to main content Wasp logoWasp logo .wasp (beta)DocsBlog Search All our posts * New React docs pretend SPAs don't exist anymore * Building a full-stack app for learning Italian: Supabase vs. Wasp * 10 "Hard Truths" All Junior Developers Need to Hear * Wasp Beta - February 2023 * The Most Common Misconceptions Amongst Junior Developers * From Idea to Paying Customers in 1 Week: An Interview with Amicus.work * The Best Web App Framework Doesn't Exist * Convincing developers to try a new web framework - the effects of launching beta * Wasp Beta December 2022 * Hosting Our First Hackathon: Results & Review * Watch us build a *truly* full-stack app in just 9 minutes w/ Wasp & ChatGPT * Wasp Beta brings major IDE improvements * Feature Release Announcement - Wasp Optimistic Updates * Permissions (access control) in web apps * Feature Announcement - TypeScript Support * Wasp is in Beta: Auth, TypeScript, Tailwind, LSP * Why we chose Prisma as a database layer for Wasp * Amicus: See how Erlis built a SaaS for legal teams with Wasp and got first paying customers! * How Michael Curry chose Wasp to build Grabbit: an internal tool for managing dev resources at StudentBeans * Wasp Beta Launch Week announcement * How Wasp reached all-time high PR count during Hacktoberfest: tips for OSS maintainers * Alpha Testing Program: post-mortem * Feature Announcement - Tailwind CSS support * Feature Announcement - New auth method (Google) * Farnance: How Julian built a SaaS for farmers with Wasp and won a hackathon! * How Wasp reached 1,000 stars on GitHub (detailed stats & timeline) * Building an app to find an excuse for our sloppy work * How to get started with Haskell in 2022 (the straightforward way) * How and why I got started with Haskell * How to communicate why your startup is worth joining * ML code generation vs. coding by hand - what we think programming is going to look like * Feature Announcement - Wasp Jobs * How to win a hackathon. Brief manual. * Meet the team - Filip Sodic, Founding Engineer * Build a metrics dashboard with background jobs in Wasp - Say hello to Waspleau! * Meet the team - Shayne Czyzewski, Founding Engineer * How we built a Trello clone with Wasp - Waspello! * Our fundraising learnings - 250+ meetings in 98 days to the oversubscribed round * Following YC, Wasp raised $1.5M Seed Round led by Lunar Ventures and HV Capital * Tutorial: `forall` in Haskell * How to implement a Discord bot (in NodeJS) that requires new members to introduce themselves * Wasp - language for developing full-stack Javascript web apps with no boilerplate * Journey to YCombinator * Hello Wasp! New React docs pretend SPAs don't exist anymore March 17, 2023 * 5 min read Matija Sosic Matija Sosic Co-founder & CEO @ Wasp Where is Vite React just released their new docs at https://react.dev/. While it looks great and packs a lot of improvements, one section that caught the community's attention is "Start a New React Project". The strongly recommended way to start a new React project is to use a framework such as Next.js, while the traditional route of using bundlers like Vite or CRA is fairly strongly discouraged. Next.js is a great framework, and its rise in popularity is due in a large part to the return of SEO optimization via Server-Side-Rendering (SSR) within the collective developer conscience. And it definitely does make sense to use a framework that provides SSR for static sites and pages that rely on SEO. But what about typical Single Page Apps (SPAs)? Dashboard-like tools that live behind the auth (and don't need SEO at all), and for which React was originally designed, still very much exist. The new React docs - use a framework unless your app has "unusual" constraints react new project docs The new docs make a pretty strong claim for using a framework when starting a new React project. Even if you read through the "Can I use React without a framework" section (hidden behind a collapsed toggle by default), you have to go through a wall of text convincing you why not using a framework is a bad idea, mainly due to the lack of SSR. Only then, in the end, comes the piece mentioning other options, such as Vite and Parcel: use framework unless you app has unusual constraints Even then, first you'll have to admit your app has unusual constraints (and no examples were given of what that could be) before you're actually "allowed" not to use a framework. It feels very much like you're doing it in spite of all the warnings and that there actually isn't a case where you should do it. Why SPAs (still) matter SPAs still have their place SSR/SSG has been getting a lot of attention lately and has been a flagship feature of most new frameworks built on top of React. And rightly so - it has solved a major issue of using React for static & SEO-facing sites where time to first content (FCP) is crucial. On the other hand, the use case where React, Angular, and other UI frameworks initially shined were dashboard apps (e.g., project management systems, CRMs, ...) - it allowed for a radically better UX, which resembled that of desktop apps. Although interactive content-rich apps (blogging platforms, marketplaces, social platforms) are today a typical poster child demo app for frameworks, dashboard-like apps still very much exist, and there are more of them than ever. Thousands of companies are building their internal tools daily, just like new SaaS-es pop up every day. SEO is largely irrelevant for them since everything is happening behind the auth layer, where everything is centered around workflows, not content. SSR might even be counter-productive since it puts more pressure on your servers instead of distributing the rendering load across the clients. How then would you develop SPAs? Traditionally, React was only a UI library in your stack of choice. You would use CRA (or Vite nowadays) as a bundler/starter for your React project. Then you'd probably add a routing library (e.g., react-router) and maybe a state management library (e.g., Redux, or react-query), and you'd already be set pretty well. You would develop your backend in whatever you choose - Node.js/Express, Rails, or anything else. There are also new frameworks emerging that focus on this particular use case (e.g., RedwoodJS and Wasp (disclaimer: this is us!)) whose flagship feature is not SSR, but rather the abstraction of API and CRUD on data models, and getting full-stack functionality from UI to the database, with extra features such as easy authentication and deployment out of the box. With a "go for Next or you are unusual" and "you need SSR" message, React is making a strong signal against other solutions that don't emphasize SSR as their main feature. So what's the big deal? Nobody forces you to use SSR in Next/Remix That's correct, but also it's true that a buy-in into a whole framework is a much bigger step than just opting for a UI library. Frameworks are (more) opinionated and come with many decisions (code structure, architecture, deployment) made upfront for you. Which is great and that's why they are valuable and why we'll keep using them. But, both sides of the story should be presented, and the final call should be left to the developer. React is too useful, valuable, and popular a tool and community to allow itself to skip this step. Want to stay in the loop? - Join our newsletter! Tags: * webdev * react Edit this page Older Post Building a full-stack app for learning Italian: Supabase vs. Wasp * The new React docs - use a framework unless your app has "unusual" constraints * Why SPAs (still) matter * How then would you develop SPAs? * So what's the big deal? Nobody forces you to use SSR in Next/ Remix Docs * Getting started * Todo app tutorial * Reference Community * Discord More * GitHub * Contact Copyright (c) 2023 Wasp.