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

141–150 of 337 posts

Re: The future of web software is HTML over WebSockets

#141

Post by conradfr »

nickjj wrote: post #113
benzible wrote: post #91

Earlier quoted context omitted.

When did you last use it? Javascript hook support wasn't there early on. The state of the art is the "PETAL StacK" [1] which uses client-side JS for interactions that don't require a roundtrip [1] https://thinkingelixir.com/petal-stack-in-elixir/

> When did you last use it? I gave it a fair shake a few times. Once when it first came out, then again a year later and then again 6 months ago. Lack of hooks wasn't a concern I had at the time. It was more around core behavior of the library and critical features that were missing. Some of those features have been added after I posted about them but all that did was destroy any confidence I had in using LV because…

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 :)

Re: The future of web software is HTML over WebSockets

#142

Post by IgorPartola »

Martinsos wrote: post #108
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…

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

VueJS SPA + simple REST API will get you a really nice experience for most CRUD type apps. For the backend I like Django.

Re: The future of web software is HTML over WebSockets

#143

Post by IgorPartola »

lmarcos wrote: post #135
snejad123 wrote: post #125

Earlier quoted context omitted.

it's difficult to keep up with the design expectations of the modern web with just HTML and CSS. It's possible but extremely difficult to create a "modern" experience with just html. Just like how we don't build houses with mud-bricks anymore even though it's easier than steel and wood.

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 concerns. Sever takes care of the data (storing it, syncing it, authenticating your access to it, serving it, sharing it). Client takes care of presentation. I build SPAs because they are better. Imagine if all the apps on your phone or computer were effectively HTML documents rendered on the server. Emacs over HTML/CSS? Minesweeper? World of Warcraft? Would that be an OK experience? Probably not because you don’t want to wait for a page load every time you do something in your Minesweeper game or check stock prices or whatever. Why should web apps be inferior?

When people complain about SPAs it’s because they don’t like web apps running in the same environment as their document-based content. I guess some people prefer the ActiveX/JavaApplet model, which to a degree I can understand. Slack is an application, not a website. But let’s not overlook the fact that implementing a Slack client with just HTML and CSS would be miserable to do and miserable to use.

Re: The future of web software is HTML over WebSockets

#144

Post by lostcolony »

nickjj wrote: post #133
shakow wrote: post #127

Earlier quoted context omitted.

> Instead of managing the state of your app you’re now managing the state of your app and a connection to a remote server. Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem?

> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem? I don't think so but if I'm wrong please correct me. For example, imagine this simple scenario: you load the comment page for this post on HackerNews HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload. You can be sitting here on the page…

If the connectivity state doesn't matter to the user, why would you show it?

Re: The future of web software is HTML over WebSockets

#145

Post by TheRealPomax »

Joeri wrote: post #132
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…

Not only that. The basic problem is latency. We moved logic to the client to be able to update the screen without incurring the latency hit of a server roundtrip. Latency isn’t going down, thanks to physics, so it is going to keep making sense to run logic locally to improve apparent performance. Granted, you need data to render something useful and if an SPA does a data fetch on every click, it might as well be rend…

Note that a websocket round trip is vastly shorter than an http round trip, though. If your payloads are small, 500 consecutive websocket back and forths take orders of magnitude less time than the "traditional" high level url post/fetch becauses there's none of the overhead of an http round trip.

Re: The future of web software is HTML over WebSockets

#146

Post by TheRealPomax »

lostcolony wrote: post #144
nickjj wrote: post #133

Earlier quoted context omitted.

> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem? I don't think so but if I'm wrong please correct me. For example, imagine this simple scenario: you load the comment page for this post on HackerNews HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload. You can be sitting here on the page…

If the connectivity state doesn't matter to the user, why would you show it?

This. No reason to say "the server's gone!" when your user's not doing anything in which that matters. Do notify them _before_ trying to execute on a task that requires the server to be up, but that's not the case that was getting described.

Re: The future of web software is HTML over WebSockets

#147

Post by nickjj »

lostcolony wrote: post #144
nickjj wrote: post #133

Earlier quoted context omitted.

> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem? I don't think so but if I'm wrong please correct me. For example, imagine this simple scenario: you load the comment page for this post on HackerNews HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload. You can be sitting here on the page…

If the connectivity state doesn't matter to the user, why would you show it?

> If the connectivity state doesn't matter to the user, why would you show it?

It's due to Live View triggering a visual indicator that the websocket connection isn't available.

It's a combination of CSS and JS. You can turn this off but if you turn it off then you have no way to show an indicator when you do care (such as transitioning between pages or submitting a form).

I don't think LV at the client level can be coded in such a way that it can tell the difference between the server dropping and the user's connection dropping due to their internet being spotty.

Re: The future of web software is HTML over WebSockets

#148

Post by shakow »

nickjj wrote: post #133
shakow wrote: post #127

Earlier quoted context omitted.

> Instead of managing the state of your app you’re now managing the state of your app and a connection to a remote server. Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem?

> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem? I don't think so but if I'm wrong please correct me. For example, imagine this simple scenario: you load the comment page for this post on HackerNews HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload. You can be sitting here on the page…

> You also don't want to disable this visual warning because on slower devices it might take 2 seconds to load the page which is much different than an uncontrolled disconnect.

You can restrict the visual warning to the first load only, it would be pretty distracting otherwise.

Re: The future of web software is HTML over WebSockets

#149

Post by bitsen »

cogman10 wrote: post #93
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…

Here's another one. How do you deploy a new version of your service? Imagine a few customers open up your site and leave for lunch. Or maybe just a random crawler or bot sitting watching for some piece of information they are scraping. These sorts of issues can be challenging with stateless connections. I can only imagine how daunting they are with persistent connections.

I bet your ass that at least half of the developers reading HN don’t have caching of JS fully figured out such that when the JS changes server-side and immediately needs reloading on the client side that it does then and there instead of on the next request, the next page refresh, or never because they’ve f’d it up.

With server-fed, event-driven pages, you could potentially force refresh.

Re: The future of web software is HTML over WebSockets

#150

Post by mxxx »

hfjtktkf wrote: post #45
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 am doing something somewhat similar - I have a Postgres database and I send all the user tables to the client on connection and then stream all the updates. I use Vue and Vuex-ORM to make the client tables reactive, and put a view on that. When something changes in the database, the client UI will also update. It is indeed a very powerful and reliable way of ensuring synced state.

Sounds like you’re describing a system similar to Meteor.
Post reply on HN