Doing Rails Wrong

The way I remember it around 2006 there were a few up and coming web development shops in my town that had their practice centered around Rails. That last half of the decade I was working on advanced RIAs like knowledge graph editors and decision support tools using systems like GWT and Silverlight that were not Javascript but had the same async comm challenges.

Circa 2010 those people who were so successful with Ruby had come to the conclusion that they couldn't sell RoR apps anymore so instead they were struggling with Angular -- not to do anything they couldn't with do Rails but rather they though customers demanded applications that looked like Angular applications.

React was a big hit because it was an "Angular" which people could actually deliver working applications with. Its strength I think it is that it addressed certain concerns but left other ones unaddressed such as the theory of async comm. If there is a simple mapping between the state of the application and the state that is represented in the React tree life is great but I look back at the applications I was writing in 2006 and it still looks like a regression.

What I like about it is that I can draw absolutely anything I can imagine with it, even 3-d virtual worlds

https://aframe.io/

Vue has a model which is closer to my mental model of web forms with first-class lists but I can see how to get into "you can't get here from there" situations.

I see the problem React solving is "how to compose an application out of components" and compared to WPF, JavaFX, and such, it's dramatically simpler, it's like a missing chapter out of Graham's On Lisp

The ecosystem isn’t there with Phoenix unfortunately. It’s why I stick with Rails or Laravel.

I think the point of the article is that it's likely you didn't need a "modern web application" in the first place, because vanilla Rails would work fine. But you won't know that if you don't bother understanding the choices made in vanilla Rails.

I use Kubernetes for almost everything (including my pet projects) and I see the value it brings, even if for increased complexity (although k3s is a pretty good middle ground). But none of these things you mentioned are unsolvable or require manual intervention.

> What if a server gets rebooted

Then the rsync/scp would fail and I would notice it in deployment logs. Or it should be straightforward to monitor current version across a fleet of baremetal.

> Maybe you lost internet while doing the update

True, but even Ansible recommends running a controller closer to target machines.

> What about a broken build

That's what tests are for.

> maybe migration problem

That's trickier, but unrelated to deployment method.

> How do you revert (push an older tarball)

By... pushing an older tarball?

this ^^^

I've used turbo/stimulus/hotwire. It's best suited for STATELESS interactions withe the browser/web page. The problem is not all desired user experiences and use cases are stateless. And the ecosystem for hotwire is a minuscule fraction of all the other popular js frameworks.

If you're searching for inventory available its perfect. However if you want to update one thing based on the most recently touched input it becomes more complicated and in all honesty more trouble that it's worth.

Honestly if you're a solo Rails dev, use whatever you want. However the React ecosystem, and really all of the other popular JS ecosystems (vue, ), are very strong and you have so many available options. Stimulus is 2 steps back from jQuery, it inverted the Event delegation pattern. No one else outside of the rails community is using it.