Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js is infuriating

blog.meca.sh

Post reply on HN
Print view View original

421–430 of 602 posts

Re: Next.js is infuriating

#421

Post by qbane »

wetoastfood wrote: post #359
zelphirkalt wrote: post #283

Earlier quoted context omitted.

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

As a JavaScript developer, combining/consolidating middlewares manually just defeats the design of middleware. I would rather call it a callback function.

Re: Next.js is infuriating

#422

Post by fragmede »

recursive wrote: post #414
fragmede wrote: post #396

Earlier quoted context omitted.

What are you really testing for? That sounds like a bad interview.

Basic react experience presumably. As a first approximation, it seems like every possible interview sounds like a bad interview to someone. What has worked well for you?

Seems more like a test on random React minutiae. Like, let's take some framework, take away some random piece. How well do you know the area around that random piece we just removed? Frameworks are large and gnarly (or there isn't enough to them). Expecting a candidate to be lucky and know random implementation details in the area that happened to be picked doesn't seem like you'd select for anything other than luck.

For me, lately, the interview question is "here's code that ChatGPT generated for (previous interview question as related to the role we're hiring for that we could do)", what's wrong with it? What do now? (ChatGPT may or may not have actually generated the code in question.)

Re: Next.js is infuriating

#423

Post by worldsayshi »

kadhirvelm wrote: post #419

Well the thing that’s infuriating for me is feeling like there isn’t a good, well supported alternative for writing an enterprise grade React app that will be continue to be around. I used to rely on create-react-app, but now that that’s deprecated, I often find myself asking what else can I actually rely on? I don’t want to spend eng cycles dealing with webpack and stuff, this seems to be what the React team is endo…

What about vite.js?

One of my latest experiments was using vite.js and then using a go backend where I embedded the vite app using embed.FS. I haven't tried it in a live environment yet but it seemed like a potentially nice way of doing it.

Re: Next.js is infuriating

#424

Post by digianarchist »

pavel_lishin wrote: post #226

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

I can’t help but feel some of these decisions are made because it’s what is best for Vercel and not what’s best for the framework.

Re: Next.js is infuriating

#425

Post by FredPret »

recroad wrote: post #212

I feel a poor tool choice for your use case should not give you the right to blast the tool and it's design decisions. Most of those complaints are resulting from not understanding how NextJS works and the design decisions that it's creators have made. For example, the middlewares. they're to be treated as a hook. If NextJS had a mechanism for having handlers like Express does, you'd have complained about handler exe…

What challenges did you pick up with Elixir?

Re: Next.js is infuriating

#426

Post by fragmede »

recursive wrote: post #415
fragmede wrote: post #410

Earlier quoted context omitted.

Sounds like a conspiracy theory. What's wrong with making the framework easier to use? Yes, the company that's paying for development on the framework is also paying those developers to make the golden path for deployment to use that company's PaaS offering, but unless we all band together and GoFundMe a framework that doesn't, how else do you want framework development to happen? Heroku/Cloudflare/AWS/GCp's entirely…

> What's wrong with making the framework easier to use? Vendor lock in. Magic leaky abstractions are great until you need to debug something a few layers down when the magic stops working. > how else do you want framework development to happen? Loosely affiliated open source efforts maybe. If that doesn't work, I would prefer to have none at all.

> If that doesn't work, I would prefer to have none at all.

While we would all like to retire to a cabin in the woods and be a carpenter, and for corporations not to exist, that seems unrealistic.

Magic leaky abstractions are orthogonal to vendor-lock in, and the source is open, so I'm not seeing the lock-in part. The "hey it's easier and cheaper to smash the deploy-to-vercel"-in, sure, but things cost money. Either to a developer, or to a company.

Re: Next.js is infuriating

#427

Post by specialp »

oompydoompy74 wrote: post #249
9dev wrote: post #177

Earlier quoted context omitted.

Vercel is the cancer of the modern web. The claw into every framework ecosystem and abuse them as sales funnels for their paid plans, pretending they care about open source, competition, and the web.

Vercel funds and sponsors many open source projects that would otherwise be struggling for funding. Their framework is tailored to the platform they build because that’s a good experience. I don’t currently use them, but people get funneled to their paid plans because it’s a good developer experience. I acknowledge that they are a capitalist enterprise with their own motives, but I think cancer of the modern web is a…

People get funneled to their paid plans out of necessity. While NextJS is open source, the back-end to run it is not. That is where all the complexity lies. Even on Netlify, you run into crazy issues with things like their image stack. It does all this "Optimization" and caching that make it completely impossible to reason about and you run into implementation problems from the providers. Sure you can just run it in a container but then you are taking on all the complexity of NextJS preoptimizations without getting any of them.

Serverless framework attempted to make this stack to run yourself for Next but it is buggy due to the complexity of Next. Open source includes being able to run it. Releasing the framework and funding OSS that also enhances NextJS is nice, but it is a trap because if it comes time to seriously run it, your only option is vercel.

Re: Next.js is infuriating

#428

Post by Alex3917 »

YuukiRey wrote: post #79

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.

> Next.js is easily the worst technology I've ever used.

To be fair, this is partly on the kind of people who use it. E.g. if you're trying to build something that's intended to last for 10+ years but you don't think it's worth it to spend the 20 hours watching the Udemy course on Angular, then your technology is going to be a complete dumpster fire no matter which stack you choose.

Re: Next.js is infuriating

#429

Post by rob »

I think too many newer "developers" are relying on AI tools trained on popular frameworks like Next.js to create things, and Vercel's loving this because they're the "go-to" in the end when you need to deploy something based on this stack.

There's no real alternative for these developers because they weren't brought up to understand server/networking fundamentals, how to operate a VPS, etc. Vercel manages to make this even more confusing for them by blurring the line between server and client, "edge" functions, etc, while all behind variable pricing.

Re: Next.js is infuriating

#430

Post by kremi »

yladiz wrote: post #234
kremi wrote: post #190

I think “middleware” is a bit of a misnomer in Next.js. It’s really an edge function that runs before your request hits the app -- quick header checks, routing, and other lightweight guards. It runs on the edge runtime, not on the app server. The post's author seems to conflate the edge runtime with the server runtime. They’re separate environments with different constraints and trade-offs. I struggled with Next.js a…

> But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer. The biggest issue is that the complexity is self-inflicted. The term middleware has a pretty well understood meaning if you've worked with basically any other framework in any language: it's a function or list of functions that are called at runtime before the request handler, and it is assumed those functions run in th…

Yes, the term "middleware" is unfortunate, this is abundantly clear.

> you wouldn't get a new tool simply because you might need it

No but you get a framework precisely because it's "batteries included": many apps will need those tools. You don’t have to use all of them, but having them available reduces friction when you do.

> If Next.js wants to allow you to run code on the edge before your app is called, that's fine, but it should be opt-in

It already is. Nothing runs at the edge unless you add a middleware.ts. You can build a full app without any middleware. I'm surprised the author of the article fails to acknowledge this, given how much time was spent on finding alternative solutions and writing the article.

Post reply on HN