if i want to use bun should i consider squint or nbb?
both should work
question is is there any diffrence 😄
i have the feeling that using squint would make more sense
since nbb is an app that leverages node in the back right and squint is "just" a transpiler
yeah but bun now has enough Node.js compatibility to be usable with nbb
$ bunx --bun nbb -e '(+ 1 2 3)'
6but isn't nbb wrapping node ?
$ bunx --bun nbb
Welcome to nbb v1.2.179!
user=> js/Bun.version
"1.1.24"no
it's just a library
aaaaaah ok
i thought its like babashka
and squint is just the library 😄
nbb is just a thing on npm that you can load :)
yeah a node executable i guess
just a blob of JavaScript
and yeah, a CLI that has a node.js shebang
this is why you need the --bun flag with bun, else it will still invoke node.js
ok makes sense
just asking for a friend ;D
i'm doing some video streaming stuff and i've figured out that the webtorrent stuff just works with webrtc and there is no cool library afaik for java / clojure
so i'm considering bun cause its the new kid and should handle js stuff even faster
I'd benchmark real life scenario's because sometimes the Bun benchmarks are a little specific and artificial
Awesome reading, this thread!
Yeah guess i have to benchmark it anyways. Btw if nbb is "just" a lib will i gain performance when i transpile stuff to js first?
it depends. nbb isn't a compiler but an interpreter, so code runs slower, but it depends what the overhead of interpretation vs the actual video streaming stuff is.
In general afaik the webtorrent works like that that it generates the torrent file magnet link and than offers the video over webrtc. So wss.
I thinik it just offers the bytes from the torrent without invoking to much code
Last time I was tinkering with Webtorrent the WebRTC part was native compiled code so I don't think you will run into performance issues using nbb. Maybe if you were handling 10k's of connections joining and leaving it could become and issue but I'd guess not.
If by "wss" you mean websocket protocol then it's a completely different thing to WebRTC. Webtorrent uses both - the websocket connection is for "signaling" (e.g. introducing browsers to each other) and the WebRTC is used for the direct p2p connection and streaming of data between browsers. So in this architecture nbb would probably just be running the webtorrent tracker server which is all JS code anyway and handling the websockets part. The actual streaming happens p2p away from your own server.
i guess if i'm at that scale 😄 i have diffrent problems to 😄
One good thing about WebRTC is you mostly don't have to worry about scale because the data goes directly without hitting your own infrastructure (usually, with some caveats depending on how you handle TURN).
Oh wait, if you are running the WebRTC node and streaming from the server then you will be running that (native compiled) part on your own infrastructure.