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

91–100 of 337 posts

Re: The future of web software is HTML over WebSockets

#91

Post by benzible »

nickjj wrote: post #77
skullum wrote: post #35

Earlier quoted context omitted.

Phoenix live view (anything on BEAM really) maps each ws to a BEAM process so scaling to 10000+ connections is both cheap and built-in

But LV is still in its infancy and there are very real implications of using websockets that are unrelated to open connections. Just the other day someone posted on the Elixir forums about live_redirect causing 2 network round trip connections[0]. Basically there was double the latency to transition between pages due to this "bug". I air quoted "bug" because it's working as intended, it's just not optimal. The creato…

When did you last use it? Javascript hook support wasn't there early on. The state of the art is the "PETAL StacK" [1] which uses client-side JS for interactions that don't require a roundtrip

[1] https://thinkingelixir.com/petal-stack-in-elixir/

Re: The future of web software is HTML over WebSockets

#92

Post by jamescun »

tschellenbach wrote: post #52
yingw787 wrote: post #49

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?

I've seen nothing to suggest SSE would be (or is even capable of being) deprecated on HTTP/2.

You may be confusing it with HTTP/2 Push, where a server can inform a client of a future resource it will need, which is _de facto_ dead, with only a few real implementations beyond the bare minimum required by the HTTP/2 specification.

Re: The future of web software is HTML over WebSockets

#93

Post by cogman10 »

keithwhor wrote: post #76
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…

As a thought exercise; - What happens if the client’s internet connection temporarily drops? How do you handle client reconnections and retries? - What if the remote server crashes through no fault of your own (AWS server rack catches fire)? How do you ensure a consistent reconnection that preserves application state? These are just two questions that HTTP + Browsers solved decades ago. Websockets are this cool techn…

Here's another one. How do you deploy a new version of your service?

Imagine a few customers open up your site and leave for lunch. Or maybe just a random crawler or bot sitting watching for some piece of information they are scraping.

These sorts of issues can be challenging with stateless connections. I can only imagine how daunting they are with persistent connections.

Re: The future of web software is HTML over WebSockets

#94

Post by Jtsummers »

StellarTabi wrote: post #89
jack_riminton wrote: post #57

Earlier quoted context omitted.

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.

Really? Requiring you to "show your work" was rare in college for me, though typical in K-12. But not showing your work, if you're wrong, means no potential for partial credit in college (for instance, correct process but a lost sign might get you half credit versus no credit).

Unless of course, showing the work was the task (such as writing out a proof) versus a straight computation.

Re: The future of web software is HTML over WebSockets

#95

Post by nom »

carapace wrote: post #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 cha…

I gave the author the benefit of the doubt until I read this part. A request on every input change? Browser-side validation exists for a reason. Even at Google scale this leads to embarrassingly bad UX.

Re: The future of web software is HTML over WebSockets

#97

Post by jack_riminton »

StellarTabi wrote: post #89
jack_riminton wrote: post #57

Earlier quoted context omitted.

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.

It’s not college though is it?

Re: The future of web software is HTML over WebSockets

#98

Post by Animats »

It can work, but it's harder than stateless. The web works with crappy code because the persistent state is in the database, which is of higher quality and stability than the applications. If you have persistent in-memory state server side for each client, the server has to maintain that state correctly. The server has to be much more bug-free.

Also, every background tab in the user's browser now consumes server resources although idle.

You do not need this for your 1 to 5 stars rating thing. Most web pages do not need this. They're rather banal. We have huge overkill in web technologies now. We have WebGL, which is little used, and WebAsm, which is little used, for when you really, really want to have full interactivity in the browser. There are a few nice applications using those, but only Google Earth is mainstream.

Re: The future of web software is HTML over WebSockets

#99

Post by nom »

jack_riminton wrote: post #80
aeoleonn wrote: post #75

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

Seems more like your nerve was touched. If you can't handle critique and do not want attention why are you posting your article here?

Re: The future of web software is HTML over WebSockets

#100

Post by vinay_ys »

mathgladiator wrote: post #81
brundolf wrote: post #65

Earlier quoted context omitted.

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

If your game has limited number (say, < 10) participants per game board, then concurrent updates to shared state etc can be solved with a traditional game state hosting server model. But if that number is higher say 100+ then you need a sharded distributed setup. That's when things get really tricky if you don't keep things simple.
Post reply on HN