Live data from Hacker News

How we got to LiveView

fly.io

221–230 of 293 posts

Re: How we got to LiveView

#221
post #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.…

In Phoenix it's called PETAL :) Phoenix/Elixir/Tailwind/Alpine/LiveView

Re: How we got to LiveView

#222
post #112

Earlier quoted context omitted.

> 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…

> Then why do you start running forward instantly when you press “W” in counterstrike or quake? Why not just deploy servers closer to users? You do both? Game client handles movements and writes game state changes to a server, which should be close to the user to reduce the possibility for invalid state behaviors? You really haven't seen online games that deploy servers all over the world to reduce latency for their…

I read his post as a criticism of how little optimistic updating is done in web apps, and how bad the user story is. Why can't it be easy to build every app as a collaborative editing tool without writing your own OT or CRDT?

Re: How we got to LiveView

#223

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…

Hey great work on Glimesh! I stopped streaming for while and when I came back hitbox.tv was no more. So I went searching and comparing providers and ended up selecting Glimesh and have been really happy with it. I didnt realize you were using phoenix but the snappiness makes sense now!

Re: How we got to LiveView

#224

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…

This article really helped me. It basically builds Phoenix from the ground up. Starting with "hello world" in the terminal.

http://www.petecorey.com/blog/2019/05/20/minimum-viable-phoe...

Re: How we got to LiveView

#226

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!

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…

Here is an article about updating the UI without waiting for the roundtrip to the server.

http://blog.pthompson.org/liveview-tailwind-css-alpine-js-mo...

Re: How we got to LiveView

#227
Does this mean the entire state of each connected user is hold on the server?

What's the resource cost ?

And that adding an element on a list don't show it up before a server round trip ?

What's the latency cost ?

Re: How we got to LiveView

#228
post #90

This sounds like an optimised implementation of the design described in "The Future of Web Software Is HTML-over-WebSockets": https://alistapart.com/article/the-future-of-web-software-is... HN discussion: https://news.ycombinator.com/item?id=26265999 I find developments in this area very exciting as I'm sick of dealing with layers and the required tedious glue you have to write to join them together.

Same but I already find ajax based app very slow if they implement optimist updates, now with this system, you have to wait a round trip for each interactions. This means click a counter will round trip before updating?

Re: How we got to LiveView

#229
Couple of questions from someone who’s never tried Phoenix/Elixir:

1. How does this stack handle non-browser clients, like mobile apps or APIs?

2. Can this scale horizontally? i.e, can you throw in more servers when you need to? Since servers hold state in-memory (IIUC) I’m not sure about this one.

Re: How we got to LiveView

#230
post #81

Earlier quoted context omitted.

This has most likely to do with the codebase itself rather than with Elixir or Phoenix in your case. And having to go through a few files to understand how a request is handled is not out of the ordinary in an app, especially if it's grown over the years?

Tbh Phoenix has a lot of boilerplate and some... Opinions that make the codepath slightly more complicated (often for good reason... that might not apply to all use cases) in the default project. For example:. What exactly is the distinction between an endpoint and a router?

Endpoint == instance of phoenix webserver. Changing things in the endpoint gives you WAF-like control and you can do some early footwork here and store useful data in conn[:private] for you to use later in the modules called in your router

You can have multiple routers. I just built a thing where foo.com uses one router for the main site and *.foo.com is something else.

Post reply on HN