I think NextJS lead reactjs to a doom way

[tcper]

I'm a front end developer, use Reactjs a lot, heard of nextjs for a long time, but never use it.

Finally I maintained a nextjs based project.

Yes, I know they create Server Component/Server-Side Render

But, everywhere are server components, it means, you can't use useState, useEffect and such client-function at all.

It means, nextjs turns the SPA to refresh page.

It means, you can't use console.log() or debugger; easily in a component, otherwise you have to turn the component into a client-component.

A lot of nextjs pages call async/await request, do they optimized these actions, combined many request into one? I don't know, but I don't feel pages loaded quicker than before.

And when I counter a real situation: * props.dataSource pass into

* component(use client), processed props.dataSource (React.useState(data.slice(0, defaultShowItems)))

* props.dataSource updated

* useState() return an old value

I have to give the component a fresh new key every time to fix this problem.

That's awkward, I heard motto, nextjs re-invent PHP, now I really feel it.

[verdverm]

> But, everywhere are server components, it means, you can't use useState, useEffect and such client-function at all. It means, nextjs turns the SPA to refresh page.

You can pass client components to server components, and have access to hooks & effects. See

- https://nextjs.org/docs/app/building-your-application/render...

- https://nextjs.org/docs/app/building-your-application/render...

You are also not required to use server components with NextJS and you can use it as a better overall DX and simplifications like directory (convention) based routing

[nilskj]

Yea idk. Or you can just change the perspective to: all the old stuff is actually client model + hydration like oldschool next, but and then you have new capabilities for rendering markup on server with RSC instead of hydration. Just think of it as a new additional tool in your toolbelt that you might want to use to offload big dependencies from the client bundle and run on server instead.

But from that real situation with props.dataSource, I would not expect the state from that useState to return a new value on prop update, even in a normal react app / without next. If you are not setting this client state (with the second method destructed from the hook) you could potentially ditch the useState completely and just run that data.slice(0, defaultShowItems) as is in the function body, or wrap in memo if calculation is expensive.

[mrbirddev → nilskj]

> Just think of it as a new additional tool in your toolbelt

This is the best way to introduce it. Vercel makes it too complicated in the docs where everything is splitted into app/pages, creating a large ecosystem gap.

[tcper → nilskj]

Your solution is workable, but abondon the Reactjs philosophy, use state as internal data.

And only if you are a experienced developer, new comers never know how to solve this.

[seattle_spring]

I recommend finding some established nextjs codebases and reviewing how they are built. You have a lot of info wrong in your post and I think you'd get a lot of value out of seeing how it's used by engineers experienced with the framework.

[wateroutflow]

Their business model is on your server usage

[revskill]

Next.js is a Vercel framework for ...their reason. No SPA by default because you spent money on your RSC usage on the server.

I think RSC has great potential, but Nextjs conventions limit its potential to the fullest.

[smokeydoe]

You are right. Nextjs has been terrible in my experience. And some junior developers are reaching for it for any and every project they start, even internal tools that don’t need server side rendering. I spent 2 days implementing auth middleware that clients and server side. Something that would have taken me 2 hours using a SPA. 2 days figuring out cryptic error messages and fight the client vs server model. Ended up having to convert to vite SPA

[nasmorn → smokeydoe]

I would invert and say most internal tools don’t need client side rendering unless you actually have the API already built

[moooo99 → nasmorn]

I wish this opinion was more widespread. The amount of time I have wasted building API + SPA when just sending HTML back and forth would have been entirely sufficient must be ridiculous

[nasmorn → moooo99]

If it is one person doing both it is bad enough but if you now need two teams collaborating on some stupid form to do crud that only 5 people will ever use you have lost all velocity

[tcper → smokeydoe]

Nextjs just deconstruct the React, and build their own stuff

[mmarian]

I've been using Astro with React and it's a breeze.

[android521]

react should move away from nextjs.It is a toxic relationship for React.

[verdverm → android521]

NextJS is a different project that came after React and is largely a bundler/framework built on top, implementing the bleeding edge before other frameworks. You'll often see React betas or release candidates as a next dependency. I expect that eventually other projects, like Vite, will also support RSC

How do you see React "moving away"? Maybe you mean React should not have gone down the server component path?

[tcper → android521]

Yes, that's provider-lock relationship, no other cloud provider have such service.