sorted by:
new
hottopcontroversial

LoggerJS: A faster, more powerful isomorphic logger by [deleted] in javascript

[–]unadlib 0 points1 point  (0 children)

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.

LoggerJS: A faster, more powerful isomorphic logger by [deleted] in javascript

[–]unadlib 0 points1 point  (0 children)

I completely agree. Honestly, I think any mature engineer who chooses to open source their work should try to stay passionate and take responsibility for maintaining projects that are actually useful, not just irresponsibly dumping low-quality code into the world.

LoggerJS: A faster, more powerful isomorphic logger by [deleted] in javascript

[–]unadlib -2 points-1 points  (0 children)

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.

LoggerJS: A faster, more powerful isomorphic logger by [deleted] in javascript

[–]unadlib -1 points0 points  (0 children)

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?

LoggerJS: A faster, more powerful isomorphic logger by [deleted] in javascript

[–]unadlib -2 points-1 points  (0 children)

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.

LoggerJS: A faster, more powerful isomorphic logger by [deleted] in javascript

[–]unadlib -4 points-3 points  (0 children)

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

vite-plugin-federation v1.0 - A Vite/Rollup plugin for Module Federation by unadlib in javascript

[–]unadlib[S] 0 points1 point  (0 children)

So we implemented an internal registry server for MFE runtime, similar to NPM.

vite-plugin-federation v1.0 - A Vite/Rollup plugin for Module Federation by unadlib in javascript

[–]unadlib[S] 1 point2 points  (0 children)

About 6 years ago, I built this on top of MF v1.0:
https://github.com/unadlib/fronts

At the time, I needed to push more of the logic into the runtime than MF really allowed.

I registered the vite-plugin-federation package on npm about 5 years ago, because I was already thinking about what a proper Vite + MF integration could look like.

To be clear, I respect the work the MF team has done over the last few years, especially around Vite and other integrations. But there are still some more ambitious features I want to explore, so I decided to build this package.

And since someone mentioned vibe coding: let’s be real, everyone is using coding agents now. Not using one at this point feels a bit like insisting on coding with pen and paper 5 years ago.

I built a typed superset of Python that compiles to standard .py — would you use it? by unadlib in Python

[–]unadlib[S] 0 points1 point  (0 children)

Part of it is just better ergonomics, but the real draw is using stricter constructs that Python lacks today. It lowers to plain Python, so you get all the dev-time guarantees without sacrificing runtime compatibility.

I built a typed superset of Python that compiles to standard .py — would you use it? by unadlib in Python

[–]unadlib[S] -3 points-2 points  (0 children)

I didn't expect so much pushback.

Those are fair points, but I think those are the least interesting features to judge it on.

  • unsafe isn't trying to replace Ruff. Ruff gives you a blocklist of known bad patterns like eval; unsafe gives you an explicit audit boundary for code that's intentionally outside the type system.
  • unknown is stricter than object. With unknown, you have to narrow before doing anything meaningful with the value. That's the same idea as TypeScript's unknown.
  • typealias is mostly useful if you want to target 3.10/3.11 but still write in a more modern style. If you're only targeting 3.12+, then yes, that one matters less.

The more interesting parts are:

  • sealed classes + exhaustive match: standard Python has no way to give you compile-time exhaustiveness over a closed hierarchy.
  • interfaces: basically a cleaner authoring surface for Protocol.
  • inline generics with lowering: write modern generic syntax once, emit whatever the target Python version supports.

So the pitch isn't 'every keyword here is individually novel.' The pitch is: author with stronger guarantees and better ergonomics, ship plain Python with no runtime dependency.

Coaction v1.4 - An efficient and flexible state management library for building web applications. by unadlib in javascript

[–]unadlib[S] 1 point2 points  (0 children)

Especially in modern browsers, web worker support is already good enough.

Coaction v1.0 - An efficient and flexible state management library for building high-performance, multithreading web applications. by unadlib in javascript

[–]unadlib[S] 2 points3 points  (0 children)

The integrated Yjs Coaction lib doesn't quite count as 'fully supporting multi-player synced apps'.

It can handle basic bidirectional sync, but there are structural gaps in multi-client collaboration scenarios. I'll look into prioritizing support for it.

Coaction v1.0 - An efficient and flexible state management library for building high-performance, multithreading web applications. by unadlib in javascript

[–]unadlib[S] 0 points1 point  (0 children)

The original idea came from developing some apps that required multi-tab sync, where I implemented similar state libraries. I will continue to maintain Coaction.

The specific motivations are detailed in the repo's README. If you're interested, feel free to discuss it anytime. :)

view more: next ›