Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

StimulusReflex, or LiveView for Rails

docs.stimulusreflex.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: StimulusReflex, or LiveView for Rails

#51

Post by jakswa »

bestinterest wrote: post #38
rkangel wrote: post #36

It's worth pointing out that the Phoenix Web Framework (which LiveView is built on) came into being because the creator Chris McCord tried to build something like LiveView in Ruby and eventually ran into fundamental limitations due to how concurrency was handled. He looked around, discovered Elixir and the rest is history. I'm very interested to learn what has changed since then that made this possible, or made it wo…

There's a project called AnyCable which replaces ActionCable to give Rails the real-time performance equivalent of LiveView. See this https://evilmartians.com/chronicles/anycable-actioncable-on-... Looks like having 20,000 idle clients connected to a server sits at only 380MB and Erlang is at 737MB.

Thanks for posting this. I need to try it out. I'm specifically curious about how it performs when a certain amount of those 20k connections are busy and generating traffic. If I'm understanding, the anycable-go connection to ruby is over RPC? So individual websocket messages generate requests to ruby? I could see this performing better for idle connections, that's for sure.

Re: StimulusReflex, or LiveView for Rails

#52

Post by nickjj »

sodapopcan wrote: post #46
wim wrote: post #42

Closing the gap between server and client in terms of app development is definitely the answer. Also agree with the pitch that the currently popular approach of simply moving everything to the client has made tooling incredibly complex (although it's getting better). It's great to see new tools like this being built. Moving everything to the server instead also closes the gap, but the obvious problem is that this int…

Even with tooling getting better, you're still faced with creating an API to the backend that has a high chance of your frontend being the only ever consumer of it. You're also faced with duplicating logic on both front and backends in many scenarios (though of course this can be mitigated with a node backend? I don't know... I've never used node). As for latency, this is over websockets. It becomes a problem if you…

> the TL;DR is that they are sending VERY tiny payloads over websockets

If you have a server in NY and you happen to live in Germany it's going to take about 100-120ms to do a network round trip in a best case scenario (high quality wired cable connection) even with a 1 byte payload. For most websites running in 1 datacenter that means a massive population of the world is going to feel that latency.

That's why I'm not sold on using LV and websockets for everything (such as transitioning from page A to B, etc.). Hotwire Turbo Drive / Frame uses HTTP which means you can cache responses and send back 304s when the content doesn't change. HTTP feels like the right protocol to do this, and then you can save Websockets for when you need to broadcast relatively small amounts of new / updated / removed content to 1 or more connected clients. That's what the Hotwire model provides.

Re: StimulusReflex, or LiveView for Rails

#53

Post by wim »

sodapopcan wrote: post #46
wim wrote: post #42

Closing the gap between server and client in terms of app development is definitely the answer. Also agree with the pitch that the currently popular approach of simply moving everything to the client has made tooling incredibly complex (although it's getting better). It's great to see new tools like this being built. Moving everything to the server instead also closes the gap, but the obvious problem is that this int…

Even with tooling getting better, you're still faced with creating an API to the backend that has a high chance of your frontend being the only ever consumer of it. You're also faced with duplicating logic on both front and backends in many scenarios (though of course this can be mitigated with a node backend? I don't know... I've never used node). As for latency, this is over websockets. It becomes a problem if you…

Oh definitely, totally agree the status quo of duplicating logic is unnecessary.

And I realize this is using websockets, and that the payloads are tiny, but you can't fight the speed of light ;), so it's more of a latency concern (vs bandwidth). So in order to truly keep all the state and rendering with the server, even the smallest UI interaction would require a round-trip, and unless you'll have end nodes all across the country, that seems like it will noticeable.

With some actions like "search", "save" or "reload" I would expect a spinner and delay anyway, so that's not a problem. But if opening a dropdown menu or adding an item to a list (like in the example) feels slow that might not be the best user experience. But perhaps it's not a problem in practice, I haven't seen too many examples.

Re: StimulusReflex, or LiveView for Rails

#54

Post by k__ »

hpvic03 wrote: post #43
Robin_Message wrote: post #39

In many ways, this is very cool. But, I have to admit, I don't love it. I would love to have an integrated environment where client/server doesn't matter, but I don't think this gets far enough. Working in a spread of html.erb with special tags plus some Javascript doesn't feel great to me compared to React. I like their TodoMVC app, since that gives a simple, minimal starting point. Getting persistence in that few l…

Here comes the classic HN middle-brow dismissal :) TodoMVC is meant to be a minimalist demo, not a battle-hardened app. We switched from React to Reflex 7 months ago. We have fewer bugs than we did with React, and we ship things about 3 times faster. 5/5 of us strongly prefer Reflex over React. Including one of us who was a big React aficionado beforehand. Just wanted to put that out there for anyone considering Refl…

Isn't Reflex a Haskell framework?

Switching from React to Reflex isn't just switching a framework, but a whole stack.

Re: StimulusReflex, or LiveView for Rails

#56

Post by sodapopcan »

wim wrote: post #53
sodapopcan wrote: post #46

Earlier quoted context omitted.

Even with tooling getting better, you're still faced with creating an API to the backend that has a high chance of your frontend being the only ever consumer of it. You're also faced with duplicating logic on both front and backends in many scenarios (though of course this can be mitigated with a node backend? I don't know... I've never used node). As for latency, this is over websockets. It becomes a problem if you…

Oh definitely, totally agree the status quo of duplicating logic is unnecessary. And I realize this is using websockets, and that the payloads are tiny, but you can't fight the speed of light ;), so it's more of a latency concern (vs bandwidth). So in order to truly keep all the state and rendering with the server, even the smallest UI interaction would require a round-trip, and unless you'll have end nodes all acros…

Yep, it definitely can be a concern! It takes a lot of distance before latency starts to be noticeable so it all depends on our use-case. These tools aren't one-size-fits-all. Lots of people are building things that aren't going global—at least not right off the bat—so these tools provide a way of moving very quickly out of the gate (no need to build an API for yourself, no need to duplicate any frontend and backend logic). If you do go global, you're probably in a good place to start serving your global customers from servers closer to them—the company I work, for example, for has to do regardless. And that fits under "a nice problem to have" which can be solved after your business has been validated.

But yes, there are many cases where this will not work. It's just a verrrrry attractive option when it can.

Re: StimulusReflex, or LiveView for Rails

#57

Post by bpicolo »

bestinterest wrote: post #38
rkangel wrote: post #36

It's worth pointing out that the Phoenix Web Framework (which LiveView is built on) came into being because the creator Chris McCord tried to build something like LiveView in Ruby and eventually ran into fundamental limitations due to how concurrency was handled. He looked around, discovered Elixir and the rest is history. I'm very interested to learn what has changed since then that made this possible, or made it wo…

There's a project called AnyCable which replaces ActionCable to give Rails the real-time performance equivalent of LiveView. See this https://evilmartians.com/chronicles/anycable-actioncable-on-... Looks like having 20,000 idle clients connected to a server sits at only 380MB and Erlang is at 737MB.

> Looks like having 20,000 idle clients connected to a server sits at only 380MB and Erlang is at 737MB.

That's with Go, versus with anycable itself. Anycable-go looks like 798?

Re: StimulusReflex, or LiveView for Rails

#58

Post by sodapopcan »

nickjj wrote: post #52
sodapopcan wrote: post #46

Earlier quoted context omitted.

Even with tooling getting better, you're still faced with creating an API to the backend that has a high chance of your frontend being the only ever consumer of it. You're also faced with duplicating logic on both front and backends in many scenarios (though of course this can be mitigated with a node backend? I don't know... I've never used node). As for latency, this is over websockets. It becomes a problem if you…

> the TL;DR is that they are sending VERY tiny payloads over websockets If you have a server in NY and you happen to live in Germany it's going to take about 100-120ms to do a network round trip in a best case scenario (high quality wired cable connection) even with a 1 byte payload. For most websites running in 1 datacenter that means a massive population of the world is going to feel that latency. That's why I'm no…

I addressed this in another reply but TL;DR, these solutions are totally use-case dependent and they don't pretend to be one-size-fits-all (or at least LiveView doesn't).
Post reply on HN