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

1–10 of 337 posts

Re: The future of web software is HTML over WebSockets

#2

Post by frompdx »

This seams really optimistic and kind of glosses over the subject of scaling out websocket connections apart from this.

Anecdotally, the typical single Rails server process seems to be perfectly happy supporting nearly 4,000 active connections. And you can easily swap in the excellent AnyCable to bump that up to around 10,000+ connections per node by not relying on the built-in Ruby WebSocket server.

That's not a lot of connections on it's own. If you are implementing a chat service you'll still need some form of pub/sub (or something) to glue all of that together when users connect to disparate nodes.

Also

How about client-side validations? Easy. On every input change, round up the form values and send ’em down the WebSocket.

That's just server side validation.

As a disclaimer, I haven't used any of the HTML over WS frameworks the author discusses, but I've spent a fair amount of time dealing with scaling socket connections. It definitely makes the question of scaling horizontally more challenging. I feel like this article really glosses over that aspect.

Re: The future of web software is HTML over WebSockets

#5

Post by Spivak »

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. But now your presentation layer mostly lives on your servers and is doing SSR and pushing data over websockets. It takes real discipline to not commingle the two because you’re right there you could just peak at the database a little smack.

The other hard thing about this approach is that now your frontend presentation servers have to keep their own state since they are the clients now which means they need shared storage of some fashion and likely even shared persistent storage if you really want to take advantage.

Re: The future of web software is HTML over WebSockets

#6

Post by aeoleonn »

Another "The future of is what says it is" without much more than a few paragraphs of explanation.

No diagrams. I don't see much of a comparison between costs/benefits of alternatives.

Nice hypothetical. I didn't read it, because I've seen the format before and I'm getting a bit bored of it.

Whereas if it cited some other engineers/technologists, some studies, some academics, etc., then perhaps I'd be more inclined to read this.

But one person's opinion? Nah. I need an aggregate of opinions to be persuaded to read another "The future of thing..." article.

Re: The future of web software is HTML over WebSockets

#8

Post by hinkley »

I miss having beers with people.

This whole saga feels like one of those things where "I've heard this story before, I think I'll sit this one out and hope it's not too long" situations.

We all prioritize what tech we're going to spend our time on, but I think there's something qualitatively different between, "that could be interesting but I don't care", "That'll never work!", and, "I understand this enough to know it does not meet my criteria for job satisfaction, I'm out. Call me when the Trough of Disillusionment hits."

    So we come back around to Rails, 15 years on from its launch…
I think turbolinks hit too close to the AngularJS launch, and got swamped. People who were trying to make everything happen with jQuery skipped straight to Angular. Now Elixir is trying to resurrect turbolinks-plus in Phoenix.

Re: The future of web software is HTML over WebSockets

#9

Post by treve »

We are heavy into REST and HATEOAS. This, coupled with React SPAs has worked really well for us.

The HATEOAS client we use/build has an cache/event system that will emit to subscribers (via react hooks) when a resource is stale, and needs to be refreshed.

After putting this all in place, I realized that now I just need the server to emit those 'stale' events via Websockets, and suddenly my SPA + API is a real-time multi user system with nearly no changes required in either server or client.

This made me wonder, why aren't we just always pushing the entire resource state over websockets. Use websockets to let clients indicate which resources they are interested in, and let the server keep pushing state back to the client.

This solves a number of problems that plain HTTP has:

1. We can't really push/subscribe well. It's not very natural.

2. The HTTP cache kinda sucks, because we don't have programmatic access. Simple example: Doing a DELETE on a resource should expire the cache of the parent collection. There's a good HTTP header to indicate this, but no good way to tell the browser cache to delete the cache entry, so we end up building our own caching layer.

3. Compound requests suck because HTTP caches and clients don't understand them.

But we can still keep using REST fundamentals. Things have URIs, features are discoverable, relationships are expressed with links.

Something about this also feels terribly wrong though. Do we really want to reinvent parts of HTTP over websockets? HTTP is highly optimized, what kind of performance problems are we gonna run into?

Re: The future of web software is HTML over WebSockets

#10

Post by hinkley »

aeoleonn wrote: post #6

Another "The future of is what says it is" without much more than a few paragraphs of explanation. No diagrams. I don't see much of a comparison between costs/benefits of alternatives. Nice hypothetical. I didn't read it, because I've seen the format before and I'm getting a bit bored of it. Whereas if it cited some other engineers/technologists, some studies, some academics, etc., then perhaps I'd be more inclined t…

The guy I learned about 'mis en place' from had coined a term, "retro-grouch" for people who loudly insist on a nostalgia for old technology.

When the Trough of Disillusionment hits, us old farts pop out of the woodwork to say "see, told you so" whether we were right or wrong.

Post reply on HN