I think NextJS lead reactjs to a doom way

25 points by tcper 1 year ago | 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.

verdverm 1 year ago |

> 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...

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 1 year ago |

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 1 year ago | |

> 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 1 year ago | |

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 1 year ago |

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 1 year ago |

Their business model is on your server usage

revskill 1 year ago |

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 1 year ago |

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 1 year ago | |

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

moooo99 1 year ago | | |

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

tcper 1 year ago | |

Nextjs just deconstruct the React, and build their own stuff

mmarian 1 year ago |

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

android521 1 year ago |

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

verdverm 1 year ago | |

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 1 year ago | |

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