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

181–190 of 293 posts

Re: How we got to LiveView

#181

Post by besil »

polyrand wrote: post #68

I have never used LiveView, but I'd love to see the web moving towards this kind of interfaces. HTML over the wire is powerful! The deep integration between all the parts (Phoenix, LiveView, the HEEx engine...) is nice, and compile-time template validation looks really cool. One thing that concerns me about doing everything over WebSockets, is that it seems you now need to keep a connection with every connected clien…

You can go with Server Sent Events too, that are more suitable for notifications. WS may be blocked in corporate networks

Re: How we got to LiveView

#183

Post by besil »

besil wrote: post #181
polyrand wrote: post #68

I have never used LiveView, but I'd love to see the web moving towards this kind of interfaces. HTML over the wire is powerful! The deep integration between all the parts (Phoenix, LiveView, the HEEx engine...) is nice, and compile-time template validation looks really cool. One thing that concerns me about doing everything over WebSockets, is that it seems you now need to keep a connection with every connected clien…

You can go with Server Sent Events too, that are more suitable for notifications. WS may be blocked in corporate networks

I hope too HTML Over the Wire will be trending, I hate all the SPA and JS madness nowadays.

SPA/React/Flutter are great tools and technologies, when you have a team for the backend and one for the front end. If you are a little startup or a single man project, that’s quite huge to maintain

Re: How we got to LiveView

#184

Post by rtcoms »

Only thing which prevented me going fully into Phoenix was that there was no good library for authentication and admin interface at that time.

Are there any good libraries like devise and activeadmin now ?

Re: How we got to LiveView

#185

Post by andy_ppp »

ec109685 wrote: post #162
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…

Here's a demo that illustrates that delay: https://breakoutex.tommasopifferi.com/ Agree it's super neat framework and hope a client side implementation can be written to "stage" the change.

Chris said in a different comment optimistic ui updates already exist…

Here’s the link: https://dockyard.com/blog/2020/12/21/optimizing-user-experie...

Re: How we got to LiveView

#186

Post by porker »

besil wrote: post #181
polyrand wrote: post #68

I have never used LiveView, but I'd love to see the web moving towards this kind of interfaces. HTML over the wire is powerful! The deep integration between all the parts (Phoenix, LiveView, the HEEx engine...) is nice, and compile-time template validation looks really cool. One thing that concerns me about doing everything over WebSockets, is that it seems you now need to keep a connection with every connected clien…

You can go with Server Sent Events too, that are more suitable for notifications. WS may be blocked in corporate networks

The Symfony community has been going for Server Sent Events rather than websockets, via https://mercure.rocks/. I don't understand the benefit when every other framework wanting interactivity is still going for websockets.

As you say SSE seem more suitable for notifications rather than bi-directional communication.

Re: How we got to LiveView

#187

Post by MathCodeLove »

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.

Nick! Completely unrelated to this discussion but I just wanted to say I've bought a few of your courses and love you're work. What a pleasant surprise to run into you on HN.

Re: How we got to LiveView

#188

Post by toast0 »

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…

> But if your entire active state can fit in RAM in a cluster of BEAM VMs, you might turn the BEAM VM cluster itself into a distributed database

It's hard to imagine an active state that couldn't fit into RAM in a cluster of BEAM VMs. I've run clusters with thousands of nodes, with some nodes having 768 GB of ram. With today's servers, 4 TB of ram per node is approachable. The new pg module avoids pg2's dependence on (cluster) global locks that limited effective cluster size.

Of course, you have to want to do it, and mnesia is mostly key-value, so I don't think you'd have a good time if you need other kinds of queries (but I could be wrong). And you need to have readily partitioned data if you want your cluster to be operable; having all the nodes in one mnesia schema makes a lot of things hard.

Re: How we got to LiveView

#189

Post by namelosw »

LiveView is a mirror that reflects how much accidental complexity is left in mainstream web tech stacks: It turns out people on your average React + Spring project spend the majority of the time on hassles instead of functionalities.

With that being said, it's hard to replicate LiveView in most tech stacks in an as performant way. Blazor feels like LiveView at a glance but doesn't feel like it could handle as much as LiveView in production. The key difference is BEAM was designed like an operating system (processes, preemptive scheduling, etc) instead of a programming language runtime.

Post reply on HN