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

291–300 of 337 posts

Re: The future of web software is HTML over WebSockets

#291

Post by JamesSwift »

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?

And Realm, and couch/pouch

Re: The future of web software is HTML over WebSockets

#292

Post by mbreese »

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 a red herring. ... that's a legal issue with the requirement to notify users they are being tracked

It’s not a red herring. And it’s not the website warnings that are the issue, it’s the tracking that they have to notify you about. If we didn’t have to allow cookies for basic interactions with websites (like a session cookie), then we wouldn’t need to allow tracking cookies at all. However, because we need to allow session cookies, other sites can then track us.

With a persistent connection/session, this wouldn’t be necessary.

But clearly, there are many other ways to tackle this problem. And the persistent socket connection also has issues. But after thinking about this, I think the company behind the current dominant browser may be a little conflicted about solving this issue. I’m hopeful about Firefox’s new approach.

Re: The future of web software is HTML over WebSockets

#293

Post by jiriknesl »

rafale wrote: post #284
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…

You are over complicating things. UI state should live in the client. Having the server maintain it is not only more complex but will also introduce a latency. Let's say I click a button to delete an item in the list. The button state goes to pressed, list loses focus, button takes focus, button unpressed, delete animation starts on deleted item, translation animations on the other items to slide into its place, new…

"UI state should live in the client." this is wrong and I think you have missed the point of the article.

In server-rendered app, there's nothing like UI state.

There's a request. This request and the database is enough to build response. There is no UI state. Your app can be (and often is) absolutely stateless and restult depends only on request and a state of the storage.

While when you have SPA, API & server, you lose the application state and it's not possible to store the whole app state in the client for many reasons (security, scalability, synchronisation...). So you have to store subset of it. And you have to build a machinery that will do all this synchronization so your states stay in sync. It's double the effort to get 5% improvement.

Re: The future of web software is HTML over WebSockets

#294

Post by gonational »

The Future of APIs is SOAP over UDP.

No kidding though, Poe's Law applies to this article. This shit has gotten out of hand. A List Apart used to be a serious publication; ideas like progressive enhancement and responsive CSS came right out of that publication.

The fact that many folks think this is a good idea paints a bleak picture of the future of web development.

The web worked well before (circa 2010, jQuery, Ajax, etc.). It was just too complicated to make very dynamic pages.

We don't need more inventions. We need to use the inventions we have correctly.

https://xkcd.com/2021/

Instead we got Angular, et al.

The ability to connect DOM elements to state management is great. This was another piece we needed. Unfortunately, this piece was introduced along side a pattern and framework. The former lent credibility to the latter two. This same thing happened when rails came out; rails introduced the ORM to the masses, and offered MVC along side it. The vertically integrated synergies created by these parts allowed rails to soar. In that case, it was a good thing; Rails changed the web for the better, by a long shot.

The rabbit hole that reactive took front-end web developers down over the past decade has been more than destructive, because it happened just in time for the largest growth in new web developers ever. Primarily, this is the reason it was able to happen (the overall reduction in aggregate experience).

These frameworks have taught us a lot of really great individual things, but as whole they have ruined many parts of the web, and they've destroyed the discipline of developers. Now a basic CRUD application is dynamic enough, for many developers, to warrant the use of such frameworks.

You can say what you want about how tremendous this reactive framework or that reactive framework is, but you cannot deny the fact that 75% of websites have hundreds of percent more bugs, and nearly half the web renders a blank page for multiple seconds before anything shows up to the end-user. This is worse than the 1990s. Honest to God, I give up on more than 1/3 of e-commerce transactions these days, because some form of UI fuckery breaks my will. When I open a link and the whole page is white, despite seeing that everything has loaded, I literally close the tab before even having to see the monstrosity that they've created. What's worse is that many developers will create a reactive website that literally does not react; it just changes pages and re-reacts every time a new page loads. SMH...
Tonsky writes great rants about the absolute state of things as well:

https://tonsky.me/blog/disenchantment/

https://tonsky.me/blog/tech-sucks/

Re: The future of web software is HTML over WebSockets

#295

Post by hn_throwaway_99 »

thu2111 wrote: post #263
hn_throwaway_99 wrote: post #196

Earlier quoted context omitted.

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.

How do you implement ACLs and other privacy-related transformations in that model?

You write Firebase Security Rules [1] that restrict access to paths within your database, it's quite awesome. Those rules can be used to implement ACLs and object ownership, and also role-based access according to claims that exist on the JWT of the authenticated user.

[1] https://firebase.google.com/docs/rules

Re: The future of web software is HTML over WebSockets

#296

Post by juskrey »

rafale wrote: post #284
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…

You are over complicating things. UI state should live in the client. Having the server maintain it is not only more complex but will also introduce a latency. Let's say I click a button to delete an item in the list. The button state goes to pressed, list loses focus, button takes focus, button unpressed, delete animation starts on deleted item, translation animations on the other items to slide into its place, new…

The way to eliminate latency with server side state is called optimistic updates.

Re: The future of web software is HTML over WebSockets

#297

Post by IgorPartola »

vagrantJin wrote: post #256
IgorPartola wrote: post #184

Earlier quoted context omitted.

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

I won’t debate your analogy because I think it is flawed for reasons such as you can’t change the fundamental definitions of a car as easily as we can change web standards, as we have done over the past 30+ years.

I will point out that I routinely use Reddit on mobile Safari and it is most certainly a web app. Things like Twitter, Facebook, etc. are also apps, and while you can download a native version, for privacy reasons I prefer their web app counterparts as they are less able to spy on what the rest of my phone is doing.

I will also again point out that Google Maps is a better experience than downloading OpenStreetMaps and setting it up yourself. Even something like Slack and Discord and Google Docs are perfectly good experiences on desktop browsers and require no installation whatsoever. You aren’t really addressing the zero installation point at all and that’s at the crux of why web apps are a thing and their main draw. You quoted my conclusion and called it nonsense without any basis since you provided a straw man argument and didn’t address the main point at all.

Re: The future of web software is HTML over WebSockets

#298

Post by mathgladiator »

rafale wrote: post #284
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…

You are over complicating things. UI state should live in the client. Having the server maintain it is not only more complex but will also introduce a latency. Let's say I click a button to delete an item in the list. The button state goes to pressed, list loses focus, button takes focus, button unpressed, delete animation starts on deleted item, translation animations on the other items to slide into its place, new…

The server isn't maintaining the UI state in my model. Instead, the server is maintaining a single document, and the entire UI view is then predictable based on that.

Think about the nature of a document store, you put data in and data out. You gain concurrency by using compare and set such that multiple requests can compete, but this is expensive. First, you risk conflicts which require re-execution for the losers. Second, you must download the entire object, make a change, then write the entire object back.

The key to what I am doing is that I'm having the language take a message from a durable queue, integrate that message into the document via some code, then emitting a state change out. The client then subscribes to the document's parts to updates its UI state, and as the document changes, so does the UI.

The UI can be much more complicated while the server can be beautifully simple.

Re: The future of web software is HTML over WebSockets

#299

Post by mathgladiator »

juskrey wrote: post #296
rafale wrote: post #284

Earlier quoted context omitted.

You are over complicating things. UI state should live in the client. Having the server maintain it is not only more complex but will also introduce a latency. Let's say I click a button to delete an item in the list. The button state goes to pressed, list loses focus, button takes focus, button unpressed, delete animation starts on deleted item, translation animations on the other items to slide into its place, new…

The way to eliminate latency with server side state is called optimistic updates.

This is a next step for my project as I'm trying to figure out how to generalize client side predictions in a sane way.

Basically, I'm happy with my latency (for board games) which I hope to migrate closer to people as more edge compute offerings emerge. However, I'm wondering what the path is to find some of these ideas in more latency sensitive applications.

The explanation for how the net-code behind Overwatch is a good explanation: https://www.youtube.com/watch?v=W3aieHjyNvw

and I'm just trying to figure out how to build the reactive tree in a way to support it sanely.

Re: The future of web software is HTML over WebSockets

#300

Post by mathgladiator »

dynamite-ready wrote: post #251
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. An…

Security is exceptionally interesting, and it is why my language handles privacy as a first class citizen.

The scaling up is a challenge due to the lack of common investments. It can be made absolutely cheap, and it is way cheaper than polling.

People that dismiss websockets have a point that it throws away decades of wisdom, but the winnings and potential are there. The challenge is curating the right ideas and educating everyone... is hard.

Post reply on HN