Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Direct Sockets API in Chrome 131

chromestatus.com

Post reply on HN
Print view View original

51–60 of 171 posts

Re: Direct Sockets API in Chrome 131

#51

Post by saurik »

nightowl_games wrote: post #23
modeless wrote: post #10

I think a lot of people don't realize it's possible to use UDP in browsers today with WebRTC DataChannel. I have a demo of multiplayer Quake III using peer-to-peer UDP here: https://thelongestyard.link/ Direct sockets will have their uses for compatibility with existing applications, but it's possible to do almost any kind of networking you want on the web if you control both sides of the connection.

Yeah we use WebRTC for our games built on a fork of Godot 3. https://gooberdash.winterpixel.io/ tbh the WebRTC performance is basically the same network performance as websockets and was way more complicated to implement. Maybe the webrtc perf is better in other parts of the world or something...

I mean, the only cases where UDP vs. TCP are going to matter are 1) if you experience packet loss (and maybe you aren't for whatever reason) and 2) if you are willing to actively try to shove other protocols around and not have a congestion controller (and WebRTC definitely has a congestion controller, with the default in most implementations being an algorithm about as good as a low-quality TCP stack).

Re: Direct Sockets API in Chrome 131

#52

Post by 1oooqooq »

nzoschke wrote: post #9
phildenhoff wrote: post #4

Earlier quoted context omitted.

Interesting — the Firefox team’s response was very negative, but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app (as opposed to being an API available to any website). In reading their comments, I also felt the API was a bad idea. Especially when technology like Electron or Tauri exist, which can do those TCP or UDP connections. But IWA serves to displace Electron,…

I'm hacking on a Tauri web app that needs to bridge to talking UDP protocols literally as we speak. While Tauri seems better than ever for cross platform native apps, it's still a huge step to take to allow my web app access to lower level. Rust toolchain, Tauri plugins, sidecar processes, code gen, JSON RPC, all to let my web app talk to my network. Seems great that Chrome continues to bundle these pieces into the b…

with so many multiplatform gui toolkits today, tauri and electron are really bad choices

Re: Direct Sockets API in Chrome 131

#53

Post by 1oooqooq »

jeswin wrote: post #36

I prefer web apps to native apps any day. However, web apps are limited by what they can do. But what they can do is not consistent - for example, it can take your picture and listen to your microphone if you give permissions; but it can't open a socket. Another example: Chrome came out with an File System Access API [2] in August; it's fantastic (I am using it) and it allows a class of native apps to be replaced by…

nah. we need even less. i rather webapps because of the limitations. much less to worry about

Re: Direct Sockets API in Chrome 131

#54

Post by modeless »

1oooqooq wrote: post #49
theamk wrote: post #39

Earlier quoted context omitted.

I sure hope not, this will bring in a new era for internet worms. If some ISPs are not currently firewalling all incoming IPv6 connections, it's a major security risk. I hope some security researcher raises boise about that soon, and the firewalls will go closed by default.

it kinda of already begun

Has there been a big ipv6 worm? I thought that the defense against worms was that scanning the address space was impractical due to the large size.

Re: Direct Sockets API in Chrome 131

#56

Post by montymintypie »

1oooqooq wrote: post #52
nzoschke wrote: post #9

Earlier quoted context omitted.

I'm hacking on a Tauri web app that needs to bridge to talking UDP protocols literally as we speak. While Tauri seems better than ever for cross platform native apps, it's still a huge step to take to allow my web app access to lower level. Rust toolchain, Tauri plugins, sidecar processes, code gen, JSON RPC, all to let my web app talk to my network. Seems great that Chrome continues to bundle these pieces into the b…

with so many multiplatform gui toolkits today, tauri and electron are really bad choices

What's your recommendation? I've tried so many multiplatform toolkits (including GTK, Qt, wxWidgets, Iced, egui, imgui, and investigated slint and sciter) and nothing has come close to the speed of dev and small final app size of something like Tauri+Svelte.

Re: Direct Sockets API in Chrome 131

#57

Post by modeless »

saurik wrote: post #51
nightowl_games wrote: post #23

Earlier quoted context omitted.

Yeah we use WebRTC for our games built on a fork of Godot 3. https://gooberdash.winterpixel.io/ tbh the WebRTC performance is basically the same network performance as websockets and was way more complicated to implement. Maybe the webrtc perf is better in other parts of the world or something...

I mean, the only cases where UDP vs. TCP are going to matter are 1) if you experience packet loss (and maybe you aren't for whatever reason) and 2) if you are willing to actively try to shove other protocols around and not have a congestion controller (and WebRTC definitely has a congestion controller, with the default in most implementations being an algorithm about as good as a low-quality TCP stack).

Out-of-order delivery is another case where UDP provides a benefit.

Re: Direct Sockets API in Chrome 131

#58

Post by bloomingkales »

girvo wrote: post #46
crote wrote: post #38

Earlier quoted context omitted.

That doesn't really make it any better, if you ask me. The entire Isolated Web Apps proposal is a massive breakdown of the well-established boundaries provided by browsers. Every user understands two things about the internet: 1) check the URL before entering any sensitive data, and 2) don't run random stuff you download. The latter is heavily enforced by both Chrome and Windows complaining quite a bit if you're tryi…

Unfortunately this is the future. Handing the world wide webs future to Google was a mistake, and the only remedy is likely to come from an (unlikely) antitrust breakup or divestment.

I doubt websites as we know it will be what we’ll be dealing with going forward anyways.

What is a browser if we just digest all the HTML and spit out clean text in the long run?

We handed over something of some value I guess, once upon a time.

Post reply on HN