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? This can't be such a hard problem, can it? Every other language and framework does it!

▲

conor- 5 days ago | parent [-]

> 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 overkill, perhaps you're not the target audience of the framework

[0] https://opentelemetry.io/docs/languages/js/exporters/#consol...

▲

specialp 5 days ago | parent | next [-]

Because making it easy to run and monitor NextJS is never in their interest. The difficulty of that is what pushes people that make it to production with Next onto their platform. The goal is to provide more impressive preoptimizations that complicate the stack more and make it more difficult to run NextJS yourself and actually use any of them.

▲

conor- 4 days ago | parent [-]

I don't really know anything about self-hosting Next apps - but if you're deploying to k8s, it's not really that difficult or far-fetched to run an otel collector sidecar for your applications. It's already common to run some kind of prometheus scraper or other service to collect logs/metrics from your services but instead of having to have different collection methods for APM vs logs vs traces you can have it all aggregated in one place using OTLP format

▲

camdenreslink 3 days ago | parent [-]

Just by bringing up k8s you are making their point. It should be dead simple to do logging without having to set up hardly anything. I shouldn't even need to know what a sidecar container is.

	▲	conor- 3 days ago \| parent [-]
		"dead simple" really depends on what you're targeting and how. If you're targeting a cloud deployment on hardware you don't control or that's running with multiple instances/replicas, OTEL makes that pretty simple because you get a lot for free in the way of tracking instances/correlation ids, etc. If you wanted "dead simple" text-based logging in a situation where a service is deployed in multiple places you'd end up writing a lot of fluff to get the same log correlation abilities that most OTEL drivers provide (if you can even ship your logs off the compute to begin with) Which again comes back to the "maybe the framework isn't for you" if you're building an application that's a monolith deployed on a single VPC somewhere. But situations where you're working on something distributed or replicated, OTEL is pretty simple to use compared to past vendor-specific alternatives

▲

tacker2000 5 days ago | parent | prev [-]

Again, why would one need such a heavyweight tool?

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

▲

conor- 5 days ago | parent [-]

What specifically is heavyweight about OTEL? At its core it's a standard for producing structured logs along with some standards for exporting/collection. The heaviness is really implementation-specific and can vary stack to stack

There's even a handler for monolog in PHP - they are not necessarily mutually exclusive

https://github.com/open-telemetry/opentelemetry-php/blob/mai...

▲

tacker2000 4 days ago | parent [-]

Yes but instead of just logging to a text file for example you need OTEL, thats my point.

The fact that Monolog has a handler for this tool isnt relevant, but it shows that there is one more layer of complexity tacked on.

	▲	conor- 4 days ago \| parent [-]
		That doesn't really mean it's heavyweight though; an extra layer, sure (but I don't even really agree that it's complex - you set it up once and then mostly just log the same way you would with any other). You can still log to a text file if you want to run locally, but for something like next.js where you're intended to deploy production to some cloud somewhere (probably serverless) the option of _just_ writing to a text file doesn't really exist. So having OTEL as an ootb supported way to do o11y is much better than the alternative of getting sucked into some vendor-specific garbage like datadog or newrelic