Interactive "rails new"

A May Of WTFs
41

Hey folks!

Most of the content on this topic has been really constructive – thank you all for sharing your perspectives!

A little of it has veered into “I don’t understand why anyone would want that” territory, though.

For the duration of the May of WTFs, let’s please all keep in mind that people use Rails differently, and that other people’s use cases and preferences make sense to them.

4 Likes
42

Whether or not it leaks out into day-to-day life is up to the implementation

, well that’s the real question then. If implemented well you won’t ever think about it and get free performance. You are doubting that that is possible. I understand where you’re coming from, but I think we need to trust that’s what got into the framework (by a company like Shopify no less) works until we have reason to believe otherwise.

43

This seems like the way to go to me. If it were easier to add and remove stuff after the fact we wouldn’t need to worry so much about exactly what gets installed from the start.

I can imagine two separate sets of defaults (with one of those being the default set of defaults for newbies):

rails new --lots-of-stuff     # wordsmithing required
rails new --minimal-stuff.

Then later, I could add more stuff as I need it.

rails add action_text
rails add spring
5 Likes
44

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.

1 Like
45

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.

46

There seems to be a lot of energy around this topic. Summarizing what I’m seeing:

  1. There might be value in grouping some “Rails presets,” like the existing --api flag tries to do.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

5 Likes
47

My read on 5 is that it’s a mistake to lump them into the same question.

If you ask how many people wish spring would just go away, you will cut through the lack of consensus: people passionately dislike spring.

Bootsnap seems generally neutral for most devs.

1 Like
48

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.

5 Likes
49

Excellent reply. I really appreciate your perspective.

50

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 :smile:).

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 :+1:

23 Likes
51

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.

EDIT: I just bought railstemplates.org :sweat_smile:

12 Likes
52

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!

5 Likes
53

Having a rails new --interactive option is a great idea! :+1:

I am also tired of maintaining an ever-growing list of features to exclude :smiley:

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.

4 Likes
54

rails new --interactive is really great idea!

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.

2 Likes
55

I have started a draft PR to add support for the new rails command:

rails new --minimal

What exactly are we going to skip? everything… everything?

cc/ @Betsy_Haibel @dhh can someone help make the final call on what exactly is excluded?

Here is the PR:

https://github.com/rails/rails/pull/39282

1 Like
56

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

57

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.

1 Like
58

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.

3 Likes
59

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.

60

Betsy, I’m happy for us to start kicking off issues/PRs for some of these ideas. There’s a clear go-ahead on --minimal and --interactive :+1:

4 Likes