Frameworks JavaScript : En avez-vous réellement besoin ?

Frameworks JavaScript : En avez-vous réellement besoin ?
3.3 (65%) 4 votes

Console Google Chrome onglet Network

Console Google Chrome project Symfony 4

A l’heure où tout le monde utilise des frameworks JS pour afficher un « hello world! », il convient de se demander si tout ça est réellement nécessaire… J’ai des amis développeurs qui savent parfaitement exécuter des requêtes POST ou GET via différents frameworks front, mais ne connaissent même pas la fonction native XmlHttpRequest.

Alors sans vouloir faire le rabat-joie, ce serait cool d’arrêter de faire des npm install à toutes les sauces et d’installer Angular et compagnie sous prétexte que ce sont des nouvelles technos.

La nouveauté tue la performance

J’ai récemment lu un article plutôt sympa sur Medium : « 3 erreurs de développement JavaScript qui nuisent à la performance » (c’est en anglais, mais c’est relativement court). La nouvelle syntaxe ES6 est 10 fois plus longue que la bonne vieille syntaxe… Comme quoi, l’évolution.

En parlant de ça, la version 5.7 de Laravel est 9% moins performante que la version 5.6. On marche sur la tête.

Je n’ai rien contre la nouveauté, au contraire. Je pense qu’il faut parfois savoir sacrifier la performance au détriment de la qualité du code (développement en objet, utilisation d’ORM…).

Mais ce qui est nouveau n’est pas forcément plus performant, alors qu’il le devrait, en toute logique.

Quand utiliser un framework front-end JavaScript ?

Je pense que c’est une bonne question, et on peut donner deux axes pour y répondre :

  • Quel est le type de projet web que vous réalisez ?
  • Pourquoi en auriez-vous besoin ?

Pour notre nouvelle société avec un ami, j’ai décidé de partir sur PHP pour créer notre nouveau projet. D’une part parce-que c’est performant, d’autre part parce-que Symfony 4 a fait de gros effort sur la performance (+200% par rapport à la version 3).

Ce projet va comporter pas mal de contenu, PHP est donc parfait pour cela.

Quel est le type de projet bon pour JavaScript ?

Posons-nous la question inverse, dans quels cas n’en n’a-t-on pas besoin ?

  • Un site d’actualité
  • Un site de présentation d’entreprise
  • Un site simple et léger (quelques formulaires, un jolie design…)

En fait, tout ce qui propose plus de contenu que de fonctionnalités.

Notons une chose :

Je ne sais toujours pas si les vues JavaScript ne sont pas un problème pour le SEO.

Voir cet article.

Dans quels cas aurions-nous besoin de JavaScript ?

  • Un site riche en interaction (une webapp complexe par nature)
  • Un site avec de l’interaction, même minime (pourquoi pas)
  • Grosso-modo peu de sites internet

En fait, tout ce qui propose plus de fonctionnalités que de contenu à proprement parler.

Je vous conseille fortement d’installer Wappalyzer. C’est une petite extension qui vous permet de connaître les technos qu’utilisent un site quand vous naviguez dessus.

Pour quelles utilisations utiliser JavaScript ?

  • Votre site est complexe : il y a de l’interaction, un jeu de données complexe, des données métiers, des micro-services…
  • Votre deadline est courte, pas le temps faire un truc un peu custom, VueJS rempli 25% de vos exigences, go. On a pas toujours le choix face au client !

Un exemple d’utilisation parfaite de JavaScript

Imaginons que vous ayez une partie « riche » en datas, comme un système de filtre de produits. Prenons ce site comme exemple, où j’ai acheté mon café tout à l’heure :

https://www.ekita-cafe.com/cafe-en-grains-c102x440309

Ekita Café page de produits - café en grain

Système de filtre de produits Ekita-Café

A l’heure où j’écris ces lignes, à chaque clic sur un élément de la partie de gauche nous recharge la page en appliquant un filtre (sans changer l’URL).

  • C’est mauvais pour l’expérience utilisateur ;
  • C’est loin d’être rapide ;
  • On recharge tout le DOM en rafraîchissant la page, alors que seule la zone de contenu devrait l’être.

Cette page aurait bien besoin de JavaScript !

Pourquoi utiliser un framework JS et ne pas tout faire à la main ?

Je me suis également posé cette question, pour moi la réponse tient en un mot : VDOM. Le DOM virtuel est une couche abstraite qui permet de ne mettre à jour qu’un nœud dans l’arbre à la place de tout l’arbre si jamais vous utilisez simplement JavaScript.

C’est pas très bien expliqué soit dit en passant, alors Google vous aidera mieux que moi.

Tous les gros frameworks modernes offrent la possibilité d’utiliser le VDOM / Shadow DOM or whatever. Le principal c’est de ne pas recharger tout le DOM alors que l’on a seulement 5% de ce dernier à changer.

Si jamais comme moi vous courrez à la performance (ou tout simplement vous trouvez ça stupide d’avoir un gros framework pour l’utiliser à 10% de ses capacités), je vous propose de jeter un œil à ces deux sites :

Ce sont des outils JS hyper light et ces deux-là proposent un VDOM. Si jamais seule une page de votre site est riche en interaction, pas besoin d’installer React, Angular ou autre chose, tout est déjà là !

Conclusion

J’aimerais juste sensibiliser mes amis développeurs au sujet de la performance à une heure ou Chrome prend 2GO de RAM pour 10 onglets ouverts… Ce qui était impensable il y 10 ans, on a largement abusé des ressources mises à notre disposition, pour le pire.

A une heure où on pense à minifier le HTML, le CSS et le JS ; à utiliser GZIP et à installer HTTP/2. On oublie aussi un peu que si on avait pas 5mo de data à renvoyer sur la page, on aurait moins besoin de tout cela.

Imaginez la puissance de votre application, si jamais en plus de ces outils, les données à envoyer au navigateur ne faisait que 0.5mo…

L’idée, c’est d’arrêter d’inclure des libs et des machins pour faire 3 trucs et demi alors que le natif fonctionne très bien. Utiliser une lib JavaScript pour lazyloader des images c’est bien, installer Angular pour lazyloader des images, c’est nul.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.