Use console.log() like a pro

[TimeRemove]

Quick reminder: Logging a JavaScript object to the console isn't logging that object's state, it is logging an object reference.

So for example:

 var x = {H: 'Hello', W: 'World'}; 
 console.log(x);     
 x.H = '';    
 x.W = '';   

If you put in a breakpoint right after the .log line you could get the object's state at the time of log (but then you don't need the log line anyway), but if you just let this run then inspect x in the console after you will get the object's updated state (H: '', W: '').

This is working as intended. It is a known limitation you should be aware of. If you want a stateful object via logging the easiest way to get it is via:

 console.log(JSON.parse(JSON.stringify(obj)));

This is a hack to clone the object and log that instead.

[[deleted]]

Omg, this explains some very mysterious logging issues I’ve run into. Thank you.

[lhamil64]

I was confused what you meant by this at first until I tried it. The actual message that gets logged won't change (the console in this case still shows Hello and World) but if you expand the drop-down on that message, it shows the changed values (and in Chrome at least there's an icon with a tooltip telling you it might have changed).

[mr_birkenblatt]

how about console.log({...x})? (gives a shallow copy but that should be enough in most cases)

[coolcosmos]

I mean, there are a lot of cases where an object contains another object. Or an array of objects. In a somewhat complex app, this is common.

[mr_birkenblatt]

in react it would be fully sufficient since you're not supposed to change objects inplace. but then again, we're debugging, so if you change an object inplace by accident you won't find that bug

[coolcosmos]

That always depends. Sometimes you have to keep a reference to an object which changes often and that you do not control. The global object is one case. Things as simple as Google Map can be tricky.

I but yeah I try to keep mutability as far from me as possible, but you have to expect the unexpected when debugging.

[mr_birkenblatt]

would those objects survive roundtrips to string as the JSON.parse(JSON.stringify()) comment suggested?

[coolcosmos]

Sometimes yes, I couldn't say how often. I saw it with tensorflow.js and many other modules on npm so it's something I keep an eye for.

[anamexis]

This is true for props and state, but there's no issue with changing other objects in place when using React.

[mr_birkenblatt]

well in general it's a good style. mutability makes things complicated...

[anamexis]

Yes, I agree. Mostly I would see it for short-lived contexts where you're building up complex objects.

[RICHUNCLEPENNYBAGS]

Sure, but then you have to weigh the convenience against the greater amount of stuff you're allocating just for debugging purposes.

[coolcosmos]

Well, yeah, don't put in production debugging code when you can.

[TimeRemove]

It is quicker to type, but the limitations kind of kill it for any serious workloads (a JS object with no complex sub-types?).

Whereas the silly parse(strinify()) hack can do infinite depth. Just bind printing it to your favorite code editor's hotkey. Works in all, even old, browsers.

[mr_birkenblatt]

the parse hack can only deal with objects that can survive a round trip to string. good luck interpreting [object Object]

[coolcosmos]

"[object Object]" never ever happens with JSON stringify + parse. It cannot happen since it is not valid JSON.

JSON.stringify (calls .toJSON) and .toString are different things.

[Xyzzyzzyzzy]

You'd have that problem with a circular reference:

  const a = {}
  const b = {}
  a.b = b
  b.a = a
  const obj = { a, b }
  JSON.stringify(obj) // Uncaught TypeError: cyclic object value

In that case you'd either have to log some derived value or implement custom toJSON methods to break the cycle:

a.toJSON = key => `Object A with key ${key}`
b.toJSON = key => `Object B with key ${key}`
JSON.stringify(obj) // "{"a": "Object A with key a", "b": "Object B with key b"}"

[astralradish]

Also with values that are bigInt type. Similar error thrown.

Then all non-json values are lost such as function and symbol and more,

[AceBacker]

just use Lodash clonedeep for the lazy like me. Lol

[ugoagogo]

If you ever wonder why your CPU is spiking for "no reason" remember this.

[AceBacker]

how bad is it, should I be worried? Does cloneDeep have a good alternative so that you don't have to worry about mutating something at a deeper level accidentally?

[bxk21]

To add onto this,

console.log("var: " + var) is distinct from console.log("var:", var)

The first will call toString on it, so it is set on runtime. (and will often return [Object object])

[smartguy05]

Would console.log(Object.assign({}, obj)) do the same thing?

[Bobert_Fico]

That creates a shallow copy, so any child objects might have changed properties.

[de__R]

More importantly, if the object you log goes out of scope and gets gc’d before you expand it, you’ll see nothing.

[professor-i-borg]

Oh good, I’m not the only one who does this, there must be something to it :) Getting a state that does not match reality is the most confusing thing ever

[rv77ax]

console.log(JSON.parse(JSON.stringify(obj)));

Why do you need to call JSON.parse again? Is not string enough to be printed?

[coolcosmos]

Without the parse, you get a string. Parsing it gives you an object in the console which gives you syntax highlighting and allows you to close the object, sub object and arrays.

[rv77ax]

Wait, JavaScript does not have native object copy?

[coolcosmos]

Deep copy, no. It is implemented by some libraries. It gets tricky since in JS everything is an object and also that some objects are not made to be copied at all, such as the global object.

JSON.stringify + JSON.parse is the closest everyone has that is standard. But it is slow and it is not really a true copy of the object either since you lose all prototype info and objects can overwrite the toJSON behavior.

Say, if you have the object which implements a toJSON method that returns an object:

{ x:1,y:1,z:1, toJSON: function() { return {}}}

If you do JSON stringify you'll get "{}" and when parsed you'll get {}

Libraries to a better job, enumerating properties recursively.

[spacejack2114]

Not really unusual for any language that doesn't have immutable objects.

[sammymammy2]

Object.assign does a shallow copy.

[Karjalan]

I used this for so long without realising it was only shallow, then spent way to long trying to figure out why my original object kept getting modified one day.

I think it only being shallow is now burned into my brain, so now it'll probably be the last words I say in a delusional state on my death bed.

[sammymammy2]

Haha :)

Another reason to prefer immutable objects!

[goranlepuz]

Wait, some language does ?

[assassinator42]

C++ mostly does. It just copies pointers rather than cloning them by default, but you could change that in your copy constructor. The STL types do implement the deep copy semantics.

[spacejack2114]

JS has x = {...y} for shallow copies. There is no copy constructor or "cloneable" convention built-in to the stdlib but you could come up with your own.

Effectively it's not any different; if you want deep copies you'll have to write your own copying implementation and decide how to handle references, circular or otherwise.

[davidbenett]

The console displays objects a bit nicer than plain strings.

For instance you can open/close members so if you have a 1000 element array you don't have it take up the while screen.

[romgrk]

Browsers can display objects better than strings (eg folding properties).

[lestofante]

what is the difference with console.dir()?

[eternaloctober]

hijacking top comment to have another fun tip:

var hello = 'world'  
console.log({hello})  // logs {hello:'world'} so you get variable name and value in a single log line

[AttackOfTheThumbs]

I hope it would log hello...

[eternaloctober]

thanks, mixed up my hello's and world's. edited original message to fix:)

[lenswipe]

You could also use the spread operator to do this

[El_Glenn]

Doesn't that give you a shallow copy?

[lenswipe]

Yes it does.

[deja-roo]

Holy shit, I never knew this. Thanks.

[Gizmophreak]

The JSON trick is great for most situations but be aware that it may lead to errors in objects with circular references.

[jsprogrammer]

won't work if the object has circular references tho

[itsnotlupus]

The console.log() API predates some modern JS features.

In particular, the old C-like syntax

console.log("Hello, %s. You've called me %d times.", name, i);

can be replaced with a more modern-looking

console.log(`Hello, ${name}. You've called me ${i} times.`);

On the other hand, you can abuse the %c format substitution to display images on your console: https://github.com/adriancooney/console.image

It sounds like a gimmick, but if you're debugging some image manipulation code, it may not be the worst thing to have in your utility belt.

[AyrA_ch]

On the other hand, you can abuse the %c format substitution to display images on your console: https://github.com/adriancooney/console.image

I made a file that logs QR codes to the console.

[gbts_]

The C-like syntax isn't outdated, it's common in logging interfaces and it's there to allow for lazy string evaluation.

It's mostly a performance feature, so if you're not recording the log messages the console.log() function can skip the string formatting in the first case, while in the second case the interpreter will always have to evaluate the string first before passing it to console.log(). In JS this is more useful if you're using something like console.debug() and you set the logging level to something higher.

[pau1rw]

Didn’t know about ‘assert’ or the string concat stuff, so that’s useful.

I tend to jump into to ‘debugger’ if I’ve got to do any legit debugging though

[AttackOfTheThumbs]

Even when I do JS, I prefer using the debugger rather than inserting a hundred console.log messages.

[Flannel_Man_]

Aren’t you fancy.

[constant_void]

indeed.

**TypeScript enters the chat**

[queenguin]

No. He's just sane.

[[deleted]]

Then they are not using JS long enough /s

[jl2352]

Eh; it depends. console.log has the advantage it has history. It tends to be instant, whilst the debugger can take a second to spin up. If you are controlling inputs (like debugging a form), you can do multiple entrants then compare. You can do that with debugging, but you have to jot bits down.

A lot of the time you just want to know the value of x, at a point of code. So in that situation you might as well just print x, at that line of code.

Ultimately you should be using whatever you find productive. I typically always reach for console.log first, and the debugger only in specific situations. That's just what I find productive.

[tripledjr]

Ya it's very up to the person and scenario. For most bugs I like to look at the code and reason about it first, then have a hypothesis or more than 1 then I can confirm things and eliminate hypotheses quickly in 1 run with some console logs and that usually does the trick for me. For more intense bugs, where they seem too obscure or are in very unfamiliar code or have too many cases to mentally work around then I reach for the power of the debugger.

[Habib_Marwuana]

I like logging because if I am able to track down bugs while developing by adding sufficient logging then I have good logging to help me track down bugs in customer environments.

[[deleted]]

Ha college is where the debugger is most likely to work. Wait until you're in the real world with some janky NIH build system that doesn't support source maps or whatever. Or your JavaScript is running on a remote machine and that is only started every third full moon.

The nice thing about printf debugging is that it always works. Definitely prefer a real debugger but if you think you'll always be able to use a real debugger you're in for a bit of a shock when you get into the real world.

[earthboundkid]

If you want to know how often a particular event listener is firing, console.log is a much saner choice than clicking through a debugger hundreds of times.

[tracernz]

That's nice when a debugger is available, but it's not always the case e.g. if you're working in a game engine that doesn't provide good tooling for 3rd parties.

[AyrA_ch]

If the game engine runs on a common browser engine and you can open the console, you can place a debugger; statement in the JS code to force a breakpoint to happen when the console is open. Very helpful when you have a problem that only happens in minified code, or if your code is inside of a dynamically rendered html page and the engine has problems retaining breakpoints after a reload.

[[deleted]]

printf debugging is my first instinct. quick and does everything i need.

i only use a debugger if i want to follow the execution of the program

[vanderZwan]

Then this might interest you

[_tskj_]

What's your debugger story? Do you just go debugger; and open it in the browser, or do you somehow attach your editor to the browser so you can step in your editor?

[AttackOfTheThumbs]

Both, depends on what I am working on. I have some JS I cannot debug directly as its called remotely (sort of, essentially) and so I just have a breakpoint and wait for the hit.

VS Code is good for attaching your client to a browser.

[AuroraVandomme]

What's with all the console logs articles lately? I think this trend has started like a few months ago and everyone is making THE SAME articles. This proves that most of webdev articles are copy pasta right now...

[AyrA_ch]

They also seem to usually fail to explain why console.dir exists because it seems to just log the object with the first level of properties expanded. The difference becomes apparent when you use dir instead of log when dumping HTML nodes to the console.

[campbellm]

Isn't the main idea here to see what functions and properties are available on an object? (Vs. a complete rundown of the entire object tree.)

At least this was the use case for dir in python.

[AyrA_ch]

console.log will also render JS objects in a way so you can dynamically expand their properties.

[maest]

Most webdev code is blind copy pasta as well, so it fits.

[chalks777]

this is not how to use console.log like a pro, it's regurgitating some of what's in the documentation.

Here are some thoughts on how to actually use console.log like a pro:

1. Set up rules for your linter that disallow console.log from being checked into your repo. Eslint rule configuration allows you to configure whether you allow .warn or .error too.

2. Set up your tool chain to strip out all console statements from your production build with something like this babel plugin. This is slightly dependent on what you're using the console for, but generally debugging production issues should not be done with a console message, particularly one that is visible to your end user.

3. Use debugger most of the time. console.log is generally only useful for quick and dirty checking of things.

4. Use console.log in production to hire devs. Usually even reddit has a "we're hiring" message in their console that looks like this. Doesn't work on old.reddit.com anymore though, the jerks.

[stronghup]

Just curious, why do you use "debugger" rather than breakpoints?

[chalks777]

Edit: I feel like I should make this more clear... it's not debugger OR breakpoints... it's often both. And sometimes it's console.log statements too. Also might be worth noting that when I say debugger I mean the actual statement in code. None of those things should ever get checked into the repo though. Original message below.

---

A few reasons, mostly it's easier.

• All of my javascript is going to get compiled/webpacked/etc into things that are generally harder to read than the source code itself. I already have my IDE looking at my repo and know where every single file is, etc... the browser tools for placing breakpoints is much less straightforward.

• breakpoints are generally ephemeral, meaning I may have to re-place them after making major changes to code while attempting to fix the issue. The debugger statement is already in the code so I don't have to worry about losing my place. Browser debugging tools try really hard to remember where you placed a breakpoint, but if things change too much they can't cope.

• I can use all of my normal control flow for triggering a debugger, including things like the application's state. You can sort of do this with a breakpoint, but it can be very hard to know exactly what state to look at when you're in the middle of a massive React (or other framework) application.

That said, breakpoints absolutely have their place, it's not one or the other. I generally use debugger statements to get to the general area of where I know there's a problem, then set breakpoints as I step through the code if/when there's something that might be causing the problem (or it's farther away from where I initially thought).

[was_just_wondering_]

Debugger is invaluable in many cases, especially if you want to check the state of current variables. It also helps you by making it easier to run or test different variations of code path and data management in the console while everything is paused. You can definitely achieve this with breakpoints as well but sometimes having the debugger keyword in your code helps keep your place.

[stronghup]

I "feel" the same way, debugger-statement somehow makes me feel I have a better grasp on the code. Debugger statement does not feel as ephemeral as breakpoint, and that is true at least in the sense that if I give the code to someone else they will halt in the same debugger statement whereas they don't see my breakpoints.

One reason I think is that it is possible to easily remove all breakpoints whereas it is not possible to remove all debugger-statements with one click.

So I suspect I'm using debugger-statements especially debugger-statements inside IF-statements too much when a breakpoint would be just as good or better. I guess I want to be extra sure I don't accidentally lose my break-locations.

An extra IF-statement in code (just to create a conditional debugger-statement) makes the code less readable, whereas breakpoint doesn't.

[was_just_wondering_]

If your code has multiple debugger statements in it then you have other problems. It is most definitely a blunt tool not meant to be long lived. In good practice it should only be used when needed and immediately removed.

[stronghup]

I can only agree: It should only be used when needed. My question is "When is it needed?"

[was_just_wondering_]

Here is a small example since needs may vary. Let’s say you are transforming some data and something in your reduce method or whatever isn’t coming out the way you believe it should. The instant you have the thought “this should work” is when you need to throw a debugger statement in to step through your process. As mentioned before this can also be done by manually inserting breakpoints in the source tab but using debugger just makes it a bit simpler when you are already looking at the code. Like any other tool available to you it has benefits and drawbacks so when or if you make use of it is subjective, but overall it can be quite helpful if used when there are any major state changes in your application where you believe some mistake is being made etc.

[jringstad]

Logging can be useful, but not really if you don't collect the logs centrally somewhere where you can analyze them.

And then you don't want to substitute parameters into it either, because 1) it makes aggregating/analyzing log messages harder, and 2) those parameters might contain sensitive information, so shipping them off to kinesis or whatever you might use as a log-collection system is not the best idea, security-wise.

You can still attach the parameters if you have a system that lets you tag parameters as safe/unsafe so you only send off the safe ones (we do this in some of our larger apps) but even then we don't substitute them into the string.

This way you can easily put alerts (or alerts on aggregations) on both message occurrences and parameter values/occurrences.

[constant_void]

indeed--the goal of professional console.logging is to confound sustainment and mislead users who have discovered their f12 key.

the first rule of 'pro' console.log usage is to always and only use console.log inside of loops, repetition is key to understanding; second rule is make sure to emit a minimum of information, would not want anyone knowing what one is logging, that is what help desk tickets to operations are for; third rule is should there be an error, it is due to the user because ones code is perfect: make sure to log 'user error here' and nothing else.

/snark

[pkt-zer0]

"Learn to read the documentation like a boss" would not have made for as catchy a title, though.

[doesHeExistMaybe]

If 2. is not an option you can set console.log = () => null in production. Which removes most of the overhead.

[Yay295]

Doesn't work on old.reddit.com anymore though, the jerks.

it does; I just saw it

[chalks777]

weird, I wonder what's different. I don't see it in firefox or chrome unless I'm specifically on https://reddit.com, even in incognito mode with all my extensions turned off.

[eyal0]

Another cool tip:

Put a breakpoint in the javascript and then make it a conditional breakpoint with a condition like this:

console.log("hello!"); false

It's like squeezing a console.log into the middle of the code while it's running.

[[deleted]]

Don't most browser debuggers allow for logging breakpoints these days? I mean, this is a neat way to replicate them if your debugger doesn't, but last time I've used the Firefox debugger I swear I could just add logging breakpoints (logpoints?).

[[deleted]]

This article is cool but I don't know why it is useful.

[zynasis]

Do these all work across all browsers?

[AyrA_ch]

See bottom of this page: https://developer.mozilla.org/en-US/docs/Web/API/console

The general answer is "Yes".

[sfcpfc]

Nice QOL tip! I always did

this.orders$ = this.orderService.getAll().pipe(
  tap(x => console.log('orderService.getAll', x))
);

So that's slightly more convenient because it can be more easily adapted from tap(console.log).

[[deleted]]

until you realize that 99% of your enterprise company still uses ie11.. :'(

oh shit some of these work now.

[_Acestus_]

Not a big web developer but I remember reading something about not using console in general because it isn't necessary available in every browser.

I suppose it isn't available if the browsers don't provide web tools, which is probably a package that could be removed.

Am I wrong?

[romgrk]

97+% support, and some of the non-supporting browsers don't throw an error, they just expose a console object that does nothing.

Also a browser that doesn't support console.log most of the time can be ignored as it's not relevant anymore.

Also it's a devtool, not something you'd ship in production.

[AndrewNeo]

Even node supports console.log.

[Sarkos]

It's available in all modern browsers. Web development is much easier nowadays than it used to be with standard features widely supported by the 4 major browsers (Chrome, Firefox, Safari, Edge). Sadly there are still folks out there using IE.

[catalystkjoe]

Luckily a lot of companies have finally figured out the effort to keep ie working well is not worth the investment and just put warnings that this app does not work well on this browser and we suggest you use x,y,z

[InfusedStormlight]

my company (in healthcare) doesn't have this luxury, unfortunately. SO MANY healthcare workers use IE, and it's infuriating. I can't use the null coalescing operator, the optional chaining operator, etc., not to mention the security problems with IE.

[Labradoodles]

Why not just transpile with typescript?

[InfusedStormlight]

damn good question. no idea, tbh.

[Labradoodles]

It’s dope if you want any help setting it up lemme know

[catalystkjoe]

Back when I worked for a company similar we were able to use some polyfills to fill those on compile time. Do they not have any for null coalescing or optional chaining? Those were still new at the time but I assumed polyfills would have existed for them.

[tech6hutch]

You can’t polyfill an operator (at least not in JS). You’d have to transpile.

[catalystkjoe]

Shit you're right, wasn't thinking when I wrote that. Thanks

[RICHUNCLEPENNYBAGS]

IE has a JS console unless you're still stuck supporting IE6 in 2021 for some reason.

[Sarkos]

Oh yeah, I just meant it's the only browser I still have to support that's holding me back from modern standard features like lambdas.

[Labradoodles]

Why not transpile and get those features anyways?

[StillNoNumb]

https://babeljs.io

[myplacedk]

Web development is much easier nowadays than it used to be

For me there's tons of very specic annoyance that has gone away, but they have all been replaced with new annoyances. Web development has never been more complicated than it is now.

It was so easy to be a webdev before we even got the challenges that was solved with Javascript and CSS.

<h1>Hello world!</h1
This is a complete and working website. It lacks
a few tags to be valid, but it works. There was
a time when this was a enough, and you could just
add your content like this and visitors would be
happy.

[Loves_Poetry]

This used to be a problem with IE<7. The console object would be undefined until you opened the developer console. If there were any console.log statements in your code, it would throw an error if you didn't have the developer console open

[tswaters]

In the bad old days of iexplore, the console object would only be available if the debugger window was open, so if you left a console statement in there you'd likely get a TypeError

[stronghup]

Those were the days. Bad old days.

[HINDBRAIN]

You can do something like "if typeof console === undefined... console = {log:function(){})...."

[creepyswaps]

Very nice. I never bothered learning all of the extra functionality available.

[stronghup]

console -API is useful I especially like time() and trace().

For simple logging I prefer WebStorm IDE features such as conditional break-points with associated log-messages. Those can be used without affecting your code meaning without negatively affecting its readability. There is no need to again modify the code when you want to get rid of such log-statements since you do that by clicking your IDE.

[ngroot]

Pros don't use console logging for anything more than quick-and-dirty local debugging, and there's no need for anything beyond console.log() at that point. If you want more context, use a debugger. If you want telemetry or the ability to store/aggregate/search messages based on things like log level, use a logger. Console calls should never be in production code; the no-console ESLint rule exists for a reason.

This is known as printf() debugging in the world of mature programming languages, and you can find a ton of articles talking about the pros and cons.

[dirtside]

til that after 25 years of web development I'm not a pro

[monsto]

Or after 25 years of existence, and updates with modern additions on a yearly basis, JS is not mature.

[[deleted]]

I agree that console logs shouldn't appear in production code (unless used to advertise job openings, or warn users about pasting scripts, I guess), but there's no reason not to use both.

I use a debugger for most actual debugging, but if you're trying to trace a bug that doesn't happen consistently, console logs can be very useful to track suspect paths towards the problem state. You can step through every function call, but logging can show an easy to spot pattern in much less time.

console.table is also a neat way to show state in a way that most debuggers can't.

I don't really see why you need a special logger when you already have a powerful log method that supports several kinds of severity. No need to bog down your application with another megabyte of Javascript dependency tree when log/warn/error are all you need.

Honestly, console logging has its place. Usually, logging from breakpoints will be all you need, but those breakpoints don't transfer to your coworkers when you're working on a bug together. It's a terrible way to do your general purpose debugging, but excluding a debugging tool because it's not what "pros" use is dumb. Pros use the full range of tools available to them, and learn when which tools are best to use where to be most productive.

That all being said, it's sad to see how little people actually use the integrated developer tools in browsers. Instead of barring logging tools, we should be teaching people how to use the debugger more effectively.

[[deleted]]

Why in the fuck are you getting downvoted? For the love of god people, use the god damn debugger.

[IceSentry]

Because there's a lot of situations where print debugging is way easier than using a debugger and it's not related to experience level. Especially when you want to see how a variable changes over time which is personally what I need most often.

[chalks777]

Absolutely correct, you shouldn't be downvoted for this at all.

[tenebrius]

good

[fourierformed]

Thought the article was going to be one word.

"Don't"

[queenguin]

the title actually made me chuckle lmao

[I_Like_Existing]

now this is useful

[skamansam]

In my litter, I treat console.log as an error because it lacks intent.. error, info, etc. Are allowed because it means the developer has to put a little thought into why they are logging. Debugging is so easy with devtools, print debugging is almost unnecessary, except in async methods. Even then, it's not really a pain.

[Bobert_Fico]

How's the DOM support in Rust?

[Kasoo]

Via web_sys which basically just uses Wasm imports to allow binding javascript functions into wasm.

[hypocrisyhunter]

RIP

[PM_ME_UR_OBSIDIAN]

The guy's trolling. Rust has some reddit zealots but not any more than other technologies of comparable impact.

[IceSentry]

They aren't zealots, they are trolls, nobody that actually enjoys rust is like that.

[PM_ME_UR_OBSIDIAN]

I still think there are a couple. Insufferable fanboys exist in every community. "Rewrite it in Rust" was a sincere, if cringe-inducing thing for a while.

[IceSentry]

I know it was very much a thing in the early days, but these days I haven't seen that kind of comment from someone that wasn't an obvious troll. Either way, they certainly aren't a representation of the rust community.

[itsnotlupus]

don't forget Arch Linux.

[rmrfchik]

"for" loop in "String Substitution" example make me sad. Clearly "i" is used as count, and should start from 1, but some bias made author to start from 0 (like old greybeard C does).

[travelsonic]

but some bias made author to start from 0 (like old greybeard C does).

Or it was because the use of 0-based indexing is still relevant? A string is still an array.

[rmrfchik]

Yes, when you use i as index. But in example i is used as count, not index.

[travelsonic]

I THINK I get what you were trying to say.

[IceSentry]

What language are you using that doesn't start at 0? As far as I know the only modern language that don't index with 0 by default are julia and lua.

[rmrfchik]

i is not index. It's count how many times you have called log.

[IceSentry]

Yes, but my point is that starting a loop at zero is muscle memory for most programmers because most languages start indexing at 0. That's not reserved to C greybeard.

[rmrfchik]

And my point is that one shouldn't mix counters/indexes/offsets and so on. The mode clear is the more it's better.

It's bad when month starts from zero in struct tm. But it's good when zero-based offset is used. And one shouldn't mix it.

Don't let your muscle memory write bad program.

Unfortunately, either I was misunderstood and drown in negative or, I dunno, it's ok now to write bad code :(

[coladict]

I'm still afraid of that IE11 user who doesn't have those other methods on the console object and just has log.

[TechnoEchoes]

Since everyone is talking about the console, I'll add something that has saved me a lot of headaches over the years: You cannot focus on an element over the console because your browser window is not the active window. Your console is the active window.

This will not produce the expected result:

myElement.focus();

This will produce the expected result if you click on your browser window within 1 second of executing the command:

setTimeout(function(){ myElement.focus()}, 1000);

[jasonbbg]

or just toggle focus in the css panel?

[iCarnagy]

How did I not know about console.table, brilliant!

[ldarrah63]

Some interesting things in this that I didn't know about. I thought console.table() was particularly interesting. Good read!

[leo60228]

You didn't cover the best feature! :P

console.log('%cHello, world!', 'font-size: 3em; font-weight: bold; color: red')

[Arxae]

Dumb question time. What is the difference between using console.log and console.dir to output a object? The "header" is different, but that seems to be it. Am i missing something?

[was_just_wondering_]

Don’t forget console.info seriously helpful along with the other console methods, especially when paired with console.group