Re:Telefunc: Remote Functions instead of API
by brillout on Sunday October 02, 2022 @03:33AM
(#33053784)
> My experience was that for the simplest use cases, the ergonomics were unbeatable.
Exactly.
> the “just a function” interface was a distraction and I found myself wishing for a more conventional RPC interface.
For real-time use cases, I agree. I believe functions are the wrong abstraction here for real-time. I do plan to support real-time but using a "it's just variables" abstraction instead, see https://github.com/brillout/telefunc/issues/36.
> cleverer abstractions usually mean more work overall to integrate everything and boring is better.
Yes, Telefunc's downside is that it requires a transformer. The Vite and Webpack one are reliable and used in production (using `es-module-lexer` under the hood). The hope here is that, as Telefunc's popularity grows, more and more stacks are reliably supported. Also, there is a prototype using Telefunc without a transformer at all, which works but needs polishing.
> I experimented with a higher-magic version of this a couple of years ago.
Exactly.
> the “just a function” interface was a distraction and I found myself wishing for a more conventional RPC interface.
For real-time use cases, I agree. I believe functions are the wrong abstraction here for real-time. I do plan to support real-time but using a "it's just variables" abstraction instead, see https://github.com/brillout/telefunc/issues/36.
> cleverer abstractions usually mean more work overall to integrate everything and boring is better.
Yes, Telefunc's downside is that it requires a transformer. The Vite and Webpack one are reliable and used in production (using `es-module-lexer` under the hood). The hope here is that, as Telefunc's popularity grows, more and more stacks are reliably supported. Also, there is a prototype using Telefunc without a transformer at all, which works but needs polishing.
> I experimented with a higher-magic version of this a couple of years ago.
Neat, curious, is it on GitHub?