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

191–200 of 337 posts

Re: The future of web software is HTML over WebSockets

#191

Post by rraihansaputra »

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. Let the browser maintain a DOM tree that templates over a JSON object, then reactive-ly update and it's an amazing experience. You have minimal data transfer, and minimal rendering updates. There is a great deal of power in having your UI be a stateless function over a giant JSON object.

I think a lot of the "best-practices" for SPA is trying to do this. But as streaming the data transfer is not yet common, the data is abstracted as a giant JSON object to be a parameter of the UI as a stateless function (React+Redux/MobX/etc, Vue+VueX). When enforced correctly on the project level, what's complicated _is_ syncing the data to the server. I think you'll like Supabase's subscription approach to reactively bind the JSON for the client.

I think a separation between the info-web (document-content heavy) and the app-web (needing stateful data sync) will be more clearly defined in the next few years. Nobody likes trying to sync data between the client and server over HTTP calls; we just have to wait for streaming to be the norm for the app-web (and native apps, ofcourse).

Re: The future of web software is HTML over WebSockets

#192

Post by CyanLite2 »

I'm building a new SaaS with Blazor Server-Side, and it's super productive and I simply don't get the fascination with WebAssembly. Sure, I use vanilla JS for things like field validations, but server-side rendering is so fast with it that its barely impercetible.

Re: The future of web software is HTML over WebSockets

#193

Post by m00x »

conradfr wrote: post #128
keithwhor wrote: post #76

Earlier quoted context omitted.

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…

You restore the state like you would on a SPA or regular server side rendered page. A crash or someone hitting refresh on his browser is not that different in this respect.

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.

Re: The future of web software is HTML over WebSockets

#194

Post by pseudalopex »

IgorPartola wrote: post #143
lmarcos wrote: post #135

Earlier quoted context omitted.

How so? One of the most popular (if not the most) websites for developers out there is pretty much HTML + CSS. JavaScript is used, but minimally. "Modern" experience is not necessarily the same as "good" experience. Good old server side rendered pages are fine; SPAs are being built just because "we can", not because they are actually needed (sure, in some cases,SPAs are needed, e.g., chat sites).

Are you talking about Reddit, StackOverflow, or something else? I have yet to see a proper web app (not a blog/collection of static pages, but something that does something complex like let you manage inventory, do payroll, do your taxes, monitor sensors in real time, interact with geographical maps, or edit documents) that is done without JavaScript and has even OK UX. SPAs are great because of separation of concern…

When people complain about SPAs it's because they're slower or less fit for the task than a collection of mostly static pages.

Re: The future of web software is HTML over WebSockets

#195

Post by Kranar »

m00x wrote: post #193
conradfr wrote: post #128

Earlier quoted context omitted.

You restore the state like you would on a SPA or regular server side rendered page. A crash or someone hitting refresh on his browser is not that different in this respect.

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 going to do session management and identification by issuing a unique identifier as well? Is that unique identifier going to be valid in perpetuity or have a an expiry date? Is it going to be valid and secure across all sub-domains or will it be prone to cross site scripting attacks?

Re: The future of web software is HTML over WebSockets

#196

Post by hn_throwaway_99 »

jayd16 wrote: post #183
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…

>In essence, I am building a DIY database such that people connect directly to the database and get that sweet giant JSON object along with a stream of updates Isn't that Firebase DB?

Yeah, that was my reaction to a lot of the discussion on this article. Firebase Realtime DB has been one of the most amazing pieces of software I've used. I don't have to worry about the connection details at all, I just have this data store that feels like a local DB except it's "magically" synced with the server, and any other users of the DB "magically" get updates when I change it.

Re: The future of web software is HTML over WebSockets

#197

Post by sshumaker »

This approach also completely overlooks the fact that most sophisticated products are multi-client: web and native mobile app. In this world you want APIs that can mostly be shared across platforms, as mobile should operate as more of a thick client anyway given network latency. So supporting HTML over websocket as another client is pretty incongruous from an architectural perspective.

Re: The future of web software is HTML over WebSockets

#199

Post by zajio1am »

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 routers support such setup. Alternatively, the server can just work as a router.

> This incentivized early ISPs to offer only asymmetric connections that pushed users towards a consumer-only service that crippled early Internet protocols.

Asymmetric connections are offered because many last-mile technologies (like ADSL and cable modem) are asymmetric on link-level - they use different bandwidth allocations for upstream and downstream.

Re: The future of web software is HTML over WebSockets

#200

Post by mbreese »

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…

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 the user basically had to present credentials with each request (also, HTTP-AUTH).

The second issue was so problematic that it made it into HTTP 1.1 two years later. Because a stateless protocol was used, if you wanted to download say, a document and a linked image in the document, in HTTP 1.0, you needed to make two requests. Back when each web page was predominantly text with few graphics, this was okay. When we moved to more graphical (albeit table-based) layouts, this was horrible. So, HTTP 1.1 ushered in Connection: keep-alive to allow for the same connection to be used for multiple requests. You still had to make individual requests, but at least you didn't have the overhead of setting up multiple TCP connections.

HTTP isn't fundamentally broken, but it is a kludge. The most painful parts of HTTP were also the most "stateless" aspects. I agree I don't understand why HTML over Websockets is a (big) thing. It doesn't make much sense to me either. Then again, I was also doing dynamic updates (with javascript pulling in HTML, not XML) before A List Apart (hello again) coined the term AJAX.

But let's not just say that HTTP is a perfect stateless protocol. It isn't. It was never "designed this way" -- it was patched up with quick fixes during the late 90's that we've been stuck with ever since. Websockets is the latest attempt to fix this problem. HTTP/2 and /3 don't really do anything to address maintaining session state, but focus on making individual request more efficient (roughly). That still leaves us with the problem of Cookies. Websockets have their own issues (scaling for one), but adopting the approach mentioned in the article doesn't mean that you have to completely abandon the rest of HTTP. But, if I could avoid having every website yelling at me about using cookies, I'd happily adopt a Websocket architecture, if that's what it took.

Post reply on HN