Live data from Hacker News

The future of web software is HTML over WebSockets

alistapart.com

61–70 of 337 posts

Re: The future of web software is HTML over WebSockets

#61

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…

Got a question for you -

I'm making a chat bot thing (https://www.brian.bot/) and have added socket-based web chat... but I don't even know how to phrase the question of "how do I horizontally scale the socket connections".

Webchat Server Slack. Once I have more than one server dyno (heroku), then I can't ensure that the Slack event hits the dyno with the corresponding socket connection.

Thoughts / tips?

Re: The future of web software is HTML over WebSockets

#62

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…

> HTML over WebSockets is nice, but what is better is reactive data binding over the socket. Let the browser maintain a DOM tree that templates over a JSON object, then reactive-ly update and it's an amazing experience. You have minimal data transfer, and minimal rendering updates. There is a great deal of power in having your UI be a stateless function over a giant JSON object.

Interesting that you're exploring this idea in the context of board games. I implemented[0] a similar idea while making a browser-based magic the gathering interface. Basically send commands to update the server state (a big JSON object), and the server does state diffs per client and sends lz compressed JSON patches. Worked quite well, but I haven't played with it for a couple years.

[0]: https://github.com/anderspitman/pojo_flow

Re: The future of web software is HTML over WebSockets

#63
post #2

This seams really optimistic and kind of glosses over the subject of scaling out websocket connections apart from this. Anecdotally, the typical single Rails server process seems to be perfectly happy supporting nearly 4,000 active connections. And you can easily swap in the excellent AnyCable to bump that up to around 10,000+ connections per node by not relying on the built-in Ruby WebSocket server. That's not a lot…

It is also important to note the latency in these connection. Generally speaking 4000 Active connection you are looking at 150ms+ for 98th percentile already. Which is bad to be frankly honest.

( Results were from 2016, so may be things has improved )

Re: The future of web software is HTML over WebSockets

#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. Instead of managing the state of your app you’re now managing the state of your app and a connection to a remote server. HTTP is a stateless protocol on top of a stateful socket connection. It wasn’t designed this way by accident.

I’m all for new engineers building SPAs creating exciting new libraries, but HTML-over-websocket has been rehashed at least three times over my professional career so far and it’s not even that long.

Don’t get me wrong — websockets have their use cases. Multiplayer online experiences pretty much require them. It’s just that HTTP isn’t fundamentally broken, and by engineering HTML over websockets you’ll almost universally find yourself building protocols to abstract the state away... re-engineering HTTP in the process.

It’s certainly a fun project which I have personally worked on. But I’m not sure it has legs outside of that. Open to being proven wrong, the authors of HTTP aren’t infallible.

Re: The future of web software is HTML over WebSockets

#65

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…

> The key thing to tackle is dealing with the server side state

The core problem of web UIs has always been managing state. People like statically-rendered pages because most state gets kept in a) the URL, and b) transient HTML elements, and both are highly visible and easy to deal with in robust ways. When you're forced to have server-side state it's exceptionally painful, but people usually just avoid it altogether which in most cases pushes things towards the virtue of having less state anyway.

For complex UIs with lots of little interactions the above story doesn't really work, so we've invented state management systems for the client. Managing complex state still sucks, but it sucks less with these tools.

Sounds like this approach is just moving that state store back to the server, with a greased pipeline so it isn't so horribly painful to add new pieces of state even though both sides are involved. But you'll still face all the same problems you face with a front-end store: transientness, cache-clearing, even modeling is hard when you're dealing with a big blob of mutable state. And there will be the additional challenge of associating this stuff with a user (which you get for free on the front-end, even with modern state stores).

> Let the browser maintain a DOM tree that templates over a JSON object, then reactive-ly update and it's an amazing experience. You have minimal data transfer, and minimal rendering updates. There is a great deal of power in having your UI be a stateless function over a giant JSON object.

> this is where I have my shitty idea of a programming language for board games

It's funny, I started building a web-based board game to play with family during quarantine, and I landed on this exact approach totally by coincidence :) I'm using polling requests instead of websockets because I'm lazy/it doesn't need to scale, but it's the exact same idea where the server just publishes a giant JSON object of state and the clients are pure functions of it (and send messages to the server to mutate it). I wonder if there's some aspect of board games that pushes one towards that line of thinking.

Re: The future of web software is HTML over WebSockets

#66

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…

This sounds like what Microsoft were trying to do 15 years ago with webforms: the browser was treated like a dumb terminal with the UI rendered on the server and pushed to the client.

The UX back then was horrible, however technology has come a long way since.

Re: The future of web software is HTML over WebSockets

#67
This is just crazy.

> Want a hyper-responsive datalist typeahead that is perfectly synced with the database? On every keystroke, send a query down the WebSocket and get back precisely the changed set of option tags, nothing more, nothing less.

> How about client-side validations? Easy. On every input change, round up the form values and send ’em down the WebSocket. Let your server framework validate and send back changes to the HTML of the form, including any errors that need to be rendered. No need for JSON or complicated error objects.

If you're not Google-scale this is just a good way to DDOS yourself, no?

Re: The future of web software is HTML over WebSockets

#68

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…

> The key thing to tackle is dealing with the server side state The core problem of web UIs has always been managing state. People like statically-rendered pages because most state gets kept in a) the URL, and b) transient HTML elements, and both are highly visible and easy to deal with in robust ways. When you're forced to have server-side state it's exceptionally painful, but people usually just avoid it altogether…

> I'm using polling requests instead of websockets because I'm lazy/it doesn't need to scale, but it's the exact same idea where the server just publishes a giant JSON object of state and the clients are pure functions of it (and send messages to the server to mutate it).

I like this approach as well, but I do worry that users today expect optimistic updates on the client, and the injection of a X00ms delay would make the app feel sluggish.

Re: The future of web software is HTML over WebSockets

#69
post #59
post #50

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Mise_en_place I think it also relates to operational professionalism and having your tools and toolbox in order ala Adam Savage and Jamie Hyneman from Mythbusters. They both had very interesting relationships with order, process and tooling. I think structuring dev teams around a professional kitchen is really powerful model. All roles are critical, the sous chef, the busser, the prep co…

You can't scale without delegating. And in a crunch is not the time to work out procedures. You do that between. Yeah, it's not a bad model, and you can stretch it pretty far until it breaks.

I think the closest other team arrangements to watch for modeling software around would be theatrical performance and to a lesser extent bands.

Though kitchens are especially interesting as they have pipelines, surges, lots of tasks that can be broken down into a series of steps.

Mythbusters has another interesting aspect in that they came from movie production background, so wall time was really critical, you can't hold up a shooting day to get a better glue formulation for simulated flesh falling off bone.

Part a thing is its structure, but the other part is how it evolves over time and its reaction rates to stimulus.

Agree on the beers.

Re: The future of web software is HTML over WebSockets

#70
This approach definitely has a lot of value for specific use cases. Specifically to get MVP done in a fast way. When you need to scale out, you can still add a SPA later on.

If you combine the approach of WebSockets + dom patching with postgres pg_notify you get some real magic :) In the new IHP framework we provide something like that. We call it Auto Refresh: https://ihp.digitallyinduced.com/Guide/auto-refresh.html

Auto Refresh is activated with a function call inside a controller action, like this:

  action ShowProjectAction { projectId } = autoRefresh do
      project 
The only difference to a normal IHP action is that it has the `autoRefresh` call in front of the do-block.

Once activated IHP will automatically track all tables your action is using e.g. in `SELECT * FROM ...` queries. Once the action sends a response IHP will start watching for any kind of `INSERT`, `UPDATE` or `DELETE` statement to all the tables used by your action using pg_notify.

When the page is rendered a small JavaScript function will connect back to the IHP server using a WebSocket connection.

Whenever an `INSERT`, `UPDATE` or `DELETE` happens to the tables used by your action IHP will rerun your action on the server-side. When the generated HTML looks different than the HTML generated on the initial page load it will send the new HTML to the browser using the WebSocket connection. The JavaScript listening on the WebSocket will use the new HTML to update the current page. It uses morphdom to only touch the parts of your current DOM that have changed.

Here's how this looks in the real world: https://twitter.com/digitallyinduce/status/13207288333943808... Some use cases where this really shines:

- interactive dashboards (e.g. showing the current status of job queue)

- simple user chat systems (you can send messages using normal form submission, as long as auto refresh is enabled this works like a SPA)

- building a twitter clone, the feed will automatically add new content as it's added to the database

We're using this approach in production since last year and it saves an incredible amount of development time.

Post reply on HN