How Ruby on Rails Could Be Much Better (2008)
dreamhost.com
How Ruby on Rails Could Be Much Better (2008)
1–10 of 63 posts
Re: How Ruby on Rails Could Be Much Better (2008)
#2it's bloated as hell, active record is nice but good god
Re: How Ruby on Rails Could Be Much Better (2008)
#312 years later it seems to have worked out just fine.
Re: How Ruby on Rails Could Be Much Better (2008)
#412 years later it seems to have worked out just fine.
Did the article imply it wouldn't?
Re: How Ruby on Rails Could Be Much Better (2008)
#5To 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.
Re: How Ruby on Rails Could Be Much Better (2008)
#6To 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.
Re: How Ruby on Rails Could Be Much Better (2008)
#7I remember this era like it was yesterday. Ruby on Rails in 2008 was on 2.1 or 2.2 (before it was merged with merb) and was 70 or 80% of the way there before it was mature. I think rails 3.0 is when the framework matured and stopped changing so much.
There were a lot of decisions back then that were made because it fit the rails vibe, like the fast adaptation of coffee script. In some ways it was a mistake, but in other ways it was kind of putting a foot down on the whole philosophy of rails, which was to optimize heavily for finding the ideal language of the framework, and worry about the implementation details later.
In 2008, Rails still had trouble running on windows, shipped with sqlite as the default database, did not support many other databases, had 1 or 2 servers options, was not modular (you couldn't swap out ActiveRecord), did not have Arel (so all sql queries were heavily unoptimized), had a hard dependency on jQuery... the list goes on. But because it was unrelenting on the values of the framework, we have the beauty that is rails today, which still captures the magic of rails in 2008, just with the implementation details filled in.
In some ways, Rails had a very strong startup mentality, in that it was always under-engineered instead of over engineered throughout its life until rails 4ish.
Re: How Ruby on Rails Could Be Much Better (2008)
#8It would seem they ignored this advice
Re: How Ruby on Rails Could Be Much Better (2008)
#9Worth 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.
Re: How Ruby on Rails Could Be Much Better (2008)
#10I remember this era like it was yesterday. Ruby on Rails in 2008 was on 2.1 or 2.2 (before it was merged with merb) and was 70 or 80% of the way there before it was mature. I think rails 3.0 is when the framework matured and stopped changing so much. There were a lot of decisions back then that were made because it fit the rails vibe, like the fast adaptation of coffee script. In some ways it was a mistake, but in ot…
Sqlite was used as default for local dev/testing, in production you were setting it to mysql. Fantastic setup with activerecord that made tests very fast.
People were buying macbooks just to use textmate + rails because it was so good compared to alternatives at that time. In Europe at least textmate + rails were responsible for more new apple devs than anything else; before that it was unheard of/ultra niche platform nobody was using.