How Ruby on Rails Could Be Much Better (2008)
dreamhost.com
dreamhost.com
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.
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.
* 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.
This isn't just a Rails thing either.
FAAS is a good thing. I'm a big fan. It's essentially the same thing as CGI which was awesome back in the day, BUT there are multiple good reasons to choose a framework that isn't constantly exiting.
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.
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.
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.
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.
Wow, that’s a person I haven’t heard from in ages.
He was a Big Flipp’n Deal back in the day (Mongrel, Spats with DHH, etc). Curious to know what he’s up to now.
I'm sure it's better now though I suppose
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.
What does this refer to?
It seems odd that for a decade the web dev community has singled out this framework. It's always relevant to suggest updates and things to be fix - any framework has those. But the continuing conversation of "is Ruby on Rails good enough" (which seems to be the underlying driver for conversation) is still present after hundreds of companies have built solid products with it.
I feel that SPAs get a lot of scrutiny, but it's spread out among the specific libraries/frameworks. There's also a lot of vocal advocates (as Rails used to have) that makes it feel more balanced.
Over the course of my career, it seems that the "easy" languages (Visual Basic, ColdFusion, Ruby, etc) always get a lot of criticism. I feel like Rails is in a great, mature spot right now, and some exciting things are happening to make it the best positioned for the coming push-back against "Javascript all the things".
Random fact of the day, co-founder of Dreamhost created Ceph. Which is the filesystem for nearly all block object storage (AWS S3, etc) these days.
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?
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.
The latest incarnation of this problem, was when we had to validate RUT codes (a tax code with a checksum we use here in Chile). Options for Python [1], options for Node [2], options for elixir [3] (don't mind to click, it's a list with nothing to do with RUTs or modulo11 validations). So we had to implement it ourselves. Looking for information we found example implementations [4], where as you can see you have example implementations even for Asterisk Dialplans (!!) but no mention of Elixir.
[1] https://pypi.org/search/?q=rut [2] https://www.npmjs.com/search?q=rut [3] https://hex.pm/packages?search=rut&sort=recent_downloads [4] https://es.wikipedia.org/wiki/Anexo:Implementaciones_para_al...
There are many more examples. Of course you get libraries for the "standard" stuff, it is when you get into the detailes, and that happens when you are already too deep into your project, that you realise all the missing pieces.
Also, what code editor do you use? we've tried everything, and seems the best option is you grow a beard and go emacs/vim. The VSCode plugins hog your laptop and are really inconsistent, incomplete and sluggish [1] [2].
[1] https://github.com/JakeBecker/elixir-ls/issues/54 [2] https://github.com/elixir-lsp/elixir-ls/issues/96
Of course there is no IDE similar to intellij, rubymine or pycharm.
I've had good luck with VSCode but I've never really been an IDE user (even with Ruby) so I can't comment much on that.
I can’t say it’s anything other than the fault of not enough spare time. The community is a bit smaller so there are not as many volunteers to build out the latest and greatest tooling for editor support.
Despite this, I’ve had a wonderful experience working within the elixir ecosystem and using it as a gateway to erlang. One of the things I had to acknowledge was my bias towards recent updates as a measure of quality. The ecosystem is so good that you’ll find packages years old and never updated. It simply does that it does and does it well.
I found overall great support in VS Code at the end of the day for Elixir. I wanted it to work well with emacs but it wasn’t consistently enjoyable.
VS Code works well enough for now between the satisfaction of shipping code and the satisfaction of a flick of the wrist for editor commands.
How would a SQL query block other threads? Sincere question
Here are a few references: https://github.com/puma/puma/issues/1003 https://thoughtbot.com/blog/untangling-ruby-threads
Edit: your links show that indeed its blocking and you need to spawn many threads/instances, which use memory.
"The reason for that is waiting on IO (talking to a DB, etc) will allow another thread to run"
The threads don't run in parallel, but they do run concurrently. While this isn't the panacea of performance, it does work well with many web apps which tend to be I/O bound (waiting for a database or remote service). So to your original of "Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances" - an HTTP request or SQL query will, in fact, allow other threads to execute while waiting for a response meaning you can rely on threads, rather than instances, and maintain a very low memory footprint.
If you like Ruby but want true multi-threading and parallelism, I'd highly recommend taking a look at JRuby (https://www.jruby.org). Those guys have done an incredible job with it.