Bring back XML or a better format than both, or at least a DTD for JSON.
Progressive JSON
241–244 of 244 posts
Re: Progressive JSON
#24299.9999%* of apps don't need anything nearly as 'fancy' as this, if resolving breadth-first is critical they can just make multiple calls (which can have very little overhead depending on how you do it). * I made it up - and by extension, the status quo is 'correct'.
We technically didn't need more than 640K either. Having progressive or partial reads would dramatically speed up applications, especially as we move into an era of WASM on the frontend. A proper binary encoded format like protobuf with support for partial reads and well defined streaming behavior for sub message payloads would be incredible. It puts more work on the engineer, but the improvement to UX could be massi…
>We technically didn't need more than 640K either.
That old chestnut again - this was true for MSDOS PCs in 1981 when the quote was said. It was still true 10 years later for whatever version of DOS was current then. People keep bringing it up as though Bill Gates said 'no one will need > 640k for all time to come'.
Re: Progressive JSON
#243You could stream incrementally like this without explicitly demarcating the "holes". You can simply send the unfinished JSON (with empty arrays as the holes), then compute the next iteration and send a delta, then compute the next and send a delta, and so on. A good delta format is Mendoza [1] (full disclosure: I work at Sanity where we developed this), which has Go and JS/TypeScript [2] implementations. It expresses…
Mendoza doesn't appear to provide a spec?
Re: Progressive JSON
#244Earlier quoted context omitted.
alternative is to stare at blank page without any indication that something is happening
Or, you could use caches and other optimizations to serve content fast.
lol. A cache means they already have it. That doesn’t help people who don’t have the asset yet.