My current assessment of Jsonic++.

Jsonic++ has moved from “promising tiny parser extracted from real tools” to something more interesting: a very small C++ JSON component with independent conformance evidence, disciplined memory testing and performance that no longer needs to be excused as the price of simplicity.

What changed my assessment

The biggest change is evidence. The independent conformance campaign now retains 810/810, and the parser fixes found there became permanent regressions rather than benchmark exceptions. Only after that correctness work did the project optimize the hot path.

The second change is performance. On the project's same-host native JSON benchmark, the current parser reached the same performance class as the conformant RapidJSON configuration while keeping Jsonic++'s much smaller API and dependency boundary. I would not generalize that into “Jsonic++ is faster than RapidJSON” across every RapidJSON mode or workload; I would say the old trade-off of “tiny and pleasant, but obviously slower” is no longer a fair description.

What I like

The strongest property is still restraint. The implementation is small enough to audit, easy to vendor, dependency-free, and now independently forced through malformed syntax, Unicode, number grammar/preservation, duplicate keys, streaming, serialization, sanitizer/RSS/Valgrind and external conformance pressure.

I also like the numeric compromise. Ordinary numbers remain cheap double-backed values, while StrNumber retains the original token when significant spelling would otherwise be lost. That is less ambitious than arbitrary-precision arithmetic, but substantially more honest than silently pretending every valid JSON number is exactly represented by binary floating point.

Where that simplicity still costs something

Jsonic++ remains a poor candidate for projects that want automatic C++ struct serialization, sophisticated adapters, arbitrary-precision arithmetic, JSON Pointer/Patch, schema integration, custom allocators, binary JSON formats or a huge package ecosystem. Those are not embarrassing missing checkboxes; they describe a different class of library.

Object lookup is deliberately linear because insertion order is preserved in a vector. That is reasonable for the configuration/metadata objects that motivated the parser, but I would not sell it as the ideal representation for enormous objects dominated by repeated random key lookup.

RapidJSON changes the comparison now

Earlier, RapidJSON's performance reputation was an obvious reason to accept its broader allocator/encoding/SAX surface. The recent benchmark means raw DOM parsing speed alone is no longer automatically decisive for the workloads Jsonic++ measures. I would choose RapidJSON when I specifically need SAX processing, allocator/encoding control, optional SIMD paths or its long-established ecosystem. For a small owned DOM where both parsers meet the required throughput, Jsonic++'s simpler surface becomes a real advantage rather than merely an aesthetic one.

What I would not claim yet

I still would not rank Jsonic++ above mature libraries on ecosystem maturity, API breadth or independent production deployment. It now has independent conformance evidence, so that caveat should no longer be phrased as though conformance is still waiting to happen. What remains is time: more external users, sustained fuzzing, more toolchains and a longer compatibility history.

Where I would choose it

I would seriously consider Jsonic++ for a native CLI, build tool, embedded developer utility or small C++ application where JSON is supporting infrastructure rather than the product—especially when a vendorable header, straightforward owned values and a tiny dependency footprint matter. The current correctness/performance balance makes that recommendation easier than it was at extraction.

Where I would choose something else

For a large application whose data layer revolves around JSON conversion, custom types and ecosystem integrations, I would start with one of the mature libraries in the comparison guide. For huge streaming or SIMD-dominated workloads, I would also benchmark specialized parsers such as simdjson rather than assuming a small DOM is the right architecture.

What would change my assessment next

Longer independent deployment history and sustained fuzzing would increase confidence further. Conversely, rapid API expansion would reduce one of the library's main advantages. The interesting success case remains “stay small while accumulating unusually strong evidence for the narrow job it claims to do”—but the recent conformance and performance work shows that staying small does not have to mean settling for weak engineering.