Live data from Hacker News

Next.js is infuriating

blog.meca.sh

351–360 of 602 posts

Re: Next.js is infuriating

#351

Earlier quoted context omitted.

> I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. Things will get far worse before they get better. Right now, online courses such as the ones in PluralSight are pushing Next.js on virtually all courses related to React. I have no idea what ill-advised train of thought resulted in this sad state of affairs but here…

The train of thought is “what is everyone using? I’ll use that too”

> The train of thought is “what is everyone using? I’ll use that too”

I'm not so sure about that. We're seeing Next.js being pushed as the successor of create-react-app even in react.dev[1], which as a premise is kind of stupid. There is something wrong definitely going on.

[1] https://react.dev/learn/creating-a-react-app

Re: Next.js is infuriating

#352
post #211

I’ve always felt that Vercel’s way has had fundamental flaws at its core “philosophy” and their approach to creating shiny objects from outside that stink from inside. Unfortunately incompetence of developers to see beyond has brought the web to the point that every React developer has dealt with Nextjs at some point. What are the alternatives beyond Vite and Remix?

> What are the alternatives beyond Vite and Remix?

On more than one occasion I’ve seen someone refer to Vite as an alternative to Next.js. Isn’t Vite a bundler and Next and Remix frameworks? How is Vite an alternative to these?

Re: Next.js is infuriating

#353

Maybe this is a good place to ask... but I was actually considering Next.js as a replacement for Gatsby.js project that is a few years old, but is growing at a steady pace. Given all the negative sentiments, what are better alternatives? I don't even use any SSR, or GraphQL capabilities. The main thing I liked about gatsby vs previous "bring your oown library(router)" are: very little configuring, nice dev server, ea…

Say anything negative you could possibly say about Next ... and it will apply a thousandfold to Gatsby.

Likewise React Router is ... the example I use when I want to tell someone about a terribly engineered library. As you said, there are multiple React Routers, because the developer is completely incompetent, and has no idea what he is doing. As a result, he changes the entire library in massive, backwards-incompatible ways ... EVERY. NEW. VERSION.

Astro and Remix are viable options, but there's a reason why Next (despite it's flaws) remains dominant over them.

Re: Next.js is infuriating

#354
post #338

Given all of the NextJS hate on here, I feel like I'll get downvoted for saying this...but we run Next.JS, don't host on Vercel - and really don't have many problems at all. That being said, our app is largely built like a standard React app, we aren't using much server-side-rendering, and we use TanStack Query for loading most data. So, the main value of Next.JS is mostly just the routing and project organization.

Out of curiosity, have you tried out Tanstack Start? It appears to be a framework similar to next and remix/react router.

I've loved all the Tanstack libraries so I'm looking for an excuse to use Start lol.

Re: Next.js is infuriating

#355

When I first saw Next.js I was immediatelly reminded of Meteor.js. I did invest a bit in learning into it and did some personal projects. But quickly realized it was both over-abstracted and inflexible which made it really hard to get it past prototypes. But these solutions keep coming up because they bring one thing: Self-contained / "batteries included". Just the other day there was a thread in hackernews about Lar…

Thing is I'm spoilt by asp.net, which has so much bad 'stigma' in the (esp startup) dev community but it is _extremely_ well designed. You get a very batteries included approach(es) but you can always punch out of it and override it. I've never got into a situation where I'm feeling like I'm fighting the framework. I also really like both Blazor Server and Blazor Webasm which allows you to write the frontend in C# to…

It's weird how C# can elicit such an eugh response, and TypeScript gets so much love. They're.. made.. by.. the.. same.. people

I agree people really need to update their mental model of where dotnet is at. I worked with it on Linux and it's a great experience

Re: Next.js is infuriating

#356

Earlier quoted context omitted.

I'm so glad I'm not the only one thinking this. I built a medium-complexity, money-making, production-grade app in Next.js and started out on Vercel's hosting (and Google Firebase) and then moved to hosting myself and stripping out Firebase, replacing it with Pocketbase. Pocketbase was the ONLY good thing about this journey. Everything else sucked just so terribly. Infinite complexity everywhere, breaking changes CON…

it might be a bit over the top but there is Cogent Core[0]; it supports apps on desktop, mobile apps, and the web. it even supports 2d and 3d. and it's all in go, backend and frontend (using WASM). [0] https://github.com/cogentcore/core

As much as I hate Next.js as the next guy, let's please not push full canvas rendering approaches. They SUCK. Their https://www.cogentcore.org/core/ own site is slow to load, scrolling is visually painful since it render at what I assume is 60Hz and not my native much higher monitor refresh rate. They are expensive in terms of computation, wasting resources on the machine, to display text. Want to select text, better hope the developers want you to be able to select text or didn't forget to do so, case in point text inside buttons. Accessibility is also usually much weaker, screen readers often suffer and if they don't something else will.

Canvas instead of DOM -> :(

EDIT: Gave it another try and more issues appear, within seconds of using. The left side has a rendering bug where the selected areas are cut off sometimes, ctrl+zoom does not zoom the page as it does on all normal websites. I can still zoom via menu. Middle mouse open link in new tab doesn't work. Z layer bugs everywhere. I expect more the longer I'd look.

Re: Next.js is infuriating

#357

I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts. Next.js is easily the worst technology I've ever used.

I'm so glad I'm not the only one thinking this. I built a medium-complexity, money-making, production-grade app in Next.js and started out on Vercel's hosting (and Google Firebase) and then moved to hosting myself and stripping out Firebase, replacing it with Pocketbase. Pocketbase was the ONLY good thing about this journey. Everything else sucked just so terribly. Infinite complexity everywhere, breaking changes CON…

" Codebases from years ago are still rock-solid." This is the biggest thing for me. I recently pulled down an 8 year old hobby Java/Maven project I had and it compiled and ran perfectly on the first try. Imagine trying to get an 8 year old javascript project to work...

Re: Next.js is infuriating

#358

Earlier quoted context omitted.

The train of thought is “what is everyone using? I’ll use that too”

> The train of thought is “what is everyone using? I’ll use that too” I'm not so sure about that. We're seeing Next.js being pushed as the successor of create-react-app even in react.dev[1], which as a premise is kind of stupid. There is something wrong definitely going on. [1] https://react.dev/learn/creating-a-react-app

It was interesting handling frontend interviews recently.

We do a 30-min tops exercise where you create a React project to show how to use useState and useEffect, etc. I help with whatever command they want to use and allow Google/ChatGPT.

More than half of the candidates had no idea how to use React without Next.js, and some argued it was impossible, even after I told them the opposite.

Re: Next.js is infuriating

#359

> Let's not skip over the fact that you can't have multiple middlewares or chain them either. Surely this can't be right? https://nextjs.org/docs/messages/nested-middleware > If you have more than one Middleware, you should combine them into a single file and model their execution depending on the incoming request. By Talos, this can't be happening.

Am I reading this correctly? They are advocating giving up on structuring code in separate files? Is that a scoping problem that NextJS has, which makes it difficult to use multiple files? Seems like a rather ridiculous statement of a framework to make.

It's the single file that is used to define the middleware function that runs. You can import whatever you want into it and decide how "you should combine [your middleware] into a single file."

Re: Next.js is infuriating

#360

Earlier quoted context omitted.

I believe the obsession with streaming is a major factor in the new constraints. Together with supporting the lowest common denominator, edge runtimes.

And the reason they're all in on streaming to begin with is because they're sending massive amounts of data back and forth all the time. Like Sean Goedecke said in his API design writeup [0], a technically poor product can make it nearly impossible to build an elegant API. I believe we're seeing the same thing with Next.js, all of these wonky interfaces derive from the underlying architectural issues. [0] https://www…

[deleted]
Post reply on HN