This comment thread is a little funny because every single HN thread outside of this one rants super aggressively about webpages that don't show any content before JS loads, but this thread has managed to collect the opposite group together for once because React's docs have updated to stop actively recommending tools that force that problem to happen.
I don't think that's a fair characterization of the "Start a New React Project" page [0]. Next.js is the first option listed and is described as a way to "create React apps of any size—from a mostly static blog to a complex dynamic application."<p>This reads to me like "Next.js can do SPAs (like CRA) plus static sites and SSR". Next.js' site even says "The core of Next.js has been designed to enable starting as a static site (or <i>Single-Page Application</i>)" [1].<p>0 - <a href="https://react.dev/learn/start-a-new-react-project" rel="nofollow">https://react.dev/learn/start-a-new-react-project</a><p>1 - <a href="https://nextjs.org/docs/advanced-features/static-html-export" rel="nofollow">https://nextjs.org/docs/advanced-features/static-html-export</a>
Does anyone else feel that the complexity of the full-stack frameworks is getting untenable?<p>1. There is a significant gap between dev and production environments. (See #2 why this is critical)<p>2. The production build times are super high<p>3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard.<p>4. I occasionally get X is included twice errors that are painful to track and debug<p>5. There are frequent instances where I find out that the very problem I had has been solved by someone, but they don't know how or why. They remove a, b, c then it works. They add it back, it still continues to work.<p>What happened to KISS?
There are a myriad of reasons why I prefer SPA to server rendered content for most applications. The main exception is if I have a public facing, unauthenticated application that I need indexed, I'll go for SSR.<p>Off the top of my head, here are benefits to SPA:<p>- I can just serve a few static files from a CDN. Every user gets the same client.<p>- Most requests made by the application are actually smaller. I'm just loading the data I need, rather than the data, markup and styling.<p>- It's an actual client application talking to a data API. It's the same API the rest of my client applications are talking to, be it a mobile API, native, CLI, etc.<p>- It's a much easier mental model. Interactivity without having to give consideration to whether or not it will disrupt whether it can be rendered. I build my application like a realtime application and just make requests for the data I need when I need it<p>- I don't have to think about exposing backend secrets, or trying to do things I'm mistakenly assuming to necessarily run in one environment or the other<p>- I can be much more explicit about loading and caching data when I would like to<p>Even most of the cons of a SPA can be ameliorated. The biggest con is a larger up front load, but that can be mitigated by code splitting and lazy loading. The fact that it's a handful of static files means that the application is basically cached, too. And SPAs are for applications, not websites. Most people using SPAs want the application experience to be optimal, not necessarily their initial first time load. They want small requests, interactivity, live feedback. This is all possible with SSR, but nowhere near as simple.
Starting a "new react project" should be basically creating an HTML file, and adding a script tag linking to React the JS library. Why are these developers always trying to obfuscate everything with tons and tons of layers of indirection all the time? You don't need to "bundle" anything and certainly not use some server just to add Javascript to a page (unless it's a matter of CSP of course) and you should certainly not have to rely on nodejs or cli tool X,Y,Z...<p>Somehow the JS/Node dev community managed to re-invent JEE web profile, and is very close to re-invent Glassfish as well at that point, but worse because it didn't learn anything from Java enterprise... this madness needs to stop.
All our application lives behind an authentication except login pages. I still cannot grasp how would I use Nextjs in only SPA mode. Not everything needs to be SSR, I don't want to spare resources, just want to deploy it to S3, put cloudfront infront of it, let 404 requests return index.html and I can use the URLs without #.<p>SSR should not be a must the docs should reflect that. There is no way I'm paying Vercel 20$ per user for our simple use case or I'm hosting a VM to render pages. I don't care about the improvements SSR would bring in the price of cost, deployment complexity, or any other complexity. Affecting React docs like this to push for SSR does not feel safe to me. I'm happy with my Vite based React TS project.
So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club.<p>Ignoring the noise is really becoming a key skill to survive as a programmer.
If you want the control and low overhead of Vite but don't want to implement everything a framework gives you, vite-plugin-ssr might be interesting for you.<p>It is basically Next.js as a do-one-thing-well Vite plugin (its slogan).<p><a href="https://vite-plugin-ssr.com/" rel="nofollow">https://vite-plugin-ssr.com/</a>
It sometimes seems like every web framework is run by people who see a minor problem and completely change their project to solve it. Flash back to 2014 when Rails made Turbolinks on by default, and broke everyone's SPAs. Flash back to Angular rewriting in Dart because "it's the future" (it wasn't). Flash back to React replacing the perfectly-fine functional components with hooks (because Vue did it).<p>And now React is throwing away its backend-agnosticism because they want to hold your hand and make sure you don't fail at SEO and blame React.
I'm still waiting for preact.js + htmx.org mashup. It probably exists somewhere, maybe <a href="https://docs.astro.build/en/concepts/islands/" rel="nofollow">https://docs.astro.build/en/concepts/islands/</a> or something.<p>I just want a quick way to throw some react hooks or web components into a dom element using a library that is less than 1,000 lines of code.
Those marketing pieces are becoming a bit tedious to decypher for me. The real message is not something about React SPAs but something about Wasp? Just tell me this thing about Wasp and don't distract me with something about React.
Yes, for apps that are not hosted publicly or that are not mainly "websites" – what's wrong with just using react + react-router? So I agree that this is an oversight.<p>Also, there surely are plenty of non-public web-apps in the B2B segment which run in the browser behind a login or on private networks, where SSR is basically unneeded (also, electron and the like)?<p>But:<p>for a public web site or commercial web app, I find the take from the first screenshot pretty nuanced.<p>It is easy to underestimate the complexity of building your own React SSR- or SSG-framework.<p>I recently tried out vite-plugin-ssr, which kind of does that, in a way that's agnostic to the frontend framework/library.<p>Can recommend it for people who want neither SPA without SSR nor one of the established React frameworks.<p>But for people who want to build a full, public-facing website with SSR (which is kind of a requirement for SEO), with minimal friction, I think the recommendation from the docs is absolutely correct, no?<p>Plain react for single components in otherwise non-React website, full-stack framework if you build the whole site/app in React.
I don’t want server side react.<p>It’s disappointing to me they’ve gone so hard on server side.<p>It feels like Facebook use it server side so they’ve lost interest in being purely client side.
I think to sway the only benefit of Next.js is DEO is underselling how useful it is.<p>Sure SEO is important for most people anyway, but having multiple pages that load instantly rather than having to wait for a server call is also pretty handy. Plus auth working better.<p>I don’t see why next wouldn’t be the default and react now the outlier.
I don't understand the fuss about SSR, wasn't that default way of doing websites 10+ years ago, before AJAX? E.g. Apache Struts has all of that Router logic since like 15 years ago, completely server-side.
I just want to say, as a developer that just wants to get stuff done, I'm so annoyed by frameworks needing a meta framework, etc, etc. I want something as simple as CRA to be enough.
Integrating React into an MPA is quite awkward, surprised this is the target audience for it.<p>I love the potential of web development but of recent, it's been infected by hype-marketing and blog-engineering.<p>I get that it's become very accessible to write web applications and that's good for the growth of the platform - but it almost feels like this accessibility has led it to squander its potential in pursuit of unsophisticated and unambitious objectives.<p>Web developers today are distracted by premature over-optimisations (ignoring effective low effort optimisations) and language+platform features that are a great, but kinda useless from a project development standpoint (time/money/complexity/collaborative capacity cost).<p>As a result, platform developers are distracted implementing features that don't innovate the platform - so we sit and wait for the truly groundbreaking things that never come because we gotta discuss the pipe operator, or adding types to the JavaScript language specification.<p>Meanwhile projects that can't wait for the platform to evolve flood us with Electron apps that everyone hate.<p>I have hope, kinda...
Obligatory "front end is a mess" comment. I taught at a bootcamp for 6 months, it was a great experience but when we moved on to react after vanilla JS the amount of incidental complexity was a huge step up, even with create-react-app. Now they push people towards adding a server side framework at the same time, right off the bat? I think there's a real danger with new engineers entering the industry that they have no chance to develop a proper mental model of the underlying tech stack the way so many libraries, frameworks, packages, bundlers are thrown together just to get something working. You think the docs should just start with using plain React, and then branch off in to SPA Vs SSR later.
We’ve switched to JSF with Primefaces and a lighter weight BootStrap component toolkit for internal apps.<p>Server Side Component Frameworks are probably peak developer productivity, at the small cost that they are not infinitely flexible.<p>Seems like a worthwhile tradeoff when building internal apps or database driven apps.
Here's my realm: We have a react based "framework" that in the end is zipped up and delivered as a SCORM package to be embedded in a Learning Management System. We use React Router to manage navigation.<p>After a quick scan of the Next docs, all references to routing seem to tie back to server side which is a non starter, as the SCORM is standalone HTML/CSS/JS/Media - that we happen to embellish at run time with some api calls.<p>This is a case where the pure SPA with no server side is the only way to go; seems like a real pain to go against the default state of Next. Am I wrong and am just missing something? Again, been occasionally looking at next and the like over the past while, but never had time to really dig into into it.
I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not managed. That's true of any application.
I think the author is mistaken. You can build a PWA, SPA in Next.js and it's even easier than not using it.<p>I feel like the author is just confused that they're not specifically focusing on SPA because whether anyone wants to admit or not, enterprise companies aren't asking for SPA, or mobile apps, they're asking for headless, static websites. It makes sense that React would respond to those market demands.
But… they don’t, really. “SPAs” are just a corruption of the web brought about by people who obsess over replacing end user operating systems with HTML+CSS+JavaScript. Most actual users would be just as happy to install a real native application.
As far as I understand you can use these frameworks to write SPAs as well. I have no idea how well supported that use case is in the end.<p>I find the idea that you want to handle data fetching and routing in a framework to be reasonably convincing. There are advantages here, and it's easy to get into a bit of a mess if you just fetch data in each component.<p>The part that has stopped me from looking at the frameworks until now is that they add a lot of parts I don't need, and the documentation seems to be focused on the SSR part. And then there are React server side components, which is another new concept I need to understand. Maybe the frameworks are a good fit for my SPA use cases, but it'll take quite a bit of time to find out if that is true.
Interesting that CRA isn’t mentioned anymore.<p>Someone opened an issue to discuss this:<p><a href="https://github.com/facebook/create-react-app/issues/13072">https://github.com/facebook/create-react-app/issues/13072</a>
>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.<p>I stopped reading here because the article may have been made by ChatGPT
Was React not already a framework? Are SPAs that use frameworks not SPAs? What even is a framework or SPA anymore?<p>This shit is why I stick to the backend.
sveltekit is the same, ssr first, i am so sad react now becomes ssr first too, i am forced back to vue,which still has a CSR SPA first, add ssr if you need it approach.<p>no i dont need ssr at all, internal tools,dashboards,embedded devices,etc etc have nothing to do with ssr,nothing at all
Hype driven developers/marketers believe the only type of websites that exists are those which need indexable content for SEO purposes. More news at 11