docs: new design for the documentation site (#5934)

* docs: new design for the documentation site

Apply the brand to the Material for MkDocs site: Inter and JetBrains Mono
served by the site (upright and real italic), brand colours, blue header band
with the syntax pattern, wordmark in the header, new home page (hero, cards,
animated feature tour), 404 page, polish for tabs, search, footer, focus
rings, tables and code blocks, and theme features (code copy, previous/next
footer, TOC follow, search suggestions).

Draw the number railroad diagram, the parser callback events and the iterator
illustrations as inline SVGs that follow the light and dark scheme. The
generator scripts are in docs/mkdocs/scripts/figures; the feature slideshow
(json-light.svg, json-dark.svg, replacing json.gif on the home page) is built
by docs/mkdocs/scripts/slideshow. Decision nodes in five flowcharts become
hexagons, which need far less room.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* docs: add figures, table captions and a macro chooser

- Figures with numbered captions: SAX stepper, json_view layout and edit
  stepper, exception map, JSON pointer and patch walkers, QA pipeline,
  scaling and binary size charts, roadmap lanes, release timeline,
  integration decision tree and namespace builder
- Table captions (nj-table-caption) on 9 pages
- Compile times: modules and PCH charts, filesystem section, re-measured
  Figure 1, links between features/modules.md and compile_times.md
- Interactive macro chooser for features/arbitrary_types.md
- Link check: exclude URLs that answer the plugin with 400/401/419 or are
  dead (customers.md)

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* docs: macro chooser generates adl_serializer for non-default-constructible types

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* docs: cross-link concept pages and API pages in See also sections

Add See also links in both directions between the concept pages (features,
home, integration) and the API pages, write API links in code font, give every
entry a comment after a dash, and show the callback event figure on the parser
callbacks page.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* docs: address review comments on the new design

- Home: add a "Latest release" button
- Sponsors: update the list and group it by tier
- Features: list all feature pages on the index page
- Releases: add highlights per release, link the 4.0 roadmap, add the first commit to the timeline
- Exceptions: prefix all example messages with the exception name
- API: no code font for format names in the See also links of the to_/from_ pages
- Merge Patch: show the document before, the patch, and the result
- Replace "--" with typographic dashes, mark external links with an icon, center Mermaid diagrams

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

---------

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

docs/mkdocs/docs/features/json_view.md

@@ -21,18 +21,26 @@ referenced in place in the source text: a float is converted when it is read, an
 sequences are decoded, into one shared buffer owned by the document.
 
 [`basic_json_view`](../api/basic_json_view/index.md) is a small, trivially copyable handle (two pointers) into that
-index. It gives you the read-only, type-inspection part of the `basic_json` interface --
+index. It gives you the read-only, type-inspection part of the `basic_json` interface —
 [`type()`](../api/basic_json_view/type.md) and the `is_*()` predicates,
-[`size()`](../api/basic_json_view/size.md)/[`empty()`](../api/basic_json_view/empty.md) -- as well as element access
+[`size()`](../api/basic_json_view/size.md)/[`empty()`](../api/basic_json_view/empty.md) — as well as element access
 ([`operator[]`](../api/basic_json_view/operator%5B%5D.md), [`at`](../api/basic_json_view/at.md),
 [`front`](../api/basic_json_view/front.md)/[`back`](../api/basic_json_view/back.md)), lookup
 ([`find`](../api/basic_json_view/find.md), [`contains`](../api/basic_json_view/contains.md),
 [`count`](../api/basic_json_view/count.md)), and iteration
 ([`begin`](../api/basic_json_view/begin.md)/[`end`](../api/basic_json_view/end.md),
-[`items`](../api/basic_json_view/items.md)) -- without ever allocating a `basic_json` value. When you do need an
+[`items`](../api/basic_json_view/items.md)) — without ever allocating a `basic_json` value. When you do need an
 actual `basic_json` value for a subtree, [`materialize()`](../api/basic_json_view/materialize.md) builds exactly the
 one [`parse()`](../api/basic_json/parse.md) would have produced for it.
 
+The same small text, parsed both ways:
+
+<div class="nj-fig-wrap" markdown>
+--8<-- "images/json_view_layout.svg"
+</div>
+
+<p class="nj-caption" markdown>Top: the tree of separate heap allocations that `basic_json::parse()` builds. Bottom: `json_document::parse()` keeps the source text and builds one flat index of 16-byte nodes that point back into it, plus a buffer of decoded strings.</p>
+
 ## How to use it
 
 Include `<nlohmann/json_view.hpp>` in addition to (or instead of) `<nlohmann/json.hpp>`. Parse into a
@@ -62,7 +70,7 @@ A document either **borrows** the text it was parsed from, or **owns** its own c
 [`owns_source()`](../api/basic_json_document/owns_source.md) to find out which happened.
 [`parse()`](../api/basic_json_document/parse.md) decides this from the value category and type of its argument (an
 lvalue `#!cpp std::string` is borrowed; an rvalue `#!cpp std::string` is moved in, owned without a copy; a stream is
-read into an owned buffer; and so on -- see [`parse`'s Notes](../api/basic_json_document/parse.md#notes) for the full
+read into an owned buffer; and so on — see [`parse`'s Notes](../api/basic_json_document/parse.md#notes) for the full
 table). [`parse_copy()`](../api/basic_json_document/parse_copy.md) always owns a copy, regardless of the input.
 
 !!! warning "A borrowed document depends on your buffer"
@@ -84,10 +92,16 @@ Moving the `basic_json_document<>` itself is fine and does **not** invalidate it
 allocation that keeps its address across the move. Take a fresh view from [`root()`](../api/basic_json_document/root.md)
 whenever any of the other conditions above was not met.
 
+<div class="nj-fig-wrap" markdown>
+--8<-- "images/json_view_lifetime.svg"
+</div>
+
+<p class="nj-caption" markdown>Four timelines of a document and its views, each bar showing when an object is alive or valid and when it dangles. Destroying the borrowed text, re-parsing, or shrinking the document invalidates the views taken before; moving the document does not.</p>
+
 A view can dangle, exactly like a `#!cpp std::string_view`: nothing stops you from using it after its document is
 gone. This is deliberate. A view is two pointers and trivially copyable; making it safe (a `#!cpp std::shared_ptr` in
 the document and a `#!cpp std::weak_ptr` in each view) would make it larger, add reference counting to every copy,
-and a `lock()` to every access -- exactly the costs the view exists to avoid. What is caught is the obvious case:
+and a `lock()` to every access — exactly the costs the view exists to avoid. What is caught is the obvious case:
 because a view dies with its document, [`root()`](../api/basic_json_document/root.md) is not callable on a temporary
 document: `#!cpp auto v = json_document::parse(text).root();` does not compile. Give the document a name first.
 
@@ -109,7 +123,7 @@ document: `#!cpp auto v = json_document::parse(text).root();` does not compile.
   [`parse()`](../api/basic_json_document/parse.md) accept and reject exactly the same inputs as
   [`basic_json::accept()`](../api/basic_json/accept.md)/[`basic_json::parse()`](../api/basic_json/parse.md), with the
   same `ignore_comments` and `ignore_trailing_commas` options.
-- **Errors.** A failing parse throws the same exception -- the same id, message, and position -- because on failure
+- **Errors.** A failing parse throws the same exception — the same id, message, and position — because on failure
   the library's own parser is run on the same bytes to produce the diagnostic. Valid input never pays for this, and
   the replay builds no values: it costs about a lexing pass up to the error.
   `#!cpp allow_exceptions == false` skips the replay and gives a
@@ -155,7 +169,7 @@ document: `#!cpp auto v = json_document::parse(text).root();` does not compile.
   element access and lookup functions never carry the JSON Pointer path `JSON_DIAGNOSTICS` would otherwise add: the
   view has no `basic_json` value to point at, so the exception is created without one, regardless of how
   `BasicJsonType` was built.
-- **Ordering comparisons are not provided** by `basic_json_view` -- there is no `#!cpp operator<`.
+- **Ordering comparisons are not provided** by `basic_json_view` — there is no `#!cpp operator<`.
   [`operator==`](../api/basic_json_view/operator_eq.md) and [`operator!=`](../api/basic_json_view/operator_ne.md) are
   provided, though: two views, or a view and a `BasicJsonType` value, compare equal exactly when
   [`materialize()`](../api/basic_json_view/materialize.md) or [`parse()`](../api/basic_json/parse.md) would produce
@@ -227,15 +241,15 @@ and other types the library converts (`#!cpp std::vector`, `#!cpp std::map`, `#!
 Two conversions never copy at all:
 
 - [`get_string()`](../api/basic_json_view/get_string.md) (equivalently, `#!cpp get<string_view_t>()`) returns a
-  string as a `string_view_t` pointing into the document's [`source()`](../api/basic_json_document/source.md) text --
-  or, for a string that contains escape sequences, into the document's own buffer of decoded strings -- instead of
+  string as a `string_view_t` pointing into the document's [`source()`](../api/basic_json_document/source.md) text —
+  or, for a string that contains escape sequences, into the document's own buffer of decoded strings — instead of
   allocating a new `#!cpp std::string`.
 - [`number_token()`](../api/basic_json_view/number_token.md) returns a number exactly as it was written in the
   source, e.g. `#!cpp "1.50"`, `#!cpp "1E2"`, or an integer with more digits than any number type holds, instead of
   rounding it into a `#!cpp double`/`#!cpp int64_t` the way `#!cpp get<T>()` (and
   [`basic_json::parse()`](../api/basic_json/parse.md)) would.
 
-Both results are only valid as long as the view -- and, for a string with no escapes, the borrowed source text -- is.
+Both results are only valid as long as the view — and, for a string with no escapes, the borrowed source text — is.
 
 ## Writing generic code
 
@@ -328,14 +342,14 @@ Two things differ when a `from_json()` reads the view:
 
 [`dump()`](../api/basic_json_view/dump.md) serializes a view directly from the flat index, without ever building a
 `basic_json` value. An object's members are written in document order, not sorted by key, and *every* occurrence of a
-repeated key is written, not only the last one -- the same two ways [iteration](#what-is-different) already differs
+repeated key is written, not only the last one — the same two ways [iteration](#what-is-different) already differs
 from a [`materialize()`](../api/basic_json_view/materialize.md)d value, see [Duplicate keys](#duplicate-keys).
 `#!cpp materialize().dump()` gives a different result in both respects for a `json_view`.
 
 By default, numbers are written the way [`basic_json::dump()`](../api/basic_json/dump.md) would.
 [`number_format::source`](../api/basic_json_view/number_format.md) instead copies every number exactly as it was
-written in the source text -- a price like `#!cpp 19.90`, a long order or account ID with more digits than any number
-type holds, or a high-precision coordinate -- something `basic_json` cannot do at all, since parsing already reduces
+written in the source text — a price like `#!cpp 19.90`, a long order or account ID with more digits than any number
+type holds, or a high-precision coordinate — something `basic_json` cannot do at all, since parsing already reduces
 a number to its parsed `#!cpp double`/`#!cpp int64_t` value.
 
 [`operator<<`](../api/basic_json_view/operator_ltlt.md) writes a view to a stream the way `basic_json`'s does, using
@@ -344,14 +358,14 @@ the stream's `width`/`fill` for indentation.
 ## Editing a document
 
 Everything above is read-only: a `json_document`/`json_view` lets you look at a parsed text without copying it, but
-not change it. [`basic_json_document<BasicJsonType, view_mode::editable>`](../api/basic_json_document/index.md) -- more conveniently
+not change it. [`basic_json_document<BasicJsonType, view_mode::editable>`](../api/basic_json_document/index.md) — more conveniently
 spelled [`json_editable_document`](../api/json_editable_document.md) or
-[`ordered_json_editable_document`](../api/ordered_json_editable_document.md) -- also lets you
+[`ordered_json_editable_document`](../api/ordered_json_editable_document.md) — also lets you
 [`set`](../api/basic_json_document/set.md) a value, [`push_back`](../api/basic_json_document/push_back.md) onto or
 [`insert`](../api/basic_json_document/insert.md) into an array, and [`erase`](../api/basic_json_document/erase.md)
 an object member or an array element, still without ever building a `basic_json` tree for parts you do not touch.
 
-The [mode](../api/view_mode.md) defaults to `#!cpp view_mode::read_only`, so `json_document`/`ordered_json_document` are unaffected -- they carry
+The [mode](../api/view_mode.md) defaults to `#!cpp view_mode::read_only`, so `json_document`/`ordered_json_document` are unaffected — they carry
 none of the bookkeeping edits need, and calling `set`/`push_back`/`insert`/`erase` on one is a compile error, not a
 runtime one.
 
@@ -361,15 +375,35 @@ The `#!cpp 19.90` price from [above](#writing-a-view-back) is exactly the kind o
 or `ordered_json` value in place lossy. Say you parse a configuration file, patch one field, and write it back:
 
 - **`json`** re-sorts every key on the way in (`object_t` is a `#!cpp std::map`) and rewrites every number to its
-  shortest round-trip form on the way out -- a one-field patch turns into a diff that reorders the whole file and
+  shortest round-trip form on the way out — a one-field patch turns into a diff that reorders the whole file and
   rewrites `#!cpp 19.90` to `#!cpp 19.9`.
 - **`ordered_json`** keeps the key order, but still rewrites every number the same way: parsing has already reduced
   it to a `#!cpp double`/`#!cpp int64_t`, and there is no way back to how it was spelled in the source text.
 
+The patch of the example below (set `"host"`, add `"retries"`) written back by each of them:
+
+<div class="nj-jsonview-cmp" role="group" aria-label="The same patch written back by json, ordered_json, and json_editable_document">
+<div><p class="nj-jsonview-cmp-h"><code>json</code></p><p class="nj-jsonview-cmp-v">keys sorted, numbers rewritten</p><pre>{<span class="nj-jsonview-bad">"host"</span>:"db2",
+ "name":"cache",
+ "port":6379,
+ "price":<span class="nj-jsonview-bad">19.9</span>,
+ "retries":3}</pre></div>
+<div><p class="nj-jsonview-cmp-h"><code>ordered_json</code></p><p class="nj-jsonview-cmp-v">key order kept, numbers rewritten</p><pre>{"name":"cache",
+ "host":"db2",
+ "port":6379,
+ "price":<span class="nj-jsonview-bad">19.9</span>,
+ "retries":3}</pre></div>
+<div class="nj-jsonview-cmp--best"><p class="nj-jsonview-cmp-h"><code>json_editable_document</code></p><p class="nj-jsonview-cmp-v">order and spelling kept</p><pre>{"name":"cache",
+ "host":"db2",
+ "port":6379,
+ "price":<span class="nj-jsonview-ok">19.90</span>,
+ "retries":3}</pre></div>
+</div>
+
 An editable document keeps both. [`dump()`](../api/basic_json_view/dump.md) of an edited document writes members in
-document order -- a member [`set`](../api/basic_json_document/set.md) added goes at the end, exactly where it was
+document order — a member [`set`](../api/basic_json_document/set.md) added goes at the end, exactly where it was
 inserted, and an [`erase`](../api/basic_json_document/erase.md)d member simply leaves a gap: everything around it
-keeps its place -- and [`number_format::source`](../api/basic_json_view/number_format.md) keeps the exact spelling
+keeps its place — and [`number_format::source`](../api/basic_json_view/number_format.md) keeps the exact spelling
 of every number an edit did not itself touch; a number an edit *did* touch is written the way
 [`BasicJsonType::dump()`](../api/basic_json/dump.md) would write it, since there is no source spelling for a brand
 new value.
@@ -388,14 +422,14 @@ new value.
 
 ### What stays valid, and what an edit costs
 
-The source text itself is **never written**, and the parsed index never moves -- a value keeps the node it was
+The source text itself is **never written**, and the parsed index never moves — a value keeps the node it was
 parsed into for as long as it is not itself replaced. So every [view](../api/basic_json_view/index.md) taken before
 an edit, including a previously obtained [`root()`](../api/basic_json_document/root.md), stays valid and, if it
 still refers to the edited value, sees the edit; a view of a value a later edit drops or replaces just keeps showing
 what it last held. New values go to storage the document allocates and owns on demand. The one thing an edit does
-invalidate is the **iterators** taken over an edited array or object: the first time one of its elements is set,
-appended to, inserted into, or erased, its elements move from the parsed, fixed layout to a growable block of links
-so that [`push_back`](../api/basic_json_document/push_back.md) can later grow it in amortized constant time --
+invalidate is the **iterators** taken over an edited array or object: the first time an element is added to it,
+inserted into it, erased from it, or replaced by a value that spans a different number of nodes, its elements move from the parsed, fixed layout to a growable block of links
+so that [`push_back`](../api/basic_json_document/push_back.md) can later grow it in amortized constant time —
 existing elements are not touched, but an iterator that was walking the old layout no longer matches. A string
 obtained with
 [`get_string()`](../api/basic_json_view/get_string.md) is unaffected either way and stays valid across further
@@ -404,16 +438,53 @@ edits. See [`basic_json_document`'s Edits](../api/basic_json_document/index.md#e
 throws (the *basic* guarantee, not the strong one `dump()` and the read-only functions provide). How edits are kept in
 the index is described in the [architecture overview](../home/architecture.md#node-index-of-json-views).
 
+Step through the edits of a small document (the node fields follow the [architecture overview](../home/architecture.md#node-index-of-json-views)):
+
+<div class="nj-jsonview-steps" data-nj-jsonview-steps>
+<figure class="nj-jsonview-step" data-label="After parsing">
+<div class="nj-jsonview-scroll">
+--8<-- "images/json_view_edit_0.svg"
+</div>
+<figcaption>Step 1 of 5. After parsing: nine nodes in the parsed index, no owned storage yet.</figcaption>
+</figure>
+<figure class="nj-jsonview-step" data-label="set an existing member">
+<div class="nj-jsonview-scroll">
+--8<-- "images/json_view_edit_1.svg"
+</div>
+<figcaption>Step 2 of 5. <code>doc.set(doc.root(), "port", 6380)</code> overwrites the node of the integer in place; no member is added or removed, so the object keeps its parsed layout.</figcaption>
+</figure>
+<figure class="nj-jsonview-step" data-label="erase an array element">
+<div class="nj-jsonview-scroll">
+--8<-- "images/json_view_edit_2.svg"
+</div>
+<figcaption>Step 3 of 5. <code>doc.erase(doc.root()["tags"], 0)</code>: the array is edited for the first time, so its elements move to a block of links in owned storage. The node of <code>"eu"</code> stays in the index, but nothing refers to it any more; iterators over the array taken before are invalid.</figcaption>
+</figure>
+<figure class="nj-jsonview-step" data-label="push_back onto the array">
+<div class="nj-jsonview-scroll">
+--8<-- "images/json_view_edit_3.svg"
+</div>
+<figcaption>Step 4 of 5. <code>doc.push_back(doc.root()["tags"], "new")</code>: the new string gets its own node, its text goes to the buffer of edited text, and a link to it is appended to the block of the array.</figcaption>
+</figure>
+<figure class="nj-jsonview-step" data-label="set a new member">
+<div class="nj-jsonview-scroll">
+--8<-- "images/json_view_edit_4.svg"
+</div>
+<figcaption>Step 5 of 5. <code>doc.set(doc.root(), "retries", 3)</code>: a new member, so the object moves to a block too: copies of its keys, links to the values it already had, then the new key and a link to the new integer.</figcaption>
+</figure>
+</div>
+
+<p class="nj-caption" markdown>The node index and the owned storage of the document after each of five edits. Use *Back*, *Next*, or the numbered buttons to switch between the steps; without JavaScript all steps are shown one below the other.</p>
+
 ## Images
 
 [`save()`](../api/basic_json_document/save.md) writes a document as an *image*: a byte buffer that
-[`load()`](../api/basic_json_document/load.md) reads back into a document without parsing -- no lexing, no building
+[`load()`](../api/basic_json_document/load.md) reads back into a document without parsing — no lexing, no building
 the node index, nothing but copying the nodes and pointing the text and the decoded strings at the image. Where
 [`parse_copy()`](../api/basic_json_document/parse_copy.md) still has to scan the whole input,
 [`load()`](../api/basic_json_document/load.md) turns that scan into a copy of the node index alone.
 
-**Why.** A document that is parsed once and then read many times -- a configuration loaded at startup, a template
-rendered on every request, a large reference dataset a worker process needs in memory -- pays for parsing once but
+**Why.** A document that is parsed once and then read many times — a configuration loaded at startup, a template
+rendered on every request, a large reference dataset a worker process needs in memory — pays for parsing once but
 can amortize [`save()`](../api/basic_json_document/save.md)'s cost across every later load. That makes images useful
 for a cache: save a document the first time it is parsed (to a file, a shared-memory segment, an in-process cache),
 and [`load()`](../api/basic_json_document/load.md) it on every later use instead of parsing the source text again.
@@ -424,10 +495,10 @@ plus pointers into the received bytes, not a re-parse.
 **Choosing a check.** [`load()`](../api/basic_json_document/load.md) takes an
 [`image_check`](../api/basic_json_document/load.md#image_check) that trades validation against speed:
 `image_check::full` (the default) checks everything the parser itself guarantees, so a checked image is exactly as
-safe to read and serialize as a freshly parsed document -- the right choice whenever the image did not come straight
+safe to read and serialize as a freshly parsed document — the right choice whenever the image did not come straight
 from this process's own [`save()`](../api/basic_json_document/save.md), such as a file or a network peer.
-`image_check::bounds` only checks structure and bounds -- cheaper, since it skips scanning the text and the decoded
-strings -- and fits a cache the process trusts, one it wrote and reads back itself. `image_check::none` skips
+`image_check::bounds` only checks structure and bounds — cheaper, since it skips scanning the text and the decoded
+strings — and fits a cache the process trusts, one it wrote and reads back itself. `image_check::none` skips
 validation entirely, for an image trusted as much as the process's own memory. See
 [`load()`'s Notes](../api/basic_json_document/load.md#notes) for exactly what each level does and does not guarantee.
 
@@ -447,7 +518,7 @@ validation entirely, for an image trusted as much as the process's own memory. S
 
     The image format is versioned but not yet stable, and may change in an incompatible way before it is declared
     stable. It is little-endian only (on big-endian targets, `save()` and `load()` do not exist), and tied to the
-    library build that wrote it -- use it to cache a document or to hand one to another process running the *same*
+    library build that wrote it — use it to cache a document or to hand one to another process running the *same*
     build, not as a long-term storage format; keep the original JSON text if a saved document needs to be readable by
     a future library version.
 
@@ -463,8 +534,21 @@ either.
 | **Ownership** | owns every value | owns nothing; you decide what to keep, in your handler | borrows or owns the *text*; the index is always owned by the document | same as `json_document`; edits go to storage the document owns |
 | **Mutability** | freely mutable | not applicable (a one-shot event stream) | read-only | [`set`](../api/basic_json_document/set.md)/[`push_back`](../api/basic_json_document/push_back.md)/[`insert`](../api/basic_json_document/insert.md)/[`erase`](../api/basic_json_document/erase.md) edit in place; the source text is never rewritten |
 | **What you get** | a full tree you can read, write, and keep as long as you like | a sequence of callbacks; whatever your handler builds from them | a flat index plus, on demand, [`materialize()`](../api/basic_json_view/materialize.md)d `json`/`ordered_json` values for the parts you actually use | the same, plus [`dump()`](../api/basic_json_view/dump.md) of an edited document that keeps the member order and, with [`number_format::source`](../api/basic_json_view/number_format.md), the spelling of every untouched number |
-| **Typical use** | general-purpose JSON handling: config, request/response bodies you build or modify, anything you hold onto | validating or projecting a text into your own data structure without ever holding the whole thing as JSON | large or high-volume input where you only need part of it, or need it repeatedly, and can keep the source text (or a copy) alive for as long as the document lives | a document you read, patch a few fields of, and write back -- a configuration file, for instance -- where the rest of it should come back exactly as it was |
-| **Caching/reload** | not applicable -- re-parse, or roll your own serialization | not applicable | [`save()`](../api/basic_json_document/save.md)/[`load()`](../api/basic_json_document/load.md): cache the parsed index as an image and reload it without parsing | same, saving the document's current -- possibly edited -- state |
+| **Typical use** | general-purpose JSON handling: config, request/response bodies you build or modify, anything you hold onto | validating or projecting a text into your own data structure without ever holding the whole thing as JSON | large or high-volume input where you only need part of it, or need it repeatedly, and can keep the source text (or a copy) alive for as long as the document lives | a document you read, patch a few fields of, and write back — a configuration file, for instance — where the rest of it should come back exactly as it was |
+| **Caching/reload** | not applicable — re-parse, or roll your own serialization | not applicable | [`save()`](../api/basic_json_document/save.md)/[`load()`](../api/basic_json_document/load.md): cache the parsed index as an image and reload it without parsing | same, saving the document's current — possibly edited — state |
+
+<p class="nj-table-caption" markdown>Each column is one way to work with JSON in this library, and each row compares one property of them.</p>
+
+## See also
+
+- [`basic_json_document`](../api/basic_json_document/index.md) - the document that owns the parsed index (parse, access, images, edits)
+- [`basic_json_view`](../api/basic_json_view/index.md) - the non-owning handle to a value in a document
+- [`json_document`](../api/json_document.md) - and [`ordered_json_document`](../api/ordered_json_document.md) - the read-only documents
+- [`json_editable_document`](../api/json_editable_document.md) - and [`ordered_json_editable_document`](../api/ordered_json_editable_document.md) - the documents that can be edited in place
+- [Architecture](../home/architecture.md#node-index-of-json-views) - the layout of the node index
+- [SAX interface](parsing/sax_interface.md) - event-based parsing without building a tree
+- [Performance](performance.md) - benchmarks and tuning of parsing and serialization
+- [Large, Streamed, and Partial Input](parsing/large_and_partial_input.md) - reading only the part of a text you need
 
 ## Version history