
Why we don't use a Rails template - ajsharp
http://thunderboltlabs.com/posts/why-we-dont-use-a-rails-template
======
aculver
"But take a closer look, and you'll see that the time is simply being moved
around."

No, it's not. Manual effort is being automated. That manual effort includes
calling to remembrance a list of gems, looking up their installation
instructions on GitHub, modifying views, editing initializers, converting ERB
files to Haml, setting up your test environment just so, and whatever else
floats your boat. Assuming a team can agree on some sensible defaults, it can
save significant amounts of time to have all those steps automated each time
you want to spin up a new project.

"The technical and social friction in changing the template discourages
evolution."

No, it doesn't. There is nothing stopping me from deviating from the norm once
the application is generated. Or if I need to preempt a step in the generator,
I just 'gem unpack' the generator, make my tweak, 'rake install', and generate
from that. If it works out, I can push the change up in a branch and submit a
pull request. The team can discuss.

Automation is good. From a business perspective I believe it's codifying your
expertise. Clients benefit from that automation, because you spend 10 minutes
spinning up their project instead of 2-8 hours recreating pretty much the same
wheel you created last month.

~~~
mileszs
I think, essentially, he is saying that you end up spending time maintaining
your template, losing much of the benefit of the template, depending on how
often you start new apps. I have found this to be true at a certain threshold
of complication in the app template. However, if you are indeed starting a
brand new Rails app every month, as you said, you likely don't have the same
cost, as maintenance to the app template happens on a more regular basis. Even
as a consultant, I don't start new Rails apps that often, and side projects
tend to involve experimentation outside of what I might consider my "stable"
stack.

~~~
snprbob86
> you end up spending time maintaining your template, losing much of the
> benefit of the template

It really depends on whether or not you start a lot of new projects. If you're
a Rails dev shop that does a wide variety of apps on a regular basis, then the
N=1 cost of maintaining the template is well worth the per-project getting-
started cost.

------
Mc_Big_G
I find it extremely useful to have a base foundation to start an app. Doing
all of the mundane gem integrations and standard set-up is not fun. I agree
that it's a challenge to keep the base app updated with improvements from the
forks. I have repo on github that could benefit from some cherry-picking. It's
great for working on multiple projects at the same time. You never have to go
digging to see how the basics work, you just know. On top of that, my clients
save at least a few days of work.

------
metaskills
I never liked Rails templates because I felt the quality of the final product
was never on par with what you would setup from scratch. To that end, I
created my own system that I call a Rails application prototype. If you are
interested you can learn more about it here.

<https://github.com/metaskills/holy_grail_harness>

I can see both sides of the argument here. My application prototype is really
slim and focuses on bootstrapping an application with a major emphasis on
testing tools. Even tho it has a JavaScript MVC framework (Spine.JS) it will
remove all traces depending on your setup questions. This approach to a lean
prototype means it can easily be updated like a normal Rails application and
changed/forked as needed. Best of both worlds hopefully.

~~~
DanielKehoe
This project from @metaskills is worth a close look, particularly to see the
choices Ken's made in assembling a development stack. It's a great example of
using a starter app as beginning point for a discussion about best practices.
Carbon Five's RayGun is another. Compare the two and you'll learn a lot about
high-powered Rails development and where it's going.

------
gyardley
Plus, if you're new, templates are dangerous. The excitement of saving all
that time on 'boilerplate' always turns into twelve hours of flailing around
on StackOverflow, totally over your head, for the right way to override some
Devise controller -- all because you wanted to save some time.

------
fdschoeneman
This post makes some good points about whether or not spending time working on
rails templates for the use of your team will pay off. But if you're just
using a template that someone else created -- RailsApps, by Daniel Kehoe, for
example -- then there's no time lost to you or your team.

I also think that a great use case for templates is to try out new gems before
deciding on whether or not you'd like to use them.

~~~
thunderboltlabs
The larger point is more about the philosophy of using a template, and the
impact on the culture of the team.

------
ajsharp
"Congratulations! You've now started your brand new project with technical
debt."

Love it.

The tl;dr here is that almost all of the decisions that an app template makes
are decisions the team should be discussing. Otherwise, the homogeny of an app
template creates a "you're doing it wrong" cargo-culting attitude.

Great post. Glad I read this.

~~~
fdschoeneman
I think this might work both ways though. I think that generating an app from
a template allows the team to get up to speed quicker on particular gems, and
thus might enable a better decision about whether or not to use those gems --
whether they use that gem in a generated app or build it from rails new.

------
tenderlove
What is a "Rails template"?

~~~
bascule
I think it's like ERb or Haml

------
programminggeek
The problem with app templates is, how often do you start a new app vs. how
often do you want to maintain every change you made to your base app template?
Article pretty much nails it.

~~~
aculver
Many consulting companies and freelancers spin up projects on a regular basis.
My experience working in an environment like that was that having an in-house
generator saved time in the long run. Same goes for developers who spin up
lots of personal projects whenever they have a new idea.

------
DanielKehoe
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:

<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.

~~~
marcamillion
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.

Thanks Daniel for all your awesome work.

