en	= Comparison to Other Libraries

en	:icon_good: pass:q[[.green]##&#10004##] :icon_bad: pass:q[[.red]##&#10008##]

en	There exist many C++ JSON libraries, but two are particularly noteworthy for the purpose of comparison: https://rapidjson.org/[RapidJSON], https://nlohmann.github.io/json/[JSON for Modern {cpp}] (referred to herein as nlohmann's JSON, or nlohmann), and https://github.com/lemire/simdjson[SIMD JSON].

en	Comparison to nlohmann JSON

en	Value Type: https://github.com/nlohmann/json/blob/00cb98a3d170161711ab912ae6acefba31f29f75/include/nlohmann/json.hpp#L165[`nlohmann::basic_json`]

en	This library adopts a "kitchen sink" approach. It contains a wealth of features, even those with niche uses. Its weakness is that the many template parameters, while allowing for configurability, inhibit the best possible optimizations. The consequence is that the library performs poorly. The ability to configure every aspect of the value type has the paradoxical effect of making it less suitable as a vocabulary type.

en	{icon_bad} `basic_json` is a class template. Libraries must agree on the

en	choices of template parameters to be interoperable.

en	{icon_bad} Too much customization. We struggle to see a use case for making

en	`BooleanType` anything other than `bool`.

en	{icon_bad} Poor separation of concerns. The `basic_json` container

en	declaration needlessly conflates parsing and serialization APIs.

en	{icon_bad} Limited allocator support. Only stateless allocators are allowed,

en	which rules out the most important type of allocator, a local arena-based implementation.

en	{icon_bad} No incremental parsing, no incremental serialization.

en	{icon_bad} Slow parsing and serialization performance.

en	{icon_good} Full-featured, including JSON Pointer, CBOR, and others.

en	Comparison to RapidJSON

en	Value Type: https://github.com/Tencent/rapidjson/blob/bb5f966b9939d6cdfbac3462a0410e185099b3af/include/rapidjson/document.h#L608[`rapidjson::GenericValue`]

en	{icon_bad} The value type is not regular. Assignment is destructive,

en	performing `a = b` is equivalent to `a = std::move(b)`. No copy construction or copy assignment allowed.

en	{icon_bad} Object types have no hash table or index to reduce the cost of

en	lookups.

en	{icon_bad} Allocators have reference semantics. Problems with lifetime are

en	easily encountered.

en	{icon_bad} The interface of the array and object types are considerably

en	different from their standard library equivalents, and not idiomatic.

en	{icon_bad} No incremental parsing, no incremental serialization.

en	{icon_good} Parsing and serialization performance is better than most other

en	libraries.

en	Comparison to SIMD JSON

en	This is quite an interesting data structure, which is optimized to work well with the SIMD parser. It makes very good design choices for the intended use-case. However it is not well suited as a vocabulary type due to the necessary limitations.

en	{icon_bad} Sequential access only, via `ParsedJson::BasicIterator`

en	{icon_bad} Read-only, can only be populated by the provided SIMD JSON parser.

en	{icon_good} The fastest available JSON parser.