Propshaft vs Sprockets : La révolution de la gestion des assets dans Rails 8


Imaginez ce scénario : votre investisseur providentiel vous demande d'ajouter une image de chat sur la page d'accueil de votre application Rails. Simple, n'est-ce pas ? Pourtant, cette tâche apparemment anodine soulève une question fondamentale : comment Rails gère-t-il réellement les assets statiques ? Avec l'arrivée de Rails 8, un changement majeur s'est opéré dans la gestion des assets. Exit Sprockets, place à Propshaft, un outil qui révolutionne notre approche de la gestion des fichiers statiques.


Dans cet article, nous allons explorer pourquoi ce changement est survenu, comment Propshaft fonctionne, et pourquoi il représente une simplification bienvenue pour les développeurs Rails.

Les fichiers statiques dans Rails : les fondamentaux

Qu'est-ce qu'un fichier statique ?

Rails suit une architecture MVC (Modèle-Vue-Contrôleur), mais que se passe-t-il lorsqu'un navigateur demande quelque chose qui n'entre pas dans ce cadre ? Par exemple, une image, un fichier CSS ou JavaScript ?


Rails considère les fichiers non-dynamiques (ceux qui ne contiennent pas de code Ruby) comme statiques. Ces fichiers sont généralement stockés dans le répertoire public et gérés via le middleware Action Dispatch Static.

Deux approches pour servir une image

Prenons l'exemple de notre image de chat :


Approche 1 : Placement dans public

# Dans votre layout
<img src="/kitten.jpeg" />

Le fichier est servi directement depuis public/kitten.jpeg.


Approche 2 : Utilisation de app/assets/images

# Dans votre layout
<%= image_tag "kitten.jpeg" %>


Le fichier devient kitten-e4ebcc51.jpeg avec un hash ajouté au nom.


Mais pourquoi cette différence ? La réponse réside dans un concept crucial : le cache.

Le problème du cache des navigateurs

Pourquoi le cache pose problème

Les serveurs et les navigateurs adorent mettre en cache vos fichiers statiques. C'est généralement bénéfique pour :

  1. Les logos
  2. Les photos de stock
  3. Les images qui ne changent pas souvent


Mais pour les fichiers qui évoluent fréquemment, comme JavaScript ou CSS, le cache devient problématique.

Le scénario catastrophe

  1. Un navigateur demande votre fichier app.js
  2. Le serveur le lui envoie
  3. Le navigateur le met en cache
  4. Vous modifiez app.js avec de nouvelles fonctionnalités
  5. Le navigateur redemande app.js
  6. Problème : Le navigateur utilise sa version en cache au lieu de demander la nouvelle version au serveur


Résultat ? Vos utilisateurs ne voient jamais vos nouvelles modifications jusqu'à ce que leur cache soit vidé.

La solution : le hash de fichier

La solution la plus élégante consiste à estampiller les fichiers avec une valeur représentant leur contenu. Ainsi, quand le contenu change, le nom du fichier change également.


Exemple pratique :

# Générer un hash SHA-256 du fichier
openssl sha256 hello_controller.js
# Résultat : e4ebcc51a2b3...
# Renommer le fichier
hello_controller-e4ebcc51a2b3.js

Si vous modifiez le contenu du fichier, le hash change :

openssl sha256 hello_controller.js
# Nouveau résultat : f7d9a2c4b1e8...


Le navigateur voit un nouveau nom de fichier et demande la nouvelle version au serveur. C'est exactement ce que fait Propshaft !

L'histoire de Sprockets : de l'innovation à la complexité

2011 : L'arrivée de Sprockets

En 2011, avec Rails 3.1, Sprockets devient le gestionnaire d'assets principal. À cette époque, le web était très différent :

  1. CoffeeScript était populaire
  2. Les navigateurs ne supportaient pas ES6
  3. HTTP/1 était la norme
  4. Le SASS était nécessaire pour CSS avancé

Les multiples rôles de Sprockets

Sprockets ne se contentait pas de hasher les fichiers. Il faisait beaucoup plus :

  1. Digestion et hashage : Estampiller les fichiers avec des hash pour casser le cache
  2. Transpilation :
  3. CoffeeScript → JavaScript
  4. SASS → CSS
  5. ES6 → ES3 (via Babel) pour les anciens navigateurs
  6. Optimisation :
  7. Combinaison de multiples fichiers en un seul
  8. Minification du code
  9. Compression des assets

Pourquoi tant de complexité ?

La raison principale : HTTP/1. Ce protocole ne permettait de charger qu'une seule ressource à la fois, séquentiellement.


Imaginez une cascade de requêtes :

Ressource 1 → Attendre → Ressource 2 → Attendre → Ressource 3...


Pour optimiser les performances, Sprockets devait réduire le nombre de fichiers au maximum. D'où la combinaison et la minification.

2015 : L'explosion JavaScript

Avec l'arrivée d'ES6, le monde JavaScript a explosé :

  1. Applications web monopages (SPA)
  2. Outils de build complexes (Webpack, etc.)
  3. Nouvelles fonctionnalités JavaScript


Sprockets a tenté de suivre, mais est devenu trop complexe et difficile à maintenir.

2024 : Le monde a changé, Propshaft arrive

Les avancées technologiques

Plusieurs changements majeurs ont permis une simplification radicale :


1. Support natif d'ES6

  1. Tous les navigateurs majeurs supportent ES6
  2. Plus besoin de transpilation

2. CoffeeScript est obsolète

  1. Plus personne n'utilise CoffeeScript
  2. Pas besoin de transpiler

3. CSS moderne

  1. Variables CSS natives
  2. Support du nesting
  3. SASS devient moins nécessaire

4. HTTP/2 et le multiplexing

  1. Requêtes multiples simultanées sur une seule connexion TCP
  2. Réception dans n'importe quel ordre
  3. Plus besoin de tout combiner en un seul fichier

5. Internet plus rapide et stable

  1. Moins critique de minifier à l'extrême

Propshaft : la simplicité retrouvée

Propshaft fait une seule chose, mais bien :


✓ Digestion et hashage des fichiers pour casser le cache

✓ Mapping des noms logiques vers les fichiers hashés

✗ Pas de transpilation

✗ Pas de minification

✗ Pas de concaténation

Comment fonctionne Propshaft en pratique

Précompilation des assets

En production, vous précompilez vos assets au moment du déploiement :

bin/rails assets:precompile


Cette commande :

  1. Parcourt tous vos fichiers statiques
  2. Génère un hash basé sur leur contenu
  3. Renomme les fichiers avec ce hash
  4. Place tout dans le dossier public
  5. Crée un fichier manifest

Le fichier manifest.json

Le secret de Propshaft réside dans public/assets/manifest.json :

{
"kitten.jpeg": "kitten-e4ebcc51a2b3.jpeg",
"hello_controller.js": "hello_controller-f7d9a2c4b1e8.js",
"application.css": "application-a1b2c3d4e5f6.css"
}


Grâce à ce manifest, vous pouvez utiliser le nom logique dans votre code :

<%= image_tag "kitten.jpeg" %>


Et Propshaft le résout automatiquement vers :

<img src="/assets/kitten-e4ebcc51a2b3.jpeg" />

Résolution dans les fichiers CSS

Propshaft effectue une légère compilation CSS pour résoudre les références :

/* Avant */
background-image: url('kitten.jpeg');
/* Après compilation */
background-image: url('kitten-e4ebcc51a2b3.jpeg');

HTTP/2 en action

Dans l'onglet Network de votre navigateur, vous verrez désormais :

  1. Multiples requêtes lancées simultanément
  2. Toutes retournées en parallèle
  3. Pas de cascade séquentielle

C'est la magie du multiplexing HTTP/2 !

Les avantages de Propshaft pour les développeurs


1. Simplicité

  1. Moins de configuration
  2. Moins de magie noire
  3. Code plus facile à débugger

2. Transparence

Vos fichiers JavaScript et CSS sont servis tels quels en production. Ce que vous voyez en développement est ce que vous obtenez en production.

3. Performance moderne

Propshaft tire parti des technologies modernes (HTTP/2, ES6 natif) au lieu de les combattre.

4. Flexibilité

Si vous avez besoin d'un build JavaScript complexe, vous utilisez votre propre système (Vite, esbuild, etc.). Propshaft ne se met pas en travers.

5. Maintenance réduite

Moins de code = moins de bugs = moins de maintenance.

Rails 8 : le framework d'une personne

Propshaft incarne parfaitement la philosophie de Rails 8 : permettre à un développeur solo de construire des applications web complètes sans se noyer dans la complexité.

En simplifiant la gestion des assets, Rails élimine un point de friction majeur et permet aux développeurs de se concentrer sur ce qui compte vraiment : créer de la valeur pour leurs utilisateurs.

Conclusion

Le passage de Sprockets à Propshaft dans Rails 8 n'est pas qu'un simple changement technique. C'est le reflet d'une maturité du web et d'une volonté de simplifier l'expérience développeur.


Grâce aux avancées en HTTP/2, au support natif d'ES6, et à l'amélioration générale des standards web, nous n'avons plus besoin de la complexité que Sprockets apportait. Propshaft fait une chose simple, mais essentielle : il hash vos fichiers pour casser intelligemment le cache.


Pour les développeurs Rails, cela signifie :

  1. Moins de temps passé à configurer le build
  2. Plus de transparence dans le traitement des assets
  3. Une meilleure expérience de développement globale


Alors la prochaine fois que votre investisseur vous demandera d'ajouter une image de chat sur votre page d'accueil, vous saurez exactement ce qui se passe sous le capot. Et vous pourrez l'implémenter avec confiance, sachant que Propshaft gère intelligemment le cache pour vous.


Bienvenue dans l'ère de la simplicité avec Rails 8 et Propshaft !