5 ms·

Web browser developer tools are incredible, but what do you do when more of your work is shifting to the server? These tools are no longer available or only pro

Web browser developer tools are incredible, but what do you do when more of your work is shifting to the server? These tools are no longer available or only provide minimal insights. Bye-bye network tab and source tab! That's a challenge for developers adopting React Server Components (RSCs).

blenderob 2y ago
Not quite sure what the big challenge is here. If the work is shifting to the server, you debug on the server! Read the logs. Attach a debugger. Instrument the code if you must! All that usual stuff. This is how web-development has been since the days of CGI. What am I missing?
- sroussey 2y ago
  And these days, you use the same browser debug tools to attach to nodejs.
  - mmanciop 2y ago
    For local development, yes. But I see that almost never done in production settings, especially with containerized workloads. Is there a neat way to do it in Kubernetes?
    - sroussey 2y ago
      Well, I suggest never enabling the debugger in production. But if you meant a local or dev server where you start node with --inspect then the port to forward is 9229 by default.
  - sesm 2y ago
    Yes, but it's missing the network tab, see https://github.com/nodejs/diagnostics/issues/75 https://github.com/nodejs/diagnostics/issues/75
- nottorp 2y ago
  > Read the logs. I've noted a tendency to not log stuff in some js-first devs i know ... they all say 'i'll reproduce it locally'...
  - gunian 2y ago
    how else would one reproduce a bug? in production? or is it best practice to patch with logs only without reproduction
    - bripkens 2y ago
      There are often additional hints to go by, e.g., the executed network requests, the user path taken or "breadcrumbs", i.e., custom events captured. Of course that requires a certain operational maturity.
      - gunian 2y ago
        In my head that feels like triaging but idk people really be patching bugs without reproducing? That sounds crazy to me idk why 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
        nottorp 2y ago
        Who said anything about not reproducing? 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. And if you have logs, you may not need to reproduce it because said logs give you all the info you need. Disclaimer: circumstances may vary. A bug is a bug is a bug and you may solve it by reading one log line, or you may spend a week with a debugger in your development environment and it will still crash in production when you deploy the fix. Happy now?
    - blenderob 2y ago
      > how else would one reproduce a bug? in production? 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.
- bripkens 2y ago
  What's missing are the summaries that web developers are commonly used to. For example, the network tab in the developer tools. It is arguably very handy for development – and often more actionable than having to step through individual requests. But you are of course also right that you can just attach a debugger. That's also called out in the article.

blenderob 2y ago

Not quite sure what the big challenge is here. If the work is shifting to the server, you debug on the server! Read the logs. Attach a debugger. Instrument the code if you must! All that usual stuff. This is how web-development has been since the days of CGI. What am I missing?

sroussey 2y ago
And these days, you use the same browser debug tools to attach to nodejs.
- mmanciop 2y ago
  For local development, yes. But I see that almost never done in production settings, especially with containerized workloads. Is there a neat way to do it in Kubernetes?
  - sroussey 2y ago
    Well, I suggest never enabling the debugger in production. But if you meant a local or dev server where you start node with --inspect then the port to forward is 9229 by default.
- sesm 2y ago
  Yes, but it's missing the network tab, see https://github.com/nodejs/diagnostics/issues/75 https://github.com/nodejs/diagnostics/issues/75
nottorp 2y ago
> Read the logs. I've noted a tendency to not log stuff in some js-first devs i know ... they all say 'i'll reproduce it locally'...
- gunian 2y ago
  how else would one reproduce a bug? in production? or is it best practice to patch with logs only without reproduction
  - bripkens 2y ago
    There are often additional hints to go by, e.g., the executed network requests, the user path taken or "breadcrumbs", i.e., custom events captured. Of course that requires a certain operational maturity.
    - gunian 2y ago
      In my head that feels like triaging but idk people really be patching bugs without reproducing? That sounds crazy to me idk why 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
      - nottorp 2y ago
        Who said anything about not reproducing? 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. And if you have logs, you may not need to reproduce it because said logs give you all the info you need. Disclaimer: circumstances may vary. A bug is a bug is a bug and you may solve it by reading one log line, or you may spend a week with a debugger in your development environment and it will still crash in production when you deploy the fix. Happy now?
  - blenderob 2y ago
    > how else would one reproduce a bug? in production? 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.
bripkens 2y ago
What's missing are the summaries that web developers are commonly used to. For example, the network tab in the developer tools. It is arguably very handy for development – and often more actionable than having to step through individual requests. But you are of course also right that you can just attach a debugger. That's also called out in the article.