I didn’t realize that this wasn’t just me. My Rails new tends to look like:
rails new --database mysql --skip-action-mailer --skip-action-mailbox --skip-action-text --skip-active-storage --skip-action-cable --skip-turbolinks --skip-test --skip-system-test
Briefly:
I only need to send emails in a few apps, in which case I do use action mailer.
I’ve never personally needed action mailbox.
I had two apps where action text would have been useful. In both cases, I ran into too many issues integrating it and ended up dropping back to ckeditor or some such. Unfortunately, I don’t remember what I ran into, just that I spent several hours trying to get it working before giving up.
I’ve actually used active storage in a couple of apps. I hate that it uses one gigantic database table to store everything (if smacks way too strongly of the database hell I went through from my long-past days as a Drupal developer), but it’s easy to use and probably okay for what I’m building. But most of the time I don’t need it, and it’s easy enough to add back if that changes. (Easy means, I spin up a new app in a temp directory and copy over the relevant files…)
I’ve never liked Turbolinks. I know some people get some use from it, but I don’t see any value in an in-between state between basic HTML/JS apps and client-side web apps.
I much prefer RSpec over Minitest. This coming from someone whose company only uses Minitest, so I have a lot of experience writing tests in that style.
I also then spend a bunch of time getting Rspec and Rubocop set up. I’m sure I could automate all of that, but I don’t do rails new quite often enough to be worth it for me.
I don’t mind default including everything. This is opinionated framework and making decisions on what to make default and what not is just deeply subjective.
But the truth is that apart from beginners lot of people spend too much time just coposing all the flags to rails new command when starting new application and option to simply run rails new --interactive where you can simply pick those options dynamically will go a long way.
I am dying each time i have to open help message and painstakingly copy/past all flags I need to at the moment.
Plus lack of any simple option for Rspec setup is abomination. I understand it may not preference of some but adding and configuring Rspec and rubocop each time is definitely not fun and developer friendly.
There seems to be a lot of energy around this topic. Summarizing what I’m seeing:
There might be value in grouping some “Rails presets,” like the existing --api flag tries to do.
It can be difficult (or just seem difficult) to enable or disable sub-frameworks like ActionMailbox after the fact. This makes the rails new process unnecessarily fraught.
Picking and choosing which frameworks to exclude in one mega-CLI-command makes assembling that command difficult; an --interactive mode might reduce cognitive load here.
Many people have “personal Rails scaffolds” that they assemble manually. This is something the template feature was intended to address, but something about that feature (discoverability? usability?) makes it seem easier to do this manually.
Many people either really like or really dislike speedup features like Bootsnap and Spring. There is no non-contentious perspective about whether they should be a default.
There’s a lot of division on which Rails frameworks should be included out-of-the-box. Some people favor a slimmed-down perspective because it reduces boot time. Some people favor a a fully-featured perspective because Rails is omakase. When people advocate for a subset, they tend to disagree about which subset is the truly essential one.
1-3 all seem defined enough to break up into feature suggestions. Does anyone here have the energy to work on that?
4 seems like a difficult problem and I’d love to hear more thoughts on it.
for 5 and 6, because I don’t believe we’re going to come to consensus in the space of this thread, I’d like us to focus on achievable wins that will make life easier for all camps. I think that if we focus on making it easier to enable or disable Rails frameworks, it’ll make the question of what needs to be included by default much lower-stakes.
Honestly, I like Spring! Trying to get my teammates to practice TDD pre-Spring and the same post-Spring was like night and day. It’s amazing how many hardcore technical arguments people made to avoid saying “20-second boot times annoy me too much for TDD to work for me,” and just as amazing how those arguments melted into the ether once 20-second boot times weren’t a thing any more.
So I’m going to restate my point: the chatter on this forum, and chatter I have seen elsewhere, shows me that people are unlikely to come to consensus on Spring and Bootsnap in the space of this thread. I don’t think it’s productive to argue about their existence here, or whether they should be defaults or not. I do think it’s productive to make it easier to turn them on and off, so that whether they’re defaults can become a less contentious question.
Great summary, Betsy. I’d like to throw my support behind both an interactive option and a minimal option, as well as better tooling and documentation for adding things you’ve said no to after the fact. While some might think “the list of things installed by default is insane”, it represents my honest and genuine assessment of “what would I need if I started a new application tomorrow?”. I would want, and would use, all the options we’ve included by default. That default, the inclusion of “all the tools”, isn’t likely to change.
But as discussed elsewhere, Rails is a big tent. We have a lot of different usages. It doesn’t bother me in the least that we make it easier to opt out of parts of the default stack. Nobody should ever be forced to use something they don’t want to (but also, as the omakase metaphor implies, it’s worth giving the unagi a second or third try… you might SPRING with joy once you realize that a 3s boot is reduced to 0.3s ).
Let’s make all this happen! We can start it as independent projects. The interactive mode, the minimal mode, the adding-things-back-you-removed options
I think a solution will probably arise from unifying and/or expanding the Template “API” and the AppBuilder, probably expanding Templates with some of the features from AppBuilder.
A better template API would allow more “stacks” to be expressed and shared as templates, so you could rails new blog -m https://railstemplates.org/oldschool and get a 2008-circa rails app, for example. The Template API is too limited to do that right now.
Perhaps rails new itself could be rewritten to just be a Template if the API were expanded far enough.
The plugin ecosystem around Rails might make it difficult to unify these two APIs, but all of the “pieces” are there to deliver interactive mode, minimal mode, and rails add.
That sounds like a great idea! If we’re letting you run stuff straight from a URL, we should probably preview what you’re about to run. But do like the idea of expanding the API and making the system itself use it!
Having a rails new --interactive option is a great idea!
I am also tired of maintaining an ever-growing list of features to exclude
For the work I’ve been doing an interactive mode would be more valuable than templates, as every app has different requirements and every team different preferences.
It would be really awesome if we have ability to re-add the skipped frameworks.
In one of my recent projects, I created the new rails app with rails new my_app --api but later we had to revert the api flag as we also needed rails views in the app.
@DHH because there are so many ideas going on in this thread, do you think it would be worth making a Basecamp project or similar to coordinate this work? I think the work-to-be coordinated is fast exceeding what a Discourse thread can support.
I’ve got an idea for adding back gems that were opted-out of:
In the case of core rails gem, like actiontext, we’d simply add install generator that wouldn’t add actiontext to Gemfile (because that’s not needed), but would instead add/uncomment require line to config/application.rb and do any other changes that bin/rails action_text:install does today.
Bootsnap has no friction. Devs are neutral because its just there and works. For most aspects, a dev would never realize Bootsnap is even there.
Spring has frictions. Oh you changed an initializer? You better remember to reset your Spring otherwise things won’t behave the way you expect them too (which by the way, why in the hell? I dont remember the details, but i had issues like these). You need to know that Spring exists, and to sometime takes action on it once you realize it is currently messing you up.
This cost of Spring can be offset when there is a good gain from it. Saving n seconds every time you run something is a good way to offset, but if n is too small, say 3 seconds, to me, the cost still outweights the benefit a little bit. When I save 5 to 10 seconds, then it starts to be worth it.
One good thing of Spring is that its easy to install and easy to remove. In my opinion, if Rails started without spring, and when it detected that boot times are slow enough, suggested adding Spring (or tweaking a config somewhere to stop the suggestion), then there would be less hate.
We started this forum in part because that is not true. The ground rules here are that Rails is a big tent. Your experience of Rails may not be someone else’s experience of Rails, and everyone commenting here needs to be respectful of that fact.
Let’s exclude bootsnap on --minimal; I think that will be principle-of-least-surprise here. Folks who want bootsnap but not the rest of the big modern Rails grab bag can always add it for themselves later.
).
