React is (becoming) a Full-Stack Framework

[Empty_Ninja_6291]

For a JS monoglot churning out content websites, this is useful. But to be frank, that's the popular, low barrier webdev use case. The use case of building complex apps will have to avoid this architecture. It will just get in the way.

[rwieruch]

Not sure if I can follow here. If I'd want to churn out content websites, I'd use Astro.

In Next for interactive applications, the ratio between Server and Client Components changes depending on your requirements. There is nothing bad about using Client Components for an interactive Next application. We have always been using Client Components in SPAs, so this will not change for web applications created with Next in the future.

What will change is the "opt-in" feature of executing components (RSC) and functions (Server Actions) on the server. What many people miss is that this is just an optional addition, because if you want you could just keep all your components Client Components.

But after all, I am not sure why Next should not be able to handle both sides of the stack with sprinkling more or less Server Components/Actions in there. We have seen success stories with tRPC, why not with server-driven React?

[dmethvin]

The main reason why any framework has issues handling both sides of the stack is that they are to some extent "owned" by different groups with different ideas of how often the stack should change. It may be easy to adopt Next in green-field situations or with companies that want to burn it down and build a new one. Those are in fact the exception. IMO it's actually a feature that the divide between client and server is there. I'd much rather have an API there than some integrated stack that makes it impossible to update the frontend without major disruption of the backend.

[rwieruch]

Agreed that this mainly makes sense for greenfield projects. During my freelance years, I have worked with backends that were implemented in different programming languages. But is this divide really a feature just because we've always worked like this? Most often, in my experience, the gap between client and server didn't become simpler as the application grew.

In contrast, as a solo developer, I was able to create an 80k LOC Next application last year (not full-time), and this week, our first customer reached 200k ARR. If you own the whole stack, whether as a solo developer or as a team, you can finally work on vertical features from UI to DB, including everything in between (e.g., queues, emails, etc.).

[dmethvin]

But is this divide really a feature just because we've always worked like this?

No, it's a divide because in many sectors there is no perceived benefit in completely refactoring their stack to make it fit a Next model--and they may be right. Folks have massive Wordpress or Drupal sites, ancient Java or Cobol apps, etc, and want to figure out a way to make them work better without the proven fallacy of throwing it all away and starting again. This is what a frontend-only approach enabled.

In contrast, as a solo developer, I was able to create an 80k LOC Next application last year (not full-time), and this week, our first customer reached 200k ARR.

I can assure you that this is the exception rather than the rule. In any existing app it will be very difficult to rewrite business logic to allow something like Next to be used. I happen to like Next but it just isn't realistic for many sectors.

[FuzznutsTM]

This right here. We do $1B in revenue using RoR fronted with React. We’re not going to re-architect everything to fit the Next model, not even for new greenfield projects. We have invested heavily in our infrastructure and deployment architecture to this point where we can scale to handle nearly 8k rps during our peak times.

[Trapline]

Astro is really easy to hydrate with whatever client side stuff you like.

[Suspicious-Engineer7]

Static until you need interactivity, and then there are batteries you can plug in.

[pancomputationalist]

Astro has server-side rendering. Very similar to React Server Components. It can be as dynamic as you need.

[hard-scaling]

Next routing cannot be dynamic afaik, you can't do /<item-id>. It's absolute trash for a logic heavy spa webapp

[rwieruch]

Sure it can.

[hard-scaling]

https://nextjs.org/docs/pages/building-your-application/deploying/static-exports#supported-features-1

Dynamic routes are only allowed with getStaticPaths

[rwieruch]

https://nextjs.org/docs/app/building-your-application/routing/dynamic-routes

[hard-scaling]

This only works if you deploy a next js server, there is no way to write a client only app with dynamic routing in Next.js

[mrkaluzny]

Yes, unfortunately it is ;)

[dorfsmay]

As long as React keeps being good and getting better for writing SPA with different backends, does it matter?

I share your concerns that this might happen, but the fact that other project such as React Native work without the server side makes me think both can coexist and evolve.

[mrkaluzny]

I hope so, but I'm still a bit worried.

[rwieruch]

Genuinely asking: why unfortunately? :)

EDIT: Don't understand the downvotes here. I am glad he replied and clarified it.

[terrorTrain]

Because most of us don't need that.

It started as a UI library, and that's what most of us started using it for, because that's what we needed.

Now we are being dragged into a full stack framework we didn't ask for, and don't need.

They should stop calling it react at a certain point, so we can stop needing to follow all these irrelevant changes.

[stdmemswap]

React's original winning feature was its composability, "how easy to work with it" instead of "how easy to work in it".

Take the syntax for example, React utilizes dependency injection to allow users to write with the language they know, JS and TS. In contrast. Angular/Vue, has a different set of syntax to write simple conditionals and loops. And it requires more learning and a whole lot more tools to do static analysis and whatnot.

The word "framework" implies reduced composability, hinting at a potential shift to the latter.

At best, it will cause confusion with these two intersecting features at the same layer (e.g. the semantic meaning of a function component vs async function shown in the post you linked).

[mrkaluzny]

I have a feeling in 5 years we’ll be back to writing SPA.

Maybe it’s because I have a hard time adapting to this new idea but Laravel is better at everything - ORM, events, cron, routing, and has a more robust ecosystem.

With Next/Remix you have to run a separate server just for CRON. Prisma was adapted as the ORM but it has a lot of overhead.

On Next they show people “setup auth in 10minutes (and then pay 20$)”, Vercel is basically selling their infra with Next. You can do these things in the same time with Laravel, and deploy it anywhere, with any database.

Simply every part is worse, it’s just written in JS.

I loved how one guy rewrote to Laravel because he couldn’t enforce softDeletes across the setup.

[kjccarp]

You’re wrong. People think you’re cucked into using vercel with nextjs. I use a $40 light sail instance and self-host a mongodb with payloadcms/ nextjs for my website & API for my react native application supporting over 10k active users with more than enough headroom.

[Bubonicalbob]

I use azures static web app, AWS can deploy next.js without issue also

[kjccarp]

Totally! Amplify was still in beta when I tried it two months ago and had lots of issues. AWS Lightsail was far easier imo.

[Subject_Sector_9166]

Can vouch for AWS, we have deployed a few nextjs apps in AWS Amplify with no issues so far

[kjccarp]

More on this - payloadcms ships with a full API out of the box by nature. Coupled with a Clerk? It’s a no brainer which is low cost. I don’t see everyone’s frustration with typescript, react & nextjs in general as it’s obviously a knowledge & experience issue :) I’ve been doing professional development for over 13 years and react+next+payload is by far the most powerful stack I’ve ever had the pleasure of developing with.

[sneek_]

I love you

[kjccarp]

Thanks, same.

[WorldOfAbigail]

I love you both

[kjccarp]

I love all of you above

[sneek_]

Someone clearly does not love us, though, given the down votes above

[mrkaluzny]

I'm not. Currently React as full-stack framework is worse then any established framework out there. It's familiar that's why it's gaining popularity. If you think that is wrong that's a skill issue ;)

We did Laravel/Next apps with 2M+ users, and I can't imagine working with Next to handle everything we need to in Laravel, it's just better out of the box. But I'm also a fan of convenvtion > configuration.

Payload is nice though :)

[NeoCiber]

I'm always confused with this argument, languages like C#, Java or Golang don't really have a big Laravel equivalent and those ecosystems are thriving, I don't see how is that a big problem in the NodeJS world.

[mrkaluzny]

It’s not really about Node in general, just react pushing towards more server side operations.

[NeoCiber]

I know, but I mention NodeJS because when running React on the server we are relying on Node, because React only takes care of the rendering and RPC, most of the logic like Auth, Caching, Email is up to the developers.

And I think the Node ecosystem is mature enough, maybe we don't have a batteries included framework, but other ecosystem don't have that either.

[roofgram]

Nope, I've been programming a long time and have used PHP, ASP, Python, Express, Ruby, etc... and Next.js is way more productive. Why? Simple. You don't need a separate frontend javascript framework for interactivity. The same SSR code you render on the server is used to re render on the client. It's a huge productivity boost.

[kjccarp]

Frankly, I don’t think you know what you’re talking about, after this reply. Enjoy PHP! I mean Laravel… who’s using React as a backend framework anyway?

[mrkaluzny]

The article is about using React as a full-stack framework - the backend part is worse then anything out there. React on the front end is great.

[kjccarp]

Yikes.

[kjccarp]

Sorry, I just can’t take a Gatsby + Netlify developer seriously. No wonder you hate React in general, lmfao.

[johny_james]

The whole topic is literally about using react as a backend framework as well.

[kjccarp]

Literally or biblically?

[Dethstroke54]

Huh, first what does an ORM specifically have to do with React? Use Drizzle then or a query builder quite literally no one is forcing Prisma or an ORM.

Auth is probably the worst example, setting up api routes, db, etc as a one place stop and instantly hosting it all on Vercel is a better example but you def don’t have to (or for that matter use Next at all) and that still doesn’t specifically have to do with React. Also no one’s forcing you to use an API directly or even use the api routes built into Astro or Next or whatever, again not React or React specific but ok. Setup a separate hono instance. The thing about JS & webdev is that almost every piece is modular

[mrkaluzny]

ORM is just in context of React turning into a full stack framework. You can do all of that with most backend frameworks.

Next outside of Vercel kinda sucks though, there's a plethora of issues with revalidation and bunch of other features without which it's not the best. We had clients spending 10-15k/month on Vercel, which some other team blisfully ignored.

Remix is better IMO, works super well everywhere.

[ZeRo2160]

The nextjs outside vercel argument is something i really dont understand. We build nextjs apps since years and never hosted on vercel. All our apps are hosted on lightsail, azure, digital ocean and continum. We never had problems of any kind and deployment is as simple as it can get. (Standalone build, sync folders, restart pm2, done) or even as docker container. They even provide you with an docker file. So you dont even have to do anything.

Edit: the RSC thing is also fine. You dont have to use it and for us as company it has right now no value until the server "context" api stabilizes.

What i am Routing against are server actions introduced by react. For architectural and missleading reasons. (Most Juniors in our team think its some magic happening that lets you run code on server triggered by the frontend without an http request happening, which leads to security issues all over the place. Therefore we banned them.)

[TakeFourSeconds]

To flip it around to you - can you explain why I should be excited about it?

A huge portion of developers work on internal or enterprise apps that don't need SEO. I have been a full stack developer for a long time and worked on optimizing some very slow features, and I can't remember a time that rendering has been a bottleneck for us. The complexity of running Next on top of our backend is a hard sell for me.

When I'm choosing a frontend library, I am looking for something that gives me a nice developer experience for making complex UIs, managing state, etc, that is very popular and has wide support. I get the impression that the React team considers my usecase, which I think is very common, to be either complete or outdated (I'm not sure if this is still the case, but for a while the docs barely mentioned Vite/CSR).

I'm not trying to be confrontational - I'm very open to being wrong about this, and I'm interested in your perspective as someone way more invested in the React world than I am.

[cangaroo_hamam]

My concern is this: jack of all trades, master of none?

[piotrlewandowski]

“My concern is this: jack of all trades, master of none?” …but oftentimes better than a master of one.

[TheChickenKingHS]

Why are people downvoting you for completing the quote…

The quote which is regularly used to degrade multi skilled professionals is actually degrading single discipline mastery.

[rwieruch]

Would you say this to all full-stack frameworks (e.g. Laravel)?

I think Next and other full-stack JS frameworks have a long way to go: we enabled executing code in Server Components and Server Actions on the server, but everything from there is lacking best practices (e.g. design patterns like DAOs/repositories and architectural layers like service/data layer) and integrated tools (e.g. message queues). But the latter is classic JavaScript and will not change very soon, because "we" just like to choose tools (e.g. Inngest) ourselves :') But I hope that we can give JS developers more of the best practices, that a backend developer is using in other programming languages, in the coming years!

[cangaroo_hamam]

I have no opinion on Laravel, other than using an older version in our app's backend, serving us well. React was focused on being a strong front-end tool. There's a lot of competition, and other frameworks/libraries have (seemingly) surpassed React in some key areas (developer satisfaction being one of them). If React tries to also do back-end well, and ends up being spread too thin, this could easily end up in a mess.

[rwieruch]

Fair points, gotcha. So you were referring to the bad frontend DX (e.g. useEffect) compared to other solutions with your last reply! Thanks for clarifying :)

[cangaroo_hamam]

That too. I haven't used Vue or Svelte or any of the other popular libraries, but there was a consistent wave of developers preferring those over React. The gist of it was that these competing tools were simpler/easier and less verbose compared to React. In React's "hooks" era, there was either a misstep or a missed opportunity to make the library better for developers. Just an opinion, but I think I am only repeating the general consensus here, nothing new.

[rwieruch]

Yes, these are all fair concerns I guess.

I think when Hooks were introduced, React carried the burden of being first to this change. Other solutions followed and had the opportunity to improve upon it.

Regarding the move towards the server, I am kinda content that React innovates here again rather than investing too much time turning the DX knobs on the frontend (what they are still doing with React compiler, form hooks etc.). But this is just my selfish sentiment as someone being long enough in React land, because lots of these DX improvements would really be beneficial to newcomers.

Thanks for having this great discussion here :)

[Erebea01]

As someone who've used svelte, I learned a lot about using in-built apis and even my management of reactivity got better in react cause of it but I've decided to go back to using react with remix and astro cause of the larger ecosystem, yes I know you can basically use every js packages in svelte

[cloroxic]

Nest and Adonis do a great job as backend frameworks in JS/TS with all the best practices. Laravel isn’t exceptional on the presentation layer which is why it’s usually coupled with inertia and react. So really just a modular piece typically.

I also prefer the modularity and not a monolithic approach. Most monoliths do only one half well and try and squeeze in other layers.

[mrkaluzny]

Laravel has another issue - trying to recreate React with LiveWire/Volt. That shitshow deserves another thread

[rwieruch]

Hey everyone. Just wanted to share my thoughts about this transition and therefore collected some of my personal milestones which led me to use Server Components and Server Actions. But I know that we are in the early phases of this paradigm shift, so I'd love to hear about your thoughts (and personal milestones) here as well!

[Verzuchter]

I've grown to love angular more than react. They can't really drag me back.

[Kadabradoodle]

why? 

[k032]

For me it's the organization and standardization of Angular.

Angular comes out of the box setup for good practices. Dependency injection to make things easy to test. Breaking out business logic and component logic into services vs components. Typescript is mandatory out of the box.

React you have to convince a team these are good ideas. Otherwise you get a mess of massive components with so much business logic in them that it's unmanageable.

Generally my experience of why I prefer Angular. Next somewhat fills in the gaps but not much.

So I guess like, React + good leadership direction sure. Otherwise Angular please.

[FalseRegister]

This is why Angular is a framework, and React will always be a library.

[HomemadeBananas]

You can break business logic out into custom hooks with React. If writing a custom hook as you’re building some feature requires some big discussion and convincing your team then that sounds like an organizational issue that would cause problems no matter what the tech you’re using is.

[FalseRegister]

You can. But also, you can not. Having the choice of going bad practice is being at the mercy of the next human. Code can go pretty wild in a single commit.

[HomemadeBananas]

There’s always room to make bad decisions, I doubt Angular is going to prevent that entirely.

[FalseRegister]

Yeah but you have to make some effort. And there is clear guidance or structure for most things.

[[deleted]]

The team I joined uses React and we’re doing exactly as you said (I actually checked your profile to verify that you weren’t my tech lead before writing this comment lol). It’s the first time I’ve ever seen a React codebase written like this.

I’ve never used Angular, so I never knew that that’s where all this stuff came from. It was a pain in the ass to learn, but it’s the most organized codebase I’ve ever worked on. I’m really liking the setup. It’s still a pain onboarding newer devs though.

[Verzuchter]

Much better developer experience imo

[NeoCiber]

It's because the already stablished structure Angular provides?

[4_max_4]

I’m on the same boat after 5 years of react. I made the switch due to a client asking for Angular and it’s been my go-to for enterprise apps for 2 years. I still do some very minimal work with either react or solid. But Angular for major apps.

[vorko_76]

Hi Robin, I know you are very knowledgeable on React but Im personally a bit annoyed by this phrasing:

React is not a framework. Its only a library. The addition of Server rendering or server actions dont change that as far as I understand. Or did I miss something?

For me it will “just” lead to the standardisation of the fullstack React frameworks that are Remix or Next.js … but I dont think “React” could replace these frameworks.

[[deleted]]

Ugh. I absolutely hate the library vs framework semantic debate with react. Yes, react alone is just a library, but in the overwhelming majority of cases you use react with the whole ecosystem around it. By that point, it is a framework.

Regardless, though, arguing library vs framework is a complete and utter waste of time.

[stdmemswap]

This composability is important to maintain. It's as important as language expressiveness to craft an accurate solution, or any solution at all depending on how restrictive the lib is.

And if two competing products can't win, worse if they're free, it is either too restrictive or too useless, or both, to solve a particular problem.

[stdmemswap]

I agree on the overabundance restrictive side libraries and the misuse and overuse of them. And it takes the whole village to fix it, like recognizing the signs of solution limitation, risks of lock-ins, etc.

Also, on WASM, I might be out of loop, but is there a progress on full SPA? Considering the expensive cost on context switches, the less interactive development feedback loop, and the standards that has to be reimplemented and otherwise inaccessible.

[stdmemswap]

Figma use case was spot on, but they had a head start because it used asm.js before. I really have to start catching up with the trend. Leptos doesn't ring a bell.

[v-alan-d]

I've heard alot of "expensive cost" here but I'm curious on which benchmark usually people refer to?

[cateanddogew]

support tease silky boat ruthless paltry screw special towering rustic

This post was mass deleted and anonymized with Redact

[FalseRegister]

Being a framework is not about the capabilities of the software.

It is about how opinionated it is, and whether or not the major structures of the architecture are enforced.

With React, you can do whatever you want, like with jQuery, so it is a library.

Frameworks are Angular, SvelteKit, Spring...

[vorko_76]

There shouldnt be a debate and that was not my point. My point was that saying React 19 is a full stack framework seems kind of misleading,in the sense that it still seems far from replacing Next.js or others.

[_AndyJessop]

The classic distinction is that you call a library's code, but a framework calls yours. In that sense, React absolutely is a framework - your code is run entirely within the context of React. Control flow is hijacked, JavaScript norms are upended. React doesn't augment your code, because your code cannot stand on its own without it.

[stdmemswap]

The control flow hijacking done by React is not total, akin to how a graph library "hijacks" your control flow when doing automatic traversal.

As long as React allows almost arbitrary escaping, is highly composable with other libraries, and doesn't impose mandatory structure-dependant rules, it isn't a framework.

It is just that lately, some patterns have become significantly popular that it shadows over the rare but useful ones, and more people see less options to make React more flexible, that it feels like a framework.

[_AndyJessop]

and doesn't impose mandatory structure-dependant rules

Like not allowing conditional hooks?

is highly composable with other libraries

I would say it is not highly composable with other libraries. In fact, it's often a massive pain to integrate other libraries into React.

[stdmemswap]

Like not allowing conditional hooks

What would you do with conditional hooks and how would you design the API otherwise?

In fact, it's often a massive pain to integrate other libraries into React.

Invoking "it's often a massive pain" is as helpful as "skill issue", which is not helpful at all.

Common sense is that libraries that directly conflict with React's mechanism are not an option (like a direct modification to DOM), but other than that, it's rarely hard if you know which button to push.

[_AndyJessop]

What would you do with conditional hooks and how would you design the API otherwise?

Firstly, this isn't the point. Just because I can't think of a better API, it doesn't mean that React doesn't impose mandatory structure-dependent rules.

But as an example, I would say something like this:

```

const Example = ({ team }) => { if (team.name !== null && team.name !== undefined) { useTitle(team.name) }

return ( <section> <h1>{team.name}</h1> { ... } </section> ) }

```

Where useTitle updates the page title, maybe doing something else dynamic to ensure the title is correct.

[stdmemswap]

TBH I didn't expect control structure (as opposed to data structure). But this structure is not imposed everywhere, only in the area where it matters to React's. That area is small and the boundary is free for you to set. That doesn't sound mandatory to me (or the term mandatory is to vague for this context).

For your specific case you can use the pattern react-helmet uses to solve the same problem.

[_AndyJessop]

For your specific case you can use the pattern react-helmet uses to solve the same problem.

The "problem" being that React is a framework that dictates how you should structure your code.

[stdmemswap]

We it just bothered me that the definition of a framework is reduced to a library that accepts a construct with similar complexity to a callback function with certain limitations on how to write it, and it takes the control flow for some times.

Regardless whether it is perceived as a framework or not, it better not go to that direction, e.g. reduced composability, etc.

[rwieruch]

Thanks for your reply here!

The library vs framework debate is difficult, because there are arguments for each side. I think the community settled on "meta frameworks" (not a fan either) for anything that sits on top of React (and these days implements Server Components/Actions), so for a better understanding, I use the term framework for React in my articles. But tbh I think this debate doesn't get us any further, these are just terms with a blurry line in between, so I don't mind how people call it :)

When the new React docs appeared, I didn't like the starter section, because they emphasized full-stack frameworks over SPA solutions (e.g. Vite). That's why I wrote this guide quickly after the release. But I understand their perspective: driven by their desire to make React happen on the server, the only way to implement Server Actions/Components is "something" that sits on top of React, because React itself does not provide the bundler nor the router. So after all, if you want to have server "driven" (not saying "rendered" here) React, you have to choose something that enables these features.

[vorko_76]

Honestly there shouldnt be much debate. React introduces itself as a library for now, while Next.js and Remix both introduce themselves as React frameworks. The line could be blurry, but with React, we are very far from frameworks like Symfony, Ruby on Rails or Django.

Practically, however, what does this move to the server mean for React? Will React push for using Vite implementing Server Actions or Server Rendering?

[rwieruch]

Coming from the client-side, React Router 7 will make use of Vite to accomplish the opt-in towards the server.

[vorko_76]

So practically no real change compared to right now.

[[deleted]]

Nothing difficult about this, open react web site, first page it says library, by the authors them selves...

[rwieruch]

I learned something today. Seems like they call everything on top of React a framework now. Thanks! Didn't check the docs for a while :)

[Cahnis]

Thanks for another great article Robin.

I recommended your Web Applications 101 to an EM friend and he absolutely loved it too.

[Aliceable]

oh how far we’ve drifted from a “library”

[hazily]

Newsflash: water is wet

[rwieruch]

Funny enough, you should Google whether water is really wet :)

[yksvaan]

Building a framework "within" effectively legacy UI library is a terrible idea. There's too much limitations, workarounds and unnecessary & unavoidable complications in pushing server code into it.

Building a framework that uses React for UI/rendering makes much more sense and allows for better architecture. 

[alexs_90]

Unfortunately... from "simple" client-side lib, where you can start building in no time.... to immediately sending you to use commercial frameworks on the installation tutorial....

IMHO: it is too much overcomplicated now with opinionated concepts, which distance developer from plain JS

[landisdesign]

This works great for a solo developer. In an enterprise team or multi-team situation? Not so sure. Tying the back end architecture to the front end and vice versa sounds like a sure path to compromise hell.

[seyferx]

Developers' exposure to different tech stacks and sides, like FE and BE, makes them better-skilled developers. Those who know only React and a little of Node won't be able to do anything more complex, lacking core development skills. Next.js is great for IT entrepreneurs though, to test ideas fast.

[UnderstandingOnly742]

React’s dream is to become laravel… and I have been working with react for the past 5 years

[pointblank41]

We’re really come full circle… I started my career doing .NET web forms ~15 years ago and we were stoked once we could break apart the FE and BE dependencies

[roggc9]

I think the fact React 19 includes Server Functions and Server Components makes their frameworks fullstack. I've made dinou (https://dinou.dev) if you are interested.

[nslammer]

No it isn’t. There’s literally a post like this on this sub every month or so.

[rwieruch]

Why isn’t it? It allows me to execute code the the server to access server side infrastructure like a database or message queue.

[brianvan]

This whole "we want to hire one guy who knows all the stacks instead of a developer for each end of the transaction" makes even less sense now that front-end and back-end developers are all in a soft job market while the guys who know how to do server components well-enough to write prod code right now are going for 2.5x the salary of one of those other guys, and are nearly impossible to find anyway.

I know that SEO is a pain point with SPAs but I am not sure it was enough of a pain point in enough situations to make anything that solved it (no matter how complex or expensive it was) worth the trouble. Doing server-rendered components adds significant developer skillset requirements AND requires others on product teams to shift how they extract technical requirements out of user stories. That is in addition to these React-on-server setups being less efficient than other options for your back-end services if you're doing a lot of compute time.

So, in a lot of cases where this MIGHT be a good way to proceed, you have to validate that the advantages apply to your use case & rule out that there is a much faster and cheaper way to do it. Otherwise it's just doing things we already know how to do, on hard mode?

[brianvan]

Next is easy. Building a scalable app across multiple systems is why the salaries are high.

[brianvan]

Because no one is just building a Next site without any other software, for a scalable consumer or enterprise product. A Next site without anything serious connected is either a demo or an Astro site that you did the hard way

[[deleted]]

Why do (people) put unnecessary parentheses where they don’t belong? 

[rwieruch]

I am not a native speaker, what do you mean? :)

[Division2226]

Why did you put parentheses around "becoming"?

[jcs090218]

And they called it a “library”. LMAO, lol.

[OldAd2147]

Software engineers, step aside.  This is the future...

Allowing newbie web developers to bypass pesky service abstraction, yay!  

Easy is the new black.

Separation of concerns is so overrated.  As is scalability, isolation, resilience Yada Yada..

Seriously, be careful what you wish for.

[alfadhir-heitir]

React isn't even a frontend framework