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

231–240 of 337 posts

Re: The future of web software is HTML over WebSockets

#231

Post by fogihujy »

blendergeek wrote: post #223
njharman wrote: post #206

Earlier quoted context omitted.

If your server is done 20 times in 10 min, replace your incompetent eng, ops, service provider. A feature that protects from ridiculously unlikely problem is no feature. It is over engineering

> If your server is done 20 times in 10 min, replace your incompetent eng, ops, service provider. You could have incompetent engineers or you could have bad internet. The user could be on a train that is going in and out of tunnels. Or the user could be in a house using WiFi and the microwave could be causing interference.

"Replace the user". ;)

Re: The future of web software is HTML over WebSockets

#232

Post by cutler »

Martinsos wrote: post #108
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…

Do you have any preferences regarding a direction to simplify web development, remove some of the complexity introduced with client-server separation?

PHP has its uses. Stateless request/response model with shared nothing can act as a kind of immutability. Facebook scaled for the first couple of years with just PHP 4 functions, arrays and templated HTML. The Ajax came later.

Re: The future of web software is HTML over WebSockets

#233

Post by coldtea »

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…

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

Then again, it wasn't designed this way to build applications with, either. It was designed to serve documents (the HT in HTTP).

Re: The future of web software is HTML over WebSockets

#234

Post by coldtea »

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…

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

Why would you? Nobody seems to ensure that with regular SPAs anyway...

Re: The future of web software is HTML over WebSockets

#235

Post by coldtea »

Kranar wrote: post #195
m00x wrote: post #193

Earlier quoted context omitted.

I'm astonished that people are asking these questions while there's obvious answers like this. WSs aren't a magic wand, they just allow you to do more with the same.

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…

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

The purpose is in the things explained well in TFA: single source of truth, no replicated state, simpler development, and so on...

Who said the purpose would/had to be in handing "the server caught fire" scenarios?

Re: The future of web software is HTML over WebSockets

#236

Post by coldtea »

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.

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

People did better than that, they already built applications with this model.

Re: The future of web software is HTML over WebSockets

#237

Post by josevalim »

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…

> The creator of Elixir mentioned it was doable to fix the issue but when an issue was open on GitHub[1] it was shot down with a "this is a known tradeoff, you'll need the 2nd route trip for the websocket"

Please Nick, you can literally check your links to see this is inaccurate. I mentioned a solution after the issue was closed - and not before as you describe. And I figured out the solution *with Chris*, as I clearly mention in my comment.

And then later on:

> dive into the source code that I can't read very well because there's a lot of macros

There are like 8 macros...

> since LV is a pre 1.0 release the docs aren't really written up yet since stuff is changing all the time

Seriously? No one has ever said this is the case. Just go to the [official docs](https://hexdocs.pm/phoenix_live_view). All public functions are properly documented, there are introductory guides, etc. Sure, we don't have official screencasts but that's something we rely on the community to step in: Pragmatic Studio has a fantastic course on LiveView (which I was involved as a sounding board), there is Grox.io, etc. And it hasn't stopped either, a new book was literally announced today.

There are other inaccuracies in the comments below but honestly I don't have the energy to go down this rabbit hole again.

Re: The future of web software is HTML over WebSockets

#238

Post by akshaybhalotia »

zajio1am wrote: post #199
c-linkage wrote: post #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 serv…

> NAT became a poor-man's firewall and effectively blocked peer-to-peer connections making it difficult to host a server at home. Most ISPs (with the exception of very small ones) until recently assign one public IP address per customer and NAT is done on home router. With this setup it is not hard to host a server at home - it is just one rule on router to NAT all incoming connections to that server. Many SOHO route…

Not necessarily true for all countries and ISPs. Eg in India, you have to specifically request for and pay approx $55/mo for a connection with static IP whereas regular broadband connections (150 Mbps, 500 GB data, FTTH) start as low as $12/mo.

Re: The future of web software is HTML over WebSockets

#239

Post by galaxyLogic »

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 leave the browser waiting for a fetch-response from the server. The server responds only later when the page that is open in the browser was updated on server. Seems to work much of the time, but sometimes it seems Chrome closes the connection after a timeout and shows a network error in the dev-tools. FireFox not.

I assume web-sockets could make it work more robustly.

Re: The future of web software is HTML over WebSockets

#240

Post by dnautics »

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

I work on a system with an distributed erlang service mesh.
Post reply on HN