I think the next main challenges for Rails are improving the view layer (see upcoming ViewComponent for example) and better integrating with modern javascript (WebPacker feels half baked for gem writers). To me these issues (which both have to do more with the view layer) are where Rails is very much lacking.
How Ruby on Rails Could Be Much Better (2008)
11–20 of 63 posts
Re: How Ruby on Rails Could Be Much Better (2008)
#12I think Ruby on Rails should be more asynchronous. Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances, but it uses a lot of memory and a slow http service may block all rails instances very quickly.
Re: How Ruby on Rails Could Be Much Better (2008)
#13I think Ruby on Rails should be more asynchronous. Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances, but it uses a lot of memory and a slow http service may block all rails instances very quickly.
Elixir is the solution to this with similar ergonomics.
Re: How Ruby on Rails Could Be Much Better (2008)
#14Worth noting about the shared hosting argument: Dallas (author) is a co-founder of DreamHost. DreamHost, at the time, was very invested in selling "unlimited everything" shared hosting plans.
As a Dreamhost user since 2003 or so, their shared hosting claims to let you run rails but I never had any luck running rails on their platform.
I'm sure it's better now though I suppose
Re: How Ruby on Rails Could Be Much Better (2008)
#15I think Ruby on Rails should be more asynchronous. Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances, but it uses a lot of memory and a slow http service may block all rails instances very quickly.
I thought all DB access was pooled in rails, and the server most everyone uses (Puma) multi threaded?
How would a SQL query block other threads? Sincere question
Re: How Ruby on Rails Could Be Much Better (2008)
#16I think Ruby on Rails should be more asynchronous. Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances, but it uses a lot of memory and a slow http service may block all rails instances very quickly.
Elixir is the solution to this with similar ergonomics.
I've been experimenting with it, and it definitely has the feeling of working in rails / ruby. My only gripe is that the tooling is not as mature as rails.
I use rubymine and the debugger has truly spoiled me.
I tried to get the debugger going with a third party plugin for Intelli-j but it would crash when inspecting variables.
Any tips?
Re: How Ruby on Rails Could Be Much Better (2008)
#17To 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 happeni…
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?
Re: How Ruby on Rails Could Be Much Better (2008)
#18I think the next main challenges for Rails are improving the view layer (see upcoming ViewComponent for example) and better integrating with modern javascript (WebPacker feels half baked for gem writers). To me these issues (which both have to do more with the view layer) are where Rails is very much lacking.
I agree that the view layer has not been Rail's strength. It's largely handlebars era inspired and has never really changed.
In some ways I think rails never really needed to change because the view layer worked without issues. I always felt the solutions in the modern html/javascript world were messy and half baked, with many unforeseen tradeoffs and complexity for the benefits you get (this summarizes my experience with the whole SPA era).
We are only now starting to have best practices and reasonable design around how the html/js view layer should be done. But I think many people in Rails will continue to prefer the old way of views just because of the simplicity of it.
You'd be surprised how such a small library like turbolinks has held off the entire wave of webpack / react / SPA.
Re: How Ruby on Rails Could Be Much Better (2008)
#19Earlier quoted context omitted.
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
Re: How Ruby on Rails Could Be Much Better (2008)
#20I think Ruby on Rails should be more asynchronous. Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances, but it uses a lot of memory and a slow http service may block all rails instances very quickly.
Yes, it's called Elixir with Phoenix :)