<story><title>Console.table()</title><url>https://developer.mozilla.org/en-US/docs/Web/API/Console/table</url></story><parent_chain><item><author>deathanatos</author><text>So much this! I&amp;#x27;ve long wanted something where by I can chain, into a sort of tree, to more easily follow or hide large subcomponents and subservices. For example, say I make two calls in my service A to two other services B and C, and all report logs to a centralized location; that could get rendered as,&lt;p&gt;&lt;pre&gt;&lt;code&gt;  ─ info: GET &amp;#x2F;foo&amp;#x2F;endpoint
    ├─ info: user &amp;lt;user ID&amp;gt; valid auth
    ├─ info: request to service B
    │  ├─ debug: opening new connection
    │  ├─ debug: success, result = ...
    │  └─ info: request took 1 seconds
    ├─ info: request to service B
    │  ├─ debug: opening new connection
    │  ├─ debug: success, result = ...
    │  └─ info: request took 1 seconds
    ├─ info: preparing result took 1 seconds
    └─ info: http request took 3 seconds
&lt;/code&gt;&lt;/pre&gt;
with the ability to hide sections, perhaps grep for only certain messages (particularly if you keep the formatting and the message separate, this should be doable, I think), attach metadata to messages…&lt;p&gt;As it is, we have a fairly standard shove everything into syslog, and then pipe to a downstream logging system and a local file. But the downstream system is not very good at search (this is probably mostly our fault) and requires the message to be in JSON, so the stuff in the log file is _also_ JSON, b&amp;#x2F;c that&amp;#x27;s what syslog got. There are definitely better ways with our existing tools, but it sure makes one dream up what the perfect logging solution &lt;i&gt;could&lt;/i&gt; look like.</text></item><item><author>azinman2</author><text>This is a great example that shows how poor most non-web debugging and logging. The ability to mix and match data types and presentation format is extremely useful. Almost everywhere else we just have printf. And that’s printf going to stdout — there isn’t a universally deployed format to even allow it to travel easily over the network and be viewed on one of many useful and advanced viewers.&lt;p&gt;I think part of the problem is that programmers rarely want to get into these supportive details; they just printf and get on with it.</text></item></parent_chain><comment><author>masklinn</author><text>&amp;gt; As it is, we have a fairly standard shove everything&lt;p&gt;Assuming &amp;quot;everything&amp;quot; is &amp;quot;static log statements&amp;quot; which is the first issue I have with this, a developer must have thought before deployment that this could be useful, which usually results in a lot of useless garbage &lt;i&gt;and&lt;/i&gt; a lack of actually useful information. And little by little you build up actually technically useful data collection, and rather than being spread throughout the codebase all of the probes are centralised and readable.&lt;p&gt;I&amp;#x27;ve been thinking about using dynamic instrumentation tools (bcc&amp;#x2F;dtrace) for that purpose instead, you know you need something when you actually &lt;i&gt;do&lt;/i&gt; need it, at that point you can add it to the probes&amp;#x2F;instrumentation (which is external to the program and deployable separately), and all information would be collected in a structured form in a database you can interact with (probably not something relational).</text></comment>
<story><title>Console.table()</title><url>https://developer.mozilla.org/en-US/docs/Web/API/Console/table</url></story><parent_chain><item><author>deathanatos</author><text>So much this! I&amp;#x27;ve long wanted something where by I can chain, into a sort of tree, to more easily follow or hide large subcomponents and subservices. For example, say I make two calls in my service A to two other services B and C, and all report logs to a centralized location; that could get rendered as,&lt;p&gt;&lt;pre&gt;&lt;code&gt;  ─ info: GET &amp;#x2F;foo&amp;#x2F;endpoint
    ├─ info: user &amp;lt;user ID&amp;gt; valid auth
    ├─ info: request to service B
    │  ├─ debug: opening new connection
    │  ├─ debug: success, result = ...
    │  └─ info: request took 1 seconds
    ├─ info: request to service B
    │  ├─ debug: opening new connection
    │  ├─ debug: success, result = ...
    │  └─ info: request took 1 seconds
    ├─ info: preparing result took 1 seconds
    └─ info: http request took 3 seconds
&lt;/code&gt;&lt;/pre&gt;
with the ability to hide sections, perhaps grep for only certain messages (particularly if you keep the formatting and the message separate, this should be doable, I think), attach metadata to messages…&lt;p&gt;As it is, we have a fairly standard shove everything into syslog, and then pipe to a downstream logging system and a local file. But the downstream system is not very good at search (this is probably mostly our fault) and requires the message to be in JSON, so the stuff in the log file is _also_ JSON, b&amp;#x2F;c that&amp;#x27;s what syslog got. There are definitely better ways with our existing tools, but it sure makes one dream up what the perfect logging solution &lt;i&gt;could&lt;/i&gt; look like.</text></item><item><author>azinman2</author><text>This is a great example that shows how poor most non-web debugging and logging. The ability to mix and match data types and presentation format is extremely useful. Almost everywhere else we just have printf. And that’s printf going to stdout — there isn’t a universally deployed format to even allow it to travel easily over the network and be viewed on one of many useful and advanced viewers.&lt;p&gt;I think part of the problem is that programmers rarely want to get into these supportive details; they just printf and get on with it.</text></item></parent_chain><comment><author>joshribakoff</author><text>Html5 timing API + chrome devtools performance tab &amp;quot;user timing&amp;quot; section is a great workflow in my opinion for frontend.</text></comment>