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

The future of web software is HTML over WebSockets

alistapart.com

Post reply on HN
Print view View original

221–230 of 337 posts

Re: The future of web software is HTML over WebSockets

#221

Post by happyconcepts »

keithwhor wrote: post #64

I’m gonna be “that jerk on HN,” but this is that idea that just keeps getting rehashed every couple of years then fizzles out. The reason that it’s so attractive is because as developers we love to build and save time, and we think, “imagine what we could do if we didn’t have to ask for data from remote servers...” The problem is that stateful connections suck and create artificial complexity when you don’t need them…

Just sayin' ... this time around ... a) the universe of gamers is larger and b) there's a larger base of phones which can be thought of as thin clients versus a full PC and c) node.js is widespread with Deno upcoming and d) multiplayer VR is closer to reality if it only need to compute one state at the server?

Multiplayer online experiences are also growing to include more than gaming, such as betting and gambling and zoom and trading crypto.

Are websockets and or browsers improving to handle this server centric shift?

Re: The future of web software is HTML over WebSockets

#222

Post by ricketycricket »

nickjj wrote: post #133
shakow wrote: post #127

Earlier quoted context omitted.

> Instead of managing the state of your app you’re now managing the state of your app and a connection to a remote server. Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem?

> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem? I don't think so but if I'm wrong please correct me. For example, imagine this simple scenario: you load the comment page for this post on HackerNews HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload. You can be sitting here on the page…

The sensible response to that scenario would be: Why did you make HN a Live View? I don't think anyone is suggesting that you make anything a Live View that is more appropriate as plain HTML. If you wouldn't use React, you shouldn't use Live View.

I understand you needed an example, but a better comparison would be a heavy SPA with real-time interactivity. In that case, if your server is down your API calls will fail and you're going to have to handle the failure and let the user know something went wrong any way. If anything, Live View's built-in buffer and retry can actually provide a better user experience because the UI will automatically "catch up" when the client reconnects.

> You also don't want to disable this visual warning because on slower devices it might take 2 seconds to load the page which is much different than an uncontrolled disconnect.

Live View loads the entire initial page over HTTP, then mounts the Live View. Your slow device won't see any difference if the visual warning is disabled or not.

Re: The future of web software is HTML over WebSockets

#223

Post by blendergeek »

njharman wrote: post #206
nickjj wrote: post #133

Earlier quoted context omitted.

> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem? I don't think so but if I'm wrong please correct me. For example, imagine this simple scenario: you load the comment page for this post on HackerNews HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload. You can be sitting here on the page…

If your server is done 20 times in 10 min, replace your incompetent eng, ops, service provider. A feature that protects from ridiculously unlikely problem is no feature. It is over engineering

> If your server is done 20 times in 10 min, replace your incompetent eng, ops, service provider.

You could have incompetent engineers or you could have bad internet. The user could be on a train that is going in and out of tunnels. Or the user could be in a house using WiFi and the microwave could be causing interference.

Re: The future of web software is HTML over WebSockets

#224

Post by toomim »

anderspitman wrote: post #43

I used to love WebSockets a lot more. At some point I got deeper into implementing HTTP servers and proxies, and realized how much of a special case WebSockets are to implement. They're cool, but I prefer Server-Sent Events on HTTP/2 whenever I can get away with it, which is pretty much always (binary data being a big exception, and even then I consider long-polling first). I think there's value in keeping our protoc…

You might check out https://braid.org, which is like SSE but specifically for updating state at URLs, and works for binary data.

Re: The future of web software is HTML over WebSockets

#225

Post by Felz »

I've been using a reactive websockets over HTML in Kotlin implementation that I wrote myself, and it's been the least unpleasant web development experience I've ever had. There really is a huge advantage when you don't have to marshal/unmarshal/validate a request for a simple callback on a button, and page loads can be much faster.

That said, there is more operational complexity (though given my site is relatively small, not much yet). State that lives with the server dies with the server, so deployments can take longer if client sessions live for a while.

Re: The future of web software is HTML over WebSockets

#226

Post by Skunkleton »

zajio1am wrote: post #199
c-linkage wrote: post #84

This seems like X Windows protocol over HTTPS with JSON as the wire encoding. It's sad to think how much effort is spent reimplementing technologies because the IPv4 address space wasn't large enough. If IP address space were larger, we wouldn't have needed to rely on Network Address Translation (NAT). NAT became a poor-man's firewall and effectively blocked peer-to-peer connections making it difficult to host a serv…

> NAT became a poor-man's firewall and effectively blocked peer-to-peer connections making it difficult to host a server at home. Most ISPs (with the exception of very small ones) until recently assign one public IP address per customer and NAT is done on home router. With this setup it is not hard to host a server at home - it is just one rule on router to NAT all incoming connections to that server. Many SOHO route…

They are asymmetric because the are provisioned that way. IE it was done intentionally.

Re: The future of web software is HTML over WebSockets

#227

Post by acemarke »

rmrfrmrf wrote: post #214
mathgladiator wrote: post #81

Earlier quoted context omitted.

I'm working on the complex UIs now, and it is a challenge. Fortunately, I can focus on gaming designs which is less complicated. I think the key thing here is figuring out how the UI can be made mostly declarative and a stateless function of the state. I'm drawing some inspiration from https://flutter.dev/docs/development/data-and-backend/state-... and the challenge is the polish to make products great. My strategy i…

It seems like you could get most, if not all the way, there with an "isomorphic" Redux store on client and server side, along with a custom Redux middleware (very easy to write and well-documented) that reads actions from and writes actions to whatever connection you have set up. That way, your initial "giant json object" on the client is just the current store state and your "streaming updates" are just redux action…

Yep. As an example, see this pair of posts from 2017 on a distributed VR app with Redux actions over the network:

http://jimpurbrick.com/2017/01/04/vr-redux/

http://jimpurbrick.com/2017/07/04/react-vr-redux-revisited/

Re: The future of web software is HTML over WebSockets

#228

Post by toomim »

mathgladiator wrote: post #16

I have thoughts, and I agree but also disagree a bit. We are in the dark-ages with respect to streaming sockets, and I am the architect of one of the worlds largest WebSocket and streaming services. First off, unseating the operational benefits provided by request response is a huge challenge. It's possible, and I've done it. One of these days, my co-authors and I will present an OSDI paper with the broad strokes. It…

> Second, HTML over WebSockets is nice, but what is better is reactive data binding over the socket.

This is the approach we are building in https://braid.org. We are extending HTTP from a state transfer protocol into a state synchronization protocol, so that when you do a GET request, you can also be promised to receive all updated versions of that resource. This extends very nicely with software that binds the resource directly into a DOM element.

Re: The future of web software is HTML over WebSockets

#230

Post by hnedeotes »

Matthias247 wrote: post #161
TheRealPomax wrote: post #145

Earlier quoted context omitted.

Note that a websocket round trip is vastly shorter than an http round trip, though. If your payloads are small, 500 consecutive websocket back and forths take orders of magnitude less time than the "traditional" high level url post/fetch becauses there's none of the overhead of an http round trip.

A round trip is a round trip. Software can’t beat physics. If you want to do requests in parallel, http 2 and 3 can do them just fine. If it’s sequential, you won’t see a huge difference between something on websockets and http/1.1. The only thing you can save are a few header bytes. And it’s up to you how many headers you use

I'm not going to say web sockets are the silver bullet as I don't think it is, but the "only thing you can save are a few header bytes" is a bit reductionist.

If you have authentication then cookies have to be going out also and any other information that has to be kept in order to provide state over a stateless connection. You still need to handshake on each connection (maybe http2/3 bring this down a bit), and you also don't have bidirectional flow, so if you need something resembling client side "real-time" functionality you now have to implement pooling, or server side events.

The biggest issue is basically how to load balance/scale and that becomes a problem only given a scale that 98% (scientific) of the websites online won't ever experience.

Post reply on HN