I want to acknowledge the great work that has gone into this tool, which seems to be practical and elegant. This blog post, though, has some needlessly provocative statements that distract the reader from the utility of tRPC.<p>The image of GraphQL's epitaph implies that tRPC is killing or will GraphQL. This is misleading: as you acknowledge in the text of the article, GraphQL is a specification that is language-agnostic. tRPC is not language-agnostic, nor is it a spec, so why use such stark imagery?<p>I also need to point out this snippet:<p>> But the vast majority of projects that use GraphQL are JavaScript-based. The graphql NPM module has 5M downloads/week vs ~300k) for the graphene Python module and ~230k for the graphql Rubygem. It's not a perfect metric, but the signal is clear.<p>I disagree that there's any clarity or signal to be had from these figures. Node, Python, and Ruby package management paradigms are all different. "It's not a perfect metric" is an understatement, and "the signal is clear" is an overstatement.<p>> As TypeScript approaches near-universal adoption in the JS ecosystem, that means most GraphQL-based projects will soon be TypeScript-based (if they aren't already).<p>Again, this is overstated. "Near-universal?" How could you possibly substantiate such an outlandish claim? I suggest you scale down the claim to "as TypeScript continues its rise in the JS ecosystem,".<p>But perhaps the most relevant hand-wavery in the entire article is as follows:<p>> Here's the thing: most people use GraphQL as a massively over-engineered way to share the type signature of their API with your client.<p>A citation is sorely needed here. My team is using GraphQL in a production app serving millions of users - its type system is great but only one of many features we're interested in.<p>Again, tRPC looks fantastic - it sells itself without the puffery and half-truths you've used in an otherwise excellent article.