3 ms·

Well, "right away" is kind of misleading. If you're the average company making a Rails website, you'll get by with common-sense optimizations, database indexes

Well, "right away" is kind of misleading. If you're the average company making a Rails website, you'll get by with common-sense optimizations, database indexes and the like that you'd have to do in PHP anyways. I've worked on probably a dozen Rails apps and have only ever had to resort to horizontal scaling and memcached once. I think the key is that developing the app and scaling the app can be separate tasks. If you do it right, for the lion's share of your app code is still focused on the app, and all the caching and whatnot is handled elsewhere. In PHP, if you had to use memcached it would be a massive change that would touch every corner of your codebase. In Rails, you'd use a plugin and maybe a few filters and you'd be good to go.

idlewords 17y ago
I think that's a good description of the tradeoff. At some point, the filters, plugins, middleware and so on that let you focus your energies on the app begin to interact in non-trivial ways, and so the time you spent not having to worry about them during development gets repaid worrying about them in deployment.
drgath 17y ago
That is silly. Why is adding memcached to a PHP app need to be a "massive change that would touch every corner of your codebase"?? Like any web app coded in any language, if it's properly layered, memcached can be added to an app (PHP or not) in a couple lines, sometimes as few as 1 line (ex. ADODB w/ memcached).