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

321–330 of 337 posts

Re: The future of web software is HTML over WebSockets

#321

Post by numair »

nickjj wrote: post #163
conradfr wrote: post #141

Earlier quoted context omitted.

I think ultimately Phoenix and by extension LV just don't have the manpower. LiveWire builds on Laravel which is a massively popular framework on a massively popular language, Laravel itself using components from Symfony that is basically the backend framework with the most contributors in the world. But LiveView may hit 1.0 this year :)

> I think ultimately Phoenix and by extension LV just don't have the manpower. For comparison's sake: - [LivewWire] Caleb (creator of LiveWire) made 1,000+ commits and added 200k lines of code from Jan 2019 to Feb 2021 - [LiveView] Chris (creator of LV) made 700+ commits and added 80k lines of code from Oct 2018 to Feb 2021 - [LiveView] Jose (creator of Elixir) made 450+ commits and added 25k lines of code from Oct 2…

This is an incredibly offensive and insulting comment about people you don’t know, regarding software you openly state you don’t use on a daily basis.

I would care a lot less if we were talking about billionaires building commercial startups, but you’re literally attacking open source contributors. Moreover, my personal experience in using LiveView and interacting with the community has been the exact opposite of yours, so I find your comments to be totally misleading for people who might think that your walls of text have any nuggets of wisdom in them.

I’ve tried a lot of open source software that left me thinking, “wow, what a waste of my time.” For some reason I never felt a need to openly attack the authors of these low-commercial-value-for-the-creator, volunteer-driven projects. You might want to consider directing your critical eye toward the actual problems in this world, rather than volunteer programmers’ projects that didn’t met your personal, highly-opinionated requirements.

The parent comment is Exhibit A for why so many people refuse to get actively involved in the open source software scene, and why so many drop out.

Re: The future of web software is HTML over WebSockets

#322

Post by aeoleonn »

jack_riminton wrote: post #57
aeoleonn wrote: post #33

Earlier quoted context omitted.

Clearly I arrive at this piece without the expectation of it defining the future-- I know better than to expect a pop tech piece to deliver to me a view of the future. format: blatantly unoriginal content: not persuasive, underdeveloped effort: very low value: very low "The future of" is a very bold statement. The more cliche it becomes, the more I expect an author to actually outline, in a bold, cohesive, relatively…

But he could be right Why does it annoy you so much?

The failure with "he could be right" is here:

He could be right because... (these are just generic examples)

- He mentions renowned research by XYZ who has through years of painstaking research concluded (as cited in XYZ peer reviewed journal) that the basis of his argument is sound

- He's an expert in XYZ field, having worked at XYZ company which clearly demonstrates proficiency in XYZ subject material

- He clearly elucidates, citing several researchers and with clear, understandable diagrams how the phenomenon XYZ works

... Yet you make no effort to construct a premise to base your claim upon. Because no real premise exists: the article's author makes no effort to support his own claim about the future.

Re: The future of web software is HTML over WebSockets

#323

Post by jlokier »

bullen wrote: post #289
jlokier wrote: post #134

Earlier quoted context omitted.

The architecture you're describing is awesome. It sounds like the one I was working with ~18 years ago. Except it used HTTP (long polling or comet) instead of HTTP/3 for the transport. And more partial rendering to DOM-diffs on the server side because it was faster than doing it all on the client, but the client still applied diffs. The issues with full DOM state synchronisation, handling network errors and recovery,…

Yes, HTTP/1.1 is awesome but you need to use comet-stream, comet is the same thing as long-polling and it's terrible and was only required because IE broke the XHR standard until IE8!

IE did XHR before everyone else, and many years before there was a standard. It invented XHR; it was shipped in IE4. IE's behaviour defined the standard everyone else copied.

Then other browsers copied it, adding their own quirks. The XHR standard wasn't created until about the same time as IE8 was released. So it's not possible for IE before IE8 to break the XHR standard, as there wasn't an XHR standard before IE8.

Long-polling is still used as a fallback today. The modern alternative is WebSockets, but they do not work reliably in every network environment, either at the client or server side.

Last time I looked, Facebook and Gmail were using long-polling to good effect.

Despite the conceptual ugliness, long-polling when implemented properly works quite well and is extremely reliable. In practice, "quick and dirty" long-polling is not always implemented well, but it's not hard, just takes a little thinking about unreliable networks.

XHR has nothing to do with long-polling particularly, and it doesn't remove the need for long-polling either. Long-polling is usually done with XHR these days, but it can be done easily without XHR, using invisible iframes or dynamic script elements. The latter is called JSONP and you've probably heard of it. SSE can also be used.

All of these things have nothing to do with HTTP/1.1. They work perfectly well over HTTP/1.0, 1.1, HTTP/2 and HTTP/3.

Re: The future of web software is HTML over WebSockets

#324

Post by nickjj »

numair wrote: post #321
nickjj wrote: post #163

Earlier quoted context omitted.

> I think ultimately Phoenix and by extension LV just don't have the manpower. For comparison's sake: - [LivewWire] Caleb (creator of LiveWire) made 1,000+ commits and added 200k lines of code from Jan 2019 to Feb 2021 - [LiveView] Chris (creator of LV) made 700+ commits and added 80k lines of code from Oct 2018 to Feb 2021 - [LiveView] Jose (creator of Elixir) made 450+ commits and added 25k lines of code from Oct 2…

This is an incredibly offensive and insulting comment about people you don’t know, regarding software you openly state you don’t use on a daily basis. I would care a lot less if we were talking about billionaires building commercial startups, but you’re literally attacking open source contributors. Moreover, my personal experience in using LiveView and interacting with the community has been the exact opposite of you…

> Regarding software you openly state you don’t use on a daily basis

Perhaps I was too critical in some of the replies and should have phrased things in a more positive way but I did use Elixir / Phoenix / LV on a daily basis for a pretty long time.

Over the course of those 18 months I'd estimate putting in 250-300 hours of programming time in spurts while writing 3 applications totaling around 9,500 lines of assorted Phoenix / LV code. Not a lot of code by any means, but enough to put a decent dent towards developing the main app I was building which is where I encountered those issues at the time. I have no agenda or reason to make anything up. I want to see Elixir and Phoenix succeed in the end. I just decided to temporarily put it on hold until it gets over the early adopter phase.

Re: The future of web software is HTML over WebSockets

#325

Post by alxndr »

mathgladiator wrote: post #81
brundolf wrote: post #65

Earlier quoted context omitted.

> The key thing to tackle is dealing with the server side state The core problem of web UIs has always been managing state. People like statically-rendered pages because most state gets kept in a) the URL, and b) transient HTML elements, and both are highly visible and easy to deal with in robust ways. When you're forced to have server-side state it's exceptionally painful, but people usually just avoid it altogether…

I'm working on the complex UIs now, and it is a challenge. Fortunately, I can focus on gaming designs which is less complicated. I think the key thing here is figuring out how the UI can be made mostly declarative and a stateless function of the state. I'm drawing some inspiration from https://flutter.dev/docs/development/data-and-backend/state-... and the challenge is the polish to make products great. My strategy i…

the real world is messy, games are a way of identifying the messiness (and then provoking one user to be upset at how the developers chose to model the messy world)

Re: The future of web software is HTML over WebSockets

#326

Post by Fire-Dragon-DoL »

mathgladiator wrote: post #299
juskrey wrote: post #296

Earlier quoted context omitted.

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…

Consider that while a videogame runs on 60fps (or more), a board game runs on frame-per-turn. You would be doing what overwatch is doing in a frame, for an entire turn. That's way easier: if a turn is out of sync, revert to the previous one!

Re: The future of web software is HTML over WebSockets

#327

Post by Matthias247 »

hnedeotes wrote: post #230
Matthias247 wrote: post #161

Earlier quoted context omitted.

A round trip is a round trip. Software can’t beat physics. If you want to do requests in parallel, http 2 and 3 can do them just fine. If it’s sequential, you won’t see a huge difference between something on websockets and http/1.1. The only thing you can save are a few header bytes. And it’s up to you how many headers you use

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.

Re: The future of web software is HTML over WebSockets

#328

Post by RangerScience »

mathgladiator wrote: post #73
RangerScience wrote: post #61

Earlier quoted context omitted.

Got a question for you - I'm making a chat bot thing ( https://www.brian.bot/ ) and have added socket-based web chat... but I don't even know how to phrase the question of "how do I horizontally scale the socket connections". Webchat Server Slack. Once I have more than one server dyno (heroku), then I can't ensure that the Slack event hits the dyno with the corresponding socket connection. Thoughts / tips?

I'll be completely honest... you're mostly screwed. I say this with full love in my heart. Your best bet is to use Amazon and then leverage their ELB offering with sticky routing. HOWEVER, now you have a new problem as capacity dies, gets removed, cycled, added, etc. Sticky routing was designed with the assumption that it was an efficiency play as opposed to a deterministic play. What you will see happen is that your…

That's super helpfully, actually - tells me about some problems that I wouldn't have anticipated, and tells me NOT to go looking for certain other solutions.

Short term, I think I can get by with switching from Slack's events API to their real-time widget - aka, the server gets a socket to both the web chat, and the slack.

Long term - probably the Redis pub/sub with the socket-receiving server split out as a microservice (which normally I'd be "eh" about, but this seems perfect).

I currently don't have to worry about multiple people on the webchat (outside of needed features) and even once that's an important thing, I doubt I'll need to worry about exactness. As long as each message get delivered reasonably quickly, and to everyone, should always be good.

hmm, hmm hmm - great stuff, thank you!

Re: The future of web software is HTML over WebSockets

#329

Post by RangerScience »

stevewodil wrote: post #172
Deadron wrote: post #88

Earlier quoted context omitted.

You can use a redis to distribute messages via PUB/SUB. The sockets subscribe to the events that are relevant to them. It can handle thousands of messages a second in a local environment and probably more in a dedicated hosting environment.

Seconding this approach. I've used PUB/SUB for this exact purpose. When you need to send something through the websocket then publish a message via redis and have handlers in the code that are subscribed to that channel so every server can check if they have the websocket connection and whichever one has it will send the data through

That mostly sounds great, although TBH my first instinct would be to stick all the socket stuff in a microservice. I don't normally advocate for them, but this seems like a perfect situation: very well defined layer that contains no business logic.

Re: The future of web software is HTML over WebSockets

#330

Post by mathgladiator »

m33k44 wrote: post #307
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…

> There is a great deal of power in having your UI be a stateless function over a giant JSON object. Something like this: http://jasonette.com

Kind of, except the JSON is pure data rather than a rendering tree. That's a very interesting project...
Post reply on HN