The future of web software is HTML over WebSockets • Hacker News Board

Re: The future of web software is HTML over WebSockets

#331

Post by viklove » Mon, Mar 01, 2021, 6:04 PM UTC

anderspitman wrote: post #315

viklove wrote: post #314

Earlier quoted context omitted.

I can, but why would I limit myself to one-way communication when I can have bidirectional communication?

You didn't cite bidi as your reason for choosing WS in your last comment, you cited scaling and node vs ruby. But to answer this new question: * You can have bidi without WS. * Because WS is more complicated.

> You didn't cite bidi as your reason for choosing WS in your last comment, you cited scaling and node vs ruby.

Because I was answering this question: "What's wrong with normal HTTP requests for client->server streams?"

> You can have bidi without WS.

Only by combining HTTP (which doesn't scale because my api server runs rails) and SSE (which does scale). If I want scaling bidirectional communication, I need websockets.

> Because WS is more complicated.

More complicated than SSE? I don't think so.

Re: The future of web software is HTML over WebSockets

#332

Post by da39a3ee » Tue, Mar 02, 2021, 5:11 AM UTC

notjustanymike wrote: post #290

antihero wrote: post #23

Earlier quoted context omitted.

Also: > Do we really believe that every one of our users is going to have a device capable of digesting 100 kB of JSON and rendering a complicated HTML table faster than a server-side app could on even a mid-grade server? Yes. This really isn't hard. Pretty much any smartphone can do this with blissful ease. And it scales horizontally because your server can just worry about getting stuff from the database and handin…

Exactly. Our app renders highly detailed 3D anatomy on the canvas. The largest model is a 1mb json file with 57mb(!!!) Of assets. We've never had a problem with mobile devices, they're shockingly capable.

What countries are your users in?

Re: The future of web software is HTML over WebSockets

#333

Post by da39a3ee » Tue, Mar 02, 2021, 12:47 PM UTC

This doesn't seem kind to people with slow (or expensive) network connections. Note that currently we are on the verge of a point in history where almost every person, even in rural communities in developing countries, has an internet enabled mobile device.

In the SPA model yes, they will have to wait a long time to download the initial JS payload, but that can be cached. Thereafter, if UI updates don't need to talk to the server, they can be computed client-side and the UI can update instantaneously. But in the suggested model, a much larger class of client-side actions would trigger (blocking?) network requests.

Re: The future of web software is HTML over WebSockets

#334

Post by hnedeotes » Tue, Mar 02, 2021, 3:13 PM UTC

Matthias247 wrote: post #327

hnedeotes wrote: post #230

Earlier quoted context omitted.

I'm not going to say web sockets are the silver bullet as I don't think it is, but the "only thing you can save are a few header bytes" is a bit reductionist. If you have authentication then cookies have to be going out also and any other information that has to be kept in order to provide state over a stateless connection. You still need to handshake on each connection (maybe http2/3 bring this down a bit), and you…

> You still need to handshake on each connection You can just use one connection (same as websockets) > and you also don't have bidirectional flow Sure you have. Each request and response has a body, and HTTP bodies are indefinite streams of data. You can do everything in them you like (including running your custom protocol). That's e.g. how gRPC streaming works.

Sure, but doesn't that end up being more complex than web sockets to implement correctly?

And keeping one connection then we're in the same spot regarding the scaling issues as with web sockets right? Or does plain TCP/IP have better support for changing endpoints mid-flight, reconnections and etc?

Although if so I don't understand why there was even the need to come up with Websockets? I personally would love to see a simplification of technology all across OSes, web, etc, but probably there's too much out there to provide a reasonable migration path... It sometimes feels like those projects that you work on in the beginning and then you look at, some years down the line and say, this needs a refactoring with all I've learned in the meanwhile regarding what I'm doing and regarding my understanding of the domain space - but sometimes you can't do it, doing it might not go well or you'll end up in the same place afterwards.

Re: The future of web software is HTML over WebSockets

#335

Post by ric2b » Sat, Mar 06, 2021, 5:15 PM UTC

didibus wrote: post #158

Martinsos wrote: post #108

Earlier quoted context omitted.

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

Not sure what is so hard about a client/server roundtrip? The server side is being broken up into micro-services which makes all server a client/server roundtrip as well. Your DB was always running seperately making it a client/server roundtrip, etc. Maybe I'm missing something, but what aspect of client/server is overly complex? And why is websocket (a client/server roundtrip mechanism) any easier?

>The server side is being broken up into micro-services which makes all server a client/server roundtrip as well. Your DB was always running seperately making it a client/server roundtrip, etc.

The backend is likely all in the same building with a reliable and high-bandwith link between servers.

You can't compare that to a round-trip from the client to the backend.

Re: The future of web software is HTML over WebSockets

#336

Post by ric2b » Sat, Mar 06, 2021, 5:23 PM UTC

mathgladiator wrote: post #28

afavour wrote: post #24

Earlier quoted context omitted.

Scaling is almost always the answer.

Scaling not just technically either, it's also the engineers. Most Web engineers have had their minds bent to the request response model with databases. The key reason is that a game lasts... minutes to hours (ignoring most MMOs), so the state machine makes sense and the risk of failure low. Web devs have to use a database which has state for years.

Plus most games are awful at handling connection issues, you'll be dropped from the game and have to reload the entire map and assets again, often taking 30 seconds or more to rejoin.

I'm not sure we should be taking advice about how to load information on mobile devices with spotty connections from the gaming industry.

Re: The future of web software is HTML over WebSockets

#337

Post by g105b » Sun, Mar 07, 2021, 9:55 PM UTC

da39a3ee wrote: post #332

notjustanymike wrote: post #290

Earlier quoted context omitted.

Exactly. Our app renders highly detailed 3D anatomy on the canvas. The largest model is a 1mb json file with 57mb(!!!) Of assets. We've never had a problem with mobile devices, they're shockingly capable.

What countries are your users in?

San Francisco isn't a country.