
Dans un [récent post](https://www.linkedin.com/posts/anthony-cyrille_cleancode-programming-activity-7021725435289862144-oDbo), **Anthony Cyrille**, que je vous conseille de suivre vivement (sur les réseaux, pas dans la rue) montrait un exemple de code issu d'une appli lancée par le gouvernement néerlandais.

Je lui pique sa capture d'écran :

![Fonction getPercentageRounds](/images/blog/posts/short-vs-readable-refactoring.jpg)

C'est une fonction dont le rôle est assez simple : on prend une **note de 0 à 10**, et on renvoie une **représentation graphique** à base de cercles remplis ou vides.

L'avantage de cette façon de faire, c'est que c'est assez lisible et compréhensible pour l'humain.

Mais est-ce la **meilleure version possible** ?

> J'imagine que non, sinon on n'aurait pas l'article ?  
— Un lecteur perspicace

![Violence](/images/blog/posts/doc-brown-blackboard.webp)
<div style="text-align: center;"><i>Exactement !</i></div>


## C'est quoi le souci en fait ?

Comme expliqué en introduction, le code est assez simple à comprendre. Cependant, il présente deux problèmes, ou deux **pistes d'amélioration** :
- Il est **trop long** : beaucoup de répétitions pour quelque chose de plutôt simple.
- Il est **peu lisible** : il est un peu fouillis avec ces conditions qui s'enchaînent.

> **Attention !**  
Je ne critique pas ici l'**optimisation**. En fait, ce code ne présente aucun problème de performance : bien qu'il soit un peu long, il s'exécute de façon instantanée.

J'ajouterai aussi que je ne critique pas le développeur responsable du code. Il avait sans doute **plus urgent à faire** dans l'appli et sa solution **fonctionne**. Aucun reproche envers ce confrère, qui avait sûrement ses priorités.

![Violence](/images/blog/posts/baseball-bat.gif)
<div style="text-align: center; font-size: 0.85em;"><i>Le confrère néerlandais, soulagé</i></div>

Mais améliorons un peu ce code. Pour cela, je vais utiliser du **JavaScript** de base (pas de typage). Vous pouvez facilement transposer ces solutions dans d'autres langages.


## Version 1 : simple amélioration du code existant

Cette version consiste simplement à retravailler le code de façon à **conserver son fonctionnement de base** tout en supprimant ce qui est **inutile** ou **redondant**.

```js
function getRateDotsIf(rate) {
    if (rate <= 0) return "----------";
    if (rate <= 0.1) return "*---------";
    if (rate <= 0.2) return "**--------";
    if (rate <= 0.3) return "***-------";
    if (rate <= 0.4) return "****------";
    if (rate <= 0.5) return "*****-----";
    if (rate <= 0.6) return "******----";
    if (rate <= 0.7) return "*******---";
    if (rate <= 0.8) return "********--";
    if (rate <= 0.9) return "*********-";
    return "**********";
}
```

J'ai supprimé la moitié de chaque condition : la partie `rate > ...` ne sert à rien grâce aux _early returns_ qui se chargent de sortir de la fonction :

```js
    if (rate <= 0) return "----------";
    // si rate était inférieur ou égal à 0,
    // on serait déjà sorti à la ligne précédente !
    if (rate > 0 && rate <= 0.1) return "*---------";
```

Quelques **bonnes pratiques** à retenir, toutes deux déjà présentes dans le code d'origine :


![Violence](/images/blog/posts/baseball-bat.gif)
<div style="text-align: center; font-size: 0.85em;"><i>Le confrère néerlandais, fier de ses bonnes pratiques</i></div>

- Les **`if` monolignes/sans accolades** (oui, ça existe en JavaScript et non, ce n'est pas interdit) : si vous avez une simple ligne d'instruction, vous pouvez écrire votre code ainsi : `if (condition) instruction;`.  
C'est d'autant plus pratique quand le code **se répète**, comme ici.

- Le **early return** : le mot-clé return fait "sortir" de la fonction. Cela permet d'éviter des `else` et rend le code plus lisible.

Cette version a le mérite d'être **très simple à comprendre**. Pas de grosse gymnastique intellectuelle ou visuelle.

Les bonnes pratiques citées plus haut permettent de **modifier le code très facilement** et de conserver une cohérence visuelle facilitant la lecture.

Cependant, il faut connaître le concept de l'_early return_.


## Version 2 : boucle

C'est ici qu'on va essayer de se débarrasser de l'aspect **redondant** du code de départ.

```js
function getRateDotsLoop(rate) {
    let str = "----------".split("");
    for (let  i = 0; i <= 10; i++) {
        if (rate * 10 <= i) break;
        str[i] = "*";
    }
    return str.join("");
}
```

Expliquons les étapes :
1. On crée une chaîne `"----------"` dont on divise immédiatement les caractères en **tableau** grâce à `String.split()` : `["-", "-", "-", "-", "-", "-", "-", "-", "-", "-"]`.
2. On fait une **boucle** qui itère de 0 à 10.
    - Si _rate_ multiplié par 10 est inférieur ou égal à l'itérateur i, on arrête la boucle.
    - Sinon, on transforme le caractère à l'index `i` (0 à 9) dans notre tableau : `["-", "-", ...]` devient `["*", "-", ...]` au premier passage.
3. On renvoie enfin la chaîne qui résulte de la méthode `Array.join()`.

> À noter que l'étape _split/join_ n'est pas nécessaire dans certains langages.

Cette solution est plus courte, mais je trouve qu'elle **perd en lisibilité**.

De plus, si on doit **retravailler** la fonction, il y a un certain effort intellectuel à prévoir.

> D'ailleurs, ce code contient un petit vice caché au niveau de la boucle. Saurez-vous le retrouver ?


## Version 3 : répétition

_Ou la version une fois qu'on a effectué une recherche en ligne et qu'on découvre qu'il existe une méthode [`String.repeat()`](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/String/repeat)..._

Celle-ci permet de **générer une chaîne de caractère en la répétant un certain nombre de fois**. Exactement ce que fait notre fonction !

```js
function getRateDots3(rate) {
    const filled = Math.ceil(rate * 10);
    return "*".repeat(filled) + "-".repeat(10 - filled);
}
```

- On calcule le nombre de points **"remplis"** : la variable `rate` plafonnée à l'entier supérieur (grâce à `Math.ceil()`).
- Ensuite, on renvoie ce nombre de fois le caractère rempli (`*`) et le **reste** de fois le caractère vide (`-`) pour atteindre un total de 10 caractères.

> Cette fonction peut être codée en une ligne, mais j'ai préféré créer une micro-étape pour plus de **clarté**.


## Conclusion : quelle est la meilleure version ?

Honnêtement, je partirais sur les versions 1 ou 3.
- La **troisième** a le mérite d'être plus **courte**, tout en ayant le même niveau de lisibilité que la première.
- La **première** permet cependant de **modifier rapidement les choses** si on change la formule derrière le calcul du score.

La seconde version, si elle est plus courte que la première, est une catastrophe tant en terme de **lisibilité** que d'**évolution**. Le développeur devra inutilement **passer du temps à réfléchir à là où il met les pieds**.

Et vous, quel serait votre choix ?

![Violence](/images/blog/posts/baseball-bat.gif)
<div style="text-align: center; font-size: 0.85em; margin-bottom: 2rem"><i>Le confrère néerlandais, qui vous remercie d'avoir lu l'article</i></div>

J'ai refactorisé une fonction présente sur une appli du gouvernement néerlandais.

Code court VS code lisible


J'ai récemment vu passer une discussion sur le _clean code_, le TDD... les **bonnes pratiques** en somme. Un développeur y racontait une expérience assez courante que je vais résumer ici.


## Pragmatique ? Réaliste ?

On lui avait confié une application où toute la logique était dans le fichier `App.js`, de **plusieurs milliers de lignes**. Une catastrophe à maintenir, ou même seulement lire et comprendre. Quelque chose qu'il ne faut **jamais faire**.

Cependant, cette version boiteuse avait permis de lever des millions d'euros pour **financer le projet**. Dans les mois qui ont suivi, une équipe de dix développeurs a retapé tout le code pour avoir quelque chose de gérable.

Suite à cela, le développeur conclut que **seul le résultat compte, pas le code**. J'avoue que c'est une réalité à ne jamais oublier : ne pas trop optimiser un projet dont on ne connaît pas encore l'avenir.

Dans son cas, ça s'est bien terminé et...

<div style="text-align: center; margin: 2rem 0">... c'est <b>mignon</b>.</div>

![Mignon...](/images/blog/posts/office-jim-smile.webp)


## Une autre réalité (plus courante)

J'ai eu une expérience similaire (sans les millions de financement) : notre équipe avait reçu une sorte de test pour une application, et si le travail était satisfaisant, on allait nous confier la suite.

Des composants avaient déjà été posés, mais il fallait appliquer le nouveau design. J'étais en charge de reproduire la maquette sur _ReactJS_. Le délai étant court, j'étais rejoint par un intégrateur CSS.

Très vite, nous avons été bloqués à cause de **bugs** incompréhensibles empêchant l'affichage de certains composants.

J'ai essayé de comprendre et j'ai réalisé avec horreur que **toute la logique pour trois pages se trouvait dans le fichier racine App.js**. On faisait parvenir les données aux pages et à leurs sous-composants par du _prop drilling_.

> Le **prop drilling** consiste à transmettre des données de composant en composant en leur faisant **traverser tous les composants intermédiaires**, même si ces derniers n'utilisent pas ces données.


## Le cauchemar

> Ici, j'explique en quoi c'est un problème. Si vous voulez éviter les détails techniques, passez à la section suivante.

C'est évidemment quelque chose qu'il ne faut pas faire, et qui aurait pu être évité en faisant appel à un **état global** (_Redux_ à l'époque, _Context_ ou d'autres alternatives aujourd'hui).

Mais ici, un état global n'était même pas nécessaire. Ce qui se passait, c'est que les pages faisaient appel à des fonctions **qui leur étaient propres** en terme de logique, mais qui se trouvaient à la racine de l'application.

En gros, chaque composant de l'application **remontait tous les composants parents** pour une opération, puis la réponse **redescendait ces mêmes composants**.

Il suffisait juste de mettre la logique des pages... **dans les pages** !


## Décision et conséquences

Étant développeur fullstack, et non simple intégrateur, je décide d'**enfreindre les instructions** et de régler les bugs moi-même sans toucher à la structure (j'ai tout laissé dans `App.js`). Sans ça, on aurait sans doute perdu le contrat. Bien entendu, j'avais l'aval de mon supérieur.

Je me souviens encore de la conversation téléphonique avec le développeur backend à l'origine du code, intrigué de savoir pourquoi on avait touché à la partie logique.

Quelques mois plus tard, le client est revenu vers nous. L'autre développeur a été remplacé. Je pense avec le recul qu'il était un bon développeur backend, mais qu'il ne maîtrisait pas _ReactJS_, et donc ses **bonnes pratiques**.

J'en veux pour preuve le commentaire que vous voyez en image de couverture (j'avais pris la photo à l'époque)...

![TODO refactor this epic programing fail](/images/blog/posts/todo-refactor-epic-fail.jpg)

Il savait qu'il avait produit un code impossible à maintenir. Mais il a préféré aller vite (peut-être une contrainte du client ?).


## Mais à quel prix ?

Certes, le client est revenu vers nous pour la suite, mais il nous a demandé de tout recommencer : on a dû refaire toute l'appli, backend et frontend compris (le backend était géré par une autre équipe).

Résultat : des mois de perdus pour le client :

- 1 à 3 mois à monter une version foireuse

- 3 mois à **essayer de faire quelque chose avec** avant de se rendre compte que c'était voué à l'échec

- Plusieurs mois ensuite à tout refaire de zéro

- 4 employés (au moins) payés sur une version **à jeter** : le premier développeur, la maquettiste, l'intégrateur CSS et moi.


## Conclusion

Donc non, la réalité du code pourri, c'est surtout de **gros retards**, la **multiplication des frais**, des **employés lassés** de refaire le même projet (et qui finissent parfois par s'en aller), et des clients qui **doutent** de leurs prestataires.

Moralité : **allez vite, mais bien**. Pas besoin de tout optimiser dès le départ, mais une bonne structure permet de **ne pas avoir à tout recommencer de zéro**...

Ce message s'adresse également aux **clients** : à vouloir aller **trop vite**, vous risquez d'y **perdre très gros**.


Ou comment perdre beaucoup de temps et d'argent en croyant en gagner.

Bâcler le code pour aller plus vite ?


>  – T'as pas l'air d'aller bien aujourd'hui...  
– Je dois écrire un article la dernière version de **NextJS**.  
– Les gens en ont déjà parlé, ça a l'air super.  
– Oui... mais moi, **je l'ai essayé**.  
– Tu as **testé un truc avant d'en parler** ?!  
– ...  
– Hérétique...


## J'aime NextJS

J'utilise **NextJS** au quotidien. C'est un superbe framework que je ne regrette pas d'avoir intégré à mes outils.

Il permet de démarrer rapidement un site de type NodeJS/ReactJS sans devoir se soucier de mettre en place un routeur frontend ou un serveur backend, et le tout **dans une seule application**.

Il gère aussi des choses sympa comme le multi-langue, le chargement intelligent des images...


## La hype

Comme moi, vous avez dû entendre parler de **la version 13** sortie récemment, avec conférence, grosses annonces, vidéos, tutoriaux, etc...

Comme moi, vous avez dû vous dire "Waouh ! C'est trop bien !"

> "Waouh ! C'est trop bien !"  
— Un développeur enthousiaste

Et logiquement, je me suis dit "_Tiens, je vais adapter un de mes projets sur cette version !_"


## Le test

Faisons un petit tour des fonctionnalités de NextJS 13 :

![Fonctionnalités de NextJS 13](/images/blog/posts/nextjs13-features.jpg)


### 1. Le répertoire `app` (et les composants serveur)

C'est **LA** grosse nouveauté de cette version. NextJS nécessitait jusqu'ici de mettre des fichiers `.js`/`.jsx` dans un répertoire `pages`, et assurait le **routage** en fonction de l'architecture dans ce répertoire.

La version 13 introduit un nouveau dossier `app` qui remplit le même rôle, mais plus besoin de séparer les fichiers des pages de ceux des composants de cette même page : on peut **tout mettre ensemble**. NextJS n'utilisera que les fichiers `page.js` pour déterminer le routage.

De plus, les composants peuvent **attendre le chargement de données** (fini les fonctions _getServerSideProps_ & cie), et gèrent l'affichage du chargement et des erreurs par des fichiers dédiés.

**Gros changement donc**, qui va demander de revoir toute l'architecture des applis NextJS, et...

<div style="text-align: center; margin: 3rem 0; font-size: 2em;"><b>ÇA MARCHE PAS.</b></div>

Ce n'est pas une blague. Le truc sur lequel ils ont passé des heures en présentation ne fonctionne pas. **On perd des fonctionnalités majeures** comme l'internationalisation du site. La répartition serveur/client **n'est pas stable**, et ce n'est que le début...

En même temps, pour utiliser `app`, il a fallu que je le précise dans la configuration. NextJS 13 utilise `pages` par défaut. Et c'est là que je commence à réaliser **un petit détail**...

![Fonctionnalités de NextJS 13](/images/blog/posts/nextjs13-features-beta.jpg)

Des souvenirs commencent à **remonter** de précédentes expériences sur d'autres logiciels...

![Syndrome de stress post-traumatique](/images/blog/posts/rambo-cry.jpg)
<div style="text-align: center; font-size: 0.85em;"><i>Je la voulais pas cette beta de version...</i></div>

"_Bon_", me dis-je, "_c'est une grosse modification, c'est normal... On va tester autre chose._"


### 2. Turbopack (pour aller plus vite)

Apparemment, le nouveau **Turbopack** est censé faire aller le site **700 fois plus vite**. C'est dingue quand on y pense et...

<div style="text-align: center; margin: 3rem 0; font-size: 2em;"><b>ÇA MARCHE PAS NON PLUS.</b></div>

Le truc crashe au moins une fois par heure.

> Un crash ? Du framework ?!

Oui oui, **le framework tout entier plante**. Il faut redémarrer toute l'appli. Je t'en ficherai de l'_expérience développeur_.

C'est ma faute aussi, il y avait marqué **alpha**...


### 3. Nouveau composant Image

Rien à redire. Le composant **Image** de NextJS est toujours aussi énervant à utiliser (il faut un conteneur), mais il irait apparemment plus vite. Super.

> – Il ne plante pas ?  
– Quand même, pas sur une fonctionnalité minuscule comme ça... ?


### 4. Gestion interne des polices d'écritures

Assez pratique suite au tollé que s'est pris **Google Fonts** cette année avec le traçage des visiteurs : NextJS propose d'installer et d'**héberger directement les fichiers nécessaires aux polices utilisées**.

C'est un peu embêtant à mettre en place parce qu'il faut passer par le JavaScript pour...

<div style="text-align: center; margin: 3rem 0; font-size: 2em;"><b>ÇA MARCHE PAS FRÈRE.</b></div>

MÊME ÇA ILS L'ONT PLANTÉ ! Une simple petite fonctionnalité accessoire, et... **"beta" ?!**

> Arrête, tu te fais du mal...


### 5. Amélioration de la balise de lien

Bon ben un truc qui marche : plus besoin d'écrire la balise `<a>` dans la balise `<Link>`.

![Youpi](/images/blog/posts/yippee.gif)
<div style="text-align: center; font-size: 0.85em;"><i>La joie m'inonde.</i></div>


## Conclusion : c'est une blague ?

Je râle, mais pour de bonnes raisons : NextJS est un produit **stable**. Il est utilisé en **production** par des sites accessibles au public.

On nous sort une version **majeure** : _13_, pas _13 beta_. Et **plus de la moitié des nouveautés sont foirées**.

Voyez plutôt :
![Fonctionnalités de NextJS 13 (corrigées)](/images/blog/posts/nextjs13-features-fixed.jpg)

> Mais doux rêveur, n'as-tu point vu qu'il y avait marqué beta ?

**Non.**

Parce que quand je vais sur [le site officiel](https://nextjs.org), voici ce qu'on y voit :

![Page d'accueil NextJS](/images/blog/posts/nextjs13-homepage-1.jpg)
![Page d'accueil NextJS](/images/blog/posts/nextjs13-homepage-2.jpg)

- Seule la version 13 est affichée
- Nulle part il n'est mentionné de **"beta"**.
- ce sont les fonctionnalités **buggées** qu'on met en avant sur la page produit : répertoire `app`, turbopack, next/font.

![Page d'accueil NextJS](/images/blog/posts/nextjs13-homepage-3.jpg)
<div style="text-align: center; font-size: 0.85em;"><i>"For production". LOL.</i></div>

Il y a clairement un problème de **communication**.

> – Du coup, quoi de neuf dans NextJS 13 ?  
– Ben tu écris `<Link>truc</Link>` au lieu de `<Link><a>truc</a></Link>`.  

![Youpi](/images/blog/posts/yippee.gif)
<div style="text-align: center; font-size: 0.85em;"><i>Trop bien cette version !</i></div>

À bientôt pour un article plus relax (j'espère).

... et ça ne s'est pas très bien passé.

J'ai essayé NextJS 13...


_S'il y a une chose dont l'écosystème JavaScript ne manque pas, ce sont bien les **frameworks**._

> Et on commence par la belle grosse phrase cliché... Mais encore ?

(Sérieux je ne trouvais rien d'autre...)

Je travaille avec **React** depuis 2018, et j'ai ajouté **NextJS** à mes outils en 2020. C'était la suite logique. J'ai pu expérimenter d'autres frameworks, notamment **VueJS**, mais je ne voyais pas l'intérêt de cumuler deux outils équivalents tant dans leur utilité que dans le temps nécessaire à investir pour les maîtriser.

Ma politique est donc la suivante : si l'outil fonctionne, et qu'il y a suffisamment d'entreprises qui y font appel (et donc suffisamment d'offres d'emploi), inutile de s'éparpiller. Surtout quand on a au moins deux nouveaux frameworks par an...

[![How standards proliferate](https://imgs.xkcd.com/comics/standards.png)](https://xkcd.com/927/)

Quand **Svelte** a débarqué dans l'écosystème JavaScript, j'ai été interpellé par la simplicité apparente du code. J'ai donc gardé ce framework quelque part en tête, me disant que je m'y essaierai bien un jour.

**Un enfant et cinq déménagements plus tard**, c'est enfin arrivé.


## Comment tout a basculé

Il y a quelques jours, je voulais créer un petit outil pour un projet personnel mono-page (Single Page App). Je crée un projet sur React, et je commence à mettre en place les composants.

Et c'est en créant la première variable d'état que je bloque :

```js
import { useState } from "react";

// ...

const [truc, setTruc] = useState(0);
```

Je me souviens d'un élève qui me demandait la veille ce que je pensais du framework **Svelte**. J'avais expliqué à quel point le code était connu pour être **concis**, et j'avais montré quelques exemples glanés sur un moteur de recherche.

Et dans Svelte, l'équivalent de la ligne de code ci-dessus, c'est ça :

```js
let truc = 0;
```

Pas de fonction `useState`, pas de tableau, pas de fonction de changement `setTruc`. **Juste une variable**.

J'en ai eu ras-le-bol. Je me souviens avoir supprimé le projet React sur-le-champ, et commencé à **installer Svelte**.

La suite de l'article est un post LinkedIn retravaillé qui communique mon ressenti après deux jours d'utilisation.

> Deux jours ?! Seulement ?

Oui, et c'est déjà assez pour remarquer certaines choses.


## 1/ Une mise en place rapide

Pour créer un **composant**, on tape du html dans un fichier `.svelte`, et c'est bon.

```html
<p>Coucou</p>

<p>Ça va ?</p>

<p>Tranquille. Je teste <b>Svelte</b>.</p>
```

- Pas besoin d'**englober le contenu du composant** dans une balise unique ou un fragment React (`<>...</>`).

- Pas besoin de créer et d'**exporter** une **fonction** JavaScript : les composants Svelte **se reconnaissent entre eux** ! Il suffit juste de les importer où on veut.

En gros, en quelques secondes, vous avez un composant.

Même la phase d'**initialisation de projet** avec npm est l'affaire de **quelques secondes**... Bref, très rapide !


## 2/ Un code clair
- Le composant (fichier .svelte) est du simple html (voir section précédente).

- Une balise `<script>` suffit pour les variables et les fonctions :

```html
<script>
    let truc = 0;

    function increment() {
        truc += 1;
    }
</script>

<p>Truc est égal à {truc}</p>

<button on:click={increment}>Augmenter</button>
```

- Une balise `<style>` contient le CSS du composant.

```html
<h1>Je vois rouge</h1>

<style>
    h1 {
        color: red;
    }
</style>
```

> C'est comme VueJS en fait...

![C'est comme chez nous !](/images/blog/posts/fr/rabbi-jacob-c-est-comme-chez-nous.png)

(Oui.)

Et ça a ses avantages : pas besoin de fichier supplémentaire (vous pouvez, bien entendu), et... c'est **du vrai CSS**. Pas **du JS qui essaie de passer pour du CSS**, ou un [**_template literal_**](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Template_literals).

- Il existe des balises très simples pour **l'affichage conditionnel**. 

```jsx
{#if loading === true}
    <Loader />
{:else if error !== null}
    <Error error={error} />
{:else}
    <h1>Bienvenue, mécréants !</h1>
{/if}
```

- Et **boucler une liste** n'est pas aussi lourd que sur React qui oblige à utiliser `Array.map()` (et l'attribut _key_...).

```jsx
<div class="list">
    {#each userList as user}
        <div class="user-row">{user.name}</div>
    {/each}
</div>
```

> C'est moche...

(Oui, mais on s'habitue. Ça aurait pu être pire...)


## 3/ Un travail plus rapide

- Pas de **boilerplate verbeux**. Besoin d'une variable réactive ? Pas besoin de taper tout un useState à la React : `let truc = ...` dans la balise `<script>` suffit.

```html
<script>
    let truc = 0; // Ceci est une variable d'état
</script>

<p>Truc est égal à {truc}</p>
```

- Besoin d'une **_prop_** (variable modifiable par un composant parent) ? Ajoutez `export` devant et ça fera l'affaire.

```html
<script>
    export let truc = 0; // Ceci est une variable de prop
</script>

<p>Truc est égal à {truc}</p>
```


## 4/ Des fonctionnalités sympa

- On a accès à des **variables globales** appelées **_stores_**. Il suffit de les **importer** et on peut les afficher tout simplement avec le signe $, ou effectuer des changements avec des méthodes très claires comme `truc.set()` ou `truc.update()`.

- On peut gérer les **effets de bord** (`useEffect` dans React) avec `$:` qui se place avant une ligne de code.

```html
<script>
    let truc = 0;
    
    // affiche la variable dans la console chaque fois qu'elle change
    $: console.log(truc)
</script>
```

Pour les utilisateurs de React, vous remarquerez qu'on n'a pas besoin de préciser les **dépendances** : Svelte comprend ce que vous essayez de faire (_`truc` est impliqué ? pigé_) !


## Le mot de la fin

En temps normal, deux jours serait considéré très peu pour avoir un avis éclairé, mais **la vitesse d'adaptation était fulgurante**. Svelte est tellement simple d'utilisation !

Il me reste encore à voir comment fonctionne le fetching, le SSR, etc... mais je peux déjà affirmer que côté client sur un projet statique, ce framework m'a **conquis**.

J'ai eu quelques soucis mais c'était parce que je débute et il m'est arrivé de partir en **antipatterns**...

> Antipattern ?!

(Les trucs à ne pas faire.)

En antipatterns donc, à cause d'habitudes prises sur d'autres frameworks. En fait, je perds plus de temps sur Svelte **à cause des réflexes pris sur d'autres frameworks**... 

Une fois les notions bien comprises, coder avec ce framework est du pur plaisir : on passe vraiment **moins de temps à définir les choses** qu'à tout simplement **coder le fonctionnement de l'appli**.


## Pour aller plus loin

Je vous invite à visiter ce lien pour en voir plus sur la comparaison Svelte/React, avec plein d'exemples (outil fourni par **Mathieu Schimmerling**) :
- [Component party](https://component-party.dev)

Et vous pouvez aussi consulter mon post à chaud, notamment **ce que d'autres développeurs pensent de Svelte** en commentaires :
- [Post LinkedIn](https://www.linkedin.com/posts/daniel-orchanian_javascript-react-svelte-activity-6972888781989236736-K6Ll?utm_source=share&utm_medium=member_desktop)

À la prochaine !

> Dans six mois ?

(...)

_Crédits photo : [XKCD](https://xkcd.com/927/)_

Suite à un petit ras-le-bol avec React, j'ai essayé Svelte et j'en suis bien heureux.

Svelte - Premières impressions


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 :
- [Vanilla JS](http://vanilla-js.com/)


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

Blog

Articles récents