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

491–500 of 602 posts

Re: Next.js is infuriating

#491

Post by Summershard »

pjmlp wrote: post #270
Etheryte wrote: post #267

Earlier quoted context omitted.

In most languages and frameworks logging is as simple as import, initialize, done. Here it's far from it.

Really, which ones? Because anything Java, .NET and Python, it certainly requires configuration and related infrastructure.

> .NET

I think you haven't used .NET in a while. Nowadays, logging is absurdly easy to configure. Heck, you usually don't even need to configure it, because the basics are already included in most templates. You just use the Logger class and it works.

The only time you have to spend more than 30 minutes on it is when you use some external logging libraries. And most of them are quite sane and simple to use, because it's so easy to create a custom logging provider.

Re: Next.js is infuriating

#492

Post by haltcase »

francisduvivier wrote: post #115

I recently migrated 2 projects away from Next.js to Vite. It was a lot of work, Next.JS handles quite a lot of stuff: translations, authentication, bundling, css stuff, caching... But it was very much worth it for lowering my daily infuration. I don't think I'll be using NextJS again if I don't have to.

In what way does Next.js handle translations or authentication? It doesn't prescribe or even do much to simplify either of those things.

Re: Next.js is infuriating

#493

Post by tshaddox »

digianarchist wrote: post #455
tshaddox wrote: post #445

Earlier quoted context omitted.

I don't see how this particular case makes anything better or worse for Vercel. It's just a poor developer experience to need to come up with your own composeMiddlewares function (or find one of the many that people have posted in various threads).

They validated this on the thread. They made an architectural decision to run middleware only on edge.

That's unrelated to the complaint I'm responding to, which is simply that you can only provide a single middleware file. This is merely a DX problem. You absolutely can develop your own composeMiddlewares function and import different middleware functions from different modules. It's just on you to do that, and to reimplement some basic functionality for each composable middleware function (like matcher regexes).

Re: Next.js is infuriating

#494

Post by jdthedisciple »

If you are trying to share context between middleware (backend) and rendering (frontend) literally rather than logically (via request-id only) then that seems to stem from a fundamental misconception of the distinction between backend and frontend to me ...

I suspect all these "all-in-one" JS frameworks out there unfortunately made people think that web apps are made of "one big happy javascript application, yay!" while it's really two (or even three) entirely decoupled runtimes (backend & frontend) instead.

Re: Next.js is infuriating

#495

Post by [deleted] »

platelminto wrote: post #71

I was about to start a new project with Next.js... is anyone willing to give me some advice? I'm about to start building an e-commerce site (30-50k poster print designs, i.e. no inventory), and was leaning towards a Django backend (because I know it) and... some sort of SSR frontend. I'm not really a frontend guy, but taking this as an opportunity to learn it. This article obviously does not inspire confidence in me…

[deleted]

Re: Next.js is infuriating

#496

Post by nikole9696 »

whstl wrote: post #358
motorest wrote: post #351

Earlier quoted context omitted.

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

This surprises me a lot. I spin up new react apps with vite often to replicate issues with 3rd party libs we use. Like how do they not know you can just spin something up over on CodePen or CodeSandbox and there's not a hint of a server side paradigm required? (sure, vite has a little server but you don't really need to know anything about it)

Re: Next.js is infuriating

#497

Post by platevoltage »

dev_l1x_be wrote: post #253

> In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. This true to most software projects that are used more than one set of people. Joe Armstrong proposed a solution that we should opensource functions only and people could assemble everything else using these opensource functions. I start to think that he might be right and instead using "frameworks" we should use these set of…

How I feel any time I see a simple static website or someone's developer portfolio with a vercel URL. Like, did you really need this?

Re: Next.js is infuriating

#499

Post by motorest »

hombre_fatal wrote: post #446
motorest wrote: post #417

Earlier quoted context omitted.

> You have to remember, Next is the only framework that can support some of the features in the latest version of React. That is extremely fishy, isn't it?

Not necessarily since they have to do with the inherently complex niche features like unified server/client rendering (e.g. RSC, streaming SSR with selective hydration, server actions). Next.js is essentially the reference and test bed impl. Where people go wrong is thinking they need to default to the inherently complex niche feature of client hydration which is a niche optimization enabled by a quirk of web tech.

> Not necessarily since they have to do with the inherently complex niche features like unified server/client rendering (...)

My point is that it's fishy how they push features that just so happen to be the value proposition of the only corporation that just so happens to be able to implement them.

Re: Next.js is infuriating

#500

Post by yuriy-yarosh »

There's tanstack router and tanstack start... And you don't have to choose frameworks.

I find it infuriating how people don't utilise any TSC based compiler plugin codegen, to automate two way sync for database entities...

Millions lines of code, for nothing.

Post reply on HN