Live data from Hacker News

Cap'n Web: a new RPC system for browsers and web servers

blog.cloudflare.com

131–140 of 305 posts

Re: Cap'n Web: a new RPC system for browsers and web servers

#131
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.

Re: Cap'n Web: a new RPC system for browsers and web servers

#133

Babe get in here, a new kentonv library just dropped! I'm surprised how little code is actually involved here, just looking at the linked GitHub repo. Is that really all there is to it? In theory, it shouldn't be too hard to port the server side to another language, right? I'm interested in using it in an Elixir server for a JS/TS frontend. For that matter, the language porting seems like a pretty good LLM task. Did…

Some of the tests are LLM-generated, but none of the library itself is. I don't think LLMs would be capable of writing this library (at least at present). The pieces fit together like a very intricate puzzle. I spent a lot more time thinking about how to do it right, than actually coding. Very different from my workers-oauth-provider library, where it was just implementing a well-known spec with a novel (yet straight…

Hammock driven development :)

https://www.youtube.com/watch?v=f84n5oFoZBc

Re: Cap'n Web: a new RPC system for browsers and web servers

#134

Earlier quoted context omitted.

It's not a programming paradigm shift, more of a change to how runtimes work. We want to avoid the overhead of kernel threads in servers, and async/await on top of an event loop is a convenient way to do that, like in JS, Rust, and now Python. Meanwhile Go doesn't have async/await and never will because it doesn't need it; it does greenthreading instead. Java has that too now. Either way, your code waits on IO like b…

I disagree that async/await is purely about avoiding overhead of kernel threads. Kernel threads are actually not that expensive these days. You can have a server with 10,000 threads, no problem. The problem is synchronization becomes extremely hard to reason about. With event loop concurrency, each continuation (callback) becomes effectively a transaction, in which you don't need to worry about anything else modifyin…

It's true that JS await is kinda like releasing a lock, but otherwise, you'd just use a mutex whenever you access shared state. Which is rare as you said, and also easy to enforce in various langs nowadays.

Re: Cap'n Web: a new RPC system for browsers and web servers

#135

I was really excited when I saw the headline, but I was kind of disappointed to see it doesn't support schemas natively. I know you can specify them via zod, but I'm really not looking forward to any more untyped APIs, given that the lack of strict API typing has been by far the #1 reason for the bugs I've had to deal with in my career.

I really want to bake in some sort of support for generating type checks based on TypeScript types... so then your schemas are just TypeScript. Not sure why this doesn't seem to be a common practice TBH, might be missing something.

That would be great, would these checks run at deserialization time? They'd probably need to, as you wouldn't want to assume that the stuff coming through the network is of a specific type.

Re: Cap'n Web: a new RPC system for browsers and web servers

#136
post #57

The section on how they solved arrays is fascinating and terrifying at the same time https://blog.cloudflare.com/capnweb-javascript-rpc-library/#... . > .map() is special. It does not send JavaScript code to the server, but it does send something like "code", restricted to a domain-specific, non-Turing-complete language. The "code" is a list of instructions that the server should carry out for each member of the arra…

This record and replay trick is very similar to what I recently used to implement the query DSL for Tanstack DB ( https://tanstack.com/db/latest/docs/guides/live-queries ). We pass a RefProxy object into the where/select/join callbacks and use it to trace all the props and expressions that are performed. As others have noted you can't use js operators to perform actions, so we built a set of small functions that we c…

Just a side note - reading https://tanstack.com/db/latest/docs/guides/live-queries#reus... I see:

    const isHighValueCustomer = (row: { user: User; order: Order }) => 
     row.user.active && row.order.amount > 1000
But if I'm understanding the docs correctly on this point, doesn't this have to be:

    const isHighValueCustomer = (row: { user: User; order: Order }) => 
      and(row.user.active, gt(row.order.amount, 1000))

Re: Cap'n Web: a new RPC system for browsers and web servers

#137

Earlier quoted context omitted.

I disagree that async/await is purely about avoiding overhead of kernel threads. Kernel threads are actually not that expensive these days. You can have a server with 10,000 threads, no problem. The problem is synchronization becomes extremely hard to reason about. With event loop concurrency, each continuation (callback) becomes effectively a transaction, in which you don't need to worry about anything else modifyin…

It's true that JS await is kinda like releasing a lock, but otherwise, you'd just use a mutex whenever you access shared state. Which is rare as you said, and also easy to enforce in various langs nowadays.

I said that shared state between connections is rare, but shared state within a connection is extremely common. And there are still multiple concurrent things going on within that connection context, requiring some concurrency mechanism. Locking mutexes everywhere sounds like a nightmare to me.

Re: Cap'n Web: a new RPC system for browsers and web servers

#138
post #122
post #89

Earlier quoted context omitted.

Async/await became ergonomic and widespread only recently, I am sure there were async systems in the '80 but for example nodejs focus on non blocking I/O changed how a lot of people thought about servers and concurrency (whether node was first is almost irrelevant) Often when something is discovered or invented is far less influential[1] than when it jumps on and hype train. [1] the discovery is very important for hi…

I actually hate async/await approach to concurrency and avoid it as much as I can. My mental model is that it's a caller who decides how call should be executed (synchroniously or asynchroniously). Synchronious call is when caller waits till completion/error, asynchronious - is when caller puts the call in the background (whatever it means in that language/context) and handle return results later. CSP concurrency mod…

I love this about sel4. Sel4 defines a capability based API between processes, and the invoking functions have both synchronous and asynchronous variants. (Ie, send, sendAsync, recv, recvAsync, etc). How you want to use any remote function is up to you!

Re: Cap'n Web: a new RPC system for browsers and web servers

#139

Earlier quoted context omitted.

This record and replay trick is very similar to what I recently used to implement the query DSL for Tanstack DB ( https://tanstack.com/db/latest/docs/guides/live-queries ). We pass a RefProxy object into the where/select/join callbacks and use it to trace all the props and expressions that are performed. As others have noted you can't use js operators to perform actions, so we built a set of small functions that we c…

Just a side note - reading https://tanstack.com/db/latest/docs/guides/live-queries#reus... I see: const isHighValueCustomer = (row: { user: User; order: Order }) => row.user.active && row.order.amount > 1000 But if I'm understanding the docs correctly on this point, doesn't this have to be: const isHighValueCustomer = (row: { user: User; order: Order }) => and(row.user.active, gt(row.order.amount, 1000))

Yep, that's an error in the docs..

Re: Cap'n Web: a new RPC system for browsers and web servers

#140

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.

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.
Post reply on HN