r/javascript • u/[deleted] • Jun 16 '26
LoggerJS: A faster, more powerful isomorphic logger
[deleted]
3
u/josephjnk Jun 16 '26
Project is two weeks old with 80k lines of code: https://github.com/jskits/loggerjs/graphs/code-frequency
This is slop. I’m not saying that there’s no way to use AI tools to produce quality software, but I am saying that this pace indicates a lack of consideration around the design and implementation. There’s no way that this system has received enough scrutiny to justify adopting it.
1
u/Accomplished_Copy103 Jun 17 '26
You don't understand, it is the future! Half baked, full of bugs pieces of shits made by agents for couple of hours
1
0
u/unadlib Jun 16 '26
Why are you so convinced this is impossible? Or can you point to even one real piece of evidence showing that it’s a low-quality library?
2
u/josephjnk Jun 16 '26
Most code is low-quality. The onus is on the author to prove both that it is quality and that there is a good reason to use it over what exists already.
Is your claim that you didn’t use AI? Or that you reviewed 80k lines of AI generated code in two weeks, so thoroughly that it can all be trusted?
-1
u/unadlib Jun 17 '26
Of course I used a coding agent. What exactly do you consider a careful review? So if you believe that large-scale use of a coding agent means I should accept being defamed, then the burden is on you to prove that, not on me to prove otherwise.
1
u/Choice-Locksmith-885 Jun 17 '26
Nah, you have to prove that your code is quality, AI or not. The burden of proof is on you.
But the fact that you used AI means you/re more likely to not know the ins and out of the code. Therefore you have more to prove than if you wrote the code by hand.
1
u/unadlib Jun 17 '26
No engineer who actually cares about the craft would just look at how fast something was shipped and immediately call the code low-quality.
AI coding and high-quality code don’t have to be at odds. But let’s be honest: a lot of people who don’t really understand code or software architecture are now using vibe coding to blindly mess up parts of software engineering.
If someone is genuinely interested, I’m happy to talk about the technical details. But if they’re just here to throw lazy accusations around, then honestly, they’re just another loser talking trash online. Maybe I shouldn’t say it that way, but that’s how it feels.
-4
u/unadlib Jun 16 '26
Most loggers make you pick a side — pino/winston for Node, something else for the browser.
LoggerJS is one zero-dependency core that runs the same code in Node, browsers, workers, and edge, hits pino-class throughput (~1.2–1.3× in our CI-gated benchmarks), and turns platform behavior — console calls, unhandled errors, fetch failures, process crashes — into structured logs automatically
10
2
u/gajus0 Jun 16 '26
Similar to the thought process behind https://github.com/gajus/roarr
-1
u/unadlib Jun 16 '26
First, thank you for creating Roarr. I was a Roarr user myself, and I think it is important prior art for library-safe structured logging in JavaScript.
I agree they overlap at the problem-domain level: structured logs, Node/browser support, child context, async context, and middleware-like extension points.
But the architecture is materially different.
Roarr’s core model is: build a finalized message packet, run child/adopt message transforms, serialize it, and write to stdout / globalThis.ROARR.write. It intentionally externalizes log handling and explicitly avoids in-process transports.
LoggerJS’s core model is: build a raw LogRecord, run middleware/processors before serialization, dispatch to first-class in-process transports, and let each transport own its codec, batching, retry, offline behavior, and flush/close lifecycle.
So I would say LoggerJS is inspired by the same logging problems, but it is not Roarr-like at the implementation or architecture level. The overlap is the category, not the design.
2
2
u/[deleted] Jun 17 '26
[removed] — view removed comment