What are the implementation differences between the Browser.log console and Node.js?

Question

Yesterday I was using a Mootools class on Node.js and I came across strange behavior on console.log node.js. The code works great, but the console doesn’t show what I know is there.

For example doing:

function FN(nome) {
    this.nome = nome;
}
FN.prototype.dados = {
    idade: 10,
    nacionalidade: 'pt'
};
var fn = new FN('Sérgio');
console.log(fn);

Node.js console gives me:

{nome: "Sérgio"}

while the Browser console gives:

{nome: "Sérgio", dados: Object}

Confused with the result I did console.log(fn.dados); and then both showed me the expected result: {idade: 10, nacionalidade: "pt"}.

Hence I deduce that the Node.js console does not show properties added to the _prototype_ that are not proper to the Object. That is, because fn.hasOwnProperty('dados') is false then Node.js does not display this property.

There are more differences between the implementation of console.log Browser and Node.js?

Answer 1

The method console.log is not standardized, so that each browser can implement it as you see fit. And in fact, by executing your example in different browsers, I had different results:

• Firefox: Object { nome: "Sérgio" }
• Chrome and Opera: FN or FN {nome: "Sérgio", dados: Object} (depending on when console opens - before or after the page finishes loading)
• Safari: FN
• Internet Explorer: [object Object] {dados: Object {...}, nome: "Sérgio"}

A crucial difference between the treatment given in browser and in Node.js the first is interactive while the second is just an output for the log (be the shell or some file). The browsers - all that tested - allow you to click the printed object in the log and Inspecione its structure¹, navigating its various fields including its prototype. So it doesn’t matter so much what information is displayed in the string format, because if you want more information or if you want some specific information just search for it.

But Node.js needs to choose carefully what to report, because what appears in the log is all the user will have access to, and nothing else. Assuming that an object can be part of an extensive hierarchy, it does not make much sense to log all its fields including the inherited ones, as this would "pollute" the log and make it more difficult to find the relevant information. It is best to let the programmer choose whatever is shown to him by logging in or the object or some other of his prototyping chain.

For an accurate description of how Node.js prints complex objects, see the documentation of console.log: it says that the first string may contain formatting instructions², or else each argument is passed to the function util.inspect. This in turn has several options, for example showHidden - that maybe serve to show the properties of the prototype (this option actually serves to see the non enumerable properties, which in principle has no relation to the prototype³, but it might help - unfortunately I don’t have Node.js here to test).

---

_{1. It should be noted that the inspected structure is not always of the object as it was at the time it was logged in - often it only shows the object as it is at that time. Therefore, when this difference proves important, it is more guaranteed to log not the object itself but a JSON.stringify his, or similar.}

_{2. These formatting instructions - also supported in several browsers, at least those for desktop - remember much the printf of C. Example: console.log("Hello, %s. You've called me %d times.", "Bob", i+1);}

_{3. Unless it is not enumerable whatever is preventing the prototype from appearing... I honestly do not know, the information on the subject seems to me somewhat scarce.}