Re: Standardizing console APIs: Where?

On Wed, Feb 27, 2013 at 5:07 PM, Brian Kardell <bkardell@gmail.com> wrote:
> On 26/02/2013 23:06 , Brian Kardell wrote:
>>
>> 1. Does anyone else feel like we _should_ have a standard
>
>
> I think that this thread has shown that there are interoperability issues.
> Given that this is a debugging tool, you really want it to have predictable
> behaviour so as not to waste time looking for a problem that in fact comes
> from the console API.

If I'm not mistaken, the only interoperability issue that was raised
is that the display of logging data at high frequency (using `console.log`)
has a delay which may cause it to show a newer representation of the memory slot
than was passed to `console.log`.

If there was a standard, I do not believe that it should forbid this buffering.
Doing otherwise may greatly impact performance.
Remember, this issue only happens on high frequency logging;
having the logging block for immediate string conversion
will make something that happens *very often* take a lot more time!

How much time?
In browsers, when logging an object, you can actually click on an arrow
to browse through all its properties.
Serializing the whole thing on every single console.log, when those
happen in a loop,
would make the debugging experience a nightmare, performance-wise.

That being said, the standard shouldn't forbid blocking behavior either.
If it can afford to be precise, let it be!

Right now, displaying data through `console.log` is "best effort".
In order to get better information, you should set a conditional breakpoint.

Received on Wednesday, 27 February 2013 18:19:58 UTC