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

71–80 of 293 posts

Re: How we got to LiveView

#71

Post by sillysaurusx »

chrismccord wrote: post #65
sillysaurusx wrote: post #56

Earlier quoted context omitted.

It’s telling that every answer is “just deploy servers near your users.” One of YouTube’s most pivotal moments was when they saw their latency skyrocketed. They couldn’t figure out why. Until someone realized it was because their users, for the first time, were world wide. The Brazilians were causing their latency charts to go from a nice 1.5s average. Yet obviously that was a great thing, because of Brazilians want…

> It’s telling that every answer is “just deploy servers near your users.” This isn't the takeaway at all. The takeaway is we can match or beat SPAs that necessarily have to talk to the server anyway, which covers a massive class of applications. You'd deploy your SPA driven app close to users for the same reason you'd deploy your LiveView application, or your assets – reducing the speed of light distance provides be…

> Deploying LiveView close to users is like deploying your game server closes to users – we have real, actual running code for that user so we can do all kinds of interesting things being near to them.

Then why do you start running forward instantly when you press “W” in counterstrike or quake? Why not just deploy servers closer to users?

Gamedev and webdev are more closely related than they seem. Now that webdev is getting closer, it might be good to take advantage of gamedev’s prior art in this domain.

There’s a reason us gamedevs go through the trouble. That pesky speed of light isn’t instant. Pressing “w” (or tapping a button) isn’t instant either, but it may as well be.

Re: How we got to LiveView

#73

Post by michalg »

shthrow wrote: post #47

How is it a good idea for every user interaction to hit the server?

This is not the idea. Interactions that don’t influence server-side state are suggested to be handled by JavaScript. Docs give an example for integrating AlpineJS, but you can use vanilla js or other libraries with little plumbing.

Re: How we got to LiveView

#74

Post by turtlebits »

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!

Just getting started into Liveview, what confuses me is the proper way to integrate javascript. The JavaScript interoperability documentation page isn't really helpful.

A simple case for me is using hotkeys to submit a form. Couldn't figure out a way to trigger a phx-submit from a onkeydown handler.

Re: How we got to LiveView

#75

Post by mrkurt »

shthrow wrote: post #47

How is it a good idea for every user interaction to hit the server?

A server round trip is a cost. It's not a good idea or a bad idea.

I will pay the cost of a round trip if (a) it simplifies my life and (b) the cost is low enough. LiveView simplifies interactive app development (for me). Since I can run my Phoenix servers close to people, the round trip cost is usually very low.

Re: How we got to LiveView

#76

Post by Kiro »

sillysaurusx wrote: post #56
sgrytoyr wrote: post #35

Earlier quoted context omitted.

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…

It’s telling that every answer is “just deploy servers near your users.” One of YouTube’s most pivotal moments was when they saw their latency skyrocketed. They couldn’t figure out why. Until someone realized it was because their users, for the first time, were world wide. The Brazilians were causing their latency charts to go from a nice 1.5s average. Yet obviously that was a great thing, because of Brazilians want…

I remember this story but can't find it anywhere. If I recall correctly they deployed a fix that decreased the payload size. However, in doing so they actually opened the door to users with slow connections that were unable to use it at all before. So measured latency actually went up instead of down.

Re: How we got to LiveView

#77

Post by PKop »

yewenjie wrote: post #36
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, really excited about the new release - Heex and Esbuild support is fantastic. Do you think it is possible for newcomers to pick up Phoenix and at the same time learn how frameworks work? For example, FastAPI [0] is a widely extensive Python framework yet its documentation essentially is just a long tutorial which explains basic web-development concepts while teaching its core. OTOH, almost all Phoenix learning ma…

Take a look at these courses on Elixir/OTP[0] and Phoenix LiveView[1] from Pragmatic Studio. Both of them together I felt gave a well paced overview of elixir servers, and Phoenix framework from a good starting point even for beginners as you seem to be looking for. There's a combo price deal if you by both courses.

[0] https://pragmaticstudio.com/courses/elixir

[1] https://pragmaticstudio.com/courses/phoenix-liveview

Re: How we got to LiveView

#78

Post by PKop »

mrkurt wrote: post #37
whitepoplar wrote: post #30

Earlier quoted context omitted.

If one wanted to learn LiveView today, what's the best resource to learn? Also, will there be improvements to the LiveView latency story (if it's even possible) when providing a service to a global audience? Thanks for all your work!

Non technical Fly.io founder here: LiveView and Elixir work very well distributed all over the world. Here's an example app I fumbled my way through to show it in action: https://liveview-counter.fly.dev/

Will there be a simpler quick start deploy process for LiveView coming soon? (last I looked at the tutorial it seemed a little tedious compared to other languages/platforms)

Re: How we got to LiveView

#79

Post by mrkurt »

jherdman wrote: post #39
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. We've been using LiveView to build a new app at Precision Nutrition and are largely quite happy with it so far. One concern we keep coming back to is that of the need for constant connectivity in order for the app to work. I'll throw up the disclaimer here that I've not spike on how to handle network disconnects. That said, we've had a few of our internal users lose their connection to the web socket, and t…

I've been experimenting with some progressive enhancement style HTML. You can build forms that post the "normal" way, then get the full liveview experience when the socket is mounted.

If an app can be reduced to just CRUD, I think it works very well.

Re: How we got to LiveView

#80

Post by sillysaurusx »

Kiro wrote: post #76
sillysaurusx wrote: post #56

Earlier quoted context omitted.

It’s telling that every answer is “just deploy servers near your users.” One of YouTube’s most pivotal moments was when they saw their latency skyrocketed. They couldn’t figure out why. Until someone realized it was because their users, for the first time, were world wide. The Brazilians were causing their latency charts to go from a nice 1.5s average. Yet obviously that was a great thing, because of Brazilians want…

I remember this story but can't find it anywhere. If I recall correctly they deployed a fix that decreased the payload size. However, in doing so they actually opened the door to users with slow connections that were unable to use it at all before. So measured latency actually went up instead of down.

That’s the one! Where the heck is it? It’s one of my all time favorite stories, but it seems impossible to find; thanks for the details.
Post reply on HN