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

191–200 of 293 posts

Re: How we got to LiveView

#191

Post by staticelf »

chrismccord wrote: post #155
staticelf wrote: post #32

Earlier quoted context omitted.

Are you guys looking into the Web Transport protocol for the future? Right now you have to tunnel the websocket connections over http2 and it will probably be the same for http3 afaik. I know there is this work in progress ( https://w3c.github.io/webtransport/ ) and websockets are probably fine for a long time but sooner or later (unless there is an update to websockets) it will probably be faster to just do normal h…

Phoenix Channels (which LiveView is built on) is transport agnostic, so as soon as we can open a pipe from the browser's JS environment, and listen on the server, we could have a `Phoenix.Transports.WebTransport`. All the existing user-land code and LV apis remain unchanged :)

That is something I suspected. When I first saw your talk about LiveView on youtube my mind was completely blown away.

It is such an awesome technology.

Re: How we got to LiveView

#192

Post by krainboltgreene »

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.

Re: How we got to LiveView

#193

Post by staticelf »

e9 wrote: post #167
subpixel wrote: post #121

This strikes me as sort of like Meteor, only without the suggestion that real time apps will be trivially easy to build.

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 node since it is single threaded. Meteor still doesn't support worker threads or other similar solutions in node so if you have something blocking on the server side the entire app will go down.

Liveview in the other hand is server side only (except for the liveview part). All the state is on the server and when the state changes it will push out the changes in the template and rerender automatically. In Meteor the recommended stuff to use is pub/sub and meteor methods but you still have to rerender yourself just like in a normal SPA.

Meteor is thus simply a way to quickly build SPAs and Phoenix and Liveview is a way to quickly build SPA-like feeling to apps but with everything living on the server.

You can think of Liveview as Google Stadia but for websites. Everything is rendered on the server and you just get the updates.

Re: How we got to LiveView

#194

Post by anonymousDan »

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!

How do you handle issues of consistency once you need to scale your app server across multiple nodes? Under the assumption that in the past much of this would be handled in the database, are there any guidelines regarding what state to maintain in the app server in order to avoid any issues? Or is this just a non-problem?

Re: How we got to LiveView

#196

Post by xfer »

sschueller wrote: post #157
dugmartin wrote: post #14

I've used LiveView as it was meant to be used in a couple of small personal projects but in my latest (much larger) project I'm using it in a way that (given what I just read in this post) would make Chris' head spin. Basically I'm using it as a container wrapper for a large React app and keeping all the state on the client. This is only for the app pages on the site, the rest of the pages are either traditional "dea…

I don't know if would feel comfortable if my accounting apps state was mostly local and if my pc decided to take a nose dive I don't have the state on the server that assumed I have.

The data would be in the server database not in memory hogged by state for each client's active connection.

I seriously don't understand server-side rendering when toasters are more powerful than a mid tier pc i bought 15yrs ago. Why not do apis and just send the data?

Re: How we got to LiveView

#197

Post by mands »

besil wrote: post #178
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?

Only if you want to go with LiveView. For Django, as I’m a Python dev too, I’m going with htmx+alpinejs. Or you can choose the Hotwire stack (Turbo+stimulus)

There is also Django Unicorn (https://www.django-unicorn.com/docs/), which is an implementation of LiveView for Django.

Re: How we got to LiveView

#198

Post by mands »

CodesInChaos wrote: post #67
drunner wrote: post #41

Does this kind of technology exist in other languages in a similar fashion? I am aware of Blazor for c#, but I believe that uses webassembly and ships the entire c# runtime/gc making it very heavy. It is so cool that this just has a small js layer client side.

Blazor has different modes/variants. I think the server-side variant is similar to liveview and doesn't need a .net runtime on the client. > Alternatively, Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM.

Yes, Blazor server-side is similar to LiveView, there is also LiveWire for the Laravel / PHP community (from the alpine.js creator) and Django Unicorn for the Django / Python side.

Unsure on the Rails / Ruby side, maybe stimulus-reflex, but there is also Hotwire as well ofc.

Re: How we got to LiveView

#199

Post by bugmen0t »

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!

HEEx looks awesome. How does compilation work? Does it properly & contextually encode/escape to avoid XSS? I'd love to learn more about the inner workings.

Re: How we got to LiveView

#200

Post by rishav_sharan »

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!

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?

Post reply on HN