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

271–280 of 293 posts

Re: How we got to LiveView

#271

Post by slydo »

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!

Hi Chris, two questions about phoenix and liveview.

I would like the web app to have good offline support and use localstorage for backing when the connection goes down (re-upload when connection is back up). It it in anyway feasible to add some middleware to the client connection handling of liveview so that it still plays well with it's features?

I've read that it is possible to drop in some bits of JS here and there into the liveview powered page. Is it also possible to do it the other way around and go to drop in liveview "components" into an existing SPA? Throwing away my existing SPA code is quite a loss, but the liveview appeal is certainly there for other parts of the website.

Thanks for the great work on phoenix, it looks quite attractive.

Re: How we got to LiveView

#272

Post by karmajunkie »

krainboltgreene wrote: post #192
wolf550e wrote: post #130

Since I'm a persistence person and not a UI person, I am more interested in what is on the other side of the Phoenix/Elixir/BEAM VM server cluster: the database/persistence. I understand that currently apps mostly talk to PostgreSQL, like a Rails/Django app would? Then, if something modifies the data in the database not by using the Phoenix app, the Phoenix app would not find out until it loaded the values from the d…

> Then, if something modifies the data in the database not by using the Phoenix app, the Phoenix app would not find out until it loaded the values from the database. And what would prompt it to do that? Just like Rails, phoenix is the doorway to your application. If there are data changes happening that aren't through your application, then you're doing it wrong.

> If there are data changes happening that aren't through your application, then you're doing it wrong.

This is super-unrealistic. State mutation legitimately happens through many channels. The trick is signaling to the application layer that state has changed and either the app needs to reload it or update it.

In the case of GP, I would either build in a web callback that can be used by outside processes, or put a message on a queue like SQS that can be consumed by the application. This isn't a phoenix thing so much as an enterprise app design thing.

Re: How we got to LiveView

#273

Post by neillyons »

nsomaru wrote: post #177

As someone with loads of Python and Django experience, should I invest in learning Erlang first or dive straight into Elixir/Phoenix? Would the experience be enlightening regardless if I choose to deploy apps with it and use it at work?

Depends what you are trying to accomplish.

If you are reaching for Django Channels in your Django project then yes I would investigate Phoenix, Phoenix.Channels, Phoenix.Presence, and Phoenix.LiveView.

Re: How we got to LiveView

#274

Post by karmajunkie »

flippyhead wrote: post #239
staticelf wrote: post #193

Earlier quoted context omitted.

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?

Not GP, but my take is that Meteor is more like Flash, if we're going to go with a game platform comparison...

Re: How we got to LiveView

#276

Post by karmajunkie »

rtcoms wrote: post #184

Only thing which prevented me going fully into Phoenix was that there was no good library for authentication and admin interface at that time. Are there any good libraries like devise and activeadmin now ?

There are good libraries around authentication and authorization. There was at one point an analogue to ActiveAdmin, but it looks to be a dead project now. I generally discourage the use of those kinds of interfaces but if you must, this is more current: https://github.com/mojotech/torch

Re: How we got to LiveView

#277

Post by 0x000000001 »

joelbluminator wrote: post #261
0x000000001 wrote: post #257

Earlier quoted context omitted.

It prevents unnecessarily moving data around. And if you're running the whole stack on the same server with Sideqik you're dealing with interrupts and memory copies between processes; in Elixir it's all within the same allocated memory and nothing gets copied. Plus it's another service you don't have to monitor because it's automatically monitored by BEAM.

What if you want to scale your job workers and your servers separately?

Oban will let you choose which servers the jobs can execute on, and you could do the same with your own app code

> Queue Control — Queues can be started, stopped, paused, resumed and scaled independently at runtime locally or across all running nodes (even in environments like Heroku, without distributed Erlang).

Re: How we got to LiveView

#278

Post by yencabulator »

treis wrote: post #250
strken wrote: post #222

Earlier quoted context omitted.

I read his post as a criticism of how little optimistic updating is done in web apps, and how bad the user story is. Why can't it be easy to build every app as a collaborative editing tool without writing your own OT or CRDT?

Because an occasional glitch when the client & server sync back up is acceptable in a game. Finding out that my order didn't actually go through is much worse. Especially since click button, see success, and close browser is an relatively common use case.

Consider these two scenarios.

1. SPA with asynchronous server communication. A button switches to a spinner the moment you click it, and spins until the update is safe at the server. Error messages can show up near the button, or in a toast.

2. LiveView where updates go via the server. The button shows no change (after recovering from submit "bounce" animation) until a response from the server has come back to you. To do anything better, you need to write it yourself, and now you're back in SPA world again.

There's a reason textarea input isn't sent to a server with the server updating the visible contents! Same thing applies to all aspects of the UX.

EDIT: https://dockyard.com/blogs/optimizing-user-experience-with-l... talks about this. That'll handle things like buttons being disabled while a request is in flight, but it won't e.g. immediately add new TODO items to the classic TODO list example.

Re: How we got to LiveView

#279

Post by yencabulator »

janekm wrote: post #245
a-dub wrote: post #98

Earlier quoted context omitted.

> Mark my words: if elixir takes off, someday someone is going to write the equivalent of how gamedevs solve this problem: client side logic to extrapolate instantaneous changes + server side rollback if the client gets out of sync. most games have the benefit that they're modeling the mechanics of physical objects moving around in the world and are having their users express their intentions through spatial movement…

Nothing so complicated. All that's needed is a local cache so that when you type a new message in the chat window, you immediately see it appear when you hit submit (optionally with an indication of when the message was received by the peer). But there's quite a bit of tooling required to reliably update the local cache, run the code both in the client and on the server.

Firebase does this brilliantly with Firestore queries. Any data mutation by the client shows up in persistent searches immediately, flagged as tentative until server acknowledges.

Re: How we got to LiveView

#280

Post by olah_1 »

wut42 wrote: post #268
olah_1 wrote: post #263

Earlier quoted context omitted.

Would be awesome if a Pleroma front-end was written in this way. Just host one app that is ultra-performant.

When I was still working on Pleroma, I was stealth building a fully featured frontend on Hotwire + LiveView for some parts. Sadly this won't go further :-)

I've heard from career Elixir devs that the Pleroma codebase is not very idiomatic in terms of how it's all set up.

I have to wonder if a Phoenix / LiveView activityPub server+client could be built that would be compatible with it. Something that would appeal to existing Elixir devs.

Post reply on HN