Live data from Hacker News

How we got to LiveView

fly.io

211–220 of 293 posts

Re: How we got to LiveView

#211

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!

One question here; is there anything special about Elixir/Beam which makes Liveview on Phoenix a great fit? Or can LiveViews be done on more performant languages like Go, Rust etc? I am just surprised why we don't see more LiveView implementations in other languages?

> I am just surprised why we don't see more X implementations in other languages?

X probably doesn't have the mainstream appeal some people think it should have.

Re: How we got to LiveView

#212

We used Liveview in a production app but have sense re-written it all in favor of React. The biggest issue with LV was the fact that users with poor connection were experiencing a channel timeout causing the page to completely refresh. This was unacceptable UX, and there was nothing we could do about it. Really a shame, because I was enjoying liveview.

Haven't used liveview, is it not possible to just implement some kind of heart-beating and re-connection logic?

Re: How we got to LiveView

#213

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.

Some applications use a database which is shared by multiple applications, and you are not allowed to change the models (i.e. you can't ALTER TABLE). You code your application knowing that data can be changed by others. Your application coordinates with other applications through the database. Using separate services that each have their own database is not required and incurs overhead.

Re: How we got to LiveView

#214
We use Laravel Livewire (inspired by LiveView).

It's been amazing to work with.

Thanks LiveView for inspiring Livewire!

It saves development time and solves lots of other problems along the way. I think it makes better web apps just by the way it works.

We are been using it on all our projects the past year.

Alpine js is a great compliment to Livewire.

They call it the TALL stack. Tailwind, Alpine, Laravel, Livewire.

The performance is as good or even better than vue apps.

Re: How we got to LiveView

#215

We used Liveview in a production app but have sense re-written it all in favor of React. The biggest issue with LV was the fact that users with poor connection were experiencing a channel timeout causing the page to completely refresh. This was unacceptable UX, and there was nothing we could do about it. Really a shame, because I was enjoying liveview.

Haven't used liveview, is it not possible to just implement some kind of heart-beating and re-connection logic?

LiveView has built in re-connection logic! I think he means if theres no internet connection theres nothing to re-connect too.

Re: How we got to LiveView

#217

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…

Multiple points of entry to a SQL database is the root of all evil if I’ve ever seen it.

Re: How we got to LiveView

#218

Earlier quoted context omitted.

It's unfortunate there's no standard way to dispatch this kind of thing ARIA wise. Fortunately live navigation is opt-in, so folks can continue to use ` ` vs ` ` when needed. On the form submission side, we actually still have you covered within LiveView, because the server can instruct the client to do a plain redirect: def handle_event(save, params, socket) do ... {:noreply, socket} |> put_flash(:info, "It worked!"…

As far as I know you can't pipe that sort of tuple through those functions. Is that a future feature? It would be mildly convenient if assign({:noreply, socket}), ...) == {:noreply, assign(socket, ...)}

There is a misplaced `}` :) He actually wanted to do :

        def handle_event(save, params, socket) do
      ...
      {:noreply,
      socket
      |> put_flash(:info, "It worked!"
      |> redirect(to: "..."))}
    end
which would work.

Re: How we got to LiveView

#220

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!

One question here; is there anything special about Elixir/Beam which makes Liveview on Phoenix a great fit? Or can LiveViews be done on more performant languages like Go, Rust etc? I am just surprised why we don't see more LiveView implementations in other languages?

Laravel has LiveWire https://laravel-livewire.com which works in a similar way.
Post reply on HN