3 ms·

For JavaScript developers "simple-peer" npm package is very popular and makes WebRTC very simple. I don't think its' an on-ramp problem, holding it back, it's j

For JavaScript developers "simple-peer" npm package is very popular and makes WebRTC very simple. I don't think its' an on-ramp problem, holding it back, it's just that most apps don't necessarily benefit from P2P coms, and also I'd hazard a guess not many people know about WebRTC, yet. Just guessing.

01HNNWZ0MV43FF 1y ago
In the c++ world I definitely felt the on ramp. Not surprised it is easier in js and go
- quantadev 1y ago
  I was a C++ dev all thru the 1990s, but moved to Java, JS, Python. There's really no good argument for using C++ nowadays in 99.999% of apps. Unless you're doing something VERY special like realtime stuff, or something where each action of the CPU needs to be controlled directly, you just don't need it. I'm sure you know that, tho. Not preaching at you. I learned Python as recently as 2023, just so I could get deep into the AI landscape and access all those libraries/tools.
- fidotron 1y ago
  In JS it's amazingly easier because of how you can just await on peerconnection calls, which makes developing the happy path version of the code much faster, that can then be progressively extended with proper error handling. My experience of it in Java/C++/Golang is in every case you have to deal with all the problems far more upfront before any of it works at all. And JS doesn't have the multithreaded aspect to handle, which is also the major weakness as it eliminates the extensability in that environment. I have a sort of proof of concept level SFU in golang, with a simple TypeScript/React client, and the whole client is this: https://github.com/atomirex/umbrella/blob/master/frontend/src/umbrella/SfuApp.tsx https://github.com/atomirex/umbrella/blob/master/frontend/sr... and most of the complexity there is because I can never remember if track ID or transceiver MID should be used in different situations!
  - quantadev 1y ago
    That's some pretty impressive multimedia stuff you've got there! All I know how to do is a basic P2P chat room...and the most advanced thing about it is file attachments!
    - fidotron 1y ago
      Thanks, but in truth the media stuff here isn't the difficult bit as the state of webrtc in 2025 means it's really just a question of shuffling byte buffers around in time. It's really libwebrtc and the browser integrators that deserve the credit. I have done native mobile libwebrtc work, and that's several other levels of complexity from all this, but with that you can do things like hardware accelerated neural net integration quite easily because of how it's all structured.
      - quantadev 1y ago
        I'm new to this and Claude AI talked me into using 'simple-peer' as my library (NPM package) even though the browser's native WebRTC API was almost identical code. I'd be interested in your opinion about what API to use for just a chat app, that does file-sharing. In other words it will be sending around byte buffers (files) as part of the JSON objects. I haven't looked up libwebrtc yet. My WebRTC started as a "Vibe Coding" session last week, and since the results were so impressive I kept on developing it into a full-blow chat app, just for kicks.
        fidotron 1y ago
        So, I am not familiar with "simple-peer" but there are some definite inter-browser quirks relating to datachannels which it might be taking care of. I seem to recall one browser always prefixes the buffers with sequence numbers, for example. Really fun stuff like that, but I would hope that is history by now. My preference would be to use the standard webrtc api, and then use a polyfill style library for uniform behaviour if you don't want to worry about it (which it sounds like simple-peer might be). In the event you want a much higher level API and pre-rolled signalling server etc. my go to recommendation on that would be https://livekit.io/ https://livekit.io/ which I am not affiliated with, but I tend to think people starting out should try that and then be able to explain why they're not using it, much in the same way I would expect a game dev to try using Unreal and have a good reason if they aren't planning on using it.

01HNNWZ0MV43FF 1y ago

In the c++ world I definitely felt the on ramp. Not surprised it is easier in js and go

quantadev 1y ago
I was a C++ dev all thru the 1990s, but moved to Java, JS, Python. There's really no good argument for using C++ nowadays in 99.999% of apps. Unless you're doing something VERY special like realtime stuff, or something where each action of the CPU needs to be controlled directly, you just don't need it. I'm sure you know that, tho. Not preaching at you. I learned Python as recently as 2023, just so I could get deep into the AI landscape and access all those libraries/tools.
fidotron 1y ago
In JS it's amazingly easier because of how you can just await on peerconnection calls, which makes developing the happy path version of the code much faster, that can then be progressively extended with proper error handling. My experience of it in Java/C++/Golang is in every case you have to deal with all the problems far more upfront before any of it works at all. And JS doesn't have the multithreaded aspect to handle, which is also the major weakness as it eliminates the extensability in that environment. I have a sort of proof of concept level SFU in golang, with a simple TypeScript/React client, and the whole client is this: https://github.com/atomirex/umbrella/blob/master/frontend/src/umbrella/SfuApp.tsx https://github.com/atomirex/umbrella/blob/master/frontend/sr... and most of the complexity there is because I can never remember if track ID or transceiver MID should be used in different situations!
- quantadev 1y ago
  That's some pretty impressive multimedia stuff you've got there! All I know how to do is a basic P2P chat room...and the most advanced thing about it is file attachments!
  - fidotron 1y ago
    Thanks, but in truth the media stuff here isn't the difficult bit as the state of webrtc in 2025 means it's really just a question of shuffling byte buffers around in time. It's really libwebrtc and the browser integrators that deserve the credit. I have done native mobile libwebrtc work, and that's several other levels of complexity from all this, but with that you can do things like hardware accelerated neural net integration quite easily because of how it's all structured.
    - quantadev 1y ago
      I'm new to this and Claude AI talked me into using 'simple-peer' as my library (NPM package) even though the browser's native WebRTC API was almost identical code. I'd be interested in your opinion about what API to use for just a chat app, that does file-sharing. In other words it will be sending around byte buffers (files) as part of the JSON objects. I haven't looked up libwebrtc yet. My WebRTC started as a "Vibe Coding" session last week, and since the results were so impressive I kept on developing it into a full-blow chat app, just for kicks.
      - fidotron 1y ago
        So, I am not familiar with "simple-peer" but there are some definite inter-browser quirks relating to datachannels which it might be taking care of. I seem to recall one browser always prefixes the buffers with sequence numbers, for example. Really fun stuff like that, but I would hope that is history by now. My preference would be to use the standard webrtc api, and then use a polyfill style library for uniform behaviour if you don't want to worry about it (which it sounds like simple-peer might be). In the event you want a much higher level API and pre-rolled signalling server etc. my go to recommendation on that would be https://livekit.io/ https://livekit.io/ which I am not affiliated with, but I tend to think people starting out should try that and then be able to explain why they're not using it, much in the same way I would expect a game dev to try using Unreal and have a good reason if they aren't planning on using it.