Been Too Long

Wowie it’s been a long while since my last one of these. Too long really. It’s funny too as I looked back and the beginning of my last article was also about how it’s been too long. This time for real though it has been too long.

I won’t ramble too much, my lack of posting articles is a story for a different day. I’ve been having a good time though, just super busy and a bit stalled up as I figure things out for myself. ChompChomp hasn’t left my mind, but when I play games I’m just blown away, and it makes me want to be even more ambitious with what I create. I have an awesome idea for a game that I think will be a lot of fun, but I also don’t really know where to get started on it. More to come on that.

I know I talked a bit about the whole computer thing before, and the TLDR was that the issue stemmed from power. I think the outlets are connected behind the walls, and it took a while to realize that. I still took the opportunity to upgrade though, and am now writing this from my new beast of a setup. Yeah we’re talking 4090, 64gb ram, 14900k, 6 consoles, 10 computers, bunch of mf wires… ( legendary clip).

Anyway let’s dive into today’s subject!

console.log’s true power

Developer’s tools for debugging are a true swiss army knife, we often find new useful tools, expand on tools we already knew of and more. Well today we’re going to take a look at arguably the most fundamental tool available to developers. I can’t imagine a day of coding where I didn’t log something.

We’ll examine some built-in ways of making logging awesome, as well as a couple external libs I like to use and some personal strategies. For now the topic will be just browsers but maybe in the future I’ll do a similar article for server-side logging.

I’m also going to focus on JS/TS, as that’s the world where I live, but I’m sure a lot of these concepts can be applied to other languages as well.

One other thing --- I’m going to put things into a tierlist sort of format, because why not. The tiers will be my personal opinion, so take em with a grain of salt. Perhaps you’ll find much more use out of things! Our tiers will be as follows:

S
The goats, anything in this tier is nearly perfect, and almost always provides value when used.

A
Great methods, but not quite perfect.

The Rest
There aren’t a ton of methods, so I’ll be mostly highlighting the great ones, and the rest will be down here. These methods have their use but are either too niche or just not that great.

Browser

console.log, calls a method called “log.” That’s right, it’s a method! That method is on the class Console. Maybe you see where I’m going with this but, what if I told you that there are other methods

S Tier (🐐)

console.log

This one is probably obvious, but console.log is the goat. It’s no accident that console.log is the way it is, and is used extremely often. Anything you put into those parentheses will show up in the console. It’s that simple, and for that reason extremely powerful. console.log needs no setup, no precise usage, has no limit on number of arguments passed to it, and is always available wherever JS is

Usage

console.log('Whatever', ['tf'], { you: 'want' }, 1, 2, 3);

hidden techniques

But we know that already, so let’s take a look at some of it’s secret powers in the browser.

String Substitution This is something that exists in other languages, but is super slept on in the world of JS, especially in the browser. String substitution is both simple & powerful. In short, there are specific character sequences that when present in a logged string, will change the output of said string in the console. Let’s check em out. There are a handful of different string substitutions, but they’re pretty niche, except for this one… Check out the docs here for the full list.

%c With this substitution you can apply CSS to the string that follows it. Yes, you read that correctly.

For example:

console.log(
  '%c      Devil Daggers',
  'font-size: 38px;font-weight:bold;line-height:3; text-transform: uppercase; text-shadow: -4px 4px #ef3550, -8px 8px #d73048, -12px 12px #bf2a40, -16px 16px #a72538, -20px 20px #8f2030, -24px 24px #781b28, -28px 28px #601520, -32px 32px #481018, -36px 36px #300b10;'
);

Will show up in the console like this, as copyable text:

Which is pretty neat! It may seem a bit silly, but it also has it’s uses, like making specific logs stand out. One great example of that is actually in discord’s devtools console! Upon opening the console you’ll be hit with this:

One last thing about %c that’s interesting is that in chrome, you can actually console.log entire images 💀, I couldn’t get it to show in Edge or Arc, and I’m not downloading chrome just to try that, but regardless it’s a cool feature with arguable usefulness. I’d say if you do use it, don’t spam it as I can imagine it’s not the best for performance.

Reference Shorthand You can make a short reference to console.log!

const l = console.log;

l('Hello'); // Is the same as console.log('Hello')!

This is a simple trick but it can be useful at times, especially when you’re logging a lot of things like pseudo-breakpoints (we’ll get into that later). One thing to keep in mind is that this is definitely not best practice, and should be used sparingly. It can make your code harder to read, and can be confusing to others, imagine the confusion it could cause ()

For brevity, I’ll be going into a bit less detail on the other methods otherwise I’d never finish writing there’ll be more details in the Tips & Tricks section anyway!

console.table

If you’ve ever worked with a lot of data at once, and have used console.log to log that data, you know how much of a pain it can be to read. It works but can be annoying to expand and collapse things. console.table’s your guy. Let’s say you’ve got 20 or so objects of user data modeled like this:

const person = {
  firstName: 'John',
  lastName: 'Doe',
  jobArea: 'IT',
  email: 'foo@mail.com'
};

Console logged you get this:

Which is fine, but it becomes less “fine” the more data you have, especially since after 100 it gets split into different logs. Now check this out with console.table:

Not only is it an easy-to-view table, but you’ve also got the normal expandable version at the bottom. You can also sort each column by clicking the column name. Note that this only works with tabular data which is just arrays or objects. Anything nested won’t be fully shown. Still very useful!

console.group / console.groupCollapsed / console.groupEnd

Our final S-tier entry is the console.group crew. These methods allow you to group your logs together, and collapse them. This is incredibly helpful for keeping things organized.

The syntax for it is really nice and simple as well, here’s an example:

console.group('Group Name: Devil Daggers');

console.log('Devil');
console.log('Daggers');
console.log('Gigapede');

console.groupEnd();

console.log('Some other thing');

Anything under the initial console.group will be grouped together in the console, the group ends when console.groupEnd is called. console.groupCollapsed is the same as console.group but the group is collapsed by default.

A Tier

console.time / console.timeLog / console.timeEnd

This one is pretty straightforward and while it may not be used everywhere it’s quite nice when you do need it, or are just curious about the timing of something. The way it’s used is quite similar to console.group:

async function sleep(ms: number) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function main() {
  console.time('It took'); // Start the timing
  await sleep(1000);
  console.timeLog('It took'); // Timestamp
  await sleep(2000);
  console.timeEnd('It took'); // End the timing
}

main();

Has the output:

Couple things to keep in mind when using this:

• The name of the timer must be the same for all three methods. If it’s not, it won’t work.
• You can have multiple timers running at once, but they must have unique names.
• Don’t forget to end your timers, as they can be a performance hit if left running.

Also unrelated but console.time isn’t the only way to time things in JS, you can also use performance.now(). The differences are pretty minimal and don’t matter too much.

Here’s a quick example of how you could use performance.now():

const start = performance.now();
doSomethingThatTakesTime();
const end = performance.now();
console.log(`Call to doSomethingThatTakesTime took ${start - end} milliseconds.`);

console.warn / console.error

I’m putting these together as they’re almost the same.

console.warn will log whatever’s in it to the console in the built-in warning style, and console.error will log it in the error style. They’re useful for when you want to make sure something stand out, or if you want to make sure you’re not missing something important. I personally use em for debugging purposes, like an if-statement that shouldn’t be reached will log a warning. I most commonly use console.error in catch blocks, so instead of throwing the error & exiting the program, it’s logged as an error and the program continues.

console.warn('Devil');
console.error('Daggers');

The small arrow to the left of the log is clickable and will show you the stack trace of the log, meaning you can see where the log was called from.

The Rest, those that are just mid

I’m going to just do a quick list of the potentially useful ones with brief explanations as they’re not super important imo, but check out all the methods if you’re interested!.

console.assert

This one is pretty simple, it’s like an if-statement but for logging. It’s like a mini-test, you give it an expression (like what you’d put in an if-statement) and if it evaluates to a falsy value, it logs an error with the message you give it. It’s useful for checking if something is as you expect it to be.

console.assert(3 === 4, '3 is not 4');

This sounds useful, but I find it to be in a sort of ‘limbo.’ For simpler things, throughout my code I’ll be using console.warn anyway, and if I’m going to get complicated I’ll be using a proper testing library. That said I can see it being useful for quick checks on-the-fly.

console.count / console.countReset

Kind of like console.time, but for counting. Every time you call it, it will increment a counter, and log it with the label you give it (label not needed, in which case it will use “default”). You can also reset the counter with console.countReset.

console.count('Devil'); // Will log "Devil: 1"
console.count('Devil'); // Will log "Devil: 2"
console.count('Daggers'); // Will log "Daggers: 1"
console.countReset('Devil'); // Will reset the counter for "Devil"

I can see this being useful in niche cases, but most of the time you’re probably also going to be logging something else, in which case you’ll probably just use console.log. Also console.log will show a count if you log the same thing multiple times, which is also cleaner:

Ok! That’s about it for the methods I think are worth mentioning. There are a couple more methods, but they’re pretty niche and I don’t think they’re worth writing about. If you’re interested in them, check out the MDN docs.

Tips & Tricks

Here are a collection of random tips and tricks that I’ve picked up over time!

Pseudo-Breakpoints

I’m sure most people reading this already do this but it’s worth mentioning.

Breakpoints are great, but pausing execution & stepping through code can be a bit time consuming and take some playing around with to get used to. If you just want to check the value of a variable at a certain point, or where execution stops, you can use console.log to see what’s up.

try {
  const someCall = await fetch('https://thing.com/data');
  if (someCall.ok) {
    console.log('SomeCall went through');
    const theData = await someCall.json();
    console.log(theData);
  } else {
    console.log('SomeCall is not ok!');
  }
} catch (e) {
  console.error(e); // This will log the error and continue execution!
}

And from this you can see what’s going on at each point in the code by seeing what’s logged and what’s not. You could even use emoji as a quick way of making things stand out, or use console.warn or console.error to make sure you don’t miss anything.

It also takes 30 seconds to set up as opposed to a minute or two to set up breakpoints, step, examine variables, etc… It’s even faster server-side where you’d need a local debugger and more setup for breakpoints, but we’re talking browser today.

Clearing the console

While focused on the console, you can hit

to clear the console. You can also programmatically clear it by calling console.clear().

Goto Source

On the right of every log is a file_name:line_number, which on top of being where the log originated from is clickable!

Settings / Options

There are actually settings and a few options available in the console.

Sidebar

This one I found out while writing this, but the console actually has a sidebar which seems to nicely organize logs, their sources, and levels. Pretty neat!

I could definitely see this being useful for larger projects.

Log Source

You can choose the source of logs, to choose what running program you want to check the logs of. Like extensions:

Which isn’t the most useful thing, but good to know.

Filter

You can also filter logs by typing in the filter box, which is essentially a searchbar for your logs.

Log Level

You can also change the log level, which is fantastic at times to either show or hide logs of a certain level, which you can utilize with console.log, console.warn, and console.error, as well as console.info & console.debug:

console.info & console.debug I find to be a bit redundant which is why I didn’t mention them. Also console.debug will only show up if Verbose is enabled, and that sometimes shows other unwanted stuff as well.

Issues

The “Issues” tab contains useful browser warnings and errors, like accessibility issues, performance issues, and more.

Settings

There are also settings available in the console, which you can access by clicking the gear icon in the top right of the console.

Which are pretty self-explanatory, for the most part. They’re explained in detail here!

Wrap-up

Phew! That was a lot of info! And fun to write honestly. I hope to get back into writing more often as I do miss it, I’ve just been sucked into things.

Anyway I hope you learned something new, or at least found something interesting. I know I learned about a couple useful features in writing this, and I’m sure there are even more cool things out there. Perhaps I’ll write a follow-up article on server-side logging in the future as while there’s a lot of overlap, there are some big differences too!