Public and assets folders in Ruby on Rails - Deep Dive

Overview - Public and assets folders

What is it?

In Rails, the public and assets folders are special places where files like images, stylesheets, and JavaScript live. The public folder holds files that the web server can send directly to users without any processing. The assets folder contains source files that Rails processes and combines before sending them to users, helping keep the website fast and organized.

Why it matters

These folders exist to make websites load quickly and look good by organizing and preparing files properly. Without them, websites would be slower, harder to maintain, and might show broken images or styles. They help developers manage all the files users need to see and interact with, making the web experience smooth and reliable.

Where it fits

Before learning about these folders, you should understand basic Rails app structure and how web servers deliver files. After this, you can learn about asset pipelines, caching, and optimizing web performance to make your apps faster and more efficient.

Mental Model

Core Idea

The public folder serves ready-to-use files directly to users, while the assets folder holds source files that Rails prepares and optimizes before sending.

Think of it like...

Think of the public folder as a shop window displaying finished products ready for customers, and the assets folder as the workshop where those products are crafted and polished before display.

┌─────────────┐       ┌───────────────┐
│  assets/    │──────▶│ Rails Asset   │
│ (source)    │       │ Pipeline      │
└─────────────┘       └───────────────┘
                            │
                            ▼
                      ┌─────────────┐
                      │ public/     │
                      │ (served)    │
                      └─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding the public folder basics

Concept: The public folder holds files that the web server sends directly to users without any changes.

In a Rails app, the public folder contains files like robots.txt, favicon.ico, and static HTML or images. When a user visits your site, the server looks here first to find files to send immediately. These files are not processed by Rails; they are served as-is.

Result

Users receive files from the public folder instantly, making access to static content very fast.

Knowing that files in public are served directly helps you place static resources correctly for quick delivery.

2

Foundation

Introduction to the assets folder

Concept: The assets folder stores source files like CSS, JavaScript, and images that Rails processes before sending to users.

Rails uses the assets folder to keep your stylesheets, scripts, and images organized. These files are often written in languages like SCSS or CoffeeScript, which Rails compiles into standard CSS and JavaScript. This folder is where you work on your design and behavior files before they become ready for users.

Result

Your source files are neatly organized and prepared for optimization before being sent to users.

Understanding the assets folder as a workspace clarifies why you don’t put raw files directly in public.

3

Intermediate

How Rails processes assets

🤔Before reading on: do you think Rails sends assets files as they are, or does it change them before sending? Commit to your answer.

Concept: Rails uses an asset pipeline to compile, combine, and compress files from the assets folder before serving them.

When you deploy or run your app, Rails compiles files like SCSS into CSS and CoffeeScript into JavaScript. It also combines multiple files into one and compresses them to reduce size. This process happens so users download fewer files faster, improving website speed.

Result

Users get optimized, smaller files that load quickly, improving the website experience.

Knowing that Rails transforms assets explains why you edit source files in assets but users get different optimized files.

4

Intermediate

Difference between public and assets folders

🤔Before reading on: do you think files in public and assets folders are handled the same way by Rails? Commit to your answer.

Concept: Public files are served directly, while assets files are processed by Rails before delivery.

Files in public are static and sent as-is by the web server. Files in assets are source files that Rails compiles and bundles. For example, an image in public is sent directly, but an image in assets might be fingerprinted (renamed with a hash) for caching and served through the pipeline.

Result

You understand where to put files depending on whether they need processing or not.

Recognizing this difference prevents confusion about why some files change names or content when served.

5

Intermediate

Using fingerprints for caching assets

🤔Before reading on: do you think asset filenames stay the same every time or change to help browsers cache them? Commit to your answer.

Concept: Rails adds unique fingerprints to asset filenames to help browsers cache files efficiently.

When Rails compiles assets, it adds a hash to filenames like application-3f1a2c.css. This fingerprint changes only if the file content changes. Browsers use this to cache files long-term, only downloading new versions when needed, speeding up page loads.

Result

Users get faster load times because browsers reuse cached files until they change.

Understanding fingerprinting explains why asset filenames look different in production and how caching works.

6

Advanced

Precompiling assets for production

🤔Before reading on: do you think Rails compiles assets on the fly in production or beforehand? Commit to your answer.

Concept: In production, Rails precompiles assets to serve optimized files quickly without runtime processing.

Before deploying, Rails runs a task to compile and compress all assets into the public folder under /assets. This means the server can serve these ready files immediately, avoiding delays and reducing server load during user requests.

Result

Production apps serve fast, optimized assets without runtime compilation delays.

Knowing precompilation is key to deploying performant Rails apps and avoiding slow page loads.

7

Expert

Serving assets with CDN and fallback

🤔Before reading on: do you think Rails can serve assets directly or must always serve them itself? Commit to your answer.

Concept: Rails can serve assets through a Content Delivery Network (CDN) for speed and fallback to local files if needed.

In advanced setups, assets are uploaded to a CDN, which delivers files from servers near users worldwide. Rails generates URLs pointing to the CDN. If the CDN is unavailable, fallback mechanisms serve assets from the local public folder, ensuring reliability.

Result

Users get faster asset delivery globally with fallback for reliability.

Understanding CDN integration shows how Rails scales asset delivery for large, global apps.

Under the Hood

Rails uses the asset pipeline, a system that takes source files from the assets folder, processes them through compilers (like SCSS to CSS), concatenates multiple files into one, compresses them to reduce size, and fingerprints filenames for caching. These processed files are then placed in the public/assets folder for the web server to serve. The public folder itself is served directly by the web server without Rails intervention, making static files instantly accessible.

Why designed this way?

This design separates raw source files from served files, allowing developers to write maintainable code while delivering optimized assets to users. Early web apps served static files directly, but as apps grew complex, processing and optimizing assets became necessary. Rails introduced the asset pipeline to automate this, balancing developer convenience and user performance. Alternatives like serving all files raw would slow down websites and complicate maintenance.

┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│ assets/     │──────▶│ Asset Pipeline│──────▶│ public/assets/│
│ (source)    │       │ (compile,     │       │ (fingerprinted│
│             │       │ concatenate,  │       │ optimized)    │
│             │       │ compress)     │       │               │
└─────────────┘       └───────────────┘       └───────────────┘

┌─────────────┐
│ public/     │
│ (static)    │
│ files       │
└─────────────┘

Web Server serves files from public/ and public/assets/ directly to users.

Myth Busters - 4 Common Misconceptions

Quick: Do you think files in the assets folder are served directly to users without any change? Commit to yes or no.

Common Belief: Files placed in the assets folder are sent to users exactly as they are without any processing.

Reality: Rails processes assets by compiling, combining, compressing, and fingerprinting them before serving.

Why it matters: If you expect raw files to be served, you might be confused when filenames change or styles don't update as expected.

Quick: Do you think the public folder is for source files that Rails compiles? Commit to yes or no.

Common Belief: The public folder is where you put source files that Rails will process before sending.

Reality: The public folder holds static files served directly without any Rails processing.

Why it matters: Putting source files in public can cause them to be served unprocessed, leading to broken styles or scripts.

Quick: Do you think asset filenames stay the same in production? Commit to yes or no.

Common Belief: Asset filenames remain unchanged in production environments.

Reality: Rails adds fingerprints (hashes) to asset filenames in production to enable caching.

Why it matters: Not understanding fingerprinting can cause confusion when referencing assets by name, leading to broken links.

Quick: Do you think Rails compiles assets on every user request in production? Commit to yes or no.

Common Belief: Rails compiles assets dynamically on each request in production.

Reality: Rails precompiles assets before deployment to avoid runtime compilation delays.

Why it matters: Expecting runtime compilation can lead to slow page loads and server overload in production.

Expert Zone

1

Rails asset pipeline supports source maps, allowing developers to debug original source files even after compilation and compression.

2

Assets can be organized in subfolders within assets for better modularity, and Rails automatically resolves paths during compilation.

3

The public folder can also serve files uploaded by users or generated at runtime, which should not be processed by Rails.

When NOT to use

For very large or complex front-end applications, using modern JavaScript bundlers like Webpack or esbuild outside the Rails asset pipeline can be better. Also, for dynamic assets or user uploads, storing files in cloud storage or dedicated services is preferred over the public folder.

Production Patterns

In production, assets are precompiled and served via a CDN for speed. Developers often configure Rails to fingerprint assets and set long cache expiration headers. The public folder is used for static files like robots.txt or favicon.ico, while assets folder source files are managed with version control and compiled during deployment.

Connections

Content Delivery Networks (CDN)

Builds-on

Understanding how Rails fingerprints and precompiles assets helps grasp how CDNs cache and deliver files efficiently worldwide.

Compiler Design

Same pattern

The asset pipeline acts like a compiler, transforming source files into optimized output, similar to how programming language compilers work.

Supply Chain Management

Analogy in process flow

Just as raw materials are processed and packaged before reaching customers, assets are prepared and optimized before delivery to users.

Common Pitfalls

#1 Placing source CSS or JavaScript files directly in the public folder.

Wrong approach:

public/stylesheets/application.css
public/javascripts/app.js

Correct approach:

assets/stylesheets/application.scss
assets/javascripts/app.js

Root cause:

Misunderstanding that public serves static files without processing, so source files placed there won't be compiled or optimized.

#2 Referencing asset filenames without fingerprints in production.

Wrong approach:

Correct approach:

<%= stylesheet_link_tag 'application', media: 'all' %>

Root cause:

Not using Rails helpers that generate correct fingerprinted asset paths, causing broken links in production.

#3 Not precompiling assets before deploying to production.

Wrong approach:

Deploying without running `rails assets:precompile` and expecting assets to compile on the fly.

Correct approach:

Running `rails assets:precompile` during deployment to generate optimized assets.

Root cause:

Assuming Rails compiles assets dynamically in production, leading to slow page loads and errors.

Key Takeaways

The public folder serves static files directly to users without any processing by Rails.

The assets folder holds source files that Rails compiles, combines, and compresses before serving.

Rails fingerprints asset filenames in production to enable efficient browser caching.

Precompiling assets before deployment ensures fast and reliable delivery in production.

Using Rails helpers to reference assets prevents broken links and handles fingerprinting automatically.