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

181–190 of 337 posts

Re: The future of web software is HTML over WebSockets

#181

Post by abrookewood »

RangerScience wrote: post #61
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…

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?

Pretty sure that Erlang or Elixir would work there - you can have clusters of stateful servers.

Re: The future of web software is HTML over WebSockets

#182

Post by conradfr »

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…

Maybe my impression following the Phoenix and LiveView commits was wrong but it still feels it's mainly two people.

José works at the same time on Elixir, Phoenix, LiveView, Ecto, Nx, Dashboard and more, it's a lot.

To be fair there also has been integration of LV in the Phoenix mix tasks, in addition to the Dashboard (using LV, ah!), so it's not like things are stalling.

Re: The future of web software is HTML over WebSockets

#183

Post by jayd16 »

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?

Re: The future of web software is HTML over WebSockets

#184

Post by IgorPartola »

vagrantJin wrote: post #177
IgorPartola wrote: post #143

Earlier quoted context omitted.

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…

> Why should web apps be inferior? Inferior compared to what? I'm not going to call your statement nonsense but unless you have proof that SPAs make up the majority of the websites/web apps online today, I'm afraid I must disagree. Frontend dev is a hot mess of garbage JS cobbled together to make a psuedo native experience. > but something that does something complex like let you manage inventory, do payroll, do your…

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 backwards and give up a really important feature (forthcoming) or we can move forward and push past what is essentially a tooling problem. In other words, just because in the 1980s web apps could not be envisioned does not mean that they shouldn’t be envisioned today.

The second argument is that there isn’t a technology today that supersedes the web in one crucial feature: no installation required and updates are transparent. Various app stores are trying to solve this in a platform specific way but do you really want to live in a world where to publish an app you must include Apple and Google and Microsoft in your deploy path? You and I may be able to go to GitHub and download OpenStreetMaps code, then download all the data, install it all locally (most of the documentation last I checked was still in German BTW), and then use it to find directions to the nearest Starbucks. An average user will give up before spelling out “GitHub”. If you can point at any platform that lets me type in the name of an application and stat using it in under 1 second without installing anything whatsoever on my system, I will eat my hat.

That isn’t to say that we can’t have nice things. With time and effort you can create such a platform and get all OS vendors to support it and all the developers to move to it. But I will postulate that fixing the JS frontend mess will take at least an order of magnitude less effort. Therefore the web is where these types of applications will live.

Again I am not talking about things that are static. This isn’t about a blog. This is about whether a real application is better server-rendered or as an SPA and I argue that in 99% of cases an SPA will be a cleaner architecture AND provide better experience to the user. The fact that coding one up is annoying (arguable at best) is a temporary tooling problem, not a fundamental design flaw.

Re: The future of web software is HTML over WebSockets

#186

Post by mathgladiator »

vinay_ys wrote: post #100
mathgladiator wrote: post #81

Earlier quoted context omitted.

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…

If your game has limited number (say, < 10) participants per game board, then concurrent updates to shared state etc can be solved with a traditional game state hosting server model. But if that number is higher say 100+ then you need a sharded distributed setup. That's when things get really tricky if you don't keep things simple.

So, like all engineers, I imagine that my products that I ship will reach massive levels of scale. Such massive level of scale that I need to use elastic compute, so I should expect processes to come and go.

Thus, my processes clearly has to sustain 100k+ connections. And, at a moment's notice, I should expect the process to go "poof". Maybe someone is going to do a kernel upgrade or someone decided to unplug a machine, I don't know!

Having operated with the above assumptions, I found it hard to be wise to avoid that and then invented a programming language that would operate in a modern cloud environment.

I need better hobbies, or not... who knows.

Re: The future of web software is HTML over WebSockets

#187

Post by jimmont »

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…

the power drain alone, especially for mobile devices, makes this unrealistic

Re: The future of web software is HTML over WebSockets

#189

Post by mathgladiator »

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?

It could be, but I own it and the roadmap.

The key thing that I can do is await on players decision, so I can block the entire process for multiple people to do things.

Re: The future of web software is HTML over WebSockets

#190

Post by brightball »

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…

Except Phoenix LiveView has essentially removed the complexity.

Normally I’d agree with your take entirely and I don’t actually think it’s possible to avoid the complexity issues in non-BEAM languages...but Phoenix is absolutely doing it.

Post reply on HN