App/javascript feels like the wrong name for that directory

Webpack can package CSS and images, arguably better than sprockets can (depending on your use case). Whatever your feelings on sprockets, there is a significant ecosystem of webpack plugins for managing images and CSS that often make it desirable to manage CSS and images with it. It feels really icky to put images and CSS/SCSS in app/javascript. At work we typically rename app/javascript to app/frontend to better reflect this usage.


I settled on app/webpacker for one of my projects. I agree it doesn’t really fit.

If it weren’t for Rails using both Sprockets and Webpacker, I think it’d be more sensible to use app/assets as the Webpacker root. For now, there’s going to be that conflict between them.

This certainly contradicts what was said over here

Sprockets is not going away right now, or anytime soon from what I can tell (there is another topic about getting more development going on it). I think the Rails position is that Sprockets is better for css and images, and webpacker is for js. The real need is to document this more thoroughly.

That might be the official line, but I think it’s bananas to use Webpack for only JavaScript and still use sprockets for CSS. I disable Sprockets from the very get-go on all new projects now and standardize on Webpack, and it simply makes everything more straightforward.

1 Like

This used to irk me as well, but I had an “aha” moment when I read this blog post Importing images with Webpacker -

Isn’t weird to put images and css in a folder called “javascript”? Depends. If you consider, from webpack’s perspective, everything is a JavaScript module, it may not be so strange. Otherwise, it’s possible to rename app/javascript or place your images elsewhere. More on that below.

1 Like

Well at compile-time, I think the ruby based SASS/SCSS assets are much faster than Webpack–and that almost goes without saying, since I don’t think JS is nearly as fast as Ruby and Webpack relies upon so many plugins to actually act as the “asset pipeline”.

I definitely get frustrated by how long it takes Webpack to just confirm that 99% of my assets haven’t changed when I make a small design tweak.

Full disclosure though, I feel like Webpack could be much more highly optimized than it is out of the box, and then it would be a decent solution. Sprockets feels like it was relatively lean compared to the massive dependencies Webpack requires to function.


I do agree that can be frustrating.

The real issue for this topic though is the naming of the app/javascripts directory. The clear reason is that Rails still expects you to use Sprockets for css and images.

I was actually under the impression the reason it’s the app/javascript was just for compatibility with people who have apps still partially using the asset pipeline and can’t fully upgrade to web pack right out of the upgrade to Rails 6/Webpack 4/5.

I still use some core/vanilla javascript and having app/javascript/js or app/javascript/javascript sucks… I settled on app/javascript/vanilla for now.

1 Like

I wish we could keep the old format: assets/stylesheets assets/javascripts etc.

for Webpack as well.

I thought that was a tidy and intuitive way to organize a project. Though I realize it doesn’t necessarily play well with some JS frameworks.

1 Like

my vote would go to app/frontend


If you only want to use webpack, you can remove sprockets and use app/assets as your directory. It’s configurable with webpacker.

I find that the folder being named javascript suggests how it is intended to be used by default. Don’t like it or also want to include other assets? You can rename it.

1 Like

Have you tried enabling “chunks”? I’ve found that webpacker became much faster and smarter than the asset pipeline when compiling only the changes of the code you’re working on with this set up.

I’ve renamed app/javascripts to app/assets_webpack in the projects where I’ve used webpack, because I didn’t like putting css in a “javascripts” folder. This also puts both assets directories next to each other in TextMate which is useful.

I haven’t fully migrated any projects to use exclusively webpack yet.

I think documentation, such as improvements to the Rails guides, could help here. We could help address questions about setup, such as directory names and layout, both for developers that prefer the Rails default (Webpacker for JS, Sprockets for CSS and images) and the “all-in” on Webpacker approach.

I have tried chunks, and chances are good I’m just not using them correctly. It does still take an impressive amount of time for webpack to only compile and then review all of the chunks to see what’s changed.

I’ll look into this more though. It has been extremely tempting to switch back to the asset pipeline for SCSS/images. I don’t use utility frameworks like Tailwind, so I don’t think I would really be losing anything by doing this.

Noticing a lot of crossover between this and Sprockets abandonment.

1 Like

This has my vote as well. It makes a lot of sense in a SPA, maybe less so with javascript sprinkles.

That would be very misleading. /views holds the html, which is the frontend

Finding a good name is hard. Perhaps we could use “packs” as the directory name, since they are the common name that maps between Rails and all the frontend-that-isnt-views?





I think the primary pressure to rename app/javascript comes from when you’re doing SPA-style, you want Webpack for everything, and you don’t want to use the asset pipeline at all. As Pablo suggested, I think it’s completely valid to have app/assets (or whatever you like) taken over by Webpack.

But what we have now, where Webpack by default is for JS compilation, the Asset Pipeline for css/images/etc, is not a concession to some legacy setup. It’s the legitimate choice based on how I like to build applications. We’re building a new app at Basecamp called HEY, and it’s running this combo, and we’re very happy with that.

THAT SAID, I’d be happy to support a dialect in the rails new setup where you essentially say “I want Webpack to own all my assets”, and then we provide a fork in the road there. --webpack-exclusive or whatever you’d like. Then we wouldn’t configure Sprockets, we wouldn’t have app/javascript.

Which comes to an even larger point: Rails is a very big tent. We’re never going to have everyone agree on the entire toolset, when we’re this ambitious in how much Rails should have a say in.

So that leaves us with a much easier path: The default will be the creator’s prerogative (informed/influenced/assisted by a broad community), and then we’ll codify major dialects with nicely paved options that make it easy for us all to enjoy the tent together! We don’t have to agree on whether Webpack is better at image compilation than sprockets in order to share and collaborate on Active Record. And so on.

In short: Let’s try to build consensus around a webpack-only dialect. What should the directory be called? How do we remove sprockets best by default? And then we need a champion or a group interested and dedicated to maintaining this dialect.