If you want to be able to see data in the browsers network inspector, you do. If you are already serving gRPC-web, you can use the gRPC-web transport in connect-web, it supports both protocols. It doesn't support plain gRPC because web browsers do not expose trailers, and gRPC uses them extensively.
Not sure if it is a magic bullet, but it was definitely written by TypeScript developers, for TypeScript developers.
The generated TypeScript code is already pretty minimal because all serialization ops are implemented with reflection instead of generated code (which is only marginally slower than generated code in JS).
But you can also switch to generating JavaScript + TypeScript declaration files, which is truly minimal: JavaScript is an entire dynamic language, so we actually only generated a small snippet of metadata in the .js output, and create a class at run time with a function call. The generated typings (.d.ts) give you type safety, autocompletion in the IDE, and so on.
Tree shaking works well when you have ESM imports / exports.
jquery is/was usually loaded into the global scope. There is no standard way for tree shakers to deduct which parts of the library you are using.
Yes, browser APIs have matured significantly since jquery was new and such a library doesn't add much value anymore.
I agree it would be great if the README gave a bit more background. Whoever is looking to migrate away from jquery will be aware of the background though (and will likely appreciate this tool).
