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

61–70 of 293 posts

Re: How we got to LiveView

#61

Post by losvedir »

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!

1. LiveView looks incredible! But Phoenix is also great at standard JSON APIs. How do you think about the decision between using LiveView vs a SPA with a Phoenix API backend? I'm not too sure about the limits or future vision of LiveView. Do you think there's a place for SPAs, or is the goal for LiveView to be able to replace them in almost all use cases?

2. What's your dev environment like? VSCode? What extensions, etc?

3. Excited to see you at fly.io! I think I saw a tweet about them wanting to make deploying Livebooks (built on LiveView) easy. Any news on that front?

Re: How we got to LiveView

#62

Post by kureikain »

sgrytoyr wrote: post #35
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!

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…

On modern internet, with some assumption, you can get to like 2x faster(in my case) when sending data over an *already establised* connection.

Example:

A full fresh HTTP connect from client to first byte take ~400ms(I'm in the US the server is in Europe). This includes: resolve dns, open tcp connection, ssl handshake etc...

But if the connection is already establish, it only takes ~200ms to first byte.

If I deployed the server in the same region, say US customer US server, this came down to 20ms...

That means, it's good enough.

Not super ideal but It's a trade-off we're willing to make.

Re: How we got to LiveView

#63

Post by 1_player »

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!

Phoenix 1.6 has been in alpha/release candidate for a few weeks now. Just curious, what issues are blocking the stable release of 1.6.0? I've checked GitHub but I haven't found any major outstanding bugs waiting to be ironed out.

Re: How we got to LiveView

#64

Post by ignoramous »

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,

A someone who's familiar with Kotlin, I can see how Erlang's processes and mailboxes would work. The question I have is, you mention Phoenix maxed out available FDs but RoR would have struggled. I didn't quite get what those fundamental differences are that prevent RoR/Ruby from scaling-up io-bound workloads as effortlessly as Elixir/Erlang, given you point out that sync.rb was built upon a similarly capable event-io lib.

Also, if I may, what do you make of your former employers 37 Signal's turbo (hotwire) with RoR? Does the vision you have for Phoenix with LiveView match what you see them doing with hotwire? How do the solutions compare if you have had a chance to take a look?

Thanks.

Re: How we got to LiveView

#65

Post by chrismccord »

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…

> 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 better UX. It's just that most platforms outside of Elixir have no distribution story, so being close to users involves way more operation and code level concerns and becomes a non-starter. 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.

The way we write applications lends itself to being close to users.

Re: How we got to LiveView

#67

Post by CodesInChaos »

drunner wrote: post #41

Does this kind of technology exist in other languages in a similar fashion? I am aware of Blazor for c#, but I believe that uses webassembly and ships the entire c# runtime/gc making it very heavy. It is so cool that this just has a small js layer client side.

Blazor has different modes/variants. I think the server-side variant is similar to liveview and doesn't need a .net runtime on the client.

> Alternatively, Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM.

Re: How we got to LiveView

#68

Post by polyrand »

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 client, even if they are not doing any "highly interactive" actions. I think (in most cases) it would be more efficient to do a bunch of AJAX requests to receive those HTML chunks. Now that we have CDNs, HTTP/{2,3}, etc. the benefits of using WebSockets for everything seem less obvious.

This is what HTMX[0] does by default, and then you can use WebSockets[1] if you need it. Another great thing about HTMX is that the backend can be whatever you like, as long as you can handle HTTP requests and return HTML.

In any case, I like both approaches and I would love to see the web development ecosystem moving back to sending HTML over the wire, regardless of the framework.

[0] https://htmx.org/

[1] https://htmx.org/attributes/hx-ws/

Re: How we got to LiveView

#69

Post by sodapopcan »

shthrow wrote: post #47

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

Websockets are crazy fast and the BEAM has crazy fast IO (at the expense of slower CPU-bound tasks, but that is another story). LiveView also minimizes (to an obsessive degree) the amount of data that flows over the socket. The payload is about exactly the size as the exact diff being rendered in the DOM (often times this is simply the `innerHTML` of a node).

The advantage is stack simplicity. As stated in the beginning of the article, LiveView completely removes your need for any kind of API between your front and backend. It also makes it very easy (through JS hooks) to offload any interactions you want to the client if that makes more sense. But of course, if you end up offloading EVERY interaction to the client, you should be using a frontend framework--LiveView is very clear about not being suitable for every need--if you are building a super UI heavy app (like a text editor or painting app or the like), LiveView probably isn't going to cut it.

Re: How we got to LiveView

#70

Post by y4mi »

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…

Elixir (the language phoenix is written in, which is the framework that has these live views) is great with concurrency. You can have incredible quantities of parallel sockets open with basically no overhead. There have been various write-ups about it if you're interested.
Post reply on HN