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

21–30 of 93 posts

Re: StimulusReflex, or LiveView for Rails

#21

Post by freedomben »

whalesalad wrote: post #17
raffomania wrote: post #4

To me, this looks like one of the few real ways out of the madness that is modern frontend development. Excited to see the approach gaining adoption!

I don’t think this holds up anymore. Tooling has come so far. I have never in my life been as productive as I am inside of a Vue/Tailwind code base at this point. One of my clients is a fairly vanilla Rails 4 app (which is arguably a friendly place to be - although slow) and it’s not even close. I miss Vue and having a full “app” environment on the front-end side constantly. Jumping back and forth between these proje…

I agree with you, but it took a long, long time to get that good and comfortable with react (in my case) years actually since I don't only do frontend.

For people who haven't already climbed that mountain and learned a new "language" I agree with GP. This could be a game changer.

My only regret is that for a while now JavaScript had basically been the standard. As good a development as I think this is, it will really in more fragmentation and less general purpose devs.

Nevertheless I think it's good, and web assembly was always going to do this to JavaScript ecosystem anyway.

Re: StimulusReflex, or LiveView for Rails

#22

Post by freedomben »

cpursley wrote: post #20

I appreciate the work put into this, glad to see SPA alternatives and can understand using this for existing Rails projects. I'm curious why would one would choose this over Phoenix LiveView for a new project? How are the two different?

I use Phoenix primarily (for web apps) so I of course agree with you, but the obvious answer is "anyone doing rails can add this easily without changing languages/stacks." That alone addresses a massive segment, probably much much larger than Phoenix

Re: StimulusReflex, or LiveView for Rails

#25

Post by freedomben »

agd wrote: post #19
HorizonShadow wrote: post #15

Earlier quoted context omitted.

They don't really have any overlap. Hotwire is for replacing frames with content when navigating through anchors or form posts. StimulusReflex is performing RPC, then diffs the old page and the new page, updating changed elements.

One difference is that liveview / reflex are stateful whereas Hotwire (turbo) is not. This has varying performance implications. Turbo will do repeat work server side and payloads will typically be bigger, however development may be simpler due to lack of state and memory usage server side may be lower. Turbo also has the possibility to gracefully degrade when js is not available (although I doubt this will be taken…

This is a great point. Plus not all platforms, hosts, and proxies for that matter will allow web sockets.

Especially for an established rails app, allowing web sockets can require architecture changes.

Re: StimulusReflex, or LiveView for Rails

#26

Post by nickjj »

sudhirj wrote: post #9
julianrubisch wrote: post #7

Earlier quoted context omitted.

in one word: morphdom ( https://github.com/patrick-steele-idem/morphdom ) also, StimulusReflex predates Hotwire for 1 year and is already pretty hardened :-)

So this receives the full HTML page and does a near-zero-damage “morphing” as opposed to Hotwire which either does full page dumb replacement or asks you to define which sections to replace? Does that sound right?

> as opposed to Hotwire which either does full page dumb replacement or asks you to define which sections to replace

It's not that dumb in practice because for a lot of things Hotwire uses HTTP instead of WebSockets which means you can take advantage of what HTTP has to offer such as caching.

That means if you decide to dynamically load a menu's contents with a Hotwire Turbo Frame then it's only sent over the wire once and assuming its content doesn't change, it'll serve a 304 content not modified for future requests.

For pushing updates with Turbo Stream which is done over WebSockets, I'm pretty sure it'll push that snippet of HTML (let's say a user's comment) over WebSockets and then either append or prepend it to the DOM based on however you configured it to be inserted. And if you edited that comment later on, it will replace that snippet of HTML that was previously sent (since it's the same ERB template). It won't re-render the full page.

Re: StimulusReflex, or LiveView for Rails

#27

Post by sodapopcan »

whalesalad wrote: post #17
raffomania wrote: post #4

To me, this looks like one of the few real ways out of the madness that is modern frontend development. Excited to see the approach gaining adoption!

I don’t think this holds up anymore. Tooling has come so far. I have never in my life been as productive as I am inside of a Vue/Tailwind code base at this point. One of my clients is a fairly vanilla Rails 4 app (which is arguably a friendly place to be - although slow) and it’s not even close. I miss Vue and having a full “app” environment on the front-end side constantly. Jumping back and forth between these proje…

You can certainly still use tailwind here.

Otherwise, the point is that you won’t have to jump back and forth—you can just stay on the backend. I’ve actually never used Stimulus Reflex, but in LiveView, I’m writing very small bits of JS maybe 2% of the time.

Re: StimulusReflex, or LiveView for Rails

#29

Post by akanet »

I can imagine this simplifying the development of B2B SaaS tools that are primarily about presenting and interacting with data. The bit about broadcasting to a large number of clients is harder to see the value of in a Rails application when so many approaches work simply enough already.

As for replacing rich frontend rendering libraries in more complex apps - it seems dicey. Part of the virtue of React is that it simplifies the visual presentation of the frontend based on a constellation of data. Things like highlighted elements, hover states, and dragging items. It seems difficult to enable that level of polish while the backend is making dom-level changes based on the explicit data that you have to deliberately send over the network.

Re: StimulusReflex, or LiveView for Rails

#30

Post by sodapopcan »

cpursley wrote: post #20

I appreciate the work put into this, glad to see SPA alternatives and can understand using this for existing Rails projects. I'm curious why would one would choose this over Phoenix LiveView for a new project? How are the two different?

I would love it if Elixir grew in popularity but I’m also happy other ecosystems are hopping aboard this ship. I absolutely love working this way and hope it becomes more of the norm.
Post reply on HN