J&#ai essayé de passer à Vue.js depuis React.js

Introduction

Il y a quelques années, comme beaucoup d'autres, j'étais "hypé" par l'arrivée des hooks et les composants fonctionnels de la librairie frontend React.js. Ils proposaient une toute nouvelle manière de développer en écrivant beaucoup moins de code qu'avec les class Components. J'ai véritablement accroché, et pour un bon moment.

Aujourd'hui, j'ai dû opter pour le framework Vue.js afin de répondre aux besoins d'un tout nouveau projet client. Et étant arrivé au bout de ce projet, je me suis dit que c'était l'occasion de vous proposer un retour d'expérience en tant que nouvel utilisateur de ce framework !

Alors, est-ce que cette montée en compétence a été à la hauteur de la notoriété de Vue.js ?
Est-ce qu'il vaut mieux, aujourd'hui, développer du frontend en Vue qu'en React ?

C'est ce que nous allons voir !

Démarrage du projet

Boilerplate

Qui dit démarrage de projet, dit recherche d'un bon boilerplate pour nous épargner des heures, voire des jours de configuration laborieuse !
Sans avoir besoin de chercher très loin, la commande npm create vue@latest répond largement à mes besoins :

✔ Project name: … myproject-vue
✔ Add TypeScript? … No / Yes
✔ Add JSX Support? … No / Yes
✔ Add Vue Router for Single Page Application development? … No / Yes
✔ Add Pinia for state management? … No / Yes
✔ Add Vitest for Unit Testing? … No / Yes
✔ Add an End-to-End Testing Solution? › Playwright
✔ Add ESLint for code quality? … No / Yes
✔ Add Prettier for code formatting? … No / Yes
? Add Vue DevTools 7 extension for debugging? (experimental) › No / Yes

Le langage Typescript est déjà pris en charge, un système de routage et un store sont proposés, et il y a même de quoi réaliser des tests unitaires et End-to-End !

Par défaut, c'est le bundler Vite qui est installé. Ce qui n'est pas pour me déplaire !? En effet, les builds sont rapides et, la plupart du temps le Hot Module Replacement (HMR) fonctionne bien.

Un petit npm run dev pour lancer le serveur de dev local, et hop ! Ça tourne déjà dans le navigateur !

Et pour la mise en prod ? Il suffit de saisir la commande npm run build, et le projet s'exporte en fichiers statiques dans un répertoire dist après avoir vérifié les typages (dans le cas où l'on a activé le Typescript) :

vite v5.2.11 building for production...
✓ 48 modules transformed.
dist/index.html                      0.43 kB │ gzip:  0.28 kB
dist/assets/AboutView-C6Dx7pxG.css   0.09 kB │ gzip:  0.10 kB
dist/assets/index-D6pr4OYR.css       4.21 kB │ gzip:  1.30 kB
dist/assets/AboutView-CEwcYZ3g.js    0.22 kB │ gzip:  0.20 kB
dist/assets/index-CfPjtpcd.js       89.23 kB │ gzip: 35.29 kB
✓ built in 591ms

Architecture du projet

.
├── README.md
├── e2e/
├── index.html
├── package.json
├── public/
├── src/
│   ├── App.vue
│   ├── assets/
│   ├── components/
│   │   ├── HelloWorld.vue
│   │   ├── TheWelcome.vue
│   │   ├── WelcomeItem.vue
│   │   ├── __tests__/
│   │   └── icons/
│   ├── main.ts
│   ├── router/
│   │   └── index.ts
│   ├── stores/
│   │   └── counter.ts
│   └── views/
│       ├── AboutView.vue
│       └── HomeView.vue
├── tsconfig.json
└── vite.config.ts

Côté architecture du projet, on trouve notamment :

• le fichier index.html, avec la balise
  sur laquelle vient se greffer toute notre application Vue ;
• le main.ts, avec la création successive du composant App, du router et du store :

✔ Project name: … myproject-vue
✔ Add TypeScript? … No / Yes
✔ Add JSX Support? … No / Yes
✔ Add Vue Router for Single Page Application development? … No / Yes
✔ Add Pinia for state management? … No / Yes
✔ Add Vitest for Unit Testing? … No / Yes
✔ Add an End-to-End Testing Solution? › Playwright
✔ Add ESLint for code quality? … No / Yes
✔ Add Prettier for code formatting? … No / Yes
? Add Vue DevTools 7 extension for debugging? (experimental) › No / Yes

• des fichiers .ts purs, pour gérer le routage et le store ;
• quelques fichiers de config et de test ;
• ... et bien sûr les fichiers *.vue, distingués en components (qui correspondent plutôt à des éléments génériques et réutilisables), et views (qui correspondent plutôt à des pages haut niveau)

En bref, l'architecture des fichiers est plutôt simple et relativement similaire à celle de React, même en ayant coché pas mal d'options dans le boilerplate.
Jusque-là, venant de React, rien de bien nouveau. C'est ensuite qu'apparaissent des différences significatives !

Architecture d'un fichier Vue

Voici un extrait de code inspiré du site officiel. Il se contente de changer la couleur du texte si l'on clique dessus et d'afficher la phrase "Le texte ci-dessus est vert", le cas échéant, mais il représente une architecture typique des fichiers *.vue :

vite v5.2.11 building for production...
✓ 48 modules transformed.
dist/index.html                      0.43 kB │ gzip:  0.28 kB
dist/assets/AboutView-C6Dx7pxG.css   0.09 kB │ gzip:  0.10 kB
dist/assets/index-D6pr4OYR.css       4.21 kB │ gzip:  1.30 kB
dist/assets/AboutView-CEwcYZ3g.js    0.22 kB │ gzip:  0.20 kB
dist/assets/index-CfPjtpcd.js       89.23 kB │ gzip: 35.29 kB
✓ built in 591ms

Notez le binding des évènements avec @click, l'affichage conditionnel avec le v-if, et le binding dans le CSS avec v-bind().

Le code est séparé en 3 parties bien distinctes :

• script : le code de contrôle ;
• template : la structure HTML ;
• style : la feuille de style CSS.

Et ces trois parties ne se mélangent jamais ?.
Cela présente plusieurs avantages que j'ai personnellement éprouvés tout au long mon expérience sur le projet client :

• La structure HTML est claire, fixe, et dans un style très déclaratif - tout est là, même les balises affichées sous conditions ;
• la partie logique est bien séparée de la partie affichage ;
• on peut écrire du pur CSS en place, directement lié au composant, et sans installer de librairies tierce ;
• malgré la séparation du style, on peut quand même insérer des variables dans le CSS.

Avec le tag scoped sur la balise