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

71–80 of 93 posts

Re: StimulusReflex, or LiveView for Rails

#71

Post by julianrubisch »

jakswa wrote: post #51
bestinterest wrote: post #38

Earlier quoted context omitted.

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.

I’m really excited for Ractors in this content and how/if they could improve the Ruby side

Re: StimulusReflex, or LiveView for Rails

#72

Post by anonygler »

A tiny payload from the world's slowest backend framework.

The Rails community has spent years resisting the future. Ember was an attempt to jam Rails into JavaScript and it's been a miserable, confusing, slow mess that every team utterly regrets.

Rails has spent years and years pushing server-side rendered partials. Now the Rails community has yet another "new" approach that involves writing yet more Ruby instead of JavaScript.

If you adopt any of these Ruby-for-frontend solutions, your future efforts to scale will be severely hampered as you've glued so much stuff down in Ruby. Plus you'll have trouble hiring JS developers, because who wants to learn something so unserious as this?

Write your web frontend in JavaScript. Either be a polyglot or create silos.

Re: StimulusReflex, or LiveView for Rails

#73

Post by ericb »

sodapopcan wrote: post #27
whalesalad wrote: post #17

Earlier quoted context omitted.

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.

Speaking of, DHH looks like he's using tailwind with Rails, so the use-case is getting some love! DHH created this gem:

https://github.com/rails/tailwindcss-rails

Re: StimulusReflex, or LiveView for Rails

#74

Post by [deleted] »

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…

[deleted]

Re: StimulusReflex, or LiveView for Rails

#75

Post by IggleSniggle »

augustl wrote: post #44

FWIW, I'd add a word of caution for this architecture. Coming from an SPA, it feels just like your average react/redux app, except you put your redux state on the server. Your server now maintains the state of all active clients, and you get network lag on all stateful UI interactions. Now that Google will index SPAs, I'd strongly consider a SPA where the server just generates meta tags (for SoMe link previews etc)

> you get network lag on all stateful UI interactions

Isn't this kind of a good thing, though? Now your UI can't lie to you about the true application state, making you think something worked or completed when in fact it's still interacting with the server. /s

I like SPAs because they can work offline / on spotty network connections. I don't like SPAs because they are often unclear about whether or not they are fully synchronized with their backend. I kinda wish people writing SPAs just wrote totally offline apps first that then had an independent synchronization mechanism with their respective backends as a general rule.

Re: StimulusReflex, or LiveView for Rails

#76

Post by Existenceblinks »

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…

Yeah, am silently on your side on this point everywhere you go! Because I already said once and done a good fight.

Stateful (I mean really keep things in assigns) sounds like an inefficient caching. Not all assigns are per user, caching the same things on each process is redundant. And to share these things as one set of data is to put them somewhere else, most likely in a process under the root supervision tree. And there's less point for using LV.

Folks forgot how fast Phoenix.View rendered from controller was (a hello page is microsecond!) it's pretty damn good.

Re: StimulusReflex, or LiveView for Rails

#77

Post by ksec »

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.

I remember there were still latency issues, with 99th percentile being well over 100ms.

Cant find the link to the article though.

Re: StimulusReflex, or LiveView for Rails

#78

Post by [deleted] »

thomasjk wrote: post #11

Using StimulusReflex in my latest project, been a good experience to work with. The community on Discord is very active and helpful, and the docs are top-notch. Check the StimulusReflex Expo for interactive demos w/ code samples: https://expo.stimulusreflex.com/

[deleted]

Re: StimulusReflex, or LiveView for Rails

#79

Post by heleninboodler »

I hope their form validation demo is just a toy and not an actual example of real email validation code, because it doesn't handle '+' in the localpart, which is a very commonly used character. I don't see any custom validation code in the demo source, though, so it kind of looks like they have a builtin "email" validator that's broken, which makes me question the production-readiness of this thing.

Re: StimulusReflex, or LiveView for Rails

#80

Post by e12e »

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…

> which means you can cache responses and send back 304s when the content doesn't change.

Unless I misunderstand - that's still a round-trip to fetch and return a 304? Or are you thinking an edge cache closer to the end-user?

(I don't disagree that websockets aren't a universal solution - but if used as server push - it's difficult to see how plain http could have lower latency? Long polling would be similar, but probably (even) harder to scale if you want 10k+ open connections?).

Post reply on HN