webrtc-nuts-and-bolts VS manifesto

I recommend WebRTC For The Curious too, as another comment. Personally, I didn't use WebRTC in C#, but the WebRTC concepts are nearly the same in every different language/platform. Also, you can check out my project and documentation on internals of WebRTC, written in Go and JavaScript: https://github.com/adalkiran/webrtc-nuts-and-bolts . It's not related directly, but another example of usage at my other project, written in Go, Python, and JavaScript: https://github.com/adalkiran/distributed-inference .

I am heavily biased toward WebRTC. Here is my take on it though!

> It's incredibly complex as a specification

What is complex about it? I can go and read the IETF drafts, webrtcforthecurious.com, https://github.com/adalkiran/webrtc-nuts-and-bolts and multiple implementations.

QUIC/WebTransport seems simple because it doesn't address all the things WebRTC does.

> has limitations and numerous issues that set limits in how scalable it can be

https://phenixrts.com/en-us/ does 500k viewers. I don't think anything about WebRTC makes it unscalable.

-----

IMO the future is WebRTC.

* Diverse users makes the ecosystem rich. WebRTC supports Conferencing, embedded, P2P/NAT Traversal, remote control... Every group of users has the made the ecosystem a little better.

* Client code is minimal. For most users they just need to exchange Session Descriptions and they are done. You then additional APIs if you need to change behaviors.

* Lots of implementations. C, C++, Python, Go, Typescript

Show HN: WebRTC Nuts and Bolts, A holistic way of understanding how WebRTC runs\ (0 comments)

You can find it at: https://github.com/adalkiran/webrtc-nuts-and-bolts

The toll of feature creep is what led to the informal adoption of The Extensible Web Manifesto, which argues that the web platform should focus on minimalism and performance. New features should be addressed via extensibility whenever possible. Things like WASM, Houdini, and web components were all prioritized to allow implementation of features on top of the platform and thus reduce the rate at which browsers accumulate technical debt. Features being proposed face an uphill battle if they can be implemented using a more generic mechanism, if there are already competitive alternatives, or if the proposed platform extension is not minimal.

The noise floor in the standards process is deafeningly high because there are always some passionate advocates of a technology or feature arguing for its inclusion. A bunch of prominent web platform folks published The Extensible Web Manifesto ~10 years ago arguing for browser vendors to focus on minimalism and performance while addressing new needs via extensibility.

> I just wish WebRTC wasn't so prescriptive of DTLS/SRTP.

There was a webrtc-webtransport spec, but it got renamed to p2p-webtransport[1]. I'm not sure when the rename happened. Feels like a pretty strong indicator of webrtc being deconstructed, but whose to say this goes anywhere. We'd also need webcodecs.

It's somewhat scary & also somewhat exciting thinking of the one good, working, browser supported standard being ripped into pieces (p2p-webtransport, webcodecs, more) & being user-implemented. Having the browser & servers have a well-known target is both great but also perhaps confining. If we leave it up to each site/library to DIY their solution, figure out how to balance the p2p feeds, it'll be a long long time before the Rest of the World (other than the very big few) have reasonable tech again. WebRTC is quite capable & a nice even playing field, with lots of well-known rules to enable creative interopation. We'd be throwing away a lot. I'd hoped for webrtc-webtransport, to at least keep some order & regularity, but that seems out, at the moment. But Webrtc-nv is still ultra-formative; anything could happen.

The rest of the transport stack is also undergoing massive seismic shifts. I feel like we're in for a lot of years of running QUIC or HTTP3 over WebRTC Data-Channels and over WebTransport, so we can explore solutions the new capabilities while not having to ram each & every change through with the browser implementers. It feels like a less visible but far more massive Web Extensibility Manifesto moment, only at sub-HTML levels[2]. The browsers refused to let us play with HTTP Push, never let appdevs know realtime resources had been pushed at the browser, so we're still debating terrible WebSocket vs SSE choices; terrible. I think of gRPC-web & what an abomination that is, how sad & pointless that effort is; all because the browser is a mere glimmer of the underlying transport. I feel like a lot of experimentation & exploration is going to happen if we start exploring QUIC or HTTP3 over WebTransport. Attempts to reimagine alternatives to WebRTC are also possible if we had specs like p2p-webtransport, or just did QUIC over DataChannels. Running modern protocols in the client, not the browser, seems like a semi-cursed future, but necessary, at least for a while, while we don't yet know what we could do. The browsers are super laggy, slow to expose capabilities.

[1] https://github.com/w3c/p2p-webtransport

[2] https://github.com/extensibleweb/manifesto

I can't help but feel like this is the worst. Every time we step away from HTML & the DOM & into a further farther reach of abstraction, into something custom crafted & artisinal, we lose our valuable common heritage. We flea from common understandability & recurse into something ever more unique & virtual.

In the process- as is the case with Google Docs[1]- we lose things like the ability for web extensions to work, if this is a web hosted vscode instance (vscode server, openvscode, code-server, others). Running a debugger against this part of vscode- web or native- now yields only garbage junk information.

Right now this is just the terminal. I think- "it could be worse". But it chills me deeply that the terminal is now no longer real information. It's now just a happenstance jumble of pixels, powered by only it's own inner logic & a unique maze of libraries. Big tech keeps optimizing and optimizing, & the motive we keep being sold- this is for your good, this helps you- is one I frankly have a very hard time negotiating with myself. De-webbifying the web, de-commonizing the common platform- as Facebook has done by virtualizing the DOM- feels like this ever-running big-bang from a truthful original universe into a sparse, cold, expanding universe where each little fragment defines itself, where the common hypertext medium no longer means anything.

I keep waiting for some moments of contraction, some coming back together, for things to make more sense again, to recontract into something more solid. React's first WebComponents PR[2] is a notable re-contracting, re-platforming- a powerful act I frankly didn't expect, so rare as to feel practically unprecedented.

I realize much of this flexibility, the demonstrated versatility of the web & usage of the various pieces of it represents much of it's strength. The platform being a low-level platform where higher level platforms can be created is amazing; the Extensible Web Manifesto[3] speaks to that emergence of newer higher levels systems. And right now we're in early days, just starting a precambrian explosion of higher level web, as technology like WebAssembly only just begins to become real- still so early, still way pre-pre- Interface Types[4]/Host Bindings, only just the crudest emulation beginning in via projects like Rust's wasm-bindgen / web-sys. I am happy we are still exploding. We have so much more to exlpore. But gee I also question so much when big enterprises turn hypertext into pixels. To move compute into webassembly is a bold leap but the hypertext can survive, the DOM is still truth. It's so uncertain to me, feels like so much might be lost when giants like Microsoft or Google yank out the HTML & replace it with pixels, pushed into our faces. It feels like betrayal, like sabotage, like we're giving up truth.

[1] https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

[2] https://github.com/facebook/react/pull/22184 https://news.ycombinator.com/item?id=29505332 (16 days, 0 comments)

[3] https://github.com/extensibleweb/manifesto

[] https://github.com/WebAssembly/interface-types/blob/main/pro...

The main problem isn't CPU and GPU performance, those problems had (to some extent) already been solved with asm.js and WebGL, at least for some types of games. It's all the other APIs and the general "feature churn" in browsers which are problematic for games.

Some examples:

- The fullscreen and pointerlock APIs show popup warnings which behave entirely differently between browsers.

- Timer precision has been reduced to around 1ms post-Spectre/Meltdown, and jittered on top. This makes it very hard to avoid microstuttering (we don't even need a high-precision timer, just a way to query the display refresh rate... but guess what, there is no way to query the display refresh rate)

- WebAudio is ... I don't even know what... all we need is simple buffer streaming, and the only two ways to do this in WebAudio are either deprecated (ScriptProcessorNode) or not usable without proper threading (audio worklets), and guess what, threading is also disabled or behind HTTP response headers post-Spectre.

- Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels).

...and the list goes on. In theory there are web APIs useful for gaming, but in practice those APIs have been designed for entirely different use cases, and they are not flexible enough to be reassigned to different use cases (like games). The web needs a "game mode", or better a "DirectX initiative", a set of low level APIs and features similar to WASM and WebGL/WebGPU, and if not designed specifically for games, than at least low-level and generic enough to be useful for games.

This isn't a new idea, see the Extensible Web Manifesto:

https://extensiblewebmanifesto.org/

(backup: https://github.com/extensibleweb/manifesto)

But the ideas presented there didn't seem to have much of an impact with the web people (with the notable exception of WebGPU).