Frontend - Introduction

Niveau: Débutant · Intermédiaire

1. Contexte :

Le Frontend, c’est la vitrine

Sur le web, le frontend est la première chose que l’utilisateur voit: la vitrine, l’accueil, l’expérience. Un bon backend, c’est la mécanique; un mauvais frontend, c’est une boutique fermée.

Avant, il suffisait de HTML, CSS, un peu de JavaScript. Aujourd’hui, on veut des applis rapides, belles, adaptées à tous les écrans.

Le frontend n’est plus un simple décor: c’est devenu un vrai métier d’artisan, où design et performance font la différence.

2. Concepts théoriques:

Qu’est-ce que le frontend?

Définition : « Le développement frontend désigne l’ensemble des techniques permettant de créer l’interface utilisateur d’une application ou d’un site web, c’est-à-dire la partie visible et interactive avec laquelle l’utilisateur interagit. »

En clair : Le frontend, c’est tout ce que tu vois et manipules : boutons, menus, formulaires, animations, couleurs, polices… Si tu peux cliquer, lire, scroller, drag’n’drop… c’est du frontend !

Trois piliers historiques :

HTML : structure le contenu (titres, paragraphes, images)
CSS : met en forme (couleurs, espaces, alignements)
JavaScript : donne vie à l’ensemble (interactions, animations, mises à jour dynamiques)

Aujourd’hui, le frontend va bien plus loin que “faire joli” : Il doit s’adapter à tous les supports (mobile, desktop, tablette), être rapide, accessible, et intuitif.

3. Les grandes évolutions du frontend

Le frontend, c’est un métier qui change… tout le temps!

De la page statique aux apps web modernes

Années 90–2010:
- HTML + CSS = sites statiques
- JavaScript = petites animations, menus déroulants
2010:
- Explosion du mobile, responsive design
- Les frameworks apparaissent (jQuery, puis AngularJS, React, Vue…)
Aujourd’hui:
- SPA (Single Page Application) : toute l’appli charge une seule page, tout le reste se fait côté navigateur (ex: Gmail, Facebook)
- SSR (Server Side Rendering) : le serveur prépare la page, l’envoie déjà “prête à afficher” (Next.js, Nuxt.js)
- CSR (Client Side Rendering) : tout est géré dans le navigateur après le premier chargement
- JAMstack: sites ultra rapides générés à l’avance, servis comme des fichiers statiques (Astro, Gatsby…)

En résumé: Le frontend, c’est comme une scène de théâtre:

Tu prépares le décor (HTML/CSS)

Tu fais bouger les acteurs (JavaScript)

Tu changes la mise en scène en fonction du public (responsive, accessibilité, performance)

4. Comment choisir ses outils frontend… sans oublier la planète?

Face à la multitude d’outils et frameworks (Angular, React, Vue, Svelte…), Face à la multitude d’outils et frameworks, comment choisir?

Angular
React
Vue
Svelte

Quelques critères de choix:

Simplicité: Un outil simple à apprendre t’aidera à progresser plus vite.
Communauté: Plus il y a d’utilisateurs, plus tu trouveras de l’aide et des ressources.
Performance: Certains frameworks sont plus rapides ou consomment moins de ressources (et c’est important!).
Accessibilité: L’outil facilite-t-il le développement pour tous (personnes en situation de handicap, mobile…)?
Maintenance: Un outil trop “hype” aujourd’hui peut disparaître demain. Privilégie les valeurs sûres.

Enjeux écologiques du frontend 🌱

Chaque ligne de code, chaque kilo-octet envoyé au navigateur, a un impact environnemental:
Plus ton site est “lourd” (images, JS, CSS, polices), plus il consomme d’électricité (serveur, réseau, appareil client).
Un site léger = moins de CO₂, moins d’énergie, meilleure expérience pour tous.
Éco-concevoir le frontend, c’est:
Limiter les frameworks et dépendances inutiles.
Optimiser les images et polices.
Privilégier le rendu statique ou l’hydratation partielle (Astro, Svelte, etc.).
Mesurer l’impact (ex: ecoindex.fr).

Un bon choix technique, c’est aussi un choix responsable: tu peux rendre le web plus vert et plus accessible, tout en créant des interfaces de qualité.

5. Retour d’expérience perso

Pour les petites applications ou des prototypes rapides, je privilégie toujours Pug ou simplement du HTML/CSS classique:

Léger, rapide, zéro dépendance inutile
Parfait pour apprendre, expérimenter, ou faire un site simple

Quand il faut sortir l’artillerie (projet complexe, besoin de structurer le code, maintenabilité sur le long terme), je préfère Angular:

Très stable
Architecture claire et modulaire
Support natif de TypeScript (le vrai maître du code solide et lisible)

Ma règle d’or: Commence simple, ne complexifie que si le projet le demande vraiment.