What are the implementation differences between the Browser console and the NodeJS console?

Question

What are the implementation differences between the Browser console and the NodeJS console?

Navigation

#1 by (4 votes)

7

Yesterday I was using a MooTools class in NodeJS and I encountered strange behavior in console.log of NodeJS. The code works beautifully but the console does not 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);

the NodeJS console gives me

{nome: "Sérgio"}

While the Browser console gives

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

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

From this I assume that the NodeJS console does not display properties added to prototype that are not specific to the Object. That is, because fn.hasOwnProperty('dados') is false then NodeJS does not show this property.

Are there more differences between the Browser and NodeJS console.log implementation?

javascript node.js

asked by anonymous 07.04.2015 / 08:52

1 answer

Is this a good way to instantiate a modal without leaving residues in html? cakephp login never recognizes

score 4 · Accepted Answer

The console.log method is not standardized , so that each browser can implement it the way it thinks best. And in fact, by running 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 opens the console - before or after the page finishes loading)
Safari: FN
Internet Explorer: [object Object] {dados: Object {...}, nome: "Sérgio"}

A crucial difference between the handling of the browser and node.js is that the interactive while the latter is just an output to the log the shell or some file). browsers - all I've tested - allow you to click the object printed in the log and inspect its 1 structure, navigating through its various fields including its prototype. It does not 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.

Since node.js has to choose carefully what to inform, what appears in the log is all that the user will have access to, and nothing else. Assuming that an object can be part of an extended hierarchy, it does not make much sense to log all of 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 he or she wants to be displayed by logging in to either the object or some other object in its prototype chain.

For an accurate description of how node.js prints complex objects, see the console.log documentation . : it says that the first string may contain 2 format statements, or else each argument is passed to the util.inspect ". This in turn has several options, such as showHidden - that maybe to show the properties of the prototype (this option actually serves to see non-enumerable properties, which at first does not have 3 prototype, but it might help - unfortunately I do not have the node.js here to test).

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

2. These formatting instructions - also supported on several browsers , at least the desktop - are very reminiscent of printf of C. Example: console.log("Hello, %s. You've called me %d times.", "Bob", i+1); / p>

3. Unless it is not enumerable it is what is preventing the prototype from appearing ... I honestly do not know, the information on the subject seems to me a little scanty.