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

211–220 of 337 posts

Re: The future of web software is HTML over WebSockets

#211

Post by mikeryan »

bitsen wrote: post #149
cogman10 wrote: post #93

Earlier quoted context omitted.

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.

I bet your ass that at least half of the developers reading HN don’t have caching of JS fully figured out such that when the JS changes server-side and immediately needs reloading on the client side that it does then and there instead of on the next request, the next page refresh, or never because they’ve f’d it up. With server-fed, event-driven pages, you could potentially force refresh.

I would not accept your wager. That being said if this was a “really big problem” I’d bet you that most developers on HN would have an idea how to address it.

Re: The future of web software is HTML over WebSockets

#212

Post by IgorPartola »

pseudalopex wrote: post #194
IgorPartola wrote: post #143

Earlier quoted context omitted.

Are you talking about Reddit, StackOverflow, or something else? I have yet to see a proper web app (not a blog/collection of static pages, but something that does something complex like let you manage inventory, do payroll, do your taxes, monitor sensors in real time, interact with geographical maps, or edit documents) that is done without JavaScript and has even OK UX. SPAs are great because of separation of concern…

When people complain about SPAs it's because they're slower or less fit for the task than a collection of mostly static pages.

You can build a poor UX with either technology. That does not to me condemn the technology itself. If a technology makes it easy to create a bad UX that may be grounds for condemning it. I have written horrible SPA code in my early career using nothing but straight up jQuery and yeah that can lead to bad UX. I like the way Vue does things and liked the way Angular 1 worked pretty OK. I don’t love React but don’t have anything against it. None of these inherently lead to a bad UX, IMO.

Re: The future of web software is HTML over WebSockets

#213

Post by wokwokwok »

ricketycricket wrote: post #209
Kranar wrote: post #195

Earlier quoted context omitted.

I don't see what's astonishing about it and I'm scratching my head asking the same question. If the answer is that you handle disconnections and reconnections the same way that the HTTP protocol does it, then what's the purpose of HTML over web sockets? You basically end up with a half-assed, buggy, and potentially insecure reimplementation of HTTP running over web sockets running over HTTP at that point. Are you goi…

> then what's the purpose of HTML over web sockets? Because you can do things stateless HTML alone cannot do. No one is trying to re-implement HTTP, or even remove it from the equation. What people are trying to reimplement (or rather, replace) is the HTML + JSON:API + React + Redux mess. Websockets is a means to that end.

Hm... great intentions, but you don’t seem to have actually answered any of the questions from the parent comment.

Unfortunately, great intentions alone won’t make this work; someone has to actually answer the hard questions about how it’s going to work too.

All the answers I’ve seen so far trying to answer them have been vague hand waving...

That doesn’t leave me with much confidence.

Re: The future of web software is HTML over WebSockets

#214

Post by rmrfrmrf »

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…

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 objects going over the wire. You'd probably want some extra metadata attached to the objects (e.g., a uuid field and an ack field containing the last action's uuid) and youd have to deal with all of the usual synchronization problems in your middleware, but you'd have a solid starting point, at least.

Re: The future of web software is HTML over WebSockets

#215

Post by ricketycricket »

cortesoft wrote: post #207
dnautics wrote: post #120

Earlier quoted context omitted.

> 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. Seriously, try phoenix liveview if you haven't already. These problems of dealing…

Isn’t the issue, though, how do you scale this out? HTTP app servers are great... you can add and remove them at will, based on load, and customers never know the difference, because it only takes a few seconds after not accepting new connections for the existing ones to drain. If you instead have servers holding state, those servers become a lot less ephemeral. In addition, HTTP has built in caching, which is a HUGE…

dnautics isn't wrong. Even the issues you bring up are addressed by Erlang/OTP. Distributed Erlang with 10K nodes, hot code reload, etc.

Re: The future of web software is HTML over WebSockets

#216

Post by ricketycricket »

wokwokwok wrote: post #213
ricketycricket wrote: post #209

Earlier quoted context omitted.

> then what's the purpose of HTML over web sockets? Because you can do things stateless HTML alone cannot do. No one is trying to re-implement HTTP, or even remove it from the equation. What people are trying to reimplement (or rather, replace) is the HTML + JSON:API + React + Redux mess. Websockets is a means to that end.

Hm... great intentions, but you don’t seem to have actually answered any of the questions from the parent comment. Unfortunately, great intentions alone won’t make this work; someone has to actually answer the hard questions about how it’s going to work too. All the answers I’ve seen so far trying to answer them have been vague hand waving... That doesn’t leave me with much confidence.

You are welcome to actually look at the code for any of these solutions.

Here is the documentation for Phoenix channel authentication (what Phoenix Live View is built upon): https://hexdocs.pm/phoenix/channels.html#using-token-authent...

Additionally, here is some documentation on the security considerations specific to Live View: https://hexdocs.pm/phoenix_live_view/security-model.html

Searching can probably find you more information.

Re: The future of web software is HTML over WebSockets

#217

Post by erinan »

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…

The answer as often is... "it depends".

Should you run an unindexed query on every keystroke of a text input of a form for every user? No.

But if you're not a junior dev, you'll know not to do those things and you'll know to debounce the text inputs, plus maybe only query the DB is the input text is longer than n characters for example. And you'll use a GIN index at first in your Postgres DB for fast text search.

It might all sound a bit insane but I believe that everyone should give Phoenix/Liveview a try. That stack can scale and it works amazingly well even on a cheap Heroku dyno.

Re: The future of web software is HTML over WebSockets

#218

Post by querulous »

ricketycricket wrote: post #215
cortesoft wrote: post #207

Earlier quoted context omitted.

Isn’t the issue, though, how do you scale this out? HTTP app servers are great... you can add and remove them at will, based on load, and customers never know the difference, because it only takes a few seconds after not accepting new connections for the existing ones to drain. If you instead have servers holding state, those servers become a lot less ephemeral. In addition, HTTP has built in caching, which is a HUGE…

dnautics isn't wrong. Even the issues you bring up are addressed by Erlang/OTP. Distributed Erlang with 10K nodes, hot code reload, etc.

the only people who think distributed erlang is good are people who have never done anything nontrivial with it

Re: The future of web software is HTML over WebSockets

#219

Post by johndoe42377 »

Oh, decades old client-server model, who would have thought.

Let me guess. Protocols should be binary and stateless, like telecom industry and Erlang is doing.

Pure functions on a server side, share nothing, fail fast, all the principles behind Erlang all over again.

What else? Oh, relational databases as storage backends. Can't believe it.

Re: The future of web software is HTML over WebSockets

#220

Post by thwarted »

mbreese wrote: post #200
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…

I see websockets as the endpoint for trying to fix two problems in HTTP 1.0 that has been simmering for over two decades. For all of the stateless goodness that HTTP is, in order to have user-specific content, you need to know who you're talking to. The hack to fix this was cookies. Instead of using a traditional stateful protocol (which could have kept track of the logged in user), we had a stateless protocol where…

Why isn't an identifier included in each request ("a cookie") not a valid way to track state across requests? It's the solution that makes sense with an otherwise stateless interaction. With a persistent connection, you don't need to send that with each interaction, but the RIP:RPORT:LIP:LPORT tuple becomes the "cookie" that identifies the client or session.

> That still leaves us with the problem of Cookies. ... But, if I could avoid having every website yelling at me about using cookies, I'd happily adopt a Websocket architecture, if that's what it took.

This is a red herring. If "the problem with cookies" is that websites yell at you about using cookies, that's a legal issue with the requirement to notify users they are being tracked. This "problem" of being yelled at didn't exist before the legal requirement.

Moving the transport to websockets (layered on top of HTTP, layered on top of TCP) doesn't get rid of the legal requirement for notification or opt-out. It just buys some time until the law catches up and says that the state management you're using with websockets is also subject to tracking notification and opt-out.

Post reply on HN