5 ms·
One thing to watch out is that console.log is asynchronous. If the objects to be printed change between console.log() and the actual printing, the output you s
by metafunctor 5y ago
One thing to watch out is that console.log is asynchronous.
If the objects to be printed change between console.log() and the actual printing, the output you see may not represent the state when console.log() was called.
- alessioalex 5y agoVery useful advice. In those situations if you're trying to log an object just do `JSON.stringify(obj, null, 2)` to be sure of the state at that time.
- Stratoscope 5y agoconsole.log is not asynchronous. For example, this code: let a = "hello"; console.log( a ); let a = "goodbye"; will always reliably print "hello", not "goodbye". What you're referring to is the fact that when you expand an object or array in the console, then you see the contents of that object or array at the time you expand it, not as it originally existed when console.log() was called. This is why alessioalex's sibling comment is so useful. By logging the output from JSON.stringify(), you are logging a string whose value will not change.
- metafunctor 5y agoThat's... what asynchronous means. The call to console.log() will return before the console output is actually produced.
- MatthewMob 5y agoNo. It means that when you invoke `console.log` in a browser it "logs" a reference to an object instead of serialising it. This log is still synchronous, but when you expand it in the console its properties are dereferenced and may be different from when the original log was made. The log, however, is still instantaneous and synchronous.
- metafunctor 5y agoOK, agreed. That's an important distinction. The console log will synchronously receive a reference to an object; later if you expand something in the log window it shows you the current state.
- mjbrusso 5y agoI would say the argument is lazy evaluated.
- genezeta 5y agoTo add to the MatthewMob's explanation, see this: https://imgur.com/a/vUTCumu https://imgur.com/a/vUTCumu
- voiper1 5y agoThanks! I figured it meant that, but nice to see it without having to mess around.
- bouncycastle 5y agoNonsense. Console.log does not accept a callback and does not return any promise, therefore it's expected to work synchronously.
- alessioalex 5y agoyou're being ironic, right?
- bouncycastle 5y agoNope, sarcastic. If JavaScript devs don't know if a function is async or sync it just gives more evidence that JS is a monkey-language. LOL!
- metafunctor 5y agoNot a "JavaScript dev", but I think JS is a fine language. Perhaps I'm biased, because I like Scheme. The browser environment is the shitshow. A function can call a third party service, or some subsystem running on the same computer, whatever. Regardless of the programming language, that service may or may not do stuff asynchronously after your call. There's no way to tell. I regard the console.log to be a third party service. Who the heck knows what it does, except it has access to your memory!
- bouncycastle 5y agoI don't think you can compare JS to Scheme, I've heard of that meme though. Also, JS suffers from a lot of fragmentation in tooling and frameworks, so the problem is not just the language. As for a third party service argument, you're just stretching the goal posts there to fit your argument.
- metafunctor 5y agoIt's not just a meme, JS was literally inspired by Scheme (garbage collection, lexical scoping, type system) and Java (some superficial syntax) and Self (object orientation). I agree that the core language is not the worst problem with JS; that's what I was trying to say. Regarding the other point about knowing whether something is async or not. Few languages will tell you if a function does side effects. They might spawn threads or processes, mutate the data you sent them, all after the call has returned. Languages where you can easily see that this will happen are few and far between, and they have strong static type systems.
- hinkley 5y agoI spent too long on one occasion trying to figure out why my logs looked like they were in the wrong order for a NodeJS application. It was because one message was console.info and another was console.error, which was going to stderr and so getting flushed differently. A couple months ago I fell for it again.