4 ms·

I think the very fact that you have to rely on things like that when debugging speaks volumes about the language deficiencies. Or maybe it's just the tooling or

I think the very fact that you have to rely on things like that when debugging speaks volumes about the language deficiencies. Or maybe it's just the tooling or environments where JS is executed? In any case, the debugging experience is probably the biggest reason why I dislike modern web dev and tend to steer my career towards back-end.

maddyboo 6y ago
I don’t understand your comment. Firefox and Chrome both have actual debuggers as well, but many times console.log is a faster way. What are the deficiencies you speak of?
- paweladamczuk 6y ago
  I just think there are easier ways to debug your code than including logging statements between your lines. And in some environments I have never felt the need to do so. I use the browser debuggers as well but I never saw a JS stack trace approaching readability of a C# stack trace, and there are also other things that make the entire debugging experience more troublesome. Maybe that's just because I have very little front-end experience (and no workflows and IDEs properly set up to work with particular frameworks). Or maybe it's because of the JS ecosystem. Threads like this one make me lean towards the latter.
  - maddyboo 6y ago
    If there’s an unhandled exception (or even a log message) in your JavaScript, you can click on it in the console and go straight to the source line, set a breakpoint and reload or re-trigger the code, and now you’ve got a fully interactive “stack trace” where you can inspect the values of local variables at all levels of the stack. Or you can set the debugger to automatically break on exceptions, or even to break on events or DOM modifications. I also can’t stress enough how nice it is to have the debugger integrated into the runtime environment as opposed to an auxiliary debugger like GDB. No need to launch the debugger after my code breaks because it’s already there. I think web technology has come a long way in the past few years, but a lot of people still seem to hold a grudge against it that I can only imagine they developed in the days of “jQuery all the things”. Are there still problems? Massively yes, but what ecosystem is perfect? I think if you don’t have much recent experience, it can’t hurt to try these things again with an open mind and see if your opinions still hold. I personally don’t have any experience with C# to be able to compare the debugging experience, but compared to Go or C/C++ I think it is massively better. I think with a good setup including a LSP server for your editor, a good linter, and a type checker, frontend development is actually one of the more enjoyable ways to write code. Tangential, but the only feature I really miss from browser debuggers is time travel debugging. Mozilla was working on implementing this in the Firefox DevTools as “WebReplay” [0] but it was spun out as a separate project called Replay.io [1] and I haven’t heard much about it since then. [0]: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/WebReplay https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We... [1]: https://www.replay.io/ https://www.replay.io/
sdfhbdf 6y ago
You don't have to "rely" on it just like you don't have the rely on `fmt.Println()` in golang for debugging. A language/runtime/framework gives you options and you pick your poison, browsers offer you step by step debuggers and REPL out of the box and I actually think it's awesome in terms of debugging, you can of course only use console.log(), and it's a good place to start. When you're ready to move on there are many more useful tabs in the browser devtools to debug with.
- paweladamczuk 6y ago
  What worries me is that, apparently, there are many people with a lot of web dev experience who haven't moved on. Why haven't they moved on? I don't understand it. I have yet to see a mid-level engineer using the same method when debugging C# code. Despite all that, I try to refrain from strong statements about technologies. Just throwing around ideas.

maddyboo 6y ago

I don’t understand your comment. Firefox and Chrome both have actual debuggers as well, but many times console.log is a faster way. What are the deficiencies you speak of?

paweladamczuk 6y ago
I just think there are easier ways to debug your code than including logging statements between your lines. And in some environments I have never felt the need to do so. I use the browser debuggers as well but I never saw a JS stack trace approaching readability of a C# stack trace, and there are also other things that make the entire debugging experience more troublesome. Maybe that's just because I have very little front-end experience (and no workflows and IDEs properly set up to work with particular frameworks). Or maybe it's because of the JS ecosystem. Threads like this one make me lean towards the latter.
- maddyboo 6y ago
  If there’s an unhandled exception (or even a log message) in your JavaScript, you can click on it in the console and go straight to the source line, set a breakpoint and reload or re-trigger the code, and now you’ve got a fully interactive “stack trace” where you can inspect the values of local variables at all levels of the stack. Or you can set the debugger to automatically break on exceptions, or even to break on events or DOM modifications. I also can’t stress enough how nice it is to have the debugger integrated into the runtime environment as opposed to an auxiliary debugger like GDB. No need to launch the debugger after my code breaks because it’s already there. I think web technology has come a long way in the past few years, but a lot of people still seem to hold a grudge against it that I can only imagine they developed in the days of “jQuery all the things”. Are there still problems? Massively yes, but what ecosystem is perfect? I think if you don’t have much recent experience, it can’t hurt to try these things again with an open mind and see if your opinions still hold. I personally don’t have any experience with C# to be able to compare the debugging experience, but compared to Go or C/C++ I think it is massively better. I think with a good setup including a LSP server for your editor, a good linter, and a type checker, frontend development is actually one of the more enjoyable ways to write code. Tangential, but the only feature I really miss from browser debuggers is time travel debugging. Mozilla was working on implementing this in the Firefox DevTools as “WebReplay” [0] but it was spun out as a separate project called Replay.io [1] and I haven’t heard much about it since then. [0]: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/WebReplay https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We... [1]: https://www.replay.io/ https://www.replay.io/

sdfhbdf 6y ago

You don't have to "rely" on it just like you don't have the rely on `fmt.Println()` in golang for debugging. A language/runtime/framework gives you options and you pick your poison, browsers offer you step by step debuggers and REPL out of the box and I actually think it's awesome in terms of debugging, you can of course only use console.log(), and it's a good place to start. When you're ready to move on there are many more useful tabs in the browser devtools to debug with.

paweladamczuk 6y ago
What worries me is that, apparently, there are many people with a lot of web dev experience who haven't moved on. Why haven't they moved on? I don't understand it. I have yet to see a mid-level engineer using the same method when debugging C# code. Despite all that, I try to refrain from strong statements about technologies. Just throwing around ideas.