sachinraja

Vite is not built in Go, esbuild is. esbuild is not the only reason why it's fast either, see https://vitejs.dev/guide/why.html.

If anything, Vite is less complexity. It's much easier to use and configure than any other build tool I've used. If you don't have a need/want for Vite, that's fine, but others enjoy using it. I am not fretting over the next build tool, I'm simply switching to something I prefer to use.

If they don't have knowledge of the frontend build world, then maybe they'll have to do a bit more reading. Who should Vite's landing page target?

Vite does not throw out any experience. It builds upon Rollup, esbuild, and other existing tools.

There's a great page on how it's cutting edge here: https://main.vitejs.dev/guide/why.html. I suggest you try using it to see for yourself.

Vite could use swc for compiling in the future.

I don't think anyone is expecting an existing production project to switch over. Vite offers amazing DX for new projects though. Just because something is solved doesn't mean it can't get better.

How is React not solving essential problems? Suspense solves a pretty essential issue. Also Svelte can quickly increase in bundle size and if you have enough components, it can become bigger than the equivalent in other frameworks: https://github.com/yyx990803/vue-svelte-size-analysis.

Using TS type inference to its fullest is a major part of tRPC so I don't think it has much of a benefit to you if you're ok with generation.

In my experience, you can iterate more quickly without generation. I've used GraphQL and having a separate system to generate code and types was not a good experience. If not done properly, your schema and types can also easily be out of sync.

You can't provide typesafety (with TypeScript) across the frontend and backend for multiple languages without codegen. There's no intention for this to be strictly JS, but there's no easy way to offer this for multiple languages.

There will be an openapi generator some time in the future so that could help with generating clients for other languages (https://github.com/trpc/trpc/issues/1724).

It can be made to work with any framework with a proper adapter. NestJS is quite opinionated though so I suspect the two will not work well together.

Thanks for clarifying!

I don't believe there's anything really preventing the use of server-side events. The Websocket implementation is via an adapter and special client so I think the same could be done for SSE (probably achievable in an external package too).

Could you elaborate on this? What part of tRPC do you think is unsound due to the type system?

tRPC offers typesafety across your frontend and backend without needing to generate any code. This makes it so updates in your backend "router" are immediately reflected in your frontend code. You can't use gRPC with TypeScript without codegen. tRPC may be more familiar to TS/Node.js devs too.