I find the choice of TypeScript to be disappointing. One of the reasons that capproto has struggled for market share is the lack of implementations.

Is the overhead for calling into WASM too high for a Rust implementation to be feasible?

A Haxe or Dafny implementation have let us generate libraries in multiple languages from the same source.

▲

josephg 4 days ago | parent | next [-]

There’s no way you could implement this in 10kb of rust. It takes massive advantage of javascript’s dynamism to work. Also, I’m pretty sure ts / js are vastly more popular languages than rust. I suspect this will get a lot more use because it’s typescript.

	▲	kentonv 4 days ago \| parent [-]
		Yes, pretty much. Just interfacing between the JS app and the Wasm RPC implementation would take more code than the entire RPC implementation in TypeScript. Also, the audience of this library is very specifically TypeScript developers. If your app is Rust, you'd probably be happier with Cap'n Proto.

▲

ryanrasti 4 days ago | parent | prev [-]

> I find the choice of TypeScript to be disappointing.

Genuinely curious, is the disappointment because it's limited to the JS/TS ecosystem?

My take is that by going all-in on TypeScript, they get a huge advantage: they can skip a separate schema language and use pure TS interfaces as the source of truth for the API.

The moment they need to support multiple languages, they need to introduce a new complex layer (like Protobuf), which forces design into a "lowest common denominator" and loses the advanced TypeScript features that make the approach so powerful in the first place.

▲

indolering 4 days ago | parent [-]

You can generate TypeScript schema for Haxe JS output. I'm honestly a bit surprised that TS isn't a supported target!

That could change with some investments. Haxe is a great toolkit to develop libraries in because it reduces the overhead for each implementation. It would be nice to see some commercial entity invest in Haxe or Dafny (which can also enable verification of the reference implementation).

> The moment they need to support multiple languages, they need to introduce a new complex layer (like Protobuf),

So this just won't be used outside of Node servers then?

▲

kentonv 4 days ago | parent [-]

> So this just won't be used outside of Node servers then?

Well... I imagine / hope it will be used a lot on Cloudflare Workers, which is not Node-based, it has its own custom runtime.

(I'm the author of Cap'n Web and also the lead developer for Cloudflare Workers.)

	▲	indolering 11 hours ago \| parent [-]
		We've actually chatted before . I was also asking dumb questions that you were polite enough to suffer through . I really do wish Haxe would get the attention of library developers like yourself. It's more like a framework for polyglot development. It can auto generate non-ergonomic libraries that feel like FFS automatically but you can also gradually fine tune it to match the target language over time. It really helps to centralize development effort and share burden. So sure, maybe not Rust. But Haxe's distributable size would be comparable. Maybe I'll try a Dafny implementation to see how that project is coming along!