Such conversation about streaming was already held
According to the results, there was quite a lot of work to perform before reaching “championed” state. So much, that it did not.
Deno was mentioned there because it already provides some streaming for json - @std/json - JSR
1. It mandates TextDecoderStream as the first step. Every example in the docs starts with .pipeThrough(new TextDecoderStream()). This is an intermediate string. @std/json does not parse binary - it parses strings that have already been decoded. That is the first problem I try to solve.
2. It is designed for NDJSON/JSON Lines, not single-document JSON. JsonParseStream treats each chunk as a complete, independent JSON document. ConcatenatedJsonParseStream handles back-to-back documents, not a single document split across chunks. Not an option for this debate.
3. It still throws SyntaxError. Under the hood each chunk is passed to JSON.parse(). Invalid input throws, and every SyntaxError costs the same 500Ă— overhead my errors.mjs benchmark proves. Nothing changed for failure path.
4. Infrastructure overhead on top of the existing problem. Each TransformStream has its own internal queue, backpressure machinery, and microtask scheduling overhead. For a request body that is already fully buffered in memory - which is the normal HTTP case - piping through three transform streams is strictly slower and more memory-intensive than a single synchronous call.
Conclusion - existing streaming engines still don’t solve the problem, were cumbersome to implement and are cumbersome to propose.
“I have JSON from network, I want to parse it without overhead” - this is what I try to solve. Streaming topic is more about architecture choices (websockets) and not actual parsing of payload (but my ideas complement streaming well).