How we got to LiveView • Hacker News Board

Re: How we got to LiveView

#281

Post by collinmanderson » Thu, Sep 23, 2021, 11:45 PM UTC

omegalulw wrote: post #206

chrismccord wrote: post #59

Earlier quoted context omitted.

These kinds of discussions miss a ton of nuance unfortunately (as most tech discussions do), so hopefully I can help answer this broadly: First off, it's important to call out how LiveView's docs recommend folks keep interactions purely client side for purely client side interactions: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#m... > There are also use cases which are a bad fit for LiveView: > Animati…

> LiveView will beat client-side apps that necessarily needs to talk to the server to perform writes or reads because we already have the connection established and there's less overhead Don't modern browsers already share a TCP connection for multiple queries implicitly?

Yeah. The overhead I see that's being reduced from a performance point of view is the server not needing to query the session/user information on every message, compared to ajax. That's true for websockets in general. And then the responses might be slightly smaller because it is an efficient diff with just the changed information.

Re: How we got to LiveView

#282

Post by wut42 » Fri, Sep 24, 2021, 12:09 AM UTC

olah_1 wrote: post #280

wut42 wrote: post #268

Earlier quoted context omitted.

When I was still working on Pleroma, I was stealth building a fully featured frontend on Hotwire + LiveView for some parts. Sadly this won't go further :-)

I've heard from career Elixir devs that the Pleroma codebase is not very idiomatic in terms of how it's all set up. I have to wonder if a Phoenix / LiveView activityPub server+client could be built that would be compatible with it. Something that would appeal to existing Elixir devs.

Tbh, yes, it's not.

I had long term goals to improve it but, as long term goals, especially when you're alone, isn't improving. And even more given how much manpower was throwed at it by its sponsor and it (personal opinion) went too bad to improve its codebase.

Regarding ActivityPub Servers. It's actually quite easy to build one -- but building one that is compatible with the current state of the fediverse is another story. Mastodon built on OStatus, then moved to AP but while keeping weird extensions and so on, complicating (a lot) all of it. There's an attempt at this on Bonfire[1] which is loosely a Pleroma fork (started at Moodle's MoodleNet, forked by their workers).

You'd have better luck building a "Mastodon" client (which would work with Pleroma's client API) than wasting your time working on AP S2S for Mastodon.

[1]: https://bonfirenetworks.org

Re: How we got to LiveView

#283

Post by fulafel » Fri, Sep 24, 2021, 3:47 AM UTC

danjac wrote: post #173

clone1018 wrote: post #123

Earlier quoted context omitted.

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

There's also a Clojure web setup based on htmx: https://whamtet.github.io/ctmx/

Re: How we got to LiveView

#284

Post by olah_1 » Fri, Sep 24, 2021, 6:11 AM UTC

wut42 wrote: post #282

olah_1 wrote: post #280

Earlier quoted context omitted.

I've heard from career Elixir devs that the Pleroma codebase is not very idiomatic in terms of how it's all set up. I have to wonder if a Phoenix / LiveView activityPub server+client could be built that would be compatible with it. Something that would appeal to existing Elixir devs.

Tbh, yes, it's not. I had long term goals to improve it but, as long term goals, especially when you're alone, isn't improving. And even more given how much manpower was throwed at it by its sponsor and it (personal opinion) went too bad to improve its codebase. Regarding ActivityPub Servers. It's actually quite easy to build one -- but building one that is compatible with the current state of the fediverse is anothe…

Wow bonfire looks like what I wanted!

> We're currently in the middle of a refactor to convert all components and templates from LiveView to Surface, which is a server-side rendering component library (built on top of Phoenix and LiveView) that inherits a lot of design patterns from popular JS framework like Vue.js and React, while being almost JavaScript-free compared to common SPAs.

Re: How we got to LiveView

#285

Post by wmanley » Fri, Sep 24, 2021, 1:15 PM UTC

BiteCode_dev wrote: post #228

wmanley wrote: 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?

You can apply this to any interaction where you have to wait for a round-trip anyway. It saves you coming up with a JSON schema and endpoint for the request, and then gluing it all together.

It doesn't mean that you don't use javascript at all, you just use it in a limited fashion for enhancing specific bits of your website. Just like it was in the 2000s when making websites was easy.

Re: How we got to LiveView

#286

Post by midrus » Fri, Sep 24, 2021, 2:38 PM UTC

chrismccord wrote: post #247

rishav_sharan wrote: post #200

Earlier quoted context omitted.

One question here; is there anything special about Elixir/Beam which makes Liveview on Phoenix a great fit? Or can LiveViews be done on more performant languages like Go, Rust etc? I am just surprised why we don't see more LiveView implementations in other languages?

There has been a large number of LiveView-like solutions pop up that are inspired by what we're doing. I tried to outline what makes Elixir uniquely suited to handle this kind of thing in the post, but I'll try to distill it here: 1. The concurrency and distribution model. Processes (light weight green threads) and extremely cheap, isolated, and concurrent. Process can message each other, and messaging is location tr…

I really appreciate the work and innovation you are doing, but these other alternatives exist because not everyone is starting a project from scratch, not everyone is able to rewrite their project, and not everyone is building a team with the required skills from scratch.

At a previous company I worked for, a decision was made to move to other platforms not because Elixir was bad, or LiveView was bad (it was good!) but because it was really difficult to hire for.

It is difficult to find people with elixir experience, and we didn't want to have production system built by just people learning a language, platform and architecture on the fly.

Also, that's considering "backend" developers. It was *TOTALLY* impossible to hire frontend developers wanting to work in this setup. No single frontend developer wanted to learn Elixir, and all the backend related stuff. This doesn't happen for example with Node... yes, it might be a terrible choice for the backend, but most frontend devs are happy to work with it.

Regarding to the solutions in other platforms not having the Erlang VM to power them, etc,etc.... not everyone is at google/twitter/facebook scale, 90% of companies out there can be run perfectly fine with run of the mill django/rails/laravel setup.

Premature optimization is as bad when doing an unnecessary SPA as it is using the Erlang VM when rails was enough.

Re: How we got to LiveView

#287

Post by krainboltgreene » Sat, Sep 25, 2021, 3:01 AM UTC

karmajunkie wrote: post #272

krainboltgreene wrote: post #192

Earlier quoted context omitted.

> 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 database. And what would prompt it to do that? Just like Rails, phoenix is the doorway to your application. If there are data changes happening that aren't through your application, then you're doing it wrong.

> If there are data changes happening that aren't through your application, then you're doing it wrong. This is super-unrealistic. State mutation legitimately happens through many channels. The trick is signaling to the application layer that state has changed and either the app needs to reload it or update it. In the case of GP, I would either build in a web callback that can be used by outside processes, or put a m…

> This is super-unrealistic. State mutation legitimately happens through many channels. The trick is signaling to the application layer that state has changed and either the app needs to reload it or update it.

13 years in professionally, many companies, many contracts, and many projects later I've yet to see a system where it wasn't the case. Small or large (16k/rps at the large end). Startup and "enterprise".

And why wouldn't it be the case? Why not have your data flow through a "central" business logic layer?

Re: How we got to LiveView

#288

Post by krainboltgreene » Sat, Sep 25, 2021, 3:03 AM UTC

wolf550e wrote: post #213

krainboltgreene wrote: post #192

Earlier quoted context omitted.

> 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 database. And what would prompt it to do that? Just like Rails, phoenix is the doorway to your application. If there are data changes happening that aren't through your application, then you're doing it wrong.

Some applications use a database which is shared by multiple applications, and you are not allowed to change the models (i.e. you can't ALTER TABLE). You code your application knowing that data can be changed by others. Your application coordinates with other applications through the database. Using separate services that each have their own database is not required and incurs overhead.

> Some applications use a database which is shared by multiple applications

The smallest piece of the pie possible. Even if you ignore things like wordpess.

Re: How we got to LiveView

#289

Post by redbar0n » Sat, Sep 25, 2021, 5:57 AM UTC

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…

> server side rollback

server controlled client side rollback, you mean?

Re: How we got to LiveView

#290

Post by redbar0n » Sat, Sep 25, 2021, 6:47 AM UTC

rvense wrote: post #94

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…

The time spent on discussing data exchange details (protocol) between teams is regained in their ability to work largely independently of one another (without constant sync).