I maintain the RailsApps ecosystem, which includes a gem that assembles various application templates (rails_apps_composer, derived from Michael Bleigh's RailsWizard), Rails Composer (an application template that generates various starter apps), the RailsApps collection of example applications, and a collection of tutorials that explain how each example application works.
The OP argues against using a "Rails template" but ultimately his argument is against using a starter app to begin a Rails project. His concerns are reasonable but ultimately shortsighted.
You see, everyone uses a starter app. Here's your choices:
1) Use "rails new" to get the default Rails starter app. Add your favorite gems and tweak everything to work together.
2) Build a starter app with you favorite gems, store it in a repo, and make a copy every time you start a new project (search and replace to change the app name in ten locations).
3) Build a gem that copies a starter app with all your favorite gems. Build in a search-and-replace script that changes the app name.
4) Build an application template that generates a starter app using "rails new -m".
#2 is faster than #1 for starting up a project (except for a little time to copy the starter app to a repo) if you are using the same starter app more than once.
#3 and #4 are faster that #1 and #2 for starting up a project but more time is required to "build the tool." Fine if you can save more time running the tool than hand-assembling as in choice #1.
But there's a problem with #1, #2, #3, #4. All starter apps are time consuming because you need to take time to figure out what's changed since you last used your favorite gems and hunt down any new tweaks needed to get your favorite gems to work together. Most developers underestimate this effort and and most starter apps, application-generating gems, or application templates end up mired in the tar pits of neglect, abandoned in the constant change of Rails and its gem ecosystem.
There's another choice:
5) Participate in an open source project to maintain a set of starter apps with commonly used gems. Since you are always going to use a starter app (of some kind), why not use one that other developers are using? And benefit from a community effort to identify and patch integration issues.
That seems to be what's driving the popularity of the RailsApps project (800+ "stars" and 150+ forks on GitHub for the rails_apps_composer gem). Here's the link:
"Even after the first implementation, the template must be constantly tweaked and finagled to keep it up to date."
Yep, that's where you need the leverage of a community supporting an open source project.
"Each one of the decisions that the template makes for you should be discussions within the team."
There's no reason to have a single starter app or template that generates only one stack. Take a look at the RailsApps repo. You'll find starter apps that use MongoDB, others use SQL. The Rails Composer application template will give you a choice of ERB/Haml/Slim, Twitter Bootstrap or Zurb Foundation, PostgreSQL/MySQL/MongoDB, RSpec/MiniTest, OmniAuth/Devise, etc., etc. Have your team discussion; find out what the larger community is saying; make informed choices. You can have multiple starter apps and choose the one that is appropriate for the project at hand.
"The fact is, 'best practices' are a moving target. They evolve through team communication and cohesion."
Yep, and if your team participates in an open source project to build and maintain useful starter apps, you'll benefit from the efforts of a larger community and contribute to the growth and wider adoption of Rails.
I fully agree with Daniel on this one. For a long time, I was looking for an app generator. I looked at many, and Rails App Composer (and the many RailsApps templates that come with the generator) is by and far the best thing I have come across.
I love being able to always know that when I want to create a new app, I have my core gems - that will always be up-to-date once I run the RailsApps generator.
One of the best tools in my toolbox as a Rails dev.
I agree with the other commenters - RailsApps is a fantastic resource for the community. It's a great way to have a peer reviewed and curated set of high quality examples to learn from.
At the same time, I do agree with many of the points in Tammer's article. I think the danger with Rails templates, scaffolding and even Daniel's work is that it's very easy to take it and use it part and parcel without understanding what's really going on inside, and why certain decisions were made (this gem vs. that gem, or this code technique vs. that). I think there's a lot of value in starting from scratch (Daniel's option #1) and adding things step by step. As Tammer pointed out, this can lead to a positive team discussion and learning dynamic. And I don't mind the extra typing and time required.
The next time I start a new Rails app, I'll probably:
- Look for a good example to learn from in RailsApps or elsewhere.
- But then step back to "rails new" and add in the recommended gems bit by bit, with testing along the way.
- Hopefully contribute back to RailsApp if I learn anything new :)
I really hope people will look at RailsApps as a result of this post. It looks like the author may have missed it. I can say that the RailsApps templates have been enormously valuable to me both a) as a way to try out new gems quickly and b) get started on production apps.
The OP argues against using a "Rails template" but ultimately his argument is against using a starter app to begin a Rails project. His concerns are reasonable but ultimately shortsighted.
You see, everyone uses a starter app. Here's your choices:
1) Use "rails new" to get the default Rails starter app. Add your favorite gems and tweak everything to work together.
2) Build a starter app with you favorite gems, store it in a repo, and make a copy every time you start a new project (search and replace to change the app name in ten locations).
3) Build a gem that copies a starter app with all your favorite gems. Build in a search-and-replace script that changes the app name.
4) Build an application template that generates a starter app using "rails new -m".
#2 is faster than #1 for starting up a project (except for a little time to copy the starter app to a repo) if you are using the same starter app more than once.
#3 and #4 are faster that #1 and #2 for starting up a project but more time is required to "build the tool." Fine if you can save more time running the tool than hand-assembling as in choice #1.
But there's a problem with #1, #2, #3, #4. All starter apps are time consuming because you need to take time to figure out what's changed since you last used your favorite gems and hunt down any new tweaks needed to get your favorite gems to work together. Most developers underestimate this effort and and most starter apps, application-generating gems, or application templates end up mired in the tar pits of neglect, abandoned in the constant change of Rails and its gem ecosystem.
There's another choice:
5) Participate in an open source project to maintain a set of starter apps with commonly used gems. Since you are always going to use a starter app (of some kind), why not use one that other developers are using? And benefit from a community effort to identify and patch integration issues.
That seems to be what's driving the popularity of the RailsApps project (800+ "stars" and 150+ forks on GitHub for the rails_apps_composer gem). Here's the link:
https://github.com/RailsApps
Now about what the OP said:
"Even after the first implementation, the template must be constantly tweaked and finagled to keep it up to date."
Yep, that's where you need the leverage of a community supporting an open source project.
"Each one of the decisions that the template makes for you should be discussions within the team."
There's no reason to have a single starter app or template that generates only one stack. Take a look at the RailsApps repo. You'll find starter apps that use MongoDB, others use SQL. The Rails Composer application template will give you a choice of ERB/Haml/Slim, Twitter Bootstrap or Zurb Foundation, PostgreSQL/MySQL/MongoDB, RSpec/MiniTest, OmniAuth/Devise, etc., etc. Have your team discussion; find out what the larger community is saying; make informed choices. You can have multiple starter apps and choose the one that is appropriate for the project at hand.
"The fact is, 'best practices' are a moving target. They evolve through team communication and cohesion."
Yep, and if your team participates in an open source project to build and maintain useful starter apps, you'll benefit from the efforts of a larger community and contribute to the growth and wider adoption of Rails.