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

251–260 of 337 posts

Re: The future of web software is HTML over WebSockets

#251

Post by dynamite-ready »

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…

I have a personal project based on this approach (JSON over Websockets): https://quixical.com/

It appears to work well. Security was tough work though (at least I thought it was). And scaling up, no matter what tech you have access to, can be costly.

Also, determining how to handle disconnections is quite an interesting UI problem. Auto reconnect might be an option, but then you need to think about a retry policy. And it can be harder than you think... Mobile phones drop connections with surprising frequency, so it's worth thinking about very early on.

Re: The future of web software is HTML over WebSockets

#252

Post by querulous »

hydroxyethane wrote: post #244
querulous wrote: post #218

Earlier quoted context omitted.

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.

i'd encourage everyone thinking about using it to go read the code (it's fairly approachable) but in short it just connects each node in the cluster to each other node in the cluster via a tcp connection and sends packets between them. there's almost nothing as far as protocol, queue management, congestion control or traffic management. it's discovery mechanism is just shipping lists of peers around. pretty much any competent programmer with networking experience could put together something comparable

it works okay in small clusters on reliable low latency networks but it's not a replacement for an actual network mesh

there have been attempts to fix it but none have really found adoption. i think this is the most notable: https://lasp-lang.readme.io/docs

Re: The future of web software is HTML over WebSockets

#253

Post by dilyevsky »

Skunkleton wrote: post #226
zajio1am wrote: post #199

Earlier quoted context omitted.

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

They are asymmetric because the are provisioned that way. IE it was done intentionally.

This. But also majority of people are (or were, before covid and the whole wfh thing) consumers of content not producers so that uplink would have terrible utilization anyway

Re: The future of web software is HTML over WebSockets

#254

Post by ymolodtsov »

cpill wrote: post #136
ehayes wrote: post #37

Earlier quoted context omitted.

Turbo[links], Stimulus, etc. ARE non-blocking background updates. It's HTML over the wire instead of JSON. [1] I don't think this is what you think it is. [1] https://hotwire.dev/

since when is HTML lighter than JSON?! this use case was what propelled JSON into the mainstream.

The idea is that HTML is just slightly heavier but the advantage is you can render it on the server and don't need all that middleware and serialization layer.

Re: The future of web software is HTML over WebSockets

#255

Post by dynamite-ready »

thwarted wrote: post #220
mbreese wrote: post #200

Earlier quoted context omitted.

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…

This is an aside, but to my mind, when necessary (when you're storing user data) devs should be transparent about how that data is stored. Websockets won't necessarily mean you avoid persisting state on the browser.

In fact, you'll probably find you'll need to store some tokens on the client, somehow, just to secure the client/server connection.

Re: The future of web software is HTML over WebSockets

#256

Post by vagrantJin »

IgorPartola wrote: post #184
vagrantJin wrote: post #177

Earlier quoted context omitted.

> Why should web apps be inferior? Inferior compared to what? I'm not going to call your statement nonsense but unless you have proof that SPAs make up the majority of the websites/web apps online today, I'm afraid I must disagree. Frontend dev is a hot mess of garbage JS cobbled together to make a psuedo native experience. > but something that does something complex like let you manage inventory, do payroll, do your…

I’ll give you two counter arguments and if they don’t work I think our best bet is to agree to disagree. First, I think your premise that apps are not what the web was built for is flawed. Sure, this isn’t what the web was built for, same as the Internet wasn’t built for the web, and the phone and cable lines were built for the internet, and so on. The web had a vision that changed mid way. No we can either try to go…

I'll use an analogy. We web developers are building a boat using a 1992 Toyota Hilux as the hull.

Top Gear proved it was well and truly possible. It's a popular mode of transport. It carries things. It has an engine and a mostly metal body.

It still isn't quite a boat

Web apps can walk and talk like native apps, but they aren't. Sure one off things like a Facebook or spotify or meme generators can rightfully be served from a web app - but applications for computing and getting work done?

Oh and don't forget about mobile devices - what amount of web apps do you prostulate people use there?

> SPA will be a cleaner architecture AND provide better experience to the user.

This. This is nonsense.

Re: The future of web software is HTML over WebSockets

#257

Post by ivanb »

inopinatus wrote: post #154
snejad123 wrote: post #125

Earlier quoted context omitted.

it's difficult to keep up with the design expectations of the modern web with just HTML and CSS. It's possible but extremely difficult to create a "modern" experience with just html. Just like how we don't build houses with mud-bricks anymore even though it's easier than steel and wood.

On the contrary, I generally browse with JS disabled and there's a strong correlation between sites for which this is existentially problematic and sites whose content or utility are garbage. I have a personal toolkit of components I call "you might not need Javascript". Dropdowns, slideovers, toggles, modals, tabs, accordions, autocomplete, lightboxes, all with nice transition animations, and all in pure server-rend…

> A couple of times a year, I'll re-read through the HTML LS and CSS specifications.

What is HTML LS?

Re: The future of web software is HTML over WebSockets

#258

Post by conradfr »

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…

The purpose is to render your page the "old way" but having the dom updated like an SPA.

It works for certain things and not for others. So, it's not "the future of web software" like the title says, it's one additional possibility for when it makes sense.

Re: The future of web software is HTML over WebSockets

#260

Post by dynamite-ready »

Spivak wrote: post #5

Nice to see that we’re back to thin clients again but I don’t think it addresses why SPAs backed by JSON APIs caught on which is that you got dead simple cross-platform development when every UI was just a porcelain over your backend. The missing piece here is that you still need those platform-agnostic APIs and an absolutely clean separation of your backend with all the business logic and your presentation layer. Bu…

I agree. Also, server compute is expensive, while client side resources are relatively abundant, and designed for graphics processing... Unless your program absolutely requires server side rendering, then technically, it might be cheaper not to do it. Especially when sending messages over websockets.
Post reply on HN