Hello friends!
Welcome to this week’s Sloth Bytes.
Happy holidays to all of you 😁
Sorry for missing last week, I celebrated a bit too early…
🦥 No selling out today
I am genuinely considering selling feet pics, so if you work at a company with a marketing budget please forward this to your boss immediately or the feet come out.
Sloths at top speed can cover only 1 meter in 1.5 seconds
That is only 1.5 miles per hour… yeah they’re really slow.
Beyond Console.log()
A lot of you love using console.log (me included), but let me show you better ways to debug that will save you hours of development time.
The Console Object
For those of you that know JavaScript, you should’ve noticed console is an object and .log is only ONE method from the console object. There’s actually a lot of methods in the console object that will save you so much time.
1. Console.table()
// 1. console.table() for Arrays & Objects
const users = [
{ name: 'Alice', age: 25 },
{ name: 'Bob', age: 30 }
];
console.table(users);2. Console.group()
// 2. console.group() for Nested Data
console.group('User Details');
console.log('Name:', user.name);
console.log('Age:', user.age);
console.groupEnd();3. Debugger statement
The debugger; statement asks an attached JavaScript debugger to pause at that point. In a browser with DevTools open, it behaves like a programmatic breakpoint; without an active debugger, execution normally just continues.
function calculateTotal() {
// This keyword makes the browser pause here
// Think of this as adding a breakpoint
debugger;
return items.reduce((sum, item) => sum + item.price, 0);
}4. Other Console Methods You Should Know
console.warn()— visually distinguish warningsconsole.error()— report error-level diagnostic outputconsole.trace()— print a stack trace from the current call siteconsole.time(label)+console.timeEnd(label)— quick wall-clock timing for a labeled regionconsole.assert(condition, ...)— log a message when a condition is false in supporting consoles; unlike a language/runtime assertion, it generally does not halt your program or replace real validation
5. Use the Sources Debugger
Browser DevTools lets you pause without editing your code at all. Add a line breakpoint in the Sources panel, reproduce the bug, then inspect:
Scope/local variables — what values exist at this exact moment?
Call stack — how did execution get here?
Watch expressions — how does a specific expression change as you step?
Conditional breakpoints — pause only when a condition is true, which is great for “this breaks on user #8,431” bugs.
Event/exception breakpoints — pause when a DOM event fires or an exception is thrown/caught.
Step over, step into, and step out are much cleaner than scattering 47 logs through a complicated call chain.
6. The Network Panel Is Basically an API Lie Detector
If the UI says “nothing happened,” check what the browser actually sent. The Network panel shows request URL/method, status, timing, headers, payload, response, caching, redirects, and failures.
That helps separate frontend bugs from API/auth/CORS/cache/server bugs. A button can look broken when the real problem is a 401 response, a stale cached payload, or a request that never fired.
Be careful when sharing screenshots/HAR files: headers, cookies, query strings, request bodies, and responses can contain credentials or personal data.
7. Source Maps Explain Why Your Stack Trace Looks Alien
Bundlers/transpilers can turn your readable TypeScript/JSX/source files into very different JavaScript. Source maps let DevTools map generated code back to the original source so breakpoints and stack traces are useful.
For production debugging, decide deliberately whether/how source maps are published. They improve diagnostics, but you may not want to expose every original source artifact publicly; many teams upload maps privately to error-monitoring systems instead.
8. Performance Problems Need Performance Tools
If the bug is “the page freezes for 600 ms,” more console logs may actually make measurement noisier. Use the browser Performance panel/profiler to inspect long tasks, JavaScript execution, rendering/layout/paint work, and frame timing.
Measure a representative workload before optimizing. “This function looks expensive” is not a profiler result.
Practical Example
A lot of you have probably done something like this:
const data = [
{ id: 1, name: "sloth"},
{ id: 2, name: "sloth2"},
{id: 3, name: "you smell"},
];
console.log(data)You'll get something ugly like this:
If your object has a lot of information, it could get pretty difficult to read.
HOWEVER…
Now that you know about console.table(), you can do this instead:
console.table(data);Look at the difference:
Way easier to read right?
So yes, use console.log() when it is the fastest tool. But once the problem involves control flow, timing, requests, generated code, or performance, graduate to breakpoints, Network, source maps, and profilers instead of turning your console into a novel.
And never treat the browser console as a safe place for production secrets. Tokens, passwords, sensitive user data, and private request bodies do not become harmless because the log statement says “debug.”
If you want to keep learning
Debugging techniques every developer should know — the broader workflow for reproducing, isolating, and fixing bugs.
Error handling explained — how to design failures and exceptions once you understand what went wrong.
Code profiling explained — use CPU and memory profilers when the bug is really a performance problem wearing a fake mustache.
Thank you to everyone who submitted 😃
RelyingEarth87, edoardo-albanese, Bai756, wahwha, JamesHarryT, trgr-boi, Yoshlix, Jk-frontEnd, tobiaoy, and MustySix66.
No challenge today… It’s the holidays have some fun.
Video is coming very soon!
I been slacking a bit, but this new video is almost ready. I’ll probably have it ready by the end of this week.
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week and happy holidays 😁
