3 ms·

This is one of the strongest arguments I've seen for simply starting with the "default" stack. Move to other stuff when you feel the pain. If you're teaching or

by qrush 14y ago

This is one of the strongest arguments I've seen for simply starting with the "default" stack. Move to other stuff when you feel the pain. If you're teaching or just starting off with Rails, don't use the "Prime" stack stuff until you really need it.

steveklabnik 14y ago
One of the things that got me thinking about this was the recent security issues. I was helping people on Skype upgrade their apps, because they were new, and they got into Gem Version Hell. Only pulling in fancy gems when you need it helps when you _really_ need to upgrade, and you're not stuck figuring out why twitter-bootstrap-rails, therubyracer, and libv8 (in this example, obviously, it could be any combination of gems) all refuse to get on board. If you're using the default stack, the number of dependencies you have drops quite a bit.
- fendale 14y ago
  > twitter-bootstrap-rails, therubyracer, and libv8 Those three gems recently caused me a world of pain. I've been in and out of Rails development since the 1.x versions (more hobby projects than professional development), and once getting going was as simple as 'gem install rails'. Getting the asset pipeline to work changed that totally - I get the advantages of the asset pipeline, and once you get it working and all your gem dependencies sorted it is fine, but it took me a while to get there.
  - steveklabnik 14y ago
    I don't even use therubyracer at all any more, personally. It's not generally neccesary; just {brew,apt-get} install nodejs and be done with it.
  - kaffeinecoma 14y ago
    Same here. In aggregate, I must have spent at least a two full days getting therubyracer and libv8 working in various environments. As a recent Java refugee, one of the things I find most painful about Rails is its dependence on native code libs. It's really a lot of work to get the dependencies sorted out, especially if you have several platforms to support (say OSX for dev, and multiple Linux flavors for staging/prod). One thing I learned (the hard way) is to heed the advice that "rvm requirements" offers. If you install the libs that it recommends before trying to install your gems, things will go more smoothly. This may sound obvious, but when you're installing Ruby, RVM, Rails, Apache, etc, it's easy to overlook the instructions.
- jrochkind1 14y ago
  That says to me that understanding bundler is REALLY important. If someone understood how bundler worked, there is NO reason therubyracer, twitter-bootstrap-rails, libv8, or any other gem should get in the way of upgrading (say for example) from Rails 3.2.5 to 3.2.11. `bundle update rails`, then check in your new Gemfile.lock That should change nothing but Rails and rails' own upstream dependencies (not any of the ones you mention). And indeed it did that for me on a bunch of apps. If you're going up a minor or major Rails version, then your other gems (like say twitter-bootstrap-rails, hypothetically) might not be compatible with the new rails version, and you might have some dependency hell. But to apply a security release, when you are on a maintained minor release (3.0, 3.1 or 3.2)? If you understand how bundler works, you are HIGHLY unlikely to have any troubles.
  - steveklabnik 14y ago
    > But to apply a security release, when you are on a maintained minor release (3.0, 3.1 or 3.2)? If you understand how bundler works, you are HIGHLY unlikely to have any troubles. Right, but it DID happen. Updating the Rails version updated the versions of other gems too. I know what you're saying, but the reality was different.
aneth4 14y ago
For someone who has written dozens of applications and has already experienced such pain, why would they head straight back into it instead of starting with the best tools?

by qrush 14y ago

steveklabnik 14y ago

One of the things that got me thinking about this was the recent security issues. I was helping people on Skype upgrade their apps, because they were new, and they got into Gem Version Hell. Only pulling in fancy gems when you need it helps when you _really_ need to upgrade, and you're not stuck figuring out why twitter-bootstrap-rails, therubyracer, and libv8 (in this example, obviously, it could be any combination of gems) all refuse to get on board. If you're using the default stack, the number of dependencies you have drops quite a bit.

fendale 14y ago
> twitter-bootstrap-rails, therubyracer, and libv8 Those three gems recently caused me a world of pain. I've been in and out of Rails development since the 1.x versions (more hobby projects than professional development), and once getting going was as simple as 'gem install rails'. Getting the asset pipeline to work changed that totally - I get the advantages of the asset pipeline, and once you get it working and all your gem dependencies sorted it is fine, but it took me a while to get there.
- steveklabnik 14y ago
  I don't even use therubyracer at all any more, personally. It's not generally neccesary; just {brew,apt-get} install nodejs and be done with it.
- kaffeinecoma 14y ago
  Same here. In aggregate, I must have spent at least a two full days getting therubyracer and libv8 working in various environments. As a recent Java refugee, one of the things I find most painful about Rails is its dependence on native code libs. It's really a lot of work to get the dependencies sorted out, especially if you have several platforms to support (say OSX for dev, and multiple Linux flavors for staging/prod). One thing I learned (the hard way) is to heed the advice that "rvm requirements" offers. If you install the libs that it recommends before trying to install your gems, things will go more smoothly. This may sound obvious, but when you're installing Ruby, RVM, Rails, Apache, etc, it's easy to overlook the instructions.
jrochkind1 14y ago
That says to me that understanding bundler is REALLY important. If someone understood how bundler worked, there is NO reason therubyracer, twitter-bootstrap-rails, libv8, or any other gem should get in the way of upgrading (say for example) from Rails 3.2.5 to 3.2.11. `bundle update rails`, then check in your new Gemfile.lock That should change nothing but Rails and rails' own upstream dependencies (not any of the ones you mention). And indeed it did that for me on a bunch of apps. If you're going up a minor or major Rails version, then your other gems (like say twitter-bootstrap-rails, hypothetically) might not be compatible with the new rails version, and you might have some dependency hell. But to apply a security release, when you are on a maintained minor release (3.0, 3.1 or 3.2)? If you understand how bundler works, you are HIGHLY unlikely to have any troubles.
- steveklabnik 14y ago
  > But to apply a security release, when you are on a maintained minor release (3.0, 3.1 or 3.2)? If you understand how bundler works, you are HIGHLY unlikely to have any troubles. Right, but it DID happen. Updating the Rails version updated the versions of other gems too. I know what you're saying, but the reality was different.

aneth4 14y ago

For someone who has written dozens of applications and has already experienced such pain, why would they head straight back into it instead of starting with the best tools?