My current assessment of Jsonic++.

Jsonic++ is compelling less because C++ needed another enormous JSON ecosystem and more because this parser already existed as a useful, unusually small component with real downstream pressure behind it.

What I like

The strongest property is restraint. The implementation is small enough to audit, easy to vendor, dependency-free, and already forced to handle malformed syntax, Unicode, duplicate keys, streaming metadata and serialization because Nift and Minify++ actually needed those things.

I also like that the public model is obvious. A Document tells you what it owns. Arrays and objects are ordinary containers. Parsing returns a boolean and useful error text. There is comparatively little framework knowledge between “I have JSON text” and “I have the string/number/array I need.”

Where that simplicity costs something

The same design makes Jsonic++ a poor candidate for projects that want automatic C++ struct serialization, sophisticated adapters, arbitrary-precision numeric policy, 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 also deliberately simple because insertion order is preserved in a vector. That is perfectly reasonable for the small 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.

What I would not claim yet

I would not rank it above mature JSON libraries on ecosystem maturity, API breadth or independent production evidence. Jsonic++ is intentionally narrower and newly extracted. Nift and Minify++ provide meaningful dogfooding, but external users, independent conformance campaigns and longer API stability are different evidence.

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 one vendorable header and a tiny dependency footprint are valuable. I would also choose it when auditability matters more than convenience adapters.

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. A larger abstraction can be the simpler application-level choice when it eliminates hundreds of lines of conversion code.

Why extraction helps Nift too

Separating parser ownership from Nift lets parser correctness have its own regression, fuzz and conformance story. Nift can focus on what JSON means to a build system while Jsonic++ focuses on whether JSON itself is parsed correctly. Minify++ likewise consumes the parser without becoming the place where generic JSON semantics are decided.

What would change my assessment

More independent fuzz/conformance evidence and downstream usage would increase confidence. Conversely, rapid API expansion would reduce one of the library's main advantages. The interesting success case for Jsonic++ is not “eventually grow into every other JSON library”; it is “remain small while accumulating unusually strong evidence for the narrow job it claims to do.”