Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
But you remove all of the semantic meaning behind the console.error, console.warn etc. as you just console.log everything and add no useful extra information or functionality.
So the question is...why???, this is objectively worse than using native console.
Comment hidden by post author - thread only visible in this permalink
I think @inhuofficial is thinking about it in terms of a browser console or tools inside something like Electron. If you were to use your system for client-side code you effectively remove a LOT of the extras provided by the console commands.
Like the ability to filter by type. Where's the link to the filename and line of code the console was called from? You're doing the message, but you're omitting a bunch of very useful features, both client-side and server-side.
Your goofy hard to read colours aren't doing any favors if we don't know what file, function, line, and character offset in the line the report was done from!
Sorry about the "goofy' part. System colours often fail accessibility minimums, and on the whole I'm not a fan of ever-shifting colours. Thus my intense dislike for the illegible acid trip that is colour syntax highlighting. My attitude towards coloured code is basically:
🎵Hate is a strong word, but I really really really don't like you🎵
Jokes aside, without the back-reference or a backtrace or anything else to tell you where the log/warn/error came from, this is as InHu said, somewhat crippled and a step backwards from the native methods.
But what do I know? I have this in several of my codebases because I find console.error to be "incomplete and crippled"
But you remove all of the semantic meaning behind the
console.error
,console.warn
etc. as you justconsole.log
everything and add no useful extra information or functionality.So the question is...why???, this is objectively worse than using native console.
All your concerns are addressed and latest update is released. please tell me why are u overhyping console.log, console.log is just a wrapper
I think @inhuofficial is thinking about it in terms of a browser console or tools inside something like Electron. If you were to use your system for client-side code you effectively remove a LOT of the extras provided by the console commands.
Like the ability to filter by type. Where's the link to the filename and line of code the console was called from? You're doing the message, but you're omitting a bunch of very useful features, both client-side and server-side.
Your goofy hard to read colours aren't doing any favors if we don't know what file, function, line, and character offset in the line the report was done from!
Sorry about the "goofy' part. System colours often fail accessibility minimums, and on the whole I'm not a fan of ever-shifting colours. Thus my intense dislike for the illegible acid trip that is colour syntax highlighting. My attitude towards coloured code is basically:
🎵Hate is a strong word, but I really really really don't like you🎵
Jokes aside, without the back-reference or a backtrace or anything else to tell you where the log/warn/error came from, this is as InHu said, somewhat crippled and a step backwards from the native methods.
But what do I know? I have this in several of my codebases because I find console.error to be "incomplete and crippled"
Because if it's an error, that **** should stop dead in its tracks, not blindly plod on like nothing is wrong!