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

311–320 of 337 posts

Re: The future of web software is HTML over WebSockets

#311

Post by jiriknesl »

pier25 wrote: post #305
jiriknesl wrote: post #293

Earlier quoted context omitted.

"UI state should live in the client." this is wrong and I think you have missed the point of the article. In server-rendered app, there's nothing like UI state. There's a request. This request and the database is enough to build response. There is no UI state. Your app can be (and often is) absolutely stateless and restult depends only on request and a state of the storage. While when you have SPA, API & server, you…

> In server-rendered app, there's nothing like UI state. Of course there is. For example, any state related to interactivity like forms, client-side validation, widgets, filters, etc.

All these things can be set up declaratively on the render time and managed through Ajax/socket. Local state is voluntary here.

Re: The future of web software is HTML over WebSockets

#312

Post by beagle3 »

FridgeSeal wrote: post #283
beagle3 wrote: post #281

Earlier quoted context omitted.

Isn’t this also the basis for Stadia RIP and XBox Mobile work on iPhones? That seems to deliver acceptable results for even arcade games on WiFi. Latency seems to have been conquered.

> Latency seems to have been conquered. I dare you to say that from Australia.

We are not close to conquering the speed of light. Ping time NY to Australia is 100-200ms regardless of software stack.

But if you have a server in Australia then I would still say that.

Re: The future of web software is HTML over WebSockets

#313

Post by anderspitman »

viklove wrote: post #310
anderspitman wrote: post #118

Earlier quoted context omitted.

What's wrong with normal HTTP requests for client->server streams? You get the added bonus of being able to dump them to a curl command for debugging.

More overhead, and it doesn't scale. My nodejs websockets server can handle thousands of connections without a problem, but my rails api server allocates a thread per connection so I'm limited to For infrequent requests everything goes through the api, but for stuff like chat and live-document-editing, nodejs is the better solution.

I think I missed something. Why can't you use node for SSE?

Re: The future of web software is HTML over WebSockets

#314

Post by viklove »

anderspitman wrote: post #313
viklove wrote: post #310

Earlier quoted context omitted.

More overhead, and it doesn't scale. My nodejs websockets server can handle thousands of connections without a problem, but my rails api server allocates a thread per connection so I'm limited to For infrequent requests everything goes through the api, but for stuff like chat and live-document-editing, nodejs is the better solution.

I think I missed something. Why can't you use node for SSE?

I can, but why would I limit myself to one-way communication when I can have bidirectional communication?

Re: The future of web software is HTML over WebSockets

#315

Post by anderspitman »

viklove wrote: post #314
anderspitman wrote: post #313

Earlier quoted context omitted.

I think I missed something. Why can't you use node for SSE?

I can, but why would I limit myself to one-way communication when I can have bidirectional communication?

You didn't cite bidi as your reason for choosing WS in your last comment, you cited scaling and node vs ruby.

But to answer this new question:

* You can have bidi without WS.

* Because WS is more complicated.

Re: The future of web software is HTML over WebSockets

#316

Post by anderspitman »

toomim wrote: post #224
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.

Thanks. Braid looks interesting, but complex and mathy. It's not clear to me what the use cases would be or why I would choose it over SSE or WebSockets for any given problem.

Re: The future of web software is HTML over WebSockets

#317

Post by pier25 »

jiriknesl wrote: post #311
pier25 wrote: post #305

Earlier quoted context omitted.

> In server-rendered app, there's nothing like UI state. Of course there is. For example, any state related to interactivity like forms, client-side validation, widgets, filters, etc.

All these things can be set up declaratively on the render time and managed through Ajax/socket. Local state is voluntary here.

So when using a drag-and-drop widget you're going to be waiting for server responses at every step of the way?

Re: The future of web software is HTML over WebSockets

#318

Post by toomim »

dgellow wrote: post #246
toomim wrote: post #228

Earlier quoted context omitted.

> 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 res…

Your website doesn't seem to be reachable.

Sorry, there was an outage this morning for a few hours, but it's back now.

Re: The future of web software is HTML over WebSockets

#319

Post by toomim »

anderspitman wrote: post #316
toomim wrote: post #224

Earlier quoted context omitted.

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

Thanks. Braid looks interesting, but complex and mathy. It's not clear to me what the use cases would be or why I would choose it over SSE or WebSockets for any given problem.

That's good feedback, thank you. I think we'll be able to get clearer use-cases there within the next few months.
Post reply on HN