I have not taken this decision lightly. There are currently no
consumers of the backported JSON api, which allows us to take this
measure. The problem is that backporting the libjansson API on top of
json.el is non-trivial and led to numerous problems:
1. There is a significant mismatch between the libjansson API and the
json.el API.
2. The libjansson API did not support RFC 8259 when it was introduced
in 27 This was corrected in 28, which requires Compat to provide two
compatibility versions for the json functions.
3. The `json-serialize' compatibility function was very inefficient,
since it has to walk and copy the entire object tree in order to
repair certain objects for the consumption by `json-encode'. This adds
slowness on top of the already slow json.el implementation.
4. `json-parse-buffer' (RFC 8259) modifies the buffer in order to
support toplevel object parsing and relies on undo to restore the
buffer state. This will not work for read-only buffers and for buffers
with disable undo and will have other undesired side effects.
5. The performance of libjansson and json.el are too different. It
will be unexpected if a backported API is suddenly much slower as
expected. This leads to performance bugs downstream.
For now the JSON support lives in the json branch. We can reinstate it
slowly and on-demand if necessary. However experience with the
`string-pixel-width' function showed that we have to be careful when
backports are much slower than the original function due to
performance bugs.