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

141–150 of 293 posts

Re: How we got to LiveView

#141

Post by Aeolun »

chrismccord wrote: post #125
Aeolun wrote: post #113

This looks cool, but how does it work when your server is located 100ms away from the client? Every interaction will take a minimum of 200ms to complete, which would become fairly noticable.

For things requiring the server to be there anyway – the exact same way an SPA would work, but a little faster round trip. For things that should happen instantly on the client, you'd run some JavaScript on the client via a pcx-hook (JS escape hatch), or using a tool like Alpine.js to handle purely client-side interactions.

Thanks, I read some of your other posts describing the same thing (and linked blog post), and I’m fairly confident that would indeed work in the majority of scenarios.

I’ll have to try it out sometime now ;) there is still some nagging sensation that I’ll run into a fairly major blocker somewhere, but right now I can’t articulate what I’m afraid of.

Re: How we got to LiveView

#142

Post by [deleted] »

Aeolun wrote: post #115
chrismccord wrote: post #59

Earlier quoted context omitted.

These kinds of discussions miss a ton of nuance unfortunately (as most tech discussions do), so hopefully I can help answer this broadly: First off, it's important to call out how LiveView's docs recommend folks keep interactions purely client side for purely client side interactions: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#m... > There are also use cases which are a bad fit for LiveView: > Animati…

I think the big difference is that with React a lot of interactions can be completed completely client side, with the server side component happening only after the fact (asynchronously). I’ll grant you that that isn’t often the case, and recovering from inconsistencies is pretty painful, but I can see how people would go for that. I kind of like the idea I can just build all my code in one place instead of completel…

[deleted]

Re: How we got to LiveView

#143

Post by bglusman »

hartator wrote: post #116

> In the process of building Phoenix, I believe we've hit on some new ideas that will change the way we think about building applications in much the same way Rails did for CRUD apps. I think that's the issue with Phoenix. An actual opinatred vision like the Rails one came as an afterthought.

That’s a little ironic since, in a real sense, Rails itself came as an afterthought, not a fully formed vision. DHH built Basecamp without a framework, and then refactored a lot and extracted the core of what he’d happened to build into a very general reusable framework. You could criticize Phoenix for not having the same pedigree I suppose, of being first and foremost a product for getting things done, and only a framework as a secondary decision, but saying rails started with an opinionated vision and Phoenix didn’t is a bit funny, or like the pot calling the kettle a water retaining vessel.

Re: How we got to LiveView

#144

Post by wolf550e »

ttymck wrote: post #137
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…

What's the difference between "the data is in the server memory" and "no one has write access to postgres outside the application servers"?

If you make sure no one can write to postgres except the app server, the difference is only efficiency.

Re: How we got to LiveView

#145

Post by chrismccord »

losvedir wrote: post #61
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!

1. LiveView looks incredible! But Phoenix is also great at standard JSON APIs. How do you think about the decision between using LiveView vs a SPA with a Phoenix API backend? I'm not too sure about the limits or future vision of LiveView. Do you think there's a place for SPAs, or is the goal for LiveView to be able to replace them in almost all use cases? 2. What's your dev environment like? VSCode? What extensions,…

1. Thanks! You are right Phoenix also great for APIs, and this story is pretty much baked as far as Phoenix specific features go. There's absolutely a place for SPAs, and the JavaScript ecosystem has number of great options. Anything requiring offline support is obviously out for LiveView, as well as highly complex UIs, tho that is pretty vague. For example, I wouldn't build Google Docs or Google Maps with LiveView, but as we've seen with Livebook, you can do a shocking amount of complex things with a LiveView application and a few escape hatches to JS. We're still finding out where the bounds are.

Our goal isn't to replace SPAs, but I do think we'll obviate them for a large class of applications.

2. VSCode with VIM keybindings. I bounce from vim/emacs/vscode (all w/ vim emulation), but vscode has stuck pretty well for the last couple years. Much to my chagrin, it's faster than terminal emacs.

3. No news quite yet, but we're working on it. Stay tuned!

Re: How we got to LiveView

#146

Post by Omnipresent »

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!

What resources would you recommend for someone new to Phoenix, LiveView, Elixir to get started on this stack?

Re: How we got to LiveView

#147

Post by dv35z »

tommica wrote: post #22

I've had such hard time wrapping my head around how to think in liveview - I've tried tutorials and building my own projects, but always end up thinking "am I doing this the right way"? How do other people structure their codebase, and what are the considerations they have? I think I'm trying to force my way of working with react and laravel, and lack some kind of a fundamental way of thinking to get my "aha!" Moment

Influenced by your comment and others below, I created a shared spreadsheet where we can share our code structures & patterns informally & learn from one another.

https://docs.google.com/spreadsheets/d/10gCxVJyrme6Rv-LepqId...

Once there are enough contributions, perhaps a community member could write a blog article summarizing the major patterns - the use cases, patterns, benefits & drawbacks.

Don’t be shy!

Re: How we got to LiveView

#148

Post by bglusman »

mmaunder wrote: post #105

"Do you remember when Ruby on Rails was first released? I do. Rails was also a revolution." I remember and I disagree. It was dog slow, run by a guy who made slides that said "Fuck you." and was rife with memory leaks.

Technically it was probably leaking objects, not memory per se, but… I suppose that’s a bit of a pedantic distinction/memory leaked with the objects… but none of those things is incompatible with it being a revolution.

Re: How we got to LiveView

#149

Post by mrkurt »

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…

Phoenix apps tend to use Postgres, but not always. We've seen some really interesting use of Erlang's distributed mnesia database. There's even an mnesia Ecto adapter: https://hexdocs.pm/ecto3_mnesia/Ecto.Adapters.Mnesia.html

Re: How we got to LiveView

#150

Post by cormacrelf »

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…

Postgres can do a form of pub/sub with triggers on table change events, pg_notify. For anything more complicated get Postgres to publish all its changes using Change Data Capture to a Materialize instance. With Materialize, every query can push live updates to an app server, whenever the results change. Debounce a little and push the html, ideally don’t overwrite something the user is editing.

The Materialize folks made a blog post/demo of the materialize->app server->browser pipeline in Python+JS you could follow along with. They have a Postgres CDC implementation too, so hook it all up and it will go.

https://materialize.com/a-simple-and-efficient-real-time-app... (the images are 404 though)

https://materialize.com/docs/guides/cdc-postgres/

Post reply on HN