But you are of course also right that you can just attach a debugger. That's also called out in the article.

I've noted a tendency to not log stuff in some js-first devs i know ... they all say 'i'll reproduce it locally'...

or is it best practice to patch with logs only without reproduction

I don't think they meant "either" "or". I think they meant that you should not solely rely on reproducing issues locally. If you have good logging, many times, the logs would make it apparent where the issue is. When that fails, then you resort to reproducing the issue locally.

But if an app developer never adds any logs, they would be forced to reproducing the issue locally every single time which is counter productive.

So it isn't either logs or reproduce locally. It is add logs and read logs. But also reproduce locally when you really have to.

Of course that requires a certain operational maturity.

I've never worked at a place that had local dev used to think computers hated me but wondering if this is better dev practice in general

It just takes a lot less time to reproduce if you have some logging in production... and some people seem to believe that's not needed.

How much stuff do you log in the server? I’ve only ever seen devs log basic high-level stuff. But to actually debug something, you need way more information.

I’ve tried sticking debug-level logs that log all sorts of business logic. Pretty much recreating what you would do with console.log when trying to isolate an issue locally.

But then you have your code permanently littered with debug log lines! It makes things… ugly!!

If you NEED detailed logging, do you just deal with the uglified code? Or is there a better solution? Decorators that logs parameters and such automatically??

But if you meant a local or dev server where you start node with --inspect then the port to forward is 9229 by default.