Hacker News Reader

Comment by nateberkopec | Hacker News Reader

To me, the only point on this list that hasn't improved much is "Ruby on Rails needs to more or less work in ANY environment".

Ruby's install/user story for Windows is still Not Great, and Ruby version wrangling on any operating system is a question that you still get 100 answers to ("use asdf/rvm/rbenv/chruby blah blah blah").

For the rest:

1) It's certainly Fast Enough now. More important webperf issues are happening on the frontend side nowadays. Who cares if your backend takes 500ms to respond when it takes 5 _seconds_ to compile the JS on the client.

3) Solved since Rails 4.0 IMO.

4) Discourse has more or less proven this can be done, with some hard work. Also, Heroku more or less standardized the 512MB VPS size, and nowadays 1GB is pretty cheap and becoming more common, so Rails doesn't struggle with memory limits anymore.

View on HN

The answer is rbenv :)

The ruby language has also sped up a lot since 2008, which has helped Rails. I catch your point about the slowness being in the client these days, but 500ms would be an exceptionally unusually slow response from the rails application in any of the production rails apps I’ve run.

I'm still using RVM, is RBENV the recommended approach now? What are the key differences for a user?

Personally I swapped from rbenv to asdf a while back. I don't think there's any real justification for one over another these days, just use the one you're comfortable with :D

Happy asdf user here. If you're only using ruby, then asdf isn't much better or worse - but asdf is great for supporting other toolchain, like python, crystal, rust, go... AFAIK the asdf ruby plug-in uses rbenv under the hood.

I've switch from rbenv to chruby[1] years ago. Seems simpler and doesn't have the rehash command that is (was?) required with rbenv. All it does it adjust your PATH.

1: https://github.com/postmodern/chruby

rbenv handles only ruby versions, whereas rvm also handles gem installations. I think it's simpler when you let rbenv handle ruby versions and bundler handle the gems, because you have to deal with bundler anyway.

The other responses to your comment would appear to indicate the rbenv/asdf/etc. question is still unanswered.

> Who cares if your backend takes 500ms to respond when it takes 5 _seconds_ to compile the JS on the client.

Frontend should never need 5 seconds and a 500ms delay on the backend seriously impacts usability. Backend performance still matters, it saves cost (fewer servers), makes scalability easier and has a massive impact on usability.

> Frontend should never need 5 seconds

I just pulled these numbers off of CNN.com using webpagestest.org, which is showing about a 500ms TTFB and a 5 second time to first contentful paint. I'm a web perf consultant and a 10:1 relationship between frontend and backend time is pretty typical IME.

For years I've been running everything on Docker Compose. Even with Ruby improving on Windows, many dependencies didn't run well or easily on Windows (like Redis). Things like WSL of course improve that situation, but I don't think you can beat replacing a long-winded README with installation instructions with a simple "docker-compose up" (the minimal loss of performance is worth it to me)

4GB ram is even cheaper at Hetzner.com. No, I'm not an affiliate.

Ruby would work great with WSL on Windows these days, I'm assuming.

Reply on news.ycombinator.com