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

391–400 of 602 posts

Re: Next.js is infuriating

#391

Post by blinkbat »

tankenmate wrote: post #343
throwaway77385 wrote: post #292

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

wow this is bad! like truly bad UX. please don't recommend this.

Re: Next.js is infuriating

#392

Post by tacker2000 »

conor- wrote: post #364
throwaway150 wrote: post #31

Earlier quoted context omitted.

Appreciate the response. But ... > Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention That makes it sound as though the answer to a clumsy logging facility is simply to add another heavy layer of complexity. Surely not every application needs OpenTelemetry. Why can’t logger().info() just work in a sensible way?…

> Why can’t logger().info() just work in a sensible way? I think OTEL is pretty sensible for a vendor-free and if you want to have a console logger you can use the console exporter[0] for debug mode during local development. Also if Next is designed as a framework to make it easy to build production-grade apps, having a standardized way to implement o11y with OTEL is a worthwhile tradeoff? If you view that as being o…

Again, why would one need such a heavyweight tool?

Most frameworks have powerful loggers out of the box, like Monolog in the PHP world.

Re: Next.js is infuriating

#393

Post by porridgeraisin »

AstroBen wrote: post #355
martinald wrote: post #203

Earlier quoted context omitted.

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

Probably because the standard way of writing C# is too OOP-ish (for lack of a better term). Typescript lets you write just usual functions handling mostly typed objects, which is about as much abstraction as most people want (except for 1-2 classes for stuff like `BTree`), and as much typing as most people want.

Re: Next.js is infuriating

#394

Post by rustystump »

The feeling in the article is one i share. Frustration. It stems due to the rush job that is endemic to nextjs when it comes pushing out half baked features. It started with the app router.

Case and point

“Use server” “Use client”

Intuitively, one runs on server and one on client. But you would be wrong. It is far more complicated. Now multiply this by 100 features. What you get is an obtuse hard to penetrate framework that seems to behave unpredictably unless you carefully read the thousands of pages of docs.

Now ai doesnt help as the api changes so frequently that it often spits out version 13 and not 14.5 let alone 15 or whatever is most recent.

This likely happens due to the need to rush features out for the next nextjs conf much like many other saas providers rush for their respective conf.

Re: Next.js is infuriating

#395

Post by dminik »

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…

I'm sorry, but please do read the post.

The middleware section is a setup. The real trouble starts when ejecting from Next and using a custom server still doesn't allow you to do anything because Next is a black box.

I would have been happy with installing fastify and just using it's middleware, but even that doesn't work.

Re: Next.js is infuriating

#396

Post by fragmede »

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.

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

Re: Next.js is infuriating

#397

Post by fragmede »

koonsolo wrote: post #316
felipeccastro wrote: post #262

Earlier quoted context omitted.

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

This coupled with the fact that "web development" now means anything going from a content rich website like a blog, towards some e-shop, all the way to complex applications like ux design, video editing, etc. It's pretty absurd to have such a broad range of web solutions, and think the same solution can cover everything.

Why? Microsoft's GUI framework as well as Apple's covered plenty of use cases before the rise of the web browser.

Re: Next.js is infuriating

#398

Post by Etheryte »

pjmlp wrote: post #344
Etheryte wrote: post #300

Earlier quoted context omitted.

Log4j can be as simple as add the dependency and you're good to go. Of course, you can do fancier setups and bridge your logs wherever where it is more work, but out of the box, it's very straightforward and batteries included. I have a very hard time believing you're seriously arguing the case that some of the most commonly used languages don't have good options for logging.

Which Java framework has log4j working out of the box for serious production deployment?

Spring Boot for example, which is arguably one of the most common ways to do Java anything these days. If you're trying to make a point, it would be considerably easier if you just said what you mean, because so far you're not making one. You could've easily looked up any of these questions.

Re: Next.js is infuriating

#399

Post by fragmede »

rozenmd wrote: post #195
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.

I've been running a SaaS on Next.js + GraphQL for 4.5 years now, sticking to Pages router has eliminated most of the complexity. I recently rewrote my auth to use better-auth (as a separate service), which has allowed me to start moving entirely off Next.js (looking at either React Router 7 or Tanstack Router). Back when I started, Next.js made server side rendering incredibly easy, but it turns out I didn't need it.…

Why're trying to move off next? What makes the opportunity cost worth it?

Re: Next.js is infuriating

#400

Post by evilduck »

happimess wrote: post #180
matt-p wrote: post #138

Earlier quoted context omitted.

Having front-end and backend in the same language and mono repo is such an outrageous productivity booster for me. Obviously the opposite may still be true if you've got big, separate frontend and backend teams but if you just want to ship.. I wouldn't have it any other way.

You can have a monorepo with any tech stack you'd like. You can write your front-end and back-end in the same language. No shade to you for finding a productive setup, but Next.js tightly couples your front-end and back-end, no question.

> Next.js tightly couples your front-end and back-end, no question.

I'd question that statement, since it's wrong. There's no requirement to connect your NextJS server to your backend databases, you can have it only interact with your internal APIs which are the "real backends". You can have your NextJS server in a monorepo alongside your APIs which are standalone projects, and Next could exist solely to perform optimized payloads or to perform render caching (being the head of a headless CMS). It seems like a weird choice to make but you could also build almost a pure SPA have have Next only serve client components. The tightness of the coupling is entirely up to the implementor.

Post reply on HN