oboe.js

It's no longer active, but Oboe.js did great stuff for a decade+ in this field! It has some very nice APIs for consuming. https://github.com/jimhigson/oboe.js/ It's less about incrementally parsing objects, and more about picking paths and shapes out from a feed. If you're doing something like array/newline delimited json, it's a great tool for reading things out as they arrive. Also great for example for feed parsing.

It's too bad there aren't more streaming JSON parsers like oboe.js[1]. It would be nice if parsing libraries always supplied an event-based approach like this in addition to parsers that build up the entire data structure in memory. [1]: https://github.com/jimhigson/oboe.js EDIT: looking around a bit, I found json-stream ( https://github.com/dgraham/json-stream ) for Ruby.

Pretty cool! This reminds me of oboe.js: https://github.com/jimhigson/oboe.js

Just merged in support for reading any stream in Node: https://github.com/jimhigson/oboe.js#reading-from-any-stream... oboe( fs.createReadStream( '/home/me/secretPlans.json' ) ) .node('!.schemes.*', function(scheme){ console.log('Aha! ' + scheme); }); .node('!.plottings.*', function(deviousPlot){ console.log('Hmmm! ' + deviousPlot); }) .done(function(){ console.log("*twiddles mustache*"); });

Do you know how to do that from node? Here's the little test service I wrote to stream out some gzipped content: https://github.com/jimhigson/oboe.js/blob/master/test/stream...

Should be fixed now. Thanks for pointing out. There's a test explicitly for not allowing this: https://github.com/jimhigson/oboe.js/blob/master/test/specs/...

This looks really cool! I'm confused about the usecase, however. In your foods/nonfoods example[0], it allows you to request a some JSON with 2 keys, `foods` and `"nonFoods"`, each with an array value, and use only foods, discarding nonFoods. You request this from oboe('/myapp/things.json') My question: why not modify the backend to accept a request like `/myapp/foods.json` and let the backend compose the json you need & send only that? It seems like fixing it "in the wrong place" to build your frontend to accommodate getting the wrong/too much data. Is this a contrived example that isn't the core usecase? This is my assumption. Is this primarily for 3rd party APIs and legacy codebases where it's impractical to change the response type & updating to e.g. sockets is impractical? Thanks for the cool project, I apologize for my ignora