Question about future plan of gRPC-web support

[Gumichocopengin8]

Recently connect-web is release which is an alternative tool of gRPC-web. As the article mentions,

Google's grpc-web made an early attempt to solve gRPC on the web, but developing with grpc-web is miserable: TypeScript support is a half-hearted experiment, there's no support for JSON or ECMAScript modules, the generated JavaScript looks more like decade-old Java, and bundles are enormous. Every response has a 200 OK status and an opaque binary body, so the network inspector is nearly unusable, and just sending requests to a gRPC backend requires a proxy. It's no surprise that most web developers continue to write REST clients by hand.

Are there any future plan to improve the current gRPC-web?

[wenbozhu]

We are aware of the connect-web post.

Exposing the gRPC model on web clients does come with challenges, esp. on the protobuf end, e.g. Closure based, no native TS support, non-binary formats not being open-sourced etc. Ultimately tradeoffs have to be made between server side overhead and client-side experience.

At this point, we still believe that the current grpc-web model provides a simpler solution to extend gRPC and protobuf based micro-services interfaces to Web clients. We don't believe that the grpc or grpc-web model is able to match REST in terms of debuggablility etc. We also don't plan to create a diverged solution that Google won't use internally, which in some cases means a slower adoption of language standards (via google-closure).

Hope this helps. Feel free to continue the discussion here if you have further feedback or questions. Thanks!