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.
A big pain point for me is that rails new doesn’t check its inputs in many cases. In others, it provides less feedback than it could. I’d really like an interactive version to model the full domain of rails new options, and give assistance when it’s obviously needed. The current UX is this way because of its architecture of extensive opaque delegation without back-propagation of errors. But we can do things differently in the interactive version.
Examples of UX improvements that we could make in the interactive version:
Silent failure like this should be impossible. Because usually, the mistake is buried in a list of other options, and the incorrect config is discovered much later.
rails new my_app --skip-javascrpt`
create
create README.md
create Rakefile
(etc.)
When a user clearly misuses the CLI API like this, we should at least show its synopsis and show how to get help:
$ rails new
No value provided for required arguments 'app_path'
Ditto, because it’s not clear where the app_path should be positioned on the command line:
$ rails new --skip-bundle
No value provided for required arguments 'app_path'