Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we got to LiveView

fly.io

Post reply on HN
Print view View original

231–240 of 293 posts

Re: How we got to LiveView

#231

Post by 0x000000001 »

joelbluminator wrote: post #202
innocentoldguy wrote: post #100

Earlier quoted context omitted.

The sweet spots for me are: 1. It is much easier to trace things through the entire Phoenix stack than it is in Rails. It is also much easier to add things to the Phoenix stack using plugs. 2. Elixir is concurrent, whereas Ruby is not, so when performing long-running processes, you can just do them in Elixir/Phoenix without having to rely on workarounds like Sidekiq, Resque, RabbitMQ, etc. 3. Writing multi-threaded a…

Sidekiq is not a workaround. This is a myth. Most companies need to persist their jobs (what happens during deployments or when a process dies? do u just let all the job info disappear?) and have some kind of queue system. Even Elixir has some redis backed queues. BEAM, OTP, concurrency, this whole thing is solved with the current fashion of devops teams and kubernetes. It doesn't really matter what tech stack you us…

In Elixir you'd use Oban instead of sidkiq and you get more performance and it scales out horizontally with your app. Each new instance of your app is essentially a new sideqik server as a bonus

edit: > BEAM, OTP, concurrency, this whole thing is solved with the current fashion of devops teams and kubernetes.

This is a hilarious statement which I hope is satire

Re: How we got to LiveView

#232

Post by jstummbillig »

> We're already exploring optimistic UI on the server, where we can front-run database transactions with Channels, reflect the optimistic change on the client, and reconcile when database transactions propagate

How far is this away, roughly? It's literally the sole feature I need to make the switch to literally any new (to me) web framework right now.

Re: How we got to LiveView

#233

Post by joelbluminator »

0x000000001 wrote: post #231
joelbluminator wrote: post #202

Earlier quoted context omitted.

Sidekiq is not a workaround. This is a myth. Most companies need to persist their jobs (what happens during deployments or when a process dies? do u just let all the job info disappear?) and have some kind of queue system. Even Elixir has some redis backed queues. BEAM, OTP, concurrency, this whole thing is solved with the current fashion of devops teams and kubernetes. It doesn't really matter what tech stack you us…

In Elixir you'd use Oban instead of sidkiq and you get more performance and it scales out horizontally with your app. Each new instance of your app is essentially a new sideqik server as a bonus edit: > BEAM, OTP, concurrency, this whole thing is solved with the current fashion of devops teams and kubernetes. This is a hilarious statement which I hope is satire

I don't know about Oban. I don't think it's bad design for the workers to be separate from your main app like in Sidekiq (they do 'require' the app but they are essentially separate from the servers). Anyway making this point as a huge win for Elixir over Ruby seems really exaggerated to me.

Re: How we got to LiveView

#234

Post by iruoy »

sarchertech wrote: post #166
brainbag wrote: post #161

Earlier quoted context omitted.

What is PETAL?

Phoenix, Elixir, Tailwind, Alpine, and LiveView. https://changelog.com/posts/petal-the-end-to-end-web-stack

The PHP equivalent would be the TALL stack (Tailwind, AlpineJS, Laravel and Livewire). Although Livewire just communicates over AJAX. The original Websockets version didn't make it.

I just found out that Livewire was inspired by LiveView.

Re: How we got to LiveView

#235

Post by jjdeveloper »

BiteCode_dev wrote: post #228
wmanley wrote: post #90

This sounds like an optimised implementation of the design described in "The Future of Web Software Is HTML-over-WebSockets": https://alistapart.com/article/the-future-of-web-software-is... HN discussion: https://news.ycombinator.com/item?id=26265999 I find developments in this area very exciting as I'm sick of dealing with layers and the required tedious glue you have to write to join them together.

Same but I already find ajax based app very slow if they implement optimist updates, now with this system, you have to wait a round trip for each interactions. This means click a counter will round trip before updating?

If you want to save state for the counter to the server you would do a round trip. Otherwise you’d use some light weight JS lib, most popular one for simple interactions is Alpine.js. So simple ui JavaScript use Alpine and something like form validation and showing errors will do a round trip and save you writing validation twice (on the client and on the server).

Re: How we got to LiveView

#236

Post by a_c »

sgrytoyr wrote: post #35
chrismccord wrote: post #2

Creator of Phoenix here. I'm happy to answer any questions folks have about LiveView, Phoenix, or Elixir in general. We've had some big LiveView features land recently with uploads and HEEx so now's a great time to jump in!

Almost every time I see a discussion about LiveView there’s someone complaining about the issue of latency/lag, and how it makes LiveView unsuitable for real-world applications. From what I understand, the issue is that every event that happens on the client (say, a click) has to make a roundtrip to the server before the UI can be updated. If latency is high, this can make for a poor user experience, the argument goe…

I had never used LiveView and tangential to the latency consideration here. Two applications that I think can be enabled by siphoning all events to server are server-side analytics and time travel debugging (or reconstruction of a session). I am so glad to learn of this tool and definitely giving a try in my next project

Re: How we got to LiveView

#237

Post by BiteCode_dev »

jjdeveloper wrote: post #235
BiteCode_dev wrote: post #228

Earlier quoted context omitted.

Same but I already find ajax based app very slow if they implement optimist updates, now with this system, you have to wait a round trip for each interactions. This means click a counter will round trip before updating?

If you want to save state for the counter to the server you would do a round trip. Otherwise you’d use some light weight JS lib, most popular one for simple interactions is Alpine.js. So simple ui JavaScript use Alpine and something like form validation and showing errors will do a round trip and save you writing validation twice (on the client and on the server).

Ok, so the trade off is a less snappy UI as soon as you have a state, because you can't do optimistic updates on the view, send the request, then deal with the error.

But you write only the code of the validation, and the vue, once, so it's more productive, and the state is always consistent.

I assume this means no PWA mode, although I don't really miss this.

Re: How we got to LiveView

#238

Post by jjdeveloper »

BiteCode_dev wrote: post #237
jjdeveloper wrote: post #235

Earlier quoted context omitted.

If you want to save state for the counter to the server you would do a round trip. Otherwise you’d use some light weight JS lib, most popular one for simple interactions is Alpine.js. So simple ui JavaScript use Alpine and something like form validation and showing errors will do a round trip and save you writing validation twice (on the client and on the server).

Ok, so the trade off is a less snappy UI as soon as you have a state, because you can't do optimistic updates on the view, send the request, then deal with the error. But you write only the code of the validation, and the vue, once, so it's more productive, and the state is always consistent. I assume this means no PWA mode, although I don't really miss this.

The round trip is very quick, websocket with a tiny payload in most cases. This video does a great job of discussing the advantages (skip forward to 6:50) https://youtu.be/8xJzHq8ru0M

Re: How we got to LiveView

#239

Post by flippyhead »

staticelf wrote: post #193
e9 wrote: post #167

Earlier quoted context omitted.

I thought exactly this. I wonder if we can get author to elaborate on the differences with Meteor.

Not the author, but I can elaborate on the difference with Meteor since I have experience with both. Meteor is not server generated but rather a SPA framework with a server side part to it. It helps you build a SPA app quickly and it also uses websockets for all the transport but usually you just send json data there. I don't really like Meteor because the performance is not that awesome and there is problems with no…

If Liveview is Google Stadia, to what would you compare Meteor?

Re: How we got to LiveView

#240

Post by BiteCode_dev »

jjdeveloper wrote: post #238
BiteCode_dev wrote: post #237

Earlier quoted context omitted.

Ok, so the trade off is a less snappy UI as soon as you have a state, because you can't do optimistic updates on the view, send the request, then deal with the error. But you write only the code of the validation, and the vue, once, so it's more productive, and the state is always consistent. I assume this means no PWA mode, although I don't really miss this.

The round trip is very quick, websocket with a tiny payload in most cases. This video does a great job of discussing the advantages (skip forward to 6:50) https://youtu.be/8xJzHq8ru0M

Payload size doesn't matter that much, a ping is ping.

Currently my ping to this website is 167 ms:

ping news.ycombinator.com PING news.ycombinator.com (209.216.230.240) 56(84) bytes of data. 64 bytes from news.ycombinator.com (209.216.230.240): icmp_seq=1 ttl=49 time=167 ms 64 bytes from news.ycombinator.com (209.216.230.240): icmp_seq=2 ttl=49 time=167 ms 64 bytes from news.ycombinator.com (209.216.230.240): icmp_seq=3 ttl=49 time=167 ms

Which means it's a cost I have to pay, before payload matters, before parsing matters, before rendering matters.

I'm at home, on fiber, on an ethernet cable, so ping should be very fast. And it can be:

ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=5.63 ms

Unfortunately, the network is not uniform.

It's of course, worse on Wifi, and even worse on mobile phone, on the go. Depending on your location, YMMV quite a lot as well. Then you have hardware quality playing a role, the user may use other software (torrenting, streaming, playing) that can also affect that.

Bottom line, you cannot assume the internet connection is snappy. Or stable (which is a problem with websocket, as you have to implement robust automatic reconnect, and it is slow and expensive, but then your use cannot use your software).

So knowing the trade off you make is important. On a local network in the corporate world, life view seems like a terrific deal. On a heavy mobile user centric app, it will probably hinder your app ergonomics.

Post reply on HN