Next.js is infuriating

I don't get these kind of complaints, coming from Java and .NET web frameworks, Next,js is the only sane frontend framework followed by Angular.

Saying this as someone doing Web related development since 1998, glory days of Perl and CGIs.

I don't think the post is an unreasonable complaint. The fact that you have to even think about how to get logs out of your application is insane, never mind all the hoops you need here. Logging should be a first class citizen in anything that goes to production.

Angular is absolutely not a sane framework. I'd argue it used to be, but you can't build trust in anything after being rugpulled with 4+ major breaking refactors over the years. If you get it that wrong that many times, I start to wonder what the actual purpose of the framework is.

I kinda get what you are talking about (did those refactors too...), but which of major changes had such a high impact in your case?

In consulting we don't do upgrades, we come, we deliver, and we leave, with maintenance contracts for existing deployed versions.

For an upgrade someone has to pay for it anyway, so whatever pains there are, they are reflected on project budget anyway.

More devs should do the math of work hours to money.

Interesting, because that is hardly so in most frameworks, logging requires additional libraries and configuration almost everywhere.

Angular isn't doing bad on the backwards compatibility front. Case in point: ParamMap was introduced at some point as a successor to Params, but the people revolted, so both are available without favouring one or the other:

https://github.com/angular/angular/pull/43529#issuecomment-9...

It's kind of funny in hindsight, but at least we didn't have to modify every project just to update such a minor thing which was working already anyway.

In this regard the thing that absolutely sucks is the migration tool. Your best course of action is to update the versions manually in package.json, read the documentation on breaking changes and act accordingly.

In my view Angular was always insane, but it's becoming saner with each subsequent version. We now have typed forms (that took a while), standalone components and, most importantly, signals, which do most of the stuff RxJS is doing, but without the junior-killing hidden state and memory leaks.

> Angular is absolutely not a sane framework

I have not worked with older versions, but with V20 & signals, it has been pretty good.

I’m guessing you enjoyed the nostalgia when you saw directory based path convention from the good old CGI days?

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.

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.

This really highlights one of the main differences between "product" and "project" centric work. With a project, it's the client's problem ($$$.) Usually they'll balk at the dollars and effort required and accept the risks. Even with an outdated, obsolete framework, the actual risks are often minimal. "It's still working, right?"

Really just one major breaking refactor in 13 years, and that is partly because not only have we learned a ton, but browsers themselves have changed dramatically. I'm not going to say it was perfectly handled, but they also didn't have nearly as much support from Google back then.

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

It is more the irony of pendulum going back and forth between generations.

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.

Wrong again.

Spring Boot doesn't provide a serious production quality deployment without configuration.

Bare bones logging into standard out, yes.

That isn't production quality.

Production quality is telemetry logging, log rotation and zipping, forwarding logs to Kibana or Datadog dashboard.

This is a silly no true scotsman argument. First you don't say what you mean and then stick up your nose when no one has any idea what you're on about. Anyone is capable of making up an arbitrary set of requirements that no language nor framework fulfills. This doesn't change the fact that for most languages and frameworks, logging is a boring, solved problem. That Next.js doesn't bring that to the table is more than telling.

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.

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

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.

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.