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

241–250 of 337 posts

Re: The future of web software is HTML over WebSockets

#241

Post by CamelRocketFish »

> 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.

Maybe in an ideal world where responses are 1ms this would work, but imagine real world, real-time validating user input (ie email) and the user needs to wait before they find out their input is valid.

Re: The future of web software is HTML over WebSockets

#242

Post by morelisp »

ricketycricket wrote: post #222
nickjj wrote: post #133

Earlier quoted context omitted.

> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem? I don't think so but if I'm wrong please correct me. For example, imagine this simple scenario: you load the comment page for this post on HackerNews HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload. You can be sitting here on the page…

The sensible response to that scenario would be: Why did you make HN a Live View? I don't think anyone is suggesting that you make anything a Live View that is more appropriate as plain HTML. If you wouldn't use React, you shouldn't use Live View. I understand you needed an example, but a better comparison would be a heavy SPA with real-time interactivity. In that case, if your server is down your API calls will fail…

> If you wouldn't use React, you shouldn't use Live View.

I have bad news for you about how often most web developers are using React.

Re: The future of web software is HTML over WebSockets

#244

Post by hydroxyethane »

querulous wrote: post #218
ricketycricket wrote: post #215

Earlier quoted context omitted.

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

Could you explain why that is to someone (me) has never done anything nontrivial with it? Thanks.

Re: The future of web software is HTML over WebSockets

#245

Post by hnedeotes »

CamelRocketFish wrote: post #241

> 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. Maybe in an ideal world where responses are 1ms this would work, but imagine real world, real-time validating user input…

Input formatting like, emails, phone, or things that you can know in the frontend, can all be done (and should be) on the client side (many even on html itself although it's a bit lacking in some cases, that would definitively be the ideal although I also don't think html is going to be able to cover all use cases ever - or that it should - but in the end it always seems to be missing just one tiny thing that forces you to write JS).

What you may want to do is to submit changes in case you want to see if an email has been taken already, for instance, to display additional information while the user is writing and this no matter what technology is used would always require a round-trip? No saying that you need that, but it's up to you when implementing deciding on what is the UI/UX you need and take it from there, it's not like it forces you to do that.

(sometimes articles take it a bit too far and end up showing anti-patterns, mixing problems it solves and problems it creates when misused)

Re: The future of web software is HTML over WebSockets

#246

Post by dgellow »

toomim wrote: post #228
mathgladiator wrote: post #16

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…

> 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.

Re: The future of web software is HTML over WebSockets

#247

Post by ecmascript »

hg35h4 wrote: post #14

Everything about this sounds terrible for mobile, lossy or even medium latency connections. Non-blocking background updates are unnoticeable, but imagine your website being jammed like a stuck video every time you click or scroll? He describes a "please wait buffering" future of web software. No thanks.

I had this thought as well, but having used Liveview in Phoenix this really isn't the experience. Since the updates are really small and as long as you do it only when you want updates from the backend anyway the experience is just as smooth as any SPA even on a shitty mobile connection.

Re: The future of web software is HTML over WebSockets

#250

Post by mathgladiator »

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…

You're not being a jerk, but you are applying wisdom. The challenge is that if we don't have the courage to be foolish, then we will not make progress.

All the problems with a stateful connection are solvable, but we have yet to figure out the right way to teach the discipline of doing it right. It is an exceptionally expensive proposition to solve, so most people shouldn't solve it as they will be picking up a huge bill.

The challenge is that HTTP is fundamentally broken for stateful experiences, and people are trying to build that into everything these days. They want shit to update across machines, and polling is exceptionally easy at great cost.

Post reply on HN