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

91–100 of 293 posts

Re: How we got to LiveView

#91

Post by sillysaurusx »

Kiro wrote: post #85
sillysaurusx wrote: post #80

Earlier quoted context omitted.

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.

Found it! https://blog.chriszacharias.com/page-weight-matters

YES! Thank you! I’ve seriously been searching for like five decades. What was the magical search phrase? “YouTube Brazil increase latency” came back with “How YouTube radicalized Brazil” and other such stories. (Turns out the article mentions “South America” rather than “Brazil”; guess my Dota instincts kicked in.)

Anyway, you rock. :)

Re: How we got to LiveView

#92

Post by cgarvis »

nickjj wrote: post #45
clone1018 wrote: post #7

We use Phoenix and LiveView to power all of our non-video interactions on Glimesh.tv[0] and the immediate out of the box features and performance are unmatched. LiveView allowed us to get a completely real time updating channel where streamers can edit their metadata (game, title, viewer count, etc) and all of the viewers can see it in real time. Not to mention we implemented a distributed chat system that sends mess…

Are you using Live View for everything related to navigation too? For example if you transition between any page, is this happening through Live View? In any case, I'd love to chat with you on my podcast on how you built and deploy Glimesh if you're interested. It's at https://runninginproduction.com/ , there's a become a guest button in the nav bar on the top right if you wanted to schedule a call to be on the show.

Slight difference from stock phoenix but yes. Only area I’m not 100% on is auth. https://hexdocs.pm/phoenix_live_view/live-navigation.html

Re: How we got to LiveView

#93

Post by louissm_it »

sodapopcan wrote: post #84
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…

Lots of answers here including one from Chris McCord himself, but I'll offer my take based on my professional experience developing web apps (though I've never used Phoenix professionally): A large majority of businesses out there start off targeting one region/area/country. The latency from LiveView in this scenario is imperceptible (it's micro seconds). If these businesses are so lucky as to expand internationally,…

Pretty much this. Also, I’m not sure most people realise how incremental LiveView can be. You can use it for a little widget on any page and later swap in a react component if you truly need one (which most apps probably don’t).

It’s not designed to run the NY Times. But it is a super useful tool that will benefit a ton of apps out there.

Re: How we got to LiveView

#94

Post by rvense »

heeton wrote: post #58

Personal anecdote: LiveView is absurd. It's the biggest change I've experienced in web development since Rails v1. I've been able to build rich, interactive, games without a single line of Javascript. It takes complicated server / api / front-end build projects and results in literally 1/10th the amount of code for the same result. It's one of the few times in our world that the technology isn't just "new and cool" b…

I really wanted to use it at my last job, where we had a Go backend and a React SPA and a sprawling, ad hoc RESTish API in between that was only used by the SPA.

We were mostly split between Reactors and Gophers, and the amount of time we spent arguing about the API and implementing it... I'd say was easily one third of the word, if not more, that would have just gone away if we didn't have to worry about the details of the data we were moving back and forth.

My current job is a bit too front-end heavy for LiveView to make sense. But I still keep an eye on Phoenix. It really feels like it could be a secret weapon, at least until every one else adopts a similar pattern.

Re: How we got to LiveView

#95

Post by mwcampbell »

> We also shipped a live_redirect and live_patch feature which allows you to navigate via pushState on the client without page reloads over the existing WebSocket connection.

This is one LiveView feature I've deliberately avoided so far. The reason is that when you replace real page loading with client-side navigation using pushState, accessibility for blind users suffers. When a real page load happens, a screen reader knows when the load is complete, and can handle it in an appropriate way, e.g. by beginning to read the new page. But when client-side JS updates the DOM in-place, a screen reader has no reliable way of knowing that conceptually, a new page just loaded. The usual work-around is to have an invisible ARIA live region that says something like "navigated to [page title]". That's better than nothing, but still a regression from real page loads. Of course, SPAs have the same problem.

This really ought to be fixed in ARIA, but until then, I'll keep doing form submission and page navigation the old way. Still, LiveView is really nice for real-time updates within a page.

Re: How we got to LiveView

#96

Post by sodapopcan »

joppy wrote: post #86
sodapopcan wrote: post #84

Earlier quoted context omitted.

Lots of answers here including one from Chris McCord himself, but I'll offer my take based on my professional experience developing web apps (though I've never used Phoenix professionally): A large majority of businesses out there start off targeting one region/area/country. The latency from LiveView in this scenario is imperceptible (it's micro seconds). If these businesses are so lucky as to expand internationally,…

Is microseconds correct? Even with a good connection in online games I’ve only seen ping latencies of 3ms or so, and a more common range on an average connection is 20ms-50ms.

Should be, though milage may vary, of course. I'm having trouble finding a better example but https://elixir-console-wye.herokuapp.com/ is made in LiveView. You can try it out and see what you get (I have no idea where it's deployed, it's a phoenixphrenzy.com winner and plenty more there to browse through). Its payloads are a bit larger than some typical responses I have in my personal apps and I'm seeing 1-2ms responses in Toronto, Canada (chrome devtools doesn't show greater precision than 0.001 for websocket requests).

Re: How we got to LiveView

#97

Post by Kiro »

sillysaurusx wrote: post #91
Kiro wrote: post #85

Earlier quoted context omitted.

Found it! https://blog.chriszacharias.com/page-weight-matters

YES! Thank you! I’ve seriously been searching for like five decades. What was the magical search phrase? “YouTube Brazil increase latency” came back with “How YouTube radicalized Brazil” and other such stories. (Turns out the article mentions “South America” rather than “Brazil”; guess my Dota instincts kicked in.) Anyway, you rock. :)

Thank you! It was impossible to find anything on Google since any variant of "youtube", "latency" etc showed results for problems with YouTube or actual YouTube videos talking about latency.

The trick was to use HN search: "youtube latency" and select Comments. First result was a comment on https://www.forrestthewoods.com/blog/my_favorite_paradox/ which links the story in the "Bonus!" section.

Re: How we got to LiveView

#98

Post by a-dub »

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…

> 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. the first gives a pretty healthy prior in terms of modeling movement when data drops out and the latter can be fairly repetitive and thereby learnable and predictable.

whether or not user interaction behaviors can be learned within the context of driving web applications seems a little less clear, to me at least. it does seem like there are a lot more degrees of freedom.

Re: How we got to LiveView

#99

Post by innocentoldguy »

whitepoplar wrote: post #30
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!

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!

Someone else already mentioned this in a separate thread, but Pragmatic Studio's courses on Elixir and LiveView are outstanding. They're not free but they're worth the cost. You can get both for around $200 if you buy their Pro Bundle.

https://pragmaticstudio.com/courses/elixir

Re: How we got to LiveView

#100

Post by innocentoldguy »

davidw wrote: post #26
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!

Business-wise, what do you think the sweet spots are for LiveView, Phoenix and Elixir right now? I love the BEAM ecosystem (I've been using it since 2004, on and off), but for a lot of places, Rails is still a great place to start. What kinds of applications have you seen where all the BEAM features just make Phoenix et al not just a little snappier, but a clear winner?

The sweet spots for me are:

1. It is much easier to trace things through the entire Phoenix stack than it is in Rails. It is also much easier to add things to the Phoenix stack using plugs.

2. Elixir is concurrent, whereas Ruby is not, so when performing long-running processes, you can just do them in Elixir/Phoenix without having to rely on workarounds like Sidekiq, Resque, RabbitMQ, etc.

3. Writing multi-threaded applications is much easier in Elixir than many (if not all) OO languages.

4. Pattern-matching for variables and functions, and binary pattern-matching for parsing text.

5. Mix.

6. BEAM, OTP, and supervision trees.

Post reply on HN