Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use console.log() like a pro (2020)

markodenic.com

Post reply on HN
Print view View original

131–140 of 156 posts

Re: Use console.log() like a pro (2020)

#131

Post by uyt »

console.log can also be styled! It's a restricted subset of css so you have to hack around it, but it's good enough to make images display:

  img = $$('img')[0];
  // console.log(img);
  console.log("%cPlaceholder", `background:url("${img.src}") no-repeat cyan; border:1px solid black; padding:${img.naturalHeight}px ${img.naturalWidth}px 0 0; font-size:0; line-height:0;`);
If you paste this you should see the HN logo display in your console. Credit for the image trick goes to https://github.com/adriancooney/console.image

I use this a lot for working with animated canvases. Appending the current frame into the page is not the same since you lose the context you get from being interleaved with your other log messages.

Re: Use console.log() like a pro (2020)

#132

Post by maddyboo »

paweladamczuk wrote: post #113
maddyboo wrote: post #92

Earlier quoted context omitted.

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?

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…

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

[1]: https://www.replay.io/

Re: Use console.log() like a pro (2020)

#133

Post by meetups323 »

ljm wrote: post #123
jchw wrote: post #2

Another trick that might be more practical for actually debugging is using the object shorthand. For example, instead of... console.log(x, y); which contains the information you need, but lacks any useful context, try... console.log({x, y}); ...which will print out like an object, including the key names.

The best trick for actual debugging is to leverage your browser console. In a local build you basically have a 1:1 mapping of source code to deployed code and the debugger here basically becomes your IDE. You can hit Ctrl+Shift+P in the inspector and use the same kind of fuzzy file matcher you have in Sublime Text or VS Code, and from there you can set breakpoints, modify the code in memory, and so on. The console wi…

FYI VS Code's JS debugger speaks Chrome Debugger Protocol and allows you to use the built in Debug Console just as you would the browser's debug console, also it's possible to set browser breakpoints/etc., and you get inline value hovers.

Re: Use console.log() like a pro (2020)

#134

Post by ConnorLeet »

meetups323 wrote: post #133
ljm wrote: post #123

Earlier quoted context omitted.

The best trick for actual debugging is to leverage your browser console. In a local build you basically have a 1:1 mapping of source code to deployed code and the debugger here basically becomes your IDE. You can hit Ctrl+Shift+P in the inspector and use the same kind of fuzzy file matcher you have in Sublime Text or VS Code, and from there you can set breakpoints, modify the code in memory, and so on. The console wi…

FYI VS Code's JS debugger speaks Chrome Debugger Protocol and allows you to use the built in Debug Console just as you would the browser's debug console, also it's possible to set browser breakpoints/etc., and you get inline value hovers.

Most IDEs, for that matter!

Re: Use console.log() like a pro (2020)

#135

Post by ksenzee »

yepthatsreality wrote: post #114

> Using console.log() for JavaScript debugging is the most common practice among developers. But, there is more… Cut your debugging time, knowledge of console.log, and mental churn in half and set up your tooling to use a `debugger` statement. The console.log method may be used heavily but it’s actually a bad practice and often leaves code littered with log statements. Even for the purpose of logging itself you shoul…

Browser debuggers are amazing. I've been using them since Venkman. There's no substitute for setting a breakpoint, via the UI or a `debugger` statement, and watching your code execute a line at a time, in context. But that doesn't make console.log() a bad practice! The console is a great tool I am glad to have, especially when I remember the alternative, which was calling alert() and getting [object Object] and wanting to throw your desktop tower out the nearest window.

Re: Use console.log() like a pro (2020)

#136

Post by anyfoo »

TeMPOraL wrote: post #128
pjerem wrote: post #39

Earlier quoted context omitted.

Then, one day, after 12 hours chasing a race condition bug, you learn that when you expand objects from console.log, it shows you the current value of properties and not the values at the time of the console log. Because the values are evaluated when you click on the arrow. Then you quit web development and start a new career.

FWIW, it's not like it could work in any other way. When you console.log() an object, it just stores a pointer to the object, and decorates it with an interactive label containing some text, so that it looks nice. This is fast to do, and most of the time, it's exactly what you want. To log a static snapshot with equivalent interactive expansion capability, console.log() would have to do a general deep copy of your ob…

> To log a static snapshot with equivalent interactive expansion capability, console.log() would have to do a general deep copy of your object

Not necessarily, and if it did I don't think it would address the actual problem.

console.log could do all the presentation work upfront, right then and there when you log, and provide a collapsed view of that. This would have to include detecting and cycling handles, as it would have to do for a deep copy as you mentioned. The cost would be wasting cycles on this work even if nobody looks at its result.

But where it gets dangerous is if there's any side effects in following the object tree. If visiting for logging e.g. creates nodes, or changes them, or whatever. Arguably "you get what you ask for", but this and the performance hit for generating log output before anyone really looks at it deeply, are probably the main reason things are as they are.

Post reply on HN