Propshaft vs Sprockets: The asset-management revolution in Rails 8

Propshaft vs Sprockets: The asset-management revolution in Rails 8

Imagine this scenario: your benevolent investor asks you to add a cat image to the homepage of your Rails application. Simple, right? Yet this seemingly trivial task raises a fundamental question: how does Rails actually manage static assets? With the arrival of Rails 8, a major shift in asset management has occurred. Exit Sprockets, in comes Propshaft, a tool that revolutionizes our approach to managing static files.

In this article, we will explore why this change happened, how Propshaft works, and why it represents a welcome simplification for Rails developers.

Static files in Rails: the fundamentals

What is a static file?

Rails follows an MVC (Model-View-Controller) architecture, but what happens when a browser requests something that falls outside of this framework? For example, an image, a CSS file, or JavaScript ?

Rails considers non-dynamic files (those that do not contain Ruby code) as static. These files are typically stored in the public directory and managed via the Action Dispatch Static middleware.

Two approaches to serve an image

Let's take the example of our cat image:

Approach 1: Placement in public

The file is served directly from public/kitten.jpeg.

Approach 2: Using app/assets/images

The file becomes kitten-e4ebcc51.jpeg with a hash added to the name.

But why this difference? The answer lies in a crucial concept: the cache.

The browser cache problem

Why caching is a problem

Servers and browsers love to cache your static files. It is generally beneficial for:

1. Logos
2. Stock photos
3. Images that don\'t change often

But for files that evolve frequently, like JavaScript or CSS, caching becomes problematic.

The catastrophe scenario

1. A browser requests your file app.js
2. The server serves it
3. The browser caches it
4. You modify app.js with new features
5. The browser requests app.js again
6. Problem: The browser uses its cached version instead of requesting the new version from the server

Result? Your users never see your new changes until their cache is cleared.

The solution: file hashing

The most elegant solution is to stamp the files with a value representing their content. Thus, when the content changes, the file name changes as well.

Practical example:

If you modify the file\'s contents, the hash changes:

The browser sees a new file name and requests the new version from the server. That\'s exactly what Propsshaft does!

The history of Sprockets: from innovation to complexity

2011: The arrival of Sprockets

In 2011, with Rails 3.1, Sprockets becomes the main asset manager. At that time, the web was very different:

1. CoffeeScript was popular
2. Browsers didn\'t support ES6
3. HTTP/1.1 was the standard
4. The SASS was needed for advanced CSS

The multiple roles of Sprockets

Sprockets didn\'t just hash files. It did a lot:

1. Digesting and hashing: Stamp files with hashes to bust the cache
2. Transpilation :
3. CoffeeScript → JavaScript
4. SASS → CSS
5. ES6 → ES3 (via Babel) for older browsers
6. Optimization :
7. Combining multiple files into one
8. Minification of code
9. Compression of assets

Why so much complexity?

The main reason: HTTP/1.1. This protocol allowed loading only one resource at a time, sequentially.

Imagine a cascade of requests :

To optimize performance, Sprockets had to reduce the number of files as much as possible. Hence merging and minification.

2015: The JavaScript explosion

With the arrival of ES6, the JavaScript world exploded :

1. Web applications (SPA)
2. Complex build tools (Webpack, etc.)
3. New JavaScript features

Sprockets tried to keep up, but became too complex and hard to maintain.

2024: The world has changed, Propshaft arrives

Technological advances

Several major changes enabled radical simplification:

1. Native ES6 support

1. All major browsers support ES6
2. No longer need for transpilation

2. CoffeeScript is obsolete

1. No one uses CoffeeScript anymore
2. No transpiler needed

3. Modern CSS

1. Native CSS variables
2. Support for nesting
3. SASS becomes less necessary

4. HTTP/2 and multiplexing

1. Multiple simultaneous requests on a single TCP connection
2. Receive in any order
3. No need to bundle everything into a single file

5. Faster and more stable Internet

1. Less critical to minify to the extreme

Propshaft: simplicity regained

Propshaft does one thing, but well:

✓ Digesting and hashing files to bust the cache ✓ Mapping logical names to hashed files ✗ No transpilation ✗ No minification ✗ No concatenation

How Propsshaft works in practice

Asset precompilation

In production, you precompile your assets at deployment time:

This command:

1. Scans all your static files
2. Generates a hash based on their content
3. Renames the files with that hash
4. Places everything into the public folder
5. Creates a manifest file

The manifest.json file

The secret of Propshaft lies in public/assets/manifest.json :

Thanks to this manifest, you can use the logical name in your code :

And Propshaft resolves it automatically to :

Resolution in CSS files

Propshaft performs a light CSS compilation to resolve references :

HTTP/2 in action

In your browser\'s Network tab, you will now see :

1. Multiple requests launched simultaneously
2. All returned in parallel
3. No sequential cascading

That\'s the magic of HTTP/2 multiplexing !

The advantages of Propsshaft for developers

1. Simplicity

1. Less configuration
2. Less black magic
3. Easier to debug code

2. Transparency Your JavaScript and CSS are served as-is in production. What you see in development is what you get in production.

3. Modern performance Propshaft takes advantage of modern technologies (HTTP/2, native ES6) rather than fighting them.

4. Flexibility If you need a complex JavaScript build, you use your own system (Vite, esbuild, etc.). Propsshaft won\'t get in the way.

5. Reduced maintenance Less code = fewer bugs = less maintenance.

Rails 8: The framework for a one-person project

Propshaft perfectly embodies the philosophy of Rails 8: enabling a solo developer to build complete web applications without getting lost in complexity.

By simplifying asset management, Rails eliminates a major friction point and enables developers to focus on what really matters: creating value for their users.

Conclusion

The shift from Sprockets to Propshaft in Rails 8 isn\'t just a technical change. It reflects a web maturity and a commitment to simplifying the developer experience.

Thanks to advances in HTTP/2, native ES6 support, and the overall improvement of web standards, we no longer need the complexity that Sprockets introduced. Propshaft does one simple, but essential thing: it hashes your files to intelligently bust the cache.

For Rails developers, this means :

1. Less time spent configuring the build
2. More transparency in asset processing
3. A better overall development experience

So next time your investor asks you to add a cat image to your homepage, you\'ll know exactly what\'s going on under the hood. And you\'ll be able to implement it with confidence, knowing that Propsshaft intelligently manages the cache for you.

Welcome to the era of simplicity with Rails 8 and Propshaft !