I can imagine it being useful to have a made where you never emit strings until they are final, also. I don't entirely understand why strings are emitted incrementally but numbers aren't.
Name: John Smith. Birth Year: A.D. 1 [Customer is a Senior: 2,024 years old]
Name: John Smith. Birth year: A.D. 19 [Customer is a Senior: 2,006 years old]
Name: John Smith. Birth year: A.D. 199 [Customer is a Senior: 1,826 years old]
Name: John Smith. Birth year: 1997
For instance, imagine you don't fully control the backend to split up a large response into several smaller API calls, but you could render the top part of the UI, which may be the most useful part, from the first couple of keys in the JSON, while a large "transaction history" after that is still downloading.
Seriously, you should be able to update the UI with a new character, and much more, at 60fps easily.
(but for other uses - nope)
> The parse function also matches JSON.parse's behavior for invalid input. If the input stream cannot be parsed as the start of a valid JSON document, then parsing halts and an error is thrown. More precisely, the promise returned by the next method on the AsyncIterable rejects with an Error. Likewise if the input stream closes prematurely.
As for why strings are emitted incrementally, it's just that I was often dealing with long strings produced slowly by LLMs. JSON encoded numbers can be big in theory, but there's no practical reason to do so as almost everyone decodes them as 64bit floats.