This genre of HN comment irks me. Technical writing is an exercise in taking a lot of material and distilling it down to an audience. Writing that does a good job this will often look basic to someone with a deep understanding of the tech. It doesn't mean the author is clueless, it just means they decided they made different decisions on what to cut than you would have.
That the author didn't mention UDP "leaves out" the vs. objective, however. If it were a fair contest, the article would mention the use of WebRTC over UDP, which isn't just for streaming media (an assumption I had before doing a bit more research on it).
> This article aims to delve into these technologies, comparing their performance, highlighting their benefits and limitations, and offering recommendations for various use cases to help developers make informed decisions when building real-time web applications.
So, the article's intent was to help others. When we do things like this, we should ensure all technologies being evaluated will be covered exhaustively. Otherwise, you risk leaving out an important part of the puzzle and then assumptions kick in which ignore a possible better solution for a given use case.
It looks like UDP use is possible between a browser and a server, and that connection has to have components that deal with dropout, given it's UDP. There is a LOT to consider and deal with implementing UDP over WebRTC, so I put a dump of this up here: https://pastebin.com/xgA78dky
This genre of HN comment irks me. Technical writing is an exercise in taking a lot of material and distilling it down to an audience. Writing that does a good job this will often look basic to someone with a deep understanding of the tech. It doesn't mean the author is clueless, it just means they decided they made different decisions on what to cut than you would have.