Live data from Hacker News

The future of web software is HTML over WebSockets

alistapart.com

81–90 of 337 posts

Re: The future of web software is HTML over WebSockets

#81

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 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 is that I'm going to make a UI editor so I can make faster progress on designing the board game UI and then build a minimal set of controls to do data binding. The key is to get into the fight about what is the polish needed, and what reasonable escape hatches are needed.

> I wonder if there's some aspect of board games that pushes one towards that line of thinking.

There is, they are exceptionally complicated!!! SO COMPLICATED! The key is the implicit state machine between all the players, and you just can't quickly model it with traditional tools and databases. All it takes is a single card or game piece (which changes rules) to invalidate EVERYTHING. Games are exceptionally messy!

Re: The future of web software is HTML over WebSockets

#82
post #12

Earlier quoted context omitted.

Sure, it's server-side validation – which is great, and works well. And now it works without a full page submit and reload. That's a huge benefit.

Which you can do already for over a decade with AJAX.

Yup. And DHTML over a Java applet before XMLHttpRequest. 1999 at least, iirc.

Re: The future of web software is HTML over WebSockets

#83

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…

I feel like websockets get waaay too much hype and attention compared to SSE, especially for use cases that are barely interactive at all.

Re: The future of web software is HTML over WebSockets

#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 server at home. This incentivized early ISPs to offer only asymmetric connections that pushed users towards a consumer-only service that crippled early Internet protocols. With the World Wide Web being "the" reason people got on to the Internet in the first place, early NAT-enabled routers focused only on HTTP tunneling, so completed protocols that required inbound connections were finally killed off.

Who would have thought that a small IP address space could result in a mass protocol extinction event from which only HTTP and HTML would survive....

Re: The future of web software is HTML over WebSockets

#85

Earlier quoted context omitted.

I've used HTTP/2 SSE for TinyDev (docs.tinydevcrm.com) and I've encountered the need for a reverse proxy and the unidirectional dataflow to be kinda eh, even if it is great in theory. I haven't played around too much with WebSockets though, but IMHO money + traction carries a good deal of weight.

Isn't HTTP/2 SSE being deprecated?

https://stackoverflow.com/questions/28582935/does-http-2-mak...

Re: The future of web software is HTML over WebSockets

#86

Earlier quoted context omitted.

I'm just sick of low effort articles where the author appoints themselves oracle/definer of the future. It results in devolution of knowledge and a disrespect of the attention of intelligent people. "he could be right" -- what a waste of a statement unless it is followed up by any premise. He could right... Ok, that's a claim. But based on what?

But you’re the one whose decided to dedicate so much attention to it. If it’s a prediction you don’t agree on just ignore it The fact that it’s touched a nerve is more interesting to me

Wait a sec-- So someone can write an opinion, and that's ok-- but hey: no one critique it, ok?

But if I write an opinion-- that's not ok. But you-- you're allowed to critique my opinion.

_______

Let's apply your logic to your replies:

Well, jack_riminton, It seems like I've touched a nerve.

Why did you feel compelled to comment on my commentary, when you could have just ignored it?

Why are you critiquing my opinion if you're making the case that opinions should not be critiqued (and should simply be ignored if a person is in disagreement)?

______

Ohh.... Now I see. You're the one who posted the article.

Well, everything is very clear now: Simple bias.

______

Note: You never followed up when I questioned the premise of your claim "he could be right." It seems you're not interested in analyzing whether or not he is right. So what's the point of even posting this article?

Yet the purpose of my entire thread is to draw attention to the fact that him being right will not result from conclusions of a poorly contrived, low effort, pop-tech article.

Re: The future of web software is HTML over WebSockets

#87
post #8

I miss having beers with people. This whole saga feels like one of those things where "I've heard this story before, I think I'll sit this one out and hope it's not too long" situations. We all prioritize what tech we're going to spend our time on, but I think there's something qualitatively different between, "that could be interesting but I don't care", "That'll never work!", and, "I understand this enough to know…

I know people loved turbolinks, but the very thought of it gives me nightmares. That kind of tight coupling between server side and client is everything the modern JS ecosystem evolved to get away from. I can see it being useful in a single developer full stack environment to get something up and running. But any kind of long term complicated application development in that paradigm just sounds painful.

> I know people loved turbolinks, but the very thought of it gives me nightmares.

Is it really that bad?

With Turbolinks 5 (and its successor Hotwire Turbo Drive) you can do nothing except add 1 line of JS to your application and reap massive wins in terms of page transition speeds. And this all works without changing 1 line of code on the back-end and it works with all tech stacks.

IMO it's the biggest bang for your buck that you can do to make a website feel good with the least amount of effort.

And now with Turbo Drive you can do the same with form submissions without needing any back-end code and it also works with every tech stack with no special libraries or work to be done server side.

Then Turbo Frames builds upon that to partially update a segment of your page and Turbo Streams introduces websockets for when you want to broadcast stuff or do real-time updates.

It's a great system. Use HTTP for everything except for when websockets makes sense.

Re: The future of web software is HTML over WebSockets

#88

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?

You can use a redis to distribute messages via PUB/SUB. The sockets subscribe to the events that are relevant to them. It can handle thousands of messages a second in a local environment and probably more in a dedicated hosting environment.

Re: The future of web software is HTML over WebSockets

#89

Earlier quoted context omitted.

Clearly I arrive at this piece without the expectation of it defining the future-- I know better than to expect a pop tech piece to deliver to me a view of the future. format: blatantly unoriginal content: not persuasive, underdeveloped effort: very low value: very low "The future of" is a very bold statement. The more cliche it becomes, the more I expect an author to actually outline, in a bold, cohesive, relatively…

But he could be right Why does it annoy you so much?

In college, when you write only "2" for an answer, the teacher doesn't say "hmmmm, he might be right", instead you get an F for not showing your work.

Re: The future of web software is HTML over WebSockets

#90

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…

Also I've seen request/reponse over websockets too many times.
Post reply on HN