[caseyohara]

I honestly can’t tell if your comment is sarcastic because my biggest gripe with Rails is that the asset story changes radically with every major release.

Starting with 3.2 and the introduction of the asset pipeline, every new version was “This is all about to change. A totally new way of using assets is coming.”

Every new version is supposed to solve all of the problems of the previous version. It’s exhausting to constantly change to keep up with the new One True Way™, only for it to be replaced with another assets strategy powered by a gem with a cute name.

RJS and Prototype, then UJS and jQuery, then Sprockets and CoffeeScript and Sass, then Turbolinks, SCSS, then Dart Sass, then Stimulus and Webpacker, then esbuild and TypeScript, then Turbo, then import maps but there’s also jsbundling/cssbundling, then Hotwire, then Strada, then “Turbo 8” and TypeScript is suddenly phased out because DHH doesn’t like it, and now Bun.

I’m probably leaving something out and this is certainly out of order. But my point stands: the prescribed way of handling assets with Rails is ridiculous.

[bradgessler]

I think a lot of communities assumed letting JS asset pipelines manage JS, CSS, and image assets would lead to a better future. Sadly that didn’t materialize and it inflicted a lot of damage on DevUX.

Today the perception is that the JS community doesn’t seem to care about providing a stable experience for those outside of it, which is why projects like Rails and Phoenix are successful with “No/Low-JS” features.

Where Rails screwed up is not updating their docs to reflect this new reality for a really long time. It wasn’t clear what people should be using. They’re still creating confusion by making it unclear if Turbo is for Rails or all web frameworks, which you’ll notice when you go to the Hotwire landing page and see no mention of Rails.

[nickjj]

> But my point stands: the prescribed way of handling assets with Rails is ridiculous

What would the alternative be for a 20 year old project?

I think what we're seeing is a natural progression based on how the web changed over the last 2 decades.

I'd be more concerned if Rails didn't change and `rails new` produced a jQuery / SCSS / CoffeeScript loadout and made it difficult to use modern tools. Now it's easier than ever to plug in whatever front-end you want.

[hu3]

I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech.

There's a point when change is just too much and the returns are diminishing.

[nickjj]

> I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech.

How tho?

Things naturally progressed from a lot of asset related things with few choices being baked into Rails to being more componentized but still tightly baked into Rails (Webpacker) to even more componentized and mostly decoupled from Rails (current state of things) to even more decoupled from Rails (Propshaft).

Current day if you want to use Webpack or esbuild or something else or nothing it's easy because Rails no longer cares. It only cares that assets end up in a specific directory. How they get there is up to you. The framework also provides value by giving you generators to tie things together based on the choices you want so you don't have to figure it out individually from ground zero.

If you look at it from that perspective I think things unfolded reasonably well.

Personally I didn't like Webpacker at all. Webpack was complicated enough on its own and then having to learn the Rails way of configuring it made it even harder. But I think it was a good tipping point to demonstrate that from a maintainer's POV it's hard and time consuming to create good abstractions over front-end tools on the back-end and from an end user's POV it's bad because of the complexity.

Being able to look directly at esbuild's documentation and apply it 1:1 is a much nicer outcome for everyone. Maintainers don't have to keep up with every change and users don't have another layer of abstraction to deal with.

It did take Rails a while to come to this solution but it's really good that they did. This is how I managed front-end tools in Flask and other frameworks for around the last ~decade. You have the framework look for assets in 1 spot and how they get there is up to you. It was easy for me to do that because I only had to make it work for my apps, my client's apps and the starter apps I posted on GitHub, but applying that to a framework that has hundreds of thousands of people using it is for sure a bigger project.