10 ms·

StimulusReflex, or LiveView for Rails

198 points by nanna 6y ago

adenozine 6y ago
Does python have anything like this?
- julianrubisch 6y ago
  https://pypi.org/project/django-sockpuppet/ https://pypi.org/project/django-sockpuppet/ It's a SR clone, the maintainers are actually very active in our community :-)
  - shinryuu 6y ago
    or link to actual repo -> https://github.com/jonathan-s/django-sockpuppet https://github.com/jonathan-s/django-sockpuppet (I'm the maintainer).
- tbran 6y ago
  htmx [1] (formerly intercooler) is sort of similar, although the server instead returns html fragments. Here's an example [2] of using it for infinite scroll (instead of pagination). I'm pretty excited to try out django-sockpuppet from an adjacent comment! [1]: https://htmx.org/ https://htmx.org/ [2]: https://engineering.instawork.com/iterating-with-simplicity-evolving-a-django-app-with-intercooler-js-8ed8e69d8a52 https://engineering.instawork.com/iterating-with-simplicity-...
- rkangel 6y ago
  This comment I have just made applies equally to Python as to Ruby I think: https://news.ycombinator.com/item?id=25791181 https://news.ycombinator.com/item?id=25791181
  - theptip 6y ago
    What’s the missing feature? Native M:N green threads? Seems to me that Python’s async is a fair bit more mature than Ruby, so the comparison here is not obvious to me.
    - rkangel 6y ago
      The conclusion I have come to is that the way you interact with the concurrency model is just as important as what the model is underneath. Erlang (and Elixir) have got both levels right - M:N scheduling underneath, and the actor model (with excellent library support) on top to best take advantage of it.
- m4r71n 6y ago
  Django does: https://github.com/edelvalle/reactor https://github.com/edelvalle/reactor
- adparadox 6y ago
  More of a port of Laravel's Livewire (so only AJAX calls, no websockets), but I've been working on something similar for Django at https://www.django-unicorn.com/ https://www.django-unicorn.com/. I also detail other options at https://www.django-unicorn.com/docs/#related-projects https://www.django-unicorn.com/docs/#related-projects.
raffomania 6y ago
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!
- whalesalad 6y ago
  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 projects is like going from a hot and steamy comfy jacuzzi into an icy cold pool.
  - freedomben 6y ago
    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.
    - rorykoehler 6y ago
      The JavaScript framework era always felt like a bandaid while we figure out something better. I’m convinced liveview is the future.
  - sodapopcan 6y ago
    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.
PedroBatista 6y ago
Wish I had the time to really study Phoenix's LiveView and implement the same in Java. AFAIK there's no equivalent for this in Java and I mean the same not kinda-the-same but not really like Vaadin or God forbid GWT.
- scns 6y ago
  Wish?
  - PedroBatista 6y ago
    thks
- dnautics 6y ago
  Good luck. Liveview depends strongly on features of the erlang VM that you won't get right without a deeper understanding of erlang (how do you clean up a websocket connection when the actor exits early, say due to throwing an exception - that's zero lines of code in lv), you're probably better of taking inspiration and writing it from scratch.
  - entangled999 6y ago
    So in your opinion in Java land resources are always leaked when some exception occurs? That’s a bit far from the truth
    - jspash 6y ago
      No, I think the point was that you would have be aware of these types of cases - and cleaning up after exceptions isn't the only one - and deal with it in your code. Maybe it's trivial to do in Java, but still it has to be done. Whereas with Elixir, it's handled by the way failed processes are handled which is to just "let it die". Another one will come along and replace it. (I'm greatly simplifying here)
      - 6y ago
sudhirj 6y ago
DHH recently introduced Hotwire https://hotwire.dev/ https://hotwire.dev/ which already does something similar. Any idea what the difference is?
- julianrubisch 6y ago
  in one word: morphdom (https://github.com/patrick-steele-idem/morphdom https://github.com/patrick-steele-idem/morphdom) also, StimulusReflex predates Hotwire for 1 year and is already pretty hardened :-)
  - sudhirj 6y ago
    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?
    - rolae 6y ago
      Exactly. Basically all you to is to call a remote procedure, which you can do by adding a simple `data-reflex="click->Todo#toggle`. In the remote method you change something about the state (for example db, redis). The server rerenders the page and morphs the difference. If you need more control you can get it by defining which elements to render and to morph.
    - nickjj 6y ago
      > 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.
thomasjk 6y ago
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/ https://expo.stimulusreflex.com/
- deleted 6y ago
  [deleted]
pibefision 6y ago
Russ Hanneman feels positive about stimulus reflex https://www.youtube.com/watch?v=utxCm3uLhIE https://www.youtube.com/watch?v=utxCm3uLhIE
- bithavoc 6y ago
  How did they get the actor to play this, amazing.
  - arusahni 6y ago
    Assuming Cameo?
    - julianrubisch 6y ago
      It‘s called „money“
  - deleted 6y ago
    [deleted]
- wes-k 6y ago
  Ha that was well worth the watch, ty!
cpursley 6y ago
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?
- freedomben 6y ago
  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
- sodapopcan 6y ago
  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.
- hpvic03 6y ago
  The Ruby/Rails ecosystem is massive, and remains extremely productive and pleasant to work with.
deleted 6y ago
[deleted]
akanet 6y ago
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.
- amoitnga 6y ago
  was looking for this sort of comment to confirm my bias. I'm trying to figure out what is it about how I feel about reflex: the idea that even with this you still have to reach for js libs or am I just being lazy. I guess a little bit of both maybe. But it's true, even though our app is pretty straight forward crud, we still need things like autocomplete, drag and drop, tabs, modals, form validation etc. Just having js being js and ruby being ruby seems easier for me to parse and work with.
rkangel 6y ago
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 work better. Or whether those problems are just being "lived with".
- bestinterest 6y ago
  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-steroids 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.
  - jakswa 6y ago
    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.
    - julianrubisch 6y ago
      I’m really excited for Ractors in this content and how/if they could improve the Ruby side
  - bpicolo 6y ago
    > 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?
  - deedubaya 6y ago
Robin_Message 6y ago
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 lines of code is nice. However, it has also at least one bug compared to canonical TodoMVC. I think the problem of this kind of too-clever binding is that it makes this kind of bug easy to introduce; whereas something with clear one-way data-binding like React, for all it can be verbose and annoying, tends to make it easier to get this sort of thing right. (The bug? Click an existing todo to edit it, start typing, then press escape. The edit is meant to be discarded, but instead you'll see a flash of the old value and then the new value is persisted. It's not the worst bug ever, but shows that even in a simple app, experts can subtly screw up important behaviour.)
- deleted 6y ago
  [deleted]
- hpvic03 6y ago
  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 Reflex, a bug in TodoMVC is not a harbinger of a bad framework.
  - Robin_Message 6y ago
    That may be fair :) Personally, I enjoy React on the front-end but don't currently like any back-end framework, so Reflux may well be better in aggregate. (FWIW, I have a PhD in computer science and big part of that was on web applications and frameworks for them, combined with ~15 years commercial experience mastering web development, so this wasn't meant to be a middle-brow dismissal. As I said, it is exciting, I'm just not convinced. I think there is some merit in the argument that too much cleverness can be dangerous. Battle-hardened is tricky; I agree TodoMVC is meant to be a minimalist demo, but if a minimal demo can have subtle bugs caused by the cleverness of the data binding, how much more so a real app with a much more complex data model? But I guess it does eliminate whole other classes of bug, so I can believe it works less buggy and more productive better than React+some back end. I certainly find the current front/back split endlessly painful. I am also excited by the new React Server Components which might be another good solution to that.) EDIT TO ADD: I guess what I was trying to say is: I found this interesting, and I looked at it, and then I found this bug in the example, and I wonder if this framework might make a bug like that more likely because the power of making some things easier is obscuring what is happening in some cases, and I don't know if that trade-off is worth it.
wim 6y ago
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 introduces a lot of latency for UI interactions. Ajax page loads/Turbolinks works so well because it actually makes things faster with almost zero effort. Introducing a similar method for every UI interaction though is a different matter, and I don't see how the latency won't be noticeable. For instance, The TodoMVC example's server seems to be far enough way from my location that creating a task has noticeable lag. Sure it's just an example, but without introducing some client-side/optimistic rendering, that's going to be hard to avoid (and that would defeat the purpose of having all your logic in one place, on the server). Not sure how this is addressed here?
- sodapopcan 6y ago
  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 are connecting to a server across the ocean but otherwise, it's incredibly fast and feels just as snappy as JS. I actually also haven't used Stimulus Reflex, just Phoenix LiveView so I'm not sure if they are exactly the same, but the TL;DR is that they are sending VERY tiny payloads over websockets. This video explains it well (though it's also a demo of LiveView): https://www.youtube.com/watch?v=MZvmYaFkNJI https://www.youtube.com/watch?v=MZvmYaFkNJI
  - nickjj 6y ago
    > 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.
augustl 6y ago
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)
- IggleSniggle 6y ago
  > 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.
tra3 6y ago
I love that Rails continues to evolve. I've invested so much time in it that it's good to know that Rails is still a viable choice for modern work. If someone's creating new cool stuff like this, then I'm not the only one.
- joelbluminator 6y ago
  I feel the same. I'm invested and I actually like developing on it (biased of course). I don't see any reason to worry about Rails jobs disappearing, Rails is here to stay. It's soon turning 20 forchrissake!
fareesh 6y ago
Instinctively this looks like something that works great for simple concepts. Does anyone have any experience integrating this for a complex project or UI? Would love to hear more.
cargoshipit 6y ago
Has anyone used LiveView and this enough to give a comparison of the dev UX? I've mainly used LiveView for a side project and have quite enjoyed it.
lawwantsin17 6y ago
The docs are so full of opinions and sales speak it's disgusting.
anonygler 6y ago
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.
- Toutouxc 6y ago
  Imagine that there are companies (like the one I work for) and projects that are absolutely NOT going to scale (maybe because they're somebody else's internal apps, which is what I do) and the company behind them will not have trouble hiring JS developers, because they're a Ruby shop. So they like writing more Ruby instead of JavaScript. They've enjoyed Rails pushing server-side rendered partials. And the person that comes demanding they rewrite all their frontend in the current JS framework-du-jour (possibly to be rewritten again in a couple of years) will be told to fuck right off.
  - jspash 6y ago
    You've just described my company! I struggled through rewrites of JS from jQuery -> Backbone -> Vue -> Webpacker + Vue until the "head of IT" went off to do marketing where he was better suited. Now that I have the reigns, we've been slowly removing as much JS as makes sense and we've never been happier, more productive and relatively bug-free. But we still have the requirement of "near instant" front-end for certain things. And this is precisely the sort of thing that a team of RoR devs can really get behind and do well. Rather than try and cram yet another JS paradigm and DSL into their heads only to be forgotten when the next one rolls into town. Personally I'm a Phoenix/LiveView champion, but we're a Rails shop and I know better than attempt The Big Rewrite. So this really fits the bill.
heleninboodler 6y ago
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.
- rolae 6y ago
  That was a regression in version 3.4, fixed here: https://github.com/hopsoft/stimulus_reflex/pull/418 https://github.com/hopsoft/stimulus_reflex/pull/418
miki123211 6y ago
> This entire round-trip allows us to update the UI in 20-30ms without flicker or expensive page loads. A lot of people have much worse ping times than that. Try using this on a satellite connection for example, and your experience won't be very pleasant. On my internet connection, which is pretty average by polish standards, the best ping I can get is 30ms, and that only happens when the server I ping is just one or two hops away. I probably won't be able to go under 100ms when the server is in the US. It seems like this approach sacrifices runtime performance for development speed. I feel like it might often be a good tradeoff to make, but it's a tradeoff nevertheless, and we should recognize that. Separate layers for frontend and backend introduce complexity, but client side code is client side code, you can't go much faster than that.
Barrin92 6y ago
As someone who has barely done any web development in his life but having a fairly interactive side project in mind I wanted to work on, is Rails and StimulusReflex a solid thing to start out with right now, or would you recommend just going with React, Vue and so on? Navigating all those frameworks seems very complex.
- Kailhus 6y ago
  Rails is great!
true_religion 6y ago
In my experience, the latency is just too great on 3G or 4G with congestion. It's 500ms to 1000ms for something that ought to be instantaneous like clicking on a tab that I have already seen. React websites might be a larger initial download, but its only an extra 3 seconds wait to begin with, then near instant reactivity afterwards for everything that doesn't require a network call. Ironically, the browser cache is much faster than 500ms so the tab demo would have been faster if implemented as a full page refresh.
amw-zero 6y ago
Honest question - what’s the difference between this and Hotwire?

198 points by nanna 6y ago

adenozine 6y ago

Does python have anything like this?

julianrubisch 6y ago
https://pypi.org/project/django-sockpuppet/ https://pypi.org/project/django-sockpuppet/ It's a SR clone, the maintainers are actually very active in our community :-)
- shinryuu 6y ago
  or link to actual repo -> https://github.com/jonathan-s/django-sockpuppet https://github.com/jonathan-s/django-sockpuppet (I'm the maintainer).
tbran 6y ago
htmx [1] (formerly intercooler) is sort of similar, although the server instead returns html fragments. Here's an example [2] of using it for infinite scroll (instead of pagination). I'm pretty excited to try out django-sockpuppet from an adjacent comment! [1]: https://htmx.org/ https://htmx.org/ [2]: https://engineering.instawork.com/iterating-with-simplicity-evolving-a-django-app-with-intercooler-js-8ed8e69d8a52 https://engineering.instawork.com/iterating-with-simplicity-...
rkangel 6y ago
This comment I have just made applies equally to Python as to Ruby I think: https://news.ycombinator.com/item?id=25791181 https://news.ycombinator.com/item?id=25791181
- theptip 6y ago
  What’s the missing feature? Native M:N green threads? Seems to me that Python’s async is a fair bit more mature than Ruby, so the comparison here is not obvious to me.
  - rkangel 6y ago
    The conclusion I have come to is that the way you interact with the concurrency model is just as important as what the model is underneath. Erlang (and Elixir) have got both levels right - M:N scheduling underneath, and the actor model (with excellent library support) on top to best take advantage of it.
m4r71n 6y ago
Django does: https://github.com/edelvalle/reactor https://github.com/edelvalle/reactor
adparadox 6y ago
More of a port of Laravel's Livewire (so only AJAX calls, no websockets), but I've been working on something similar for Django at https://www.django-unicorn.com/ https://www.django-unicorn.com/. I also detail other options at https://www.django-unicorn.com/docs/#related-projects https://www.django-unicorn.com/docs/#related-projects.

raffomania 6y ago

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!

whalesalad 6y ago
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 projects is like going from a hot and steamy comfy jacuzzi into an icy cold pool.
- freedomben 6y ago
  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.
  - rorykoehler 6y ago
    The JavaScript framework era always felt like a bandaid while we figure out something better. I’m convinced liveview is the future.
- sodapopcan 6y ago
  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.

PedroBatista 6y ago

Wish I had the time to really study Phoenix's LiveView and implement the same in Java. AFAIK there's no equivalent for this in Java and I mean the same not kinda-the-same but not really like Vaadin or God forbid GWT.

scns 6y ago
Wish?
- PedroBatista 6y ago
  thks
dnautics 6y ago
Good luck. Liveview depends strongly on features of the erlang VM that you won't get right without a deeper understanding of erlang (how do you clean up a websocket connection when the actor exits early, say due to throwing an exception - that's zero lines of code in lv), you're probably better of taking inspiration and writing it from scratch.
- entangled999 6y ago
  So in your opinion in Java land resources are always leaked when some exception occurs? That’s a bit far from the truth
  - jspash 6y ago
    No, I think the point was that you would have be aware of these types of cases - and cleaning up after exceptions isn't the only one - and deal with it in your code. Maybe it's trivial to do in Java, but still it has to be done. Whereas with Elixir, it's handled by the way failed processes are handled which is to just "let it die". Another one will come along and replace it. (I'm greatly simplifying here)
    - 6y ago

sudhirj 6y ago

DHH recently introduced Hotwire https://hotwire.dev/ https://hotwire.dev/ which already does something similar. Any idea what the difference is?

julianrubisch 6y ago
in one word: morphdom (https://github.com/patrick-steele-idem/morphdom https://github.com/patrick-steele-idem/morphdom) also, StimulusReflex predates Hotwire for 1 year and is already pretty hardened :-)
- sudhirj 6y ago
  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?
  - rolae 6y ago
    Exactly. Basically all you to is to call a remote procedure, which you can do by adding a simple `data-reflex="click->Todo#toggle`. In the remote method you change something about the state (for example db, redis). The server rerenders the page and morphs the difference. If you need more control you can get it by defining which elements to render and to morph.
  - nickjj 6y ago
    > 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.

thomasjk 6y ago

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/ https://expo.stimulusreflex.com/

deleted 6y ago
[deleted]

pibefision 6y ago

Russ Hanneman feels positive about stimulus reflex https://www.youtube.com/watch?v=utxCm3uLhIE https://www.youtube.com/watch?v=utxCm3uLhIE

bithavoc 6y ago
How did they get the actor to play this, amazing.
- arusahni 6y ago
  Assuming Cameo?
  - julianrubisch 6y ago
    It‘s called „money“
- deleted 6y ago
  [deleted]
wes-k 6y ago
Ha that was well worth the watch, ty!

cpursley 6y ago

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?

freedomben 6y ago
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
sodapopcan 6y ago
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.
hpvic03 6y ago
The Ruby/Rails ecosystem is massive, and remains extremely productive and pleasant to work with.

deleted 6y ago

[deleted]

akanet 6y ago

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.

amoitnga 6y ago
was looking for this sort of comment to confirm my bias. I'm trying to figure out what is it about how I feel about reflex: the idea that even with this you still have to reach for js libs or am I just being lazy. I guess a little bit of both maybe. But it's true, even though our app is pretty straight forward crud, we still need things like autocomplete, drag and drop, tabs, modals, form validation etc. Just having js being js and ruby being ruby seems easier for me to parse and work with.

rkangel 6y ago

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 work better. Or whether those problems are just being "lived with".

bestinterest 6y ago
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-steroids 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.
- jakswa 6y ago
  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.
  - julianrubisch 6y ago
    I’m really excited for Ractors in this content and how/if they could improve the Ruby side
- bpicolo 6y ago
  > 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?
- deedubaya 6y ago

Robin_Message 6y ago

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 lines of code is nice. However, it has also at least one bug compared to canonical TodoMVC. I think the problem of this kind of too-clever binding is that it makes this kind of bug easy to introduce; whereas something with clear one-way data-binding like React, for all it can be verbose and annoying, tends to make it easier to get this sort of thing right. (The bug? Click an existing todo to edit it, start typing, then press escape. The edit is meant to be discarded, but instead you'll see a flash of the old value and then the new value is persisted. It's not the worst bug ever, but shows that even in a simple app, experts can subtly screw up important behaviour.)

deleted 6y ago
[deleted]
hpvic03 6y ago
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 Reflex, a bug in TodoMVC is not a harbinger of a bad framework.
- Robin_Message 6y ago
  That may be fair :) Personally, I enjoy React on the front-end but don't currently like any back-end framework, so Reflux may well be better in aggregate. (FWIW, I have a PhD in computer science and big part of that was on web applications and frameworks for them, combined with ~15 years commercial experience mastering web development, so this wasn't meant to be a middle-brow dismissal. As I said, it is exciting, I'm just not convinced. I think there is some merit in the argument that too much cleverness can be dangerous. Battle-hardened is tricky; I agree TodoMVC is meant to be a minimalist demo, but if a minimal demo can have subtle bugs caused by the cleverness of the data binding, how much more so a real app with a much more complex data model? But I guess it does eliminate whole other classes of bug, so I can believe it works less buggy and more productive better than React+some back end. I certainly find the current front/back split endlessly painful. I am also excited by the new React Server Components which might be another good solution to that.) EDIT TO ADD: I guess what I was trying to say is: I found this interesting, and I looked at it, and then I found this bug in the example, and I wonder if this framework might make a bug like that more likely because the power of making some things easier is obscuring what is happening in some cases, and I don't know if that trade-off is worth it.

wim 6y ago

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 introduces a lot of latency for UI interactions. Ajax page loads/Turbolinks works so well because it actually makes things faster with almost zero effort. Introducing a similar method for every UI interaction though is a different matter, and I don't see how the latency won't be noticeable. For instance, The TodoMVC example's server seems to be far enough way from my location that creating a task has noticeable lag. Sure it's just an example, but without introducing some client-side/optimistic rendering, that's going to be hard to avoid (and that would defeat the purpose of having all your logic in one place, on the server). Not sure how this is addressed here?

sodapopcan 6y ago
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 are connecting to a server across the ocean but otherwise, it's incredibly fast and feels just as snappy as JS. I actually also haven't used Stimulus Reflex, just Phoenix LiveView so I'm not sure if they are exactly the same, but the TL;DR is that they are sending VERY tiny payloads over websockets. This video explains it well (though it's also a demo of LiveView): https://www.youtube.com/watch?v=MZvmYaFkNJI https://www.youtube.com/watch?v=MZvmYaFkNJI
- nickjj 6y ago
  > 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.

augustl 6y ago

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)

IggleSniggle 6y ago
> 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.

tra3 6y ago

I love that Rails continues to evolve. I've invested so much time in it that it's good to know that Rails is still a viable choice for modern work. If someone's creating new cool stuff like this, then I'm not the only one.

joelbluminator 6y ago
I feel the same. I'm invested and I actually like developing on it (biased of course). I don't see any reason to worry about Rails jobs disappearing, Rails is here to stay. It's soon turning 20 forchrissake!

fareesh 6y ago

Instinctively this looks like something that works great for simple concepts. Does anyone have any experience integrating this for a complex project or UI? Would love to hear more.

cargoshipit 6y ago

Has anyone used LiveView and this enough to give a comparison of the dev UX? I've mainly used LiveView for a side project and have quite enjoyed it.

lawwantsin17 6y ago

The docs are so full of opinions and sales speak it's disgusting.

anonygler 6y ago

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.

Toutouxc 6y ago
Imagine that there are companies (like the one I work for) and projects that are absolutely NOT going to scale (maybe because they're somebody else's internal apps, which is what I do) and the company behind them will not have trouble hiring JS developers, because they're a Ruby shop. So they like writing more Ruby instead of JavaScript. They've enjoyed Rails pushing server-side rendered partials. And the person that comes demanding they rewrite all their frontend in the current JS framework-du-jour (possibly to be rewritten again in a couple of years) will be told to fuck right off.
- jspash 6y ago
  You've just described my company! I struggled through rewrites of JS from jQuery -> Backbone -> Vue -> Webpacker + Vue until the "head of IT" went off to do marketing where he was better suited. Now that I have the reigns, we've been slowly removing as much JS as makes sense and we've never been happier, more productive and relatively bug-free. But we still have the requirement of "near instant" front-end for certain things. And this is precisely the sort of thing that a team of RoR devs can really get behind and do well. Rather than try and cram yet another JS paradigm and DSL into their heads only to be forgotten when the next one rolls into town. Personally I'm a Phoenix/LiveView champion, but we're a Rails shop and I know better than attempt The Big Rewrite. So this really fits the bill.

heleninboodler 6y ago

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.

rolae 6y ago
That was a regression in version 3.4, fixed here: https://github.com/hopsoft/stimulus_reflex/pull/418 https://github.com/hopsoft/stimulus_reflex/pull/418

miki123211 6y ago

> This entire round-trip allows us to update the UI in 20-30ms without flicker or expensive page loads. A lot of people have much worse ping times than that. Try using this on a satellite connection for example, and your experience won't be very pleasant. On my internet connection, which is pretty average by polish standards, the best ping I can get is 30ms, and that only happens when the server I ping is just one or two hops away. I probably won't be able to go under 100ms when the server is in the US. It seems like this approach sacrifices runtime performance for development speed. I feel like it might often be a good tradeoff to make, but it's a tradeoff nevertheless, and we should recognize that. Separate layers for frontend and backend introduce complexity, but client side code is client side code, you can't go much faster than that.

Barrin92 6y ago

As someone who has barely done any web development in his life but having a fairly interactive side project in mind I wanted to work on, is Rails and StimulusReflex a solid thing to start out with right now, or would you recommend just going with React, Vue and so on? Navigating all those frameworks seems very complex.

Kailhus 6y ago
Rails is great!

true_religion 6y ago

In my experience, the latency is just too great on 3G or 4G with congestion. It's 500ms to 1000ms for something that ought to be instantaneous like clicking on a tab that I have already seen. React websites might be a larger initial download, but its only an extra 3 seconds wait to begin with, then near instant reactivity afterwards for everything that doesn't require a network call. Ironically, the browser cache is much faster than 500ms so the tab demo would have been faster if implemented as a full page refresh.

amw-zero 6y ago

Honest question - what’s the difference between this and Hotwire?