// the take
LJSON extends JSON so it can serialize and deserialize pure JavaScript functions, not just data, by capturing a function's source and re-parsing it into a real closure on the other end. It's aimed at a narrow use case: sending small pieces of executable logic between client and server (e.g. user-authored game scripts) without reaching for eval or building a full sandboxed DSL.
The core idea is genuinely clever: it sidesteps the sandboxing problem rather than solving it, by restricting what functions are allowed to express (no primitives at all) instead of trying to contain what they can do. withLib/withStdLib give you real capability-based control - a parsed function literally cannot call anything beyond what you've injected into its environment, which is a meaningful security property, not just sugar. The codebase is tiny (LJSON.js plus a standalone parser, parsenhora.js), zero dependencies, readable in one sitting.
No commits since 2017 - this is frozen reference code, not a maintained library, and anyone adopting it inherits whatever JS-engine or Node-version quirks existed nine years ago with zero chance of a fix. "Purity" is a convention enforced by the author's discipline, not by the tool: there's no static analysis stopping a function from closing over a mutable outer variable, so the safety claim rests on code review, not on LJSON itself. The whole pitch is running untrusted code safely, yet there's no security audit, no CVE history, no fuzzing - exactly the kind of claim that needs independent verification before anyone trusts it with real user input. Serialization works by extracting function source via toString() and re-parsing it, which is brittle against minifiers, transpilers, and any JS syntax introduced after 2017 - it won't survive a modern bundler untouched.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →