Live data from Hacker News

Why Elixir Is the Best Language for Building a Bootstrapped, B2B SaaS in 2024

sleepeasy.app

141–142 of 142 posts

Re: Why Elixir Is the Best Language for Building a Bootstrapped, B2B SaaS in 2024

#141
post #124

Earlier quoted context omitted.

> I think Phoenix has something similar/ phoenix's channels (for realtime) is the only multiclustered websocket solution with long polling fallback that I know of that will scale to thousands of users out of the box. My startup uses websockets and its never been a bottleneck vs the headaches I've deal with doing similar stuff in nodejs. its just an absolute unit for doing realtime. And now they have liveview which ta…

> comparing it to phoenix on realtime stuff is like comparing a moped to an f16 Have you tested this? I ask because under the hood, Rails is using Faye, and Faye is using EventMachine. About 10 years ago I load tested Faye vs. Node in a websocket scalability test for a websocket based chat app I was writing, that, funnily enough had a polling fallback. We had scalability needs up to around 10k or 20k simultaneous con…

I worked at a startup using rails. I also spent several years as a nodejs engineer.

I built my startup in elixir.

having experienced all 3, I can tell you in real world perfrmance, the metaphor is accurate. if you're boostrapping a startup and you need fast, stable websockets. elixir is the GOAT.

Re: Why Elixir Is the Best Language for Building a Bootstrapped, B2B SaaS in 2024

#142
post #137

Earlier quoted context omitted.

The last Laravel project I used was using Livewire V2. Not all of the problems were strictly "Livewire" problems, but also just the limitations of PHP. Having to send the state back and forward and rehydrate the state on the server on every request is just slow no matter what you do. Live View has an active process for every connected user that maintains state so you only have to send tiny little diff's back and forw…

Do LiveWire responses get so big that the size becomes an issue? Haven't used either LiveWire or LiveViews seriously. Honestly trying to understand what you're saying. I was under the impression LiveWire only sent the data for the component being updated so realistically the main issue is latency (just as with LiveViews). I mean, sending 0.1kB vs 1kB is 10x worse but in practice this doesn't seem like it would have a…

Livewire has to send the full state of the request for the component. Search results is a good example where the state can start to get big. Once it hits the server re-hydrates the models. They are also HTTP requests which have some handshaking.

Live View only sends the diffs excuse the state lives in an active process on the server, and it uses web sockets which is much faster than http requests.

Post reply on HN