Nous utilisons nos propres cookies ainsi que ceux de tiers pour améliorer votre expérience et analyser l'utilisation de notre site web.

Pour accepter notre utilisation des cookies, sélectionnez une option.

Daniel Orchanian
Retour

Framework ou JavaScript "Vanilla" ?

Faut-il toujours utiliser un framework ? Au fait, pourquoi on utilise des frameworks ?

Framework ou JavaScript "Vanilla" ?

Depuis quelques années, le paysage du développement frontend a beaucoup changé.

On est progressivement passé d'un rôle frontend consistant à uniquement faire du HTML/CSS, à de véritables applications frontend avec une logique, des fonctions... qui n'ont plus grand-chose à envier du backend.

Si vous êtes développeur JavaScript et souhaitez progresser en frontend aujourd'hui, vous serez forcément amené à travailler sur un framework dédié comme React, Angular ou Vue.

"Ou Svelte."
-- Un fan de Svelte

Il m'a donc paru intéressant de faire un peu le tour du sujet sous différents angles, à travers quelques articles.

Mais définissons d'abord les choses.

Framework ? "Vanilla" ?

"Vous avez dit vanille ? Miam !"
-- Un lecteur affamé

Quelques explications :

  • JavaScript "Vanilla", ou JavaScript natif, est le JavaScript de base, pur, sans aucun framework ou bibliothèque externe.

  • Un framework, ou cadre applicatif, est un environnement dans lequel on peut coder une application. Il fournit des outils permettant de faciliter le développement d'un projet.

Par abus de langage, j'inclus aussi certaines bibliothèques qui remplissent un rôle similaire aux frameworks, comme ReactJS.

Et enfin, je vais surtout traiter des frameworks/librairies frontend, (donc JavaScript).

Mais certaines informations dans ces articles concerneront aussi des frameworks backend, et ceux d'autres langages.

Les outils "du futur"

Quand ces frameworks ont commencé à apparaître, le marché a sauté à pieds joints dedans.

On les présentait comme des outils révolutionnaires, permettant de créer des sites plus rapides, plus dynamiques, plus réactifs.

Un sacré argument de vente face aux clients.

Les entreprises de service du numérique (ESN) ont rapidement adopté ces technologies, notamment pour pouvoir prendre un maximum de projets.

Mais peu de gens ont vraiment creusé le sujet pour comprendre ce que faisait exactement ReactJS, par exemple.

C'était juste le nouveau joujou magique censé remplacer PHP.

"MWA HA HA HA !"
-- Un développeur PHP, hilare

J'ai par exemple connu une entreprise qui avait adopté ReactJS sur de gros projets, avant de réaliser que c'était (à l'époque) une catastrophe en termes de référencement et SEO.

Ils sont vite repassés à PHP, complètement déçus...

Et même après cet échec, personne n'a voulu prendre le temps de comprendre.

Des développeurs perdus

Le souci, c'est qu'entreprises comme développeurs utilisent ces outils sans vraiment comprendre pourquoi, et donc sans savoir expliquer pourquoi.

Et cela se ressent chez les nouveaux arrivants dans le domaine.

Combien de formations suivent le marché et lancent les juniors sur ces frameworks juste pour cocher une case ?

Les formations qui passent une semaine sur chaque framework, on vous voit...

On produit une génération de développeurs incapables d'expliquer un choix technique fondamental.

Et le pire, c'est qu'on va aller les embêter en entretien là-dessus...

Les fausses raisons de choisir un framework

Si vous utilisez React, Angular ou Vue...

"Ou Svelte."
-- Un fan de Svelte, un peu relou

... pour les fonctionnalités suivantes :

  • Reproduire facilement un bout de code HTML sur différentes pages.
  • Modifier le contenu d'une page de façon dynamique.
  • Capter les interactions utilisateur (clic, entrée clavier).
  • Gérer et envoyer un formulaire.
  • Communiquer avec un serveur distant pour envoyer et recevoir des données.

Et bien... tout cela est faisable en JavaScript natif.

Vous n'avez pas besoin de framework pour utiliser ces fonctionnalités.

"Sombre trahison ! On m'aurait menti ?"
-- Un développeur junior, désemparé

Non, on ne vous a juste pas expliqué, et n'avez vous-mêmes pas cherché à comprendre.

Mais c'est rémédiable.

Ce qui nous attend

Peut-être est-il temps de voir ce qu'apportent vraiment les frameworks au développement d'un site ou d'une application ?

Ce sera l'objet de plusieurs articles à venir. On y verra entre autres :

  • comment ces frameworks font gagner du temps
  • comment les frameworks changent la façon de structurer un projet
  • quand il est utile de travailler avec un framework
  • et quand c'est inutile (si si, ça existe)...

En attendant, pour rigoler un peu, voici un petit lien (en anglais) vers une page humoristique présentant le JavaScript natif comme un framework à part entière :

Crédits Photo : Rod Long | asier_relampagoestudio

Daniel Orchanian
N'hésitez pas à vous abonner sur LinkedIn pour suivre mon activité et me contacter.