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

161–170 of 602 posts

Re: Next.js is infuriating

#161

Post by porridgeraisin »

sensanaty wrote: post #67
zwnow wrote: post #19

Earlier quoted context omitted.

I work with Vue 2 and Vue 3, both options and composition APIs and both are pretty great. I dont know how it's like for very complex UI but it 100% fulfills my needs. Also shout out to Pinia, I love you!

I have a monstrosity of a Vue 3 project at work and I far prefer it to any "elegant" React codebase I've ever had the displeasure of working with. Boggles the mind that React still has any mindshare to me, Vue and Svelte are both superior to it in pretty much every way except for availability of component libraries (which isn't so relevant in my line of work), and a slight edge in terms of TypeScript support (mostly…

Yeah, vue is really easy to work with, conceptually simpler and has so many more niceties.

Re: Next.js is infuriating

#162

Post by ale »

celicoo wrote: post #157

Reading through all these comments gives me hope. Finally people are speaking up about what we have all been experiencing in isolation — the gradual enshittification of Vercel/Next.js in service of Vercel's business model. The middleware issues the OP describes are not bugs, they are symptoms. When you can't get basic logging to work, when you can't use WebSockets, when you are forced to deploy on edge runtimes that…

To be fair Next.js is just following the natural progression of what their product always has been: holding devs' hands in all things deployment at the expense of vendor lock-in. Being aware of Vercel's limitations is not about the open web, it just means you should be setting up servers yourself at this point.

Re: Next.js is infuriating

#163

Post by divan »

kumarvvr wrote: post #78
divan wrote: post #75

For the past 5 years, my main stack is Flutter+gRPC+Go, and I read articles like this in horror and satisfaction simultaneously. For many years I'm advocating the community to be very open about the history of web stack (and JS in particular) and be honest about it's suitability for the modern software development. The level of accidental complexity in this stack is insane and people seem to embrace it add more and m…

> my main stack is Flutter+gRPC+Go For web apps? How is the performance? How is the developer experience?

Yes, web build comes as a nice bonus, and I've been using it from the early days of Flutter web renderer support. Now I'm using it for client-side web apps exclusively.

Developer experience is... well, I usually develop app while running it locally as a MacOS desktop app build. Just much easier to use with hot-reload and Flutter dev tools. Often using DevicePreview [1] wrapper to check against different sizes, dark/light mode, font scaling etc. Unless I'm working on something platform-dependent (like push notifications or a QR code scanner that uses camera/ML frameworks from OS), I don't even test it on mobile devices or web - I know that it will look pixel-perfect. There are optimization caveats like "emojis are not included in the web build by default to decrease the size", but otherwise web build looks the same way pixel-to-pixel as MacOS or mobile view. Test I run with maestro in iOS simulator.

Centering widgets ("") is never a problem, haha. Having a properly designed layout system is a no-brainer and thousands of times better experience than that pile of hacks on top of hacks called CSS.

Still, my main issue with the current Flutter design is the tight coupling of two main design systems (Material Design and Cupertino) and the core, and the lack of a wide choice of alternative design systems. Just to make it clear - it's extremely easy to create your own widgets/themes/look-and-feel in Flutter app. But having a well-thought-out design system is a different beast. Luckily, decoupling is on the way [2] and I hope it will lead to a boom of nice design systems implementations.

Also, because Flutter originally was targeting mobile development, and expanded to desktop/web almost accidentally, the majority of the widgets are optimized for mobile UI. For example, if you want a date input field that feels native to a desktop user, with masking and yet a calendar picker – good luck finding one. And as I create desktop/mobile apps 50/50, I settled for now with forui [3] design system, heavily inspired by shadcn.

Performance has been the last of my concerns with Flutter, because the engine was originally heavily optimized to hit [1] https://pub.dev/packages/device_preview

[2] https://docs.google.com/document/d/189AbzVGpxhQczTcdfJd13o_E...

[3] https://forui.dev

Re: Next.js is infuriating

#164

Post by nobleach »

wg0 wrote: post #95

Genuine question - What are the alternatives? React Router + Express? Or something else?

We do React Router 7 (previously Remix) with Fastify for a couple of our apps. Both external and internal. I'm really happy with the dev experience. We also have plenty of NextJS floating around here too. Most teams use it as a "better Create React App". There's little use of any of its features. I'm the only one that's used any server-side stuff.

For my team, React Router 7 just gets out of the way. If you use it in framework mode (SSR) you will have loaders and actions, which are things that run on your server. I find it SO much less convoluted. The logger example from the article above is childs play in React Router. Either import your logger and run it in your loader. (You may want to add .server.ts to make it explicitly ONLY server) or inject the logger via context.

Re: Next.js is infuriating

#166

Post by QuadrupleA »

Every time I hear about modern JS/TS frameworks, I'm amazed at the unnecessary complexity.

In python / bottle.py this would just be a print statement to stderr in before_request() or before_response(). One additional LOC.

Re: Next.js is infuriating

#167

Post by Aldipower »

xdanger wrote: post #111
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…

You should really try Nuxt (a vue framework, like Next.js but better).

I had to use a webpage built with Nuxt recently. This thing was completely messed up.

Re: Next.js is infuriating

#168

Post by zwnow »

sfn42 wrote: post #152
sensanaty wrote: post #67

Earlier quoted context omitted.

I have a monstrosity of a Vue 3 project at work and I far prefer it to any "elegant" React codebase I've ever had the displeasure of working with. Boggles the mind that React still has any mindshare to me, Vue and Svelte are both superior to it in pretty much every way except for availability of component libraries (which isn't so relevant in my line of work), and a slight edge in terms of TypeScript support (mostly…

I think React is fine, the problem is that every single react app I've inherited is ass - people just do everything incorrectly and overcomplicate simple things. Components with like 5 different useEffects, huge global state causing all kinds of bugs, way too much frontend logic in general. The amount of JS code that exists just to mimic things you can do with HTML and CSS is staggering. Everyone complains that react…

> Everyone complains that react is so slow and horrible, it isn't. It's their code that's slow and horrible, react is snappy as hell when you use it properly.

Why use something that you have to use "properly" when there are things out there that enforce being used properly?

Re: Next.js is infuriating

#169

Post by jjani »

anonzzzies wrote: post #40

As much as I don't like most things about nextjs (I could write a vastly larger blogpost about it but won't as I like to keep my heartrate down), it feels like claude was trained specifically for it. In our experience, claude code is better at nextjs than other frameworks.

Significantly better than just React and a Node backend? I doubt it, what's the comparison here?

Re: Next.js is infuriating

#170

Post by delfinom »

berkes wrote: post #107
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.

Many of the abstractions and nextjs tools do things that my OS does better, cleaner and more predictable too. I suppose the overly complicated ENV/.env loading hierarchy is (partly) needed because Windows doesn't (didn't?) have ENV vars. Same for inotify, port detection, thread management: *nix does it well, consistent ish. But when you want an interface or feature that works on both *nix and windows, in the same way…

Damn, I didn't know someone could be so clueless about Windows or operating system history in general. What the hell do they teach in computer science these days
Post reply on HN