It's great that we have options! Personally, I think that sticking to the "Rails Core" as much as possible is the best route for a long term maintained application. It looks like the stuff being done over at StimulusReflex is awesome and you're right, there is overlap between the two. I think that it ultimately comes down to which method resonates with your team. If the team find that StimulusReflex is solving their needs and prefers it over Hotwire, then that's the correct route to go. Really, Hotwire is, currently, just Stimulus and "Turbolinks 6" (Turbo). I think I read somewhere that because Turbo has much more functionality than Turbolinks, they believe it warranted a new name instead of a version bump and with the release of Hotwire, it was the perfect opportunity. So, in the future, I think that we will see Rails 7 or later with Hotwire as the default, so its adoption rate will likely be a lot higher than StimulusReflex. And I'm waiting to see if View Components will make it into the Rails core. I believe that there was a merge request for this to be included on 6.1, but for one reason or another, it was delayed/rejected. However, this could just be due to polishing up the feature before it gets added into the core.

I've used it in situations where we had demo environments which would automatically reset after a period of time. Using the seeds file was very helpful to reset the data. Sales people would have their own logins which they could give a demo of the application and would perform certain functions like approving timesheets or correct missing IN/OUT punches for employees. They didn't want to prepare new data each time they had a demo for potential clients, so having the seeds generate new data each day/week was a huge timesaver for them.

Thanks  ☒ . Between episode prep and recording, this one did take quite a while. Mostly it was waiting for AWS to do its stuff, fixing and then waiting for AWS to do its stuff.

FYI to all, if you want to set up a swapfile, because you're using a small instance and not much RAM is available, you can create one when the VM is getting provisioned. I actually prefer to have a small swapfile in the event that my VM runs out of RAM, this would keep it from crashing. It is bad practice to rely on swap since it slows things down and is just overall bad practice, but it is much better than having the VM crash and die due to Out of Memory issues.

# .ebextensions/swap.config
commands:
  000_swap:
    ignoreErrors: true
    test: test ! -f /swapfile
    command: dd if=/dev/zero of=/swapfile bs=1M count=4096 && mkswap /swapfile && swapon /swapfile

 ☒ Try running the yarn commands manually in the EC2 instance. I'm also a bit confused. What is this pop user? Are you trying to do this within Beanstalk's EC2 instance or on your local host machine?

sudo curl --silent --location https://rpm.nodesource.com/setup_14.x | sudo bash -
sudo yum -y install nodejs

sudo wget https://dl.yarnpkg.com/rpm/yarn.repo -O /etc/yum.repos.d/yarn.repo
sudo yum -y install yarn