Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Ruby on Rails Could Be Much Better (2008)

dreamhost.com

Post reply on HN
Print view View original

31–40 of 63 posts

Re: How Ruby on Rails Could Be Much Better (2008)

#31

Post by cutler »

spyckie2 wrote: post #18
joelbluminator wrote: post #11

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.

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…

Don't forget Stimulus. The next iteration of Turbolinks is also slated to be more forms-friendly.

Re: How Ruby on Rails Could Be Much Better (2008)

#32

Post by MXfive »

speedgoose wrote: post #25
welearnednothng wrote: post #24

Earlier quoted context omitted.

This is not correct. When Ruby is doing I/O such as this is the only time it’s not blocking. This is due to Ruby, not specific to Rails. Here are a few references: https://github.com/puma/puma/issues/1003 https://thoughtbot.com/blog/untangling-ruby-threads

I have to admit that I have not used puma for development. Edit: your links show that indeed its blocking and you need to spawn many threads/instances, which use memory.

Extra processes (workers) consume extra memory, threads do not.

Re: How Ruby on Rails Could Be Much Better (2008)

#33

Post by e12e »

robotmay wrote: post #19
syspec wrote: post #17

Earlier quoted context omitted.

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.

Re: How Ruby on Rails Could Be Much Better (2008)

#34

Post by colinramsay »

joelbluminator wrote: post #11

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.

> see upcoming ViewComponent for example

What does this refer to?

Re: How Ruby on Rails Could Be Much Better (2008)

#35

Post by user34234 »

dfischer wrote: post #13
speedgoose wrote: post #12

I 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.

The company I work for (mostly standard Web Dev) uses almost exclusively Elixir for any backend work. Only the fanboys of Elixir and functional everything are happy with it, just to be different to everyone else.

The experience is terrible: Tooling (editor plugins, tests runners, IDEs (oh, there are no IDEs...), debugging) is like going back 20 years.

There are no libraries for the most basic stuff you get almost by default on the Ruby, Python, Node or Java ecosystems. So we end up reinventing half assed solutions to anything we need to do.

Some days I think we would be sooo much better by just using Rails or Django.

Of course, concurrency and the Erlang VM are awesome and the perfect fit for the web... if your problem is performance, it will solve that problem for you of course... other than that, is all wasted time in my opinion from my experience after years of using it.

Re: How Ruby on Rails Could Be Much Better (2008)

#36

Post by mhw »

colinramsay wrote: post #34
joelbluminator wrote: post #11

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.

> see upcoming ViewComponent for example What does this refer to?

https://github.com/github/view_component

Re: How Ruby on Rails Could Be Much Better (2008)

#37

Post by bovermyer »

burlesona wrote: post #6
nateberkopec wrote: post #5

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 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.

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

Re: How Ruby on Rails Could Be Much Better (2008)

#38

Post by mhw »

This really should be titled "How Ruby on Rails Could Be Much Better for Shared Hosting", as that's where the issue really was for Dreamhost at the time. In a shared hosting environment back then:

* You didn't get root shell access. Dreamhost were (and still are) one of the good platforms in that they allowed shell access at all. Many shared hosting platforms didn't even do that, requiring you to upload files using FTP.

* The services provided were generally ones where a single server process (or processes) could serve a large number of shared hosting tennants: a web server with many virtual hosts, PHP applications running within that shared web server, jabber services, mail services, etc.

* All web server configuration was either through the control panel or .htaccess files, because you were sharing the web server instance with everyone else on your shared server.

* The economics of shared hosting meant you couldn't keep processes running for each individual hosting user for an extended period of time: memory was just too expensive to dedicate that way.

Rails didn't really fit this model: a production Rails app loads all the code in to memory and then expects to run for a number of hours serving requests. Shared hosting required these processes to shut down when there was no traffic to the site, and then start up on demand when a new request for the app came in. So the fundamental problem was not "Ruby on Rails needs to be a helluva lot faster", it was "Rails is too slow to start up to serve a single HTTP request and then be shut down again".

I did run a production Rails app on Dreamhost shared hosting for a while: it seemed to receive just enough traffic not to get killed, but not so much that it became an issue. But as soon as virtual server hosting became cheap enough to make the jump, we moved.

Re: How Ruby on Rails Could Be Much Better (2008)

#39

Post by nateberkopec »

dx034 wrote: post #23
nateberkopec wrote: post #5

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 happeni…

> 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.

Re: How Ruby on Rails Could Be Much Better (2008)

#40

Post by Dirlewanger »

syspec wrote: post #17
burlesona wrote: post #6

Earlier 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?

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.
Post reply on HN