Live data from Hacker News

How we got to LiveView

fly.io

171–180 of 293 posts

Re: How we got to LiveView

#171
For anyone wanting a "SPA" like feeling of their apps without having to deal with all the SPA complexity, and not starting from scratch or being able to rewrite their applications, try Unpoly. It is really great and very underrated.

https://unpoly.com/

Re: How we got to LiveView

#172
post #49

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…

There's a funny story here. We created Fly.io, Chris created Phoenix. We met earlier this year and realized we'd accidentally built complimentary tools. The pithy answer is now "just deploy LiveView apps close to users". If a message round trip (over a pre-established websocket) takes This means moving logic to client side JS becomes an optimization, rather than a requirement. You can naively build LiveView and send…

How would you exactly 'optimize with JS'? Do you think this optimization can be done to the extent of enabling offline experiences? Might not be full functionality, but bookmarks/saved articles, for example.

Re: How we got to LiveView

#173
post #45

Earlier quoted context omitted.

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.

Yeah, the channel / category pages are all "live patched" generally, which means the user can navigate around without incurring a full HTTP roundtrip. Some pages like the account settings are "dumb views" though and do not offer the same advantages. Thanks for the offer to be on the podcast, I'll check it out!

I've used a similar technique with HTMX[1]. General navigation just patches the main "content" section, but actions where it's necessary to replace the entire page (e.g. login/logout) just do a full page "dumb" refresh.

[1] https://htmx.org

Re: How we got to LiveView

#174

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…

> is that it seems you now need to keep a connection with every connected client But seriously, what is the problem with this? I am guessing you don't really have much experience with the BEAM. It's completely not-objectionable, there aren't many stability issues, and they are very light weight (maybe a couple of kB/process). I believe (have not done this myself) you can do liveview over long-poll, since liveview onl…

[deleted]

Re: How we got to LiveView

#175

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…

> is that it seems you now need to keep a connection with every connected client But seriously, what is the problem with this? I am guessing you don't really have much experience with the BEAM. It's completely not-objectionable, there aren't many stability issues, and they are very light weight (maybe a couple of kB/process). I believe (have not done this myself) you can do liveview over long-poll, since liveview onl…

Do Phoenix channels have server-side state though? LiveView has server side state, so long polling would only work if there were also some form of server pinning involved (or a single server). Websockets are persistent connections so no need to worry about pinning a server across several requests.

Re: How we got to LiveView

#176

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…

[deleted]

Re: How we got to LiveView

#177
As someone with loads of Python and Django experience, should I invest in learning Erlang first or dive straight into Elixir/Phoenix?

Would the experience be enlightening regardless if I choose to deploy apps with it and use it at work?

Re: How we got to LiveView

#178

As someone with loads of Python and Django experience, should I invest in learning Erlang first or dive straight into Elixir/Phoenix? Would the experience be enlightening regardless if I choose to deploy apps with it and use it at work?

Only if you want to go with LiveView. For Django, as I’m a Python dev too, I’m going with htmx+alpinejs. Or you can choose the Hotwire stack (Turbo+stimulus)

Re: How we got to LiveView

#179

As someone with loads of Python and Django experience, should I invest in learning Erlang first or dive straight into Elixir/Phoenix? Would the experience be enlightening regardless if I choose to deploy apps with it and use it at work?

you don't need to learn Erlang first. you can directly dive into Elixir and Phoenix. the experience working with elixir/phoenix will be so soo good that it will be a hard to go back to any other stack.

Re: How we got to LiveView

#180
post #171

For anyone wanting a "SPA" like feeling of their apps without having to deal with all the SPA complexity, and not starting from scratch or being able to rewrite their applications, try Unpoly. It is really great and very underrated. https://unpoly.com/

How Unpoly differ from Hotwire (Turbo+stimulus) or htmx+alpinejs?

https://htmx.org/ https://alpinejs.dev/ https://turbo.hotwired.dev/ https://stimulus.hotwired.dev/

Post reply on HN