from Hacker News

I think NextJS lead reactjs to a doom way

by tcper on 7/12/24, 1:23 PM with 16 comments

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.

  • by verdverm on 7/12/24, 4:40 PM

    > 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

  • by nilskj on 7/12/24, 7:31 PM

    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.

  • by seattle_spring on 7/15/24, 4:21 AM

    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.

  • by wateroutflow on 7/12/24, 4:02 PM

    Their business model is on your server usage

  • by revskill on 7/14/24, 10:47 PM

    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.

  • by smokeydoe on 7/12/24, 3:32 PM

    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

  • by mmarian on 7/13/24, 4:09 AM

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

  • by android521 on 7/12/24, 5:56 PM

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