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

251–260 of 293 posts

Re: How we got to LiveView

#251

Post by vosper »

Aeolun wrote: post #205
vosper wrote: post #29

> HTTP almost entirely falls away. No more REST. No more JSON. No GraphQL APIs, controllers, serializers, or resolvers In React / Typescript world you can get a little bit of this with Blitz - but not the live updating part, as far as I know. I found there was quite a lot to learn, but I’d also been out of the React world for a couple of years. Probably getting up to speed with TS was half of it, and obviously that’s…

You kind of still need to think about your queries though, especially when building more complicated stuff. I do agree the batteries included part of Blitz makes it really pleasant to use if you need both front and backend.

> You kind of still need to think about your queries though, especially when building more complicated stuff.

I’m not sure I follow - are you talking about client-side invalidation, which you may have to do manually with functions like `invalidateQuery`? I can see that being a gotcha in more complex Blitz apps. https://blitzjs.com/docs/mutation-usage#cache-invalidation

Re: How we got to LiveView

#252

Post by strzibny »

ignoramous wrote: post #64
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 capabl…

I am not Chris, but maybe I can answer the Hotwire and LiveView difference.

Hotwire is building stuff from regular HTTP requests (ala AJAX) and uses WebSockets only for Turbo Streams. LiveView is all on WebSockets.

You can think of Hotwire as being stateless and stateful when required. LiveView is stateful.

Hotwire exchanges HTML snippets at various length whereas LiveView tries to do a very minimal diff for an update.

WebSockets would be faster for your regular updates, but you need to keep a connection open. In other stacks this might not be ideal, but it's what Beam is made for.

Re: How we got to LiveView

#253

Post by strzibny »

brap wrote: post #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.

You can have more servers and you route the client to the server that made the initial connection. Same as with any other web socket.

Re: How we got to LiveView

#254

Post by strken »

treis wrote: post #250
strken wrote: post #222

Earlier quoted context omitted.

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?

Because an occasional glitch when the client & server sync back up is acceptable in a game. Finding out that my order didn't actually go through is much worse. Especially since click button, see success, and close browser is an relatively common use case.

That's a deliberate UI choice, though, and it doesn't always make sense in non-transactional workflows. It's easy to wait for Google Docs to say "Saved to Drive", and going to a new page to save a document would be really disruptive to your workflow, for example.

Re: How we got to LiveView

#255

Post by chrismccord »

brap wrote: post #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.

1. Fantastic for non-browser clients. The community has native channel clients for objc/swift/c++/rust/java so you can do real-time things natively, and course do standard json/graphql. 2. Yes, we scale vertically and horizontally. Because we have distributed pubsub and messaging baked-in, the horizontal scaling story just works – you don't have to rearchitect your app to add more servers :)

Re: How we got to LiveView

#256

Post by midrus »

besil wrote: post #180
midrus wrote: 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/

(My opinions)

Compared to Hotwire:

I think hotwire is the best option if you're using Rails. From what I know, hotwire needs a lot more of backend "collaboration" than Unpoly, so you will need backend "hotwire" implementations. You can see these things are being built for django, etc.

Compared to Htmlx+ Alpine:

Let me start with the disclaimer that I think Alpine.js is an aberration. Writing code inside html attributes is a fantastic way to break every editor templating language plugin, syntax highlighting, etc.

Despite of me not liking Alpine, I think unpoly handles a lot more use cases, and it feels a lot more "declarative" to me.

Compared to both:

Unpoly is kind of the "django" or "rails" in this category of tools. It gives you a lot of stuff. From page transitions loading progress bar (a'la turbolinks) to ajax replacing links, to modals, to popups to sidebars, to automatic blocks replacement (up-hungry) to form posts, to handle error responses, layers, polling.... and it has an awesome way of writing your own "components" with the up.compiler api.

I honestly think the only reason Unpoly isn't the most popular solution in this space is because of bad marketing (well, no marketing at all...). I really think it is the best (if you're not using Rails, then I'd use Hotwire+Stimulus+etc...).

Re: How we got to LiveView

#257

Post by 0x000000001 »

joelbluminator wrote: post #233
0x000000001 wrote: post #231

Earlier quoted context omitted.

In Elixir you'd use Oban instead of sidkiq and you get more performance and it scales out horizontally with your app. Each new instance of your app is essentially a new sideqik server as a bonus edit: > BEAM, OTP, concurrency, this whole thing is solved with the current fashion of devops teams and kubernetes. This is a hilarious statement which I hope is satire

I don't know about Oban. I don't think it's bad design for the workers to be separate from your main app like in Sidekiq (they do 'require' the app but they are essentially separate from the servers). Anyway making this point as a huge win for Elixir over Ruby seems really exaggerated to me.

It prevents unnecessarily moving data around. And if you're running the whole stack on the same server with Sideqik you're dealing with interrupts and memory copies between processes; in Elixir it's all within the same allocated memory and nothing gets copied. Plus it's another service you don't have to monitor because it's automatically monitored by BEAM.

Re: How we got to LiveView

#258

Post by 0x000000001 »

dnautics wrote: post #249
0x000000001 wrote: post #230

Earlier quoted context omitted.

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.

Point is, they are just plugs. You can put routes in an endpoint, it'll work just fine. The distinction is just a -often useful- prescriptive opinion by Phoenix. (Plug does not split between endpoints and routers)

very true, but the abstraction is pretty useful

Re: How we got to LiveView

#259

Post by iudqnolq »

wut42 wrote: post #218
iudqnolq wrote: post #158

Earlier quoted context omitted.

As far as I know you can't pipe that sort of tuple through those functions. Is that a future feature? It would be mildly convenient if assign({:noreply, socket}), ...) == {:noreply, assign(socket, ...)}

There is a misplaced `}` :) He actually wanted to do : def handle_event(save, params, socket) do ... {:noreply, socket |> put_flash(:info, "It worked!" |> redirect(to: "..."))} end which would work.

Ah. It's a nonstandard formatting though.

Re: How we got to LiveView

#260

Post by [deleted] »

0x000000001 wrote: post #257
joelbluminator wrote: post #233

Earlier quoted context omitted.

I don't know about Oban. I don't think it's bad design for the workers to be separate from your main app like in Sidekiq (they do 'require' the app but they are essentially separate from the servers). Anyway making this point as a huge win for Elixir over Ruby seems really exaggerated to me.

It prevents unnecessarily moving data around. And if you're running the whole stack on the same server with Sideqik you're dealing with interrupts and memory copies between processes; in Elixir it's all within the same allocated memory and nothing gets copied. Plus it's another service you don't have to monitor because it's automatically monitored by BEAM.

[deleted]
Post reply on HN