Live data from Hacker News

Next.js is infuriating

blog.meca.sh

551–560 of 602 posts

Re: Next.js is infuriating

#551

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

it's completely shit

Re: Next.js is infuriating

#552

Earlier quoted context omitted.

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

It's not React "minutiae". It's incredibly basic concepts, that if you don't know, you cannot in good faith say you know react.

It's like not knowing how to write a for loop or how to access an object's property in JavaScript.

Re: Next.js is infuriating

#553

Earlier quoted context omitted.

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…

In the win32/MFC days, there was no "front-end developer". There was only HTML and content creators writing it.

Then there came small web applications, and still no "front-end developers", since functionality could only work on the server.

It's only when AJAX was introduced in the mid 2000's that you could start to talk about "front-end developers".

By that time, win32 and MFC was old. We had Java, C# with .net framework, etc.

Re: Next.js is infuriating

#554
post #472

Earlier quoted context omitted.

Nope my dear, you're the one insinuating that logging works out of the box in production quality deployment without any kind of additional configuration or code changes, hence please make use happy, where that is the case. Word vomit into standard output isn't production quality .

It seems you might've missed functional reading class. The first thing I led with was that you need to import and initialize logging which covers both of those. You're the only one insinuating the strawmen you're arguing against. This isn't Reddit, surely you can do better.

I was there, initialize logging is configuration be it by code or settings files, which apparently isn't needed, an import does everything to show on production monitoring dashboards.

I do whatever I feel like, you're the one that started down this thread, don't complain where it goes.

Re: Next.js is infuriating

#555
post #270

Earlier quoted context omitted.

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 i…

I use it almost every day.

Java, .NET and nodejs are all over the place around here.

The point was without configuration.

Logger class doesn't do the work for production monitoring, without additional configuration so that its output appears on the necessary production dashboards.

Re: Next.js is infuriating

#556
post #312

Earlier quoted context omitted.

their issue with breaking changes is from way before the Remix days - React Router introducing massive breaking changes at every major that required significant rewrites was already a running joke of the community

Their documentation was also abysmal the last time I used their product.

YMMV but the current docs seem fine to me. Though it was pretty bad during the Remix -> RRv7 transition. You can also learn a lot from their github activity (proposals/rfcs/issues). API docs have some additional docs too.

New devs coming in and expecting the framework to be with "batteries included", which it absolutely is not, will also have a bad time. Node apis, ALS/context, handling app version changes on deploys, running the server app itself (if in cluster mode, e.g. with pm2, what that means in terms of a "stateless" app, wiring up all the connnections and pool and events and graceful reloads and whatnot...), hell even basic logging (instead of console.xxx) ... all of that is up to you to handle. But the framework gives you space.

People new to React and/or Node will be confused as hell for quite a bit... in such a cases I would add like 3 months of personal dev time and learning to just wrapping your head around everything... React docs themselves say that you should use a framework if you're using React in 2025 - but it's not that easy. There is a cost, especially if you go the full stack route (client + server + hydration) of having everything under one "typescript roof". The payoff is big, but definitely not immediate.

Re: Next.js is infuriating

#557
I've found that as long as I don't try to use Next.js for fullstack applications I was ok. It is remarkably good at frontend only role. Since most of my applications were built with spa's in mind, I just use Nextjs primarily to consume the api. So yes, I don't experience a lot of this angst.

Re: Next.js is infuriating

#558

Earlier quoted context omitted.

I don't agree. Having front-end and backend in the same language is so convenient I would never go back to doing it the old way. I'd rather compile the frontend to WASM than introduce a mismatch. I used to use Django and there were so many issues that arose from having to duplicate everything in JS and Python.

What about HTML? Are you writing HTML via JS - if not you're already writing multiple languages.

HTML is not a programming language. But yes, I don't write much HTML anymore.

The issue with mixing languages is that they have different data models, even simple things like strings and integers are different in Python and JS, and the differences only increase the more complex the objects get.

Sometimes I write some code and I realise that this code actually needs to execute on the client instead of the server (e.g. for performance) or the server instead of the client (e.g. for security). Or both. Using one language means that this is can be a relatively simple change, whereas using two different languages guarantees a painful rewrite, which can be infectious and lead to code duplication.

Re: Next.js is infuriating

#559

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…

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

At my previous startup (co-founder who made all technical decisions) we were unfortunately stuck with React Native. I had Mondays that started with the project not building after some dependency changes. Imagine something failing to build 3 days after you've last touched the codebase…

Re: Next.js is infuriating

#560

Earlier quoted context omitted.

> 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. Things will get far worse before they get better. Right now, online courses such as the ones in PluralSight are pushing Next.js on virtually all courses related to React. I have no idea what ill-advised train of thought resulted in this sad state of affairs but here…

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

This is only partially true. For example, with React Native even the core team now tells you to "just use Expo", as if relegating all responsibility to a project maintained by a for-profit that thinks 2 weeks is enough time to beta test a Major release.

It's also dismissive of market forces, i.e. developers have to pay bills and therefore are easier to hire if they know the skillset that is in wide use.

I've never worked or interviewed a single senior that wanted to use Next.

Post reply on HN