Live data from Hacker News

Next.js is infuriating

blog.meca.sh

541–550 of 602 posts

Re: Next.js is infuriating

#541

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.

What is frustrating is that like 3 or 4 major versions ago Next.js was the best thing since sliced bread.

Re: Next.js is infuriating

#542

Earlier quoted context omitted.

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

You mean like this? nvm use && npm i && npm run dev

Does NPM work for you in the first place? Much less after 5 years? They’ll have gone through 2 major revisions on their lock file format, and it’ll complain you don’t have the exact version of node specified in your package.json

Re: Next.js is infuriating

#543

Recently started developing a client side web app using Angular v 20. The app is quite complex, with about 40 components many of them nested, about 7 to 8 "pages", data dashboards, multiple forms, continuously updating data from server, etc. There substantial amount of data flow in the application. So far, the experience has been absolutely wonderful, particularly, given the context of myself as a developer in the wh…

Meanwhile, I've been looking for a while and if they want a full stack or a FE developer it's always, always React. Rarely if ever Angular, occasionally Vue or Svelte, and never Phoenix.

I recall back in the day when Struts was everywhere, some of us figured out it was because Struts was a trap that took twice as many devs to get anything done, and that's why there are so many openings for it. Every time I look at React, I just wonder if it is the new Struts.

The old Angular apps I worked on (heck that was before AngularJS and Angular split) was pretty decent. Long argument lists were a big problem, sure, but the whole Service layer was one of the smartest features I've seen in a framework in a while. Second only to Routes. It saved us leaking a bunch of impedance mismatches across the entire codebase. It gave us some place to stash code while we asked the backend team to change their APIs.

Re: Next.js is infuriating

#544
post #464

Earlier quoted context omitted.

That would be Nest , not Next . A true abomination.

I'm a bit surprised at reading that. I've tried both, Next left a bad taste in my mouth, but Nest was kinda neat. Didn't used it for anything too complicated though, so I'm curious about what sort of grievances people have against Nest.

Something, something enterprise software. I find its dependency injection harder to reason about.

Re: Next.js is infuriating

#545
post #372

Folks will deal with all of this crazy stuff just to avoid using Ruby on Rails, Phoenix, Django, etc. Why? Is Next.js that much better for the user? I doubt it.

You only need to know one language, and that makes it easier to hire people that can work on both back and frontend

Re: Next.js is infuriating

#546

Earlier quoted context omitted.

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

Then why did HTML became so popular if win32 or MFC were so great?

> Then why did HTML became so popular if win32 or MFC were so great?

One of the factors is that web dev pushes for a complete separation of concerns, and thus allows frontend developers to specialize in front end development. Therefore it becomes far easier to hire someone to do frontend work with a webdev background than a win32/MFC background.

Number of applicants is also a big factor. There is far more demand for webdev than pure GUI programming. You can only hire people who show up, and if no one shows up then you need to scramble.

Frontend development is also by far the most expensive part of a project. In projects which use low-level native frameworks you are forced to hire a team for each target platform. Adopting technologies that implement GUIs with webpages running in a WebView allow projects to halve the cost. This is also why technologies like React Native shine.

Also, apps like Visual Studio Code prove that webview-based apps can be both nice to look at and be performant.

It's not capabilities. It's mainly the economics.

Re: Next.js is infuriating

#547

Remix ( cough react router 7 framework mode cough ) is like the polar opposite of this, it's just a Request -> Response handler that you have to build your server around manually. Which I found kind of annoying at first but it does give you the freedom to do what you want.

RRv7 is great. It does the heavy lifting of what you'd use this kind of framework for in the first place (one codebase in one language - typescript - one "stack"/lib tree - that does both the server and the client rendering), handles routing, route modules, code splitting, bundling, etc. etc.

Having to know node (or other supported server) and needing to implement your server business logic from scratch (models, db access, caching layer with redis or something, etc. etc.) is not a weakness, it's a strength.

The thing that .net tried to do for like a decade and failed to (one stack for both the server and the client), see Blazor bullshit etc. is handled here. Imagine you need a modern web app or a shop or whatever and that means React. It just does. Your backend stack is PHP or Rails or Go or whatever. Now you have to somehow square the hydration circle which you can't do without it being a massive pita (as PHP renders a page on the backend in.. well.. PHP) so you end up passing the data manually in some blobs of jsons or whatever with each request (or even worse, side to it in some fetches) that then React initializes from on the client and it's a total mess. Not to mention that unless you render the page in both php and react (try to keep both outputs the same lmao), you'll only see the full app "on the client" meaning crawlers/bots/google have to run JS on all your pages or see nonsense ... yikes.

SSR with hydration is there for this reason. You render the same React tree both on the server and on the client. The hydration process itself is made much easier by RR and its infrastructure (automatic passing of data to the client). Hell, thanks to SSR you don't even have to have JS enabled on the client if you're using just basic web standarts (see RRv7 docs on progressive enhancement and state management) and the site will work. This means even crawlers without JS runtimes will be able to index your site.

Re: Next.js is infuriating

#548

Earlier quoted context omitted.

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

You mean like this? nvm use && npm i && npm run dev

Oops, one of the dependencies is a C++ library that doesn't compile on your less-than-five-years old arch.

Re: Next.js is infuriating

#549

Earlier quoted context omitted.

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

You mean like this? nvm use && npm i && npm run dev

That only works if the project is constantly maintained. Otherwise it can and will break in time.

Re: Next.js is infuriating

#550

Earlier quoted context omitted.

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

You mean like this? nvm use && npm i && npm run dev

Ok, 50 packages have critical vulnerabilities now
Post reply on HN