Small surface, stronger evidence, still a conservative claim.

Jsonic++ is used inside Nift and Minify++, passes its independent 810-case conformance gate, has a completed standalone lifetime gate, and now has same-host performance evidence against mature parsers. The independent project is still young, so those facts should strengthen the assessment without erasing the remaining ecosystem gap.

What is already strong

• the implementation is compact enough to audit as one header;
• the independent conformance repository retains 810/810 mandatory passes;
• normal parsing rejects malformed JSON instead of applying permissive recovery;
• strict parsing remains the default while configuration extensions and duplicate-key rejection require explicit options;
• significant numeric spellings are preserved when converting only to double would lose representation;
• Unicode escape/surrogate behavior has explicit test coverage;
• parse failures expose byte, line and column locations;
• the maintained lifetime corpus passes ASan/LSan/UBSan, native RSS-soak and independent Valgrind gates with all allocations released at exit;
• same-host benchmark work puts current parsing performance in the same class as the conformant RapidJSON configuration;
• the same parser semantics are dogfooded by larger Nift and Minify++ codebases.

What “used by Nift and Minify++” proves

It proves more than a toy example: the parser is exercised in real configuration/build-tool paths, has survived changes driven by those consumers, and is integrated into projects with their own regression expectations. It also creates useful pressure for deterministic behavior and small dependency cost.

It does not prove that every independent Jsonic++ use case has been explored. Nift and Minify++ naturally exercise the shapes of JSON they need. A public library eventually encounters different file sizes, object shapes, error-reporting expectations, toolchains and calling styles.

What independence still needs to earn

The conformance and standalone memory campaigns are no longer hypothetical gaps. The remaining maturity work is sustained fuzzing, broader packaging/toolchain coverage, API-stability history and genuinely independent downstream deployment. The relevant question is now less “does the parser basically conform?” and more “how broadly has this exact small contract been exercised over time?”

Risk profile

Choosing it responsibly

Jsonic++ is easiest to justify when dependency weight and auditability matter, the Document model fits the application, and the project can pin/vendor a known version. If you need decades of ecosystem history, extensive serialization adapters, arbitrary-precision arithmetic, JSON Pointer/Patch, schema integration, SAX-oriented processing or broad package-manager support, a larger mature library may be the more responsible choice.

Release discipline

Parser changes should arrive with permanent regression evidence, 810/810 conformance and synchronized downstream validation. Performance changes should be measured against the same corpus/host assumptions and must not buy speed by weakening parsing rules. Production-readiness claims should follow evidence rather than version numbers.