Ten years later, être développeur full stack JS en 2024

“Ouep, ça passe vite, hein…”

C’est ce que je me suis dit quand je me suis mis en tête de bloguer à nouveau, et que j’ai vu la date des derniers articles que j’avais publiés.

10 ans.

Diantre.

Entre les emplois salariés, les formations, les projets personnels, le démarrage de mon activité en tant que freelance, les projets clients, un passage en société, les treks et autres cross triathlons, faire de la soupe, sortir le chien … ouep, ça passe vite, hein…

Pour ce come back fracassant, j’ai décidé d’observer l’évolution technique de ces 10 dernières années, et l’impact sur le métier de développeur full stack Javascript.

Dans les grandes lignes, c’est pas un livre non plus.

Tout est dans le titre. Et dans ce fabuleux détournement graphique offert par la maison. 28 jours plus tard, en mode langage de programmation. En 10 ans, Javascript a tout avalé sur son passage.

• Consommer du web en 2024
• Boîte à outils
  • Editeurs graphiques
  • IDE’s
  • Clients HTTP
  • Gestionnaires de paquets
  • Outils de build
  • Versionnement
  • IA et pair programming
• Infrastructures
  • Containerisation
  • Cloud
  • Devops et pipelines CI/CD
• Architectures
  • RESTFul API’s & GraphQL
  • Micros
• Back on the stack
  • HTML5
  • CSS3
    • API’s Flexbox et Grid
    • Préprocesseurs
    • Tailwind
    • CSSinJS
    • Vanilla CSS en 2024
  • Javascript
    • Ecmascript
    • jQuery
    • Typescript, le Javascript des bons gens
    • Frameworks front-end
      • Les poids lourds
        • React
        • Vue
        • Angular
      • Les outsiders
        • Svelte
        • Solid
        • Alpine
        • Htmx
  • Node.js
    • Frameworks back-end
      • Express
      • Nest
    • Deno is the new node, oui mais…
  • Persistance et performances NoSQL
  • Tester dans l’écosystème Javascript
• Juste à côté…
• Ten years further

Consommer du web en 2024

3, 4, 5 et bientôt 6G, fibre optique. En 10 ans, les opérateurs du monde entier se sont déployés de façon constante. Quantitativement et qualitativement, en 2024 le réseau offre des performances d’excellente qualité.

La fracture numérique se réduit au fil du temps, du moins dans les pays industrialisés, et de plus en plus d’êtres humains sont connectés. Suivant la loi de l’offre et de la demande, les opérateurs proposent aujourd’hui des abonnements au trafic illimité pour des prix très abordables.

A côté de ça, la loi de Moore se vérifie régulièrement: les ressources matérielles croissent de manière exponentielle.  Sur le plan hardware, les smartphones actuels sont équipés comme les laptops d’il y a 10 ans.

Il est courant en 2024 de charger des Mo de données pour une page web, même en version mobile. D’après le site wp-rocket, spécialisé dans le caching de sites WordPress, le poids moyen d’une page web en version mobile serait passé de 1223.7Kb (+-1.2Mb) en mai 2017 à 2037.3kb (+-2.0Mb) en février 2023.

© https://wp-rocket.me/

Le constat est là, même si les chiffres de wp-rocket sont pour le moins optimistes. D’après mon expérience et en fonction du produit final, le poids total d’une page web en 2024 peut vite monter à plusieurs dizaines de Mo.

Ce n’est pas dingue pour la planète, et c’est quelque chose que le développeur doit avoir à l’oeil, tant en front qu’en back. C’est un enjeu crucial lié aux performances, alors pourquoi se priver de ces petits plaisirs d’optimisations si ça peut sauver des arbres ?

En 2024 plus que jamais, il faudra penser store, cache, BFF, SSR, requêtes HTTP, optimisations, lazy loading…

Pour aller plus loin sur cette problématique particulière, je vous passe le lien de l’excellent article de Jamie Indigo et Dave Smart, laconiquement intitulé Page Weight.

Enfin, je n’ai pas d’actions chez eux, mais voici en bonus un lien sympa vers EcoIndex, qui permet de lancer un scan pour attribuer un score écologique à votre site web.

Boîte à outils

Editeurs graphiques

En tant que développeur, en mission – taylorisme oblige, je ne suis pas souvent amené à en utiliser.  Sur les sides projects, par contre, c’est régulier. Je glisse donc ça là, en passant.

Pour faire une découpe, pour corriger un élément graphique voire pour en créer un, ou encore pour dériver l’affiche d’un film bien connu, Photoshop reste un outil que tout développeur front-end devrait maîtriser au moins en surface.

Pour le prototypage, trois softs se tirent la bourre: Adobe XD, Figma et InVision.

IDE’s

Pas de changements énormes à ce niveau: les acteurs en place il y a dix ans ont conforté leurs positions.  Jetbrains est leader avec un soft comme WebStorm.

A la même table, on trouve Visual Studio Code, extrêmement efficace.

Et derrière ces grosses machines, les mêmes “marginaux” qu’il y a dix ans, à savoir Sublime Text, Atom, Netbeans et ce bon vieux Notepad (le premier que j’installe, soit-dit en passant).

Et des tas d’autres.

Clients HTTP

Ils se sont fortement développés avec l’avènement des API RESTfull et autres services web, et font partie intégrante du quotidien de développeur.

On en trouve pléthore, parmi les principaux:

• Postman
• Insomnia
• Httpie (avec de l’IA dedans)
• Ce bon vieux cURL

Gestionnaires de paquets

Bower est mort, vive Bower. Déjà mourrant en 2014, il existe toujours mais il n’est plus utilisé, à moins de ne pas avoir d’autre choix sur un projet legacy.

En 2016 apparaît Yarn, un gestionnaire de paquets basé sur le registre NPM. Il fonctionne un rien différemment et offre de meilleures performances à l’installation. Bien que prometteur, Yarn ne s’est pas vraiment imposé comme le NPM killer qui avait été annoncé.

A côté, on trouve aujourd’hui pNPM.  Un autre gestionnaire de paquets. Encore un, oui. Plus rapide, et plus sécurisé que NPM. Adopté par pas mal de grands comptes, il reste cependant peu répandu dans la communauté.

Et donc, en 2024, malgré des désavantages certains par rapport à Yarn ou pNPM, et parce que c’est le gestionnaire natif de l’écosystème node, c’est NPM qui domine, que ce soit via la commande npm ou npx.

My project after installing all NPM dependencies pic.twitter.com/JFw76zon5I

— Gregor (@gregocoder) September 30, 2023

Outils de build

Principalement utilisés en tant que gestionnaires de tâches, Grunt et Gulp sont encore dans la place, en mode zombie. Hypes jusqu’à la fin des années 2010-2020, ils ne sont plus mis à jour et, à part pour travailler sur des projets legacy,  jusqu’il y a peu, je ne voyais plus trop l’intérêt de démarrer quelque chose avec ces deux outils en 2024. Mais ça dépend de votre workflow, et ça peut encore rendre service en développement pour builder from scratch.

Un temps utilisé pour bundler des modules node pour le front, Browserify a lentement disparu des radars.

En 2024 le vainqueur est … Webpack, qui est partout en cycle de développement dès qu’il s’agit de builder du front-end moderne.

Source: Best JS build tools and task runners

A côté de Webpack, il est quand même intéressant de mentionner des outils comme Parcel, Rollup, Vite.js, Lerna, Turborepo, Storybook ou encore, dans une moindre mesure, Bit. Ces outils de build trouvent leur place dans des contextes bien particuliers qui dépassent le sujet de l’article, mais méritent assurément que l’on s’y intéresse. Et bien évidemment, le toujours utile Babel.

Versionnement

Là, c’est simple: git écrase toute la concurrence. Omniprésent, il a complètement éclipsé les autres systèmes de versionnement qui étaient encore présents en 2014, comme Apache Subversion.

IA et pair programming

C’est l’un des principaux changements dans nos vies de développeurs. L’IA, on l’a vue arriver, mais on l’a quand même prise en pleine face. Certains annoncent que son avènement va tuer le métier de développeur.

sounds like clickbait but I 100% agree with him, just to be on the safe side. you have 5 years (let’s say 7-10 max) to do something with your life before changing professions. please spend them on changing your terminal and tweaking your editor theme and arguing about vim 😘 pic.twitter.com/WS7vwewewR

— kitze 🚀 (@thekitze) December 14, 2023

Je n’y crois pas vraiment, du moins pas à moyen terme. Il est par contre évident que l’intelligence artificielle va devenir, entre autres, un outil de développement à part entière.

C’est ainsi que Microsoft propose depuis plusieurs mois déjà, une intégration de Github Copilot en tant qu’outil de pair programming.

Infrastructures

Virtualisation et containerisation

En 2014, ça bosse pas mal avec des machines virtuelles. Rien de mal, on utilise encore des VM en 2024. Docker pointait le bout de son nez, mais c’était marginal.

Aujourd’hui, Docker est dans la place. Le déploiement et l’orchestration d’applications dans des containers dans le clout, c’est le quotidien.

Geek humor. Or is it? pic.twitter.com/KxIqBcWq10

— José Paumard (@JosePaumard) November 8, 2022

Gros sujet donc, et des skills que le développeur full stack doit intégrer – en partie, parce que ça reste quand même plutôt du devops.

Bonus: le concurrent de Docker est bien installé 😉

Cloud

2014, le cloud est balbutiant. Microsoft Azure, AWS et GCP sont là, mais pas encore adoptés par les entreprises. On est plutôt sur une bonne vieille architecture client/serveur, la plupart du temps.

Well deserved pic.twitter.com/pEu6QkYLqh

— Simpsons Against DevOps (@SimpsonsOps) September 11, 2020

Aujourd’hui, les architectures distribuées, les containers Docker, l’orchestration, c’est courant.

Est-ce qu’en 2024 tout le monde est dans le Cloud, avec du serverless ou des containers Docker qui tournent sous Kubernetes ?

Non. Sur les petits projets, il n’est pas nécessaire d’aller dans le cloud, à moins d’avoir des besoins spécifiques auxquels peuvent répondre les fournisseurs.

Cela dit, les moyens et grands comptes, eux, y sont, ou sont en train de faire le pas, à juste titre.

Devops et pipelines CI / CD

La gestion des déploiements en 2014, c’est marginal et réservé aux grands comptes ou aux entreprises IT.  On ne parle pas encore de devops comme c’est le cas aujourd’hui.

Jenkins est là depuis plusieurs années, mais n’est pas encore répandu.

Vers 2016, évolution sur les stacks JS avec PM2, qui permet d’effectuer une release depuis une machine locale vers une machine distante, en CLI via SSH. Et de faire du monitoring.

A la même époque, la révolution est en marche et commencent à se démocratiser les services dits de CI/CD tels que Gitlab CI, Azure Devops, Github actions, Travis-CI, ou encore CircleCI.

En tant que SaaS ou installés “on premise”, ces services ont changé la manière de gérer les flux de déploiement, en améliorant considérablement la flexibilité et l’efficacité des releases.

Impossible de passer à côté.

Architectures

RESTFul API’s & GraphQL

Someone shouted “GraphQL is a better REST” and then this happened pic.twitter.com/eHO36cUAit

— Marc-André Giroux (@__xuorig__) September 9, 2020

Objets connectés, services web, API RESTful et GraphQL, c’est l’ABC du développeur en 2024.

Les API RESTful se sont imposées pour les communications client / serveur, et serveur / serveur, en s’appuyant la plupart du temps sur les formats JSON et XML.

GraphQL est une technologie créée par Facebook pour solutionner les problèmes de performances liés à la bande passante. L’idée est simple: requêter ce qu’on veut, pour obtenir ce qu’on veut.  Ce n’est pas un moteur de bases de données, mais une couche de requête client / serveur.

REST API vs. GraphQL

When it comes to API design, REST and GraphQL each have their own strengths and weaknesses.

REST
– Uses standard HTTP methods like GET, POST, PUT, DELETE for CRUD operations.
– Works well when you need simple, uniform interfaces between separate… pic.twitter.com/lUgCEfECip

— Alex Xu (@alexxubyte) January 15, 2024

Les API RESTful sont là pour durer. Quant à GraphQL, de paire avec les enjeux de performances et d’empreinte carbone, ça devrait continuer à se développer et intéresser les grands comptes en 2024.

Micros

Fin de décénie 2010-2020, aidés par la démocratisation de la containerisation et du serverless, apparaissent les principes d’architectures “micro”, apliqués côté back-end as microservices, et côté front-end as microfrontends.

L’approche micro a été évangelisée comme la solution à tous les problèmes de scalabilité, d’intégrité de données, et de maintenabilité.

C’est à relativiser, parce que ça demande des ressources humaines et matérielles, ça introduit une (grosse) complexité technique et, simplement, ça ne répond pas à tous les besoins. Ce peut être le bazooka qui tue la mouche.

En tant que développeur en 2024, c’est une approche excitante, fun et solide. C’est là, vous y toucherez probablement à un moment ou l’autre.

MOM’s

Non, ça n’a rien à voir avec les MILF’s.

On parle d’architecture Message Oriented Middleware pour désigner des systèmes au sein desquels les différents composants communiquent les uns avec les autres, en utilisant des messages.

C’est utile sur les grosses infrastructures qui embarquent des stacks hétérogènes. Et sur les architectures distribuées / microservices. Car oui, à partir du moment où on découpe les API’s en microservices, très vite ça devient compliqué. Parce que, bien qu’on fasse du NoSQL, il y a des relations entre les données.  Hé ouais mon pote.

Du coup, Kafka, RabbitMQ, ou pour les cloudeux Pub / Sub et SQS.

Un article sympa de Rayed Benbrahim, sur l’architecture MOM.

Tout comme l’architecture microservices, c’est là, c’est fun, ça marche fort, et c’est plutôt pour les grands comptes / gros projets.

Back on the stack

Retour à des choses plus terre à terre.

La base de la stack n’a pas changé: HTML5, CSS3 et Javascript – la sainte trinité du web.

Ajoutez un runtime node.js, un écosystème NPM velu, velu, des frameworks à la pelle, un peu de virtualisation, quelques containers, poussez tout ça dans le cloud à grands coups de CI/CD et vous obtenez la stack de la mort.

HTML5

On ne s’en rend pas toujours compte, mais HTML5 c’est bien plus qu’une spécification qui définit quelques balises.

Sortie officiellement en 2014, la dernière mouture de la spécification HTML a, notamment, mis un terme à quelques hold-ups propriétaires comme Adobe Flash ou Microsoft Silverlight, en introduisant de nouveaux élements tels que canvas, video et audio.

Sémantiquement, on a également vu apparaître des éléments intéressants comme section, article, aside, header, footer ou encore, nav.

Et des tas d’attributs favorisant l’interactivité avec l’utilisateur.

Ce n’est pas tout: moult API majeures ont également été introduites progressivement par la spécification, participant à l’essor de ce qu’on a appelé à l’époque, le web 2.0.

Parmi les principales:

• Drag’ and drop
• File
• Geolocation
• IndexDB
• Storage
• Websockets
• Webstorage
• Webworkers
• …

Comme toujours, ça a pris du temps. C’est aujourd’hui une spécification mature, relativement bien supportée et qui offre des possibilités énormes.

La base.

CSS3

CSS, autre brique essentielle dans le développement web. Bien présent en 2014 dans sa troisième mouture, la plupart des API CSS3 n’étaient cependant pas encore implémentées par les navigateurs.

Aujourd’hui, à ce niveau là, c’est Byzance: la spécification est très riche, bien implémentée par la grande majorité des navigateurs, il y a des tas de frameworks qui amènent une base de travail tout prête à l’emploi, avec ou sans préprocesseurs.

Tellement que … cette profusion de surcouches m’amènent à croire que c’est une partie du développement dont la complexité est sous-estimée. Comme si on cherchait encore la meilleure manière de travailler simplement avec CSS.

C’est fou ce qu’on peut faire en termes d’UX juste avec un peu de CSS…

Here’s what I coded today, some fun little CSS ✨! pic.twitter.com/MnHsE4pHrT

— ˗ˏˋmewtru´ˎ˗ (@trunarla) September 21, 2023

Lien bonus de boomer, pour ceux qui ne connaissent pas: CSS Zen Garden est une source d’inspiration sympa lorsqu’il s’agit de comprendre le fonctionnement et la puissance de CSS.

La base aussi.

API’s Flexbox et GRID

En 2014, il faut avoir recours à des librairies tierces comme Bourbon, Susy ou Bootstrap pour bidouiller et mettre en place des positionnements en colonnes.

Ou, pour les plus audacieus d’entre-nous, il faut y aller à grands coups de float: left; de nth-child, de marges négatives, j’en passe et des meilleures. Certains n’en sont pas revenus.

Mais ça, c’était avant.

Evolutions CSS majeures implémentées progressivement au cours de ces dix dernières années, Flexbox et Grid Layout ont apporté une vraie plus-value au positionnement CSS natif.

Préprocesseurs

Faire du SASS, du LESS, du Stylus, c’était une bonne chose en 2014, ça l’est toujours en 2024 et ça le sera encore dans les années qui viennent, même si CSS tend de plus en plus à combler le gap avec les préprocesseurs.

Tailwind

Non, je ne vais pas m’étendre sur la plus belle régression évolution de ces 10 dernières années, aka tailwind.css, qui est tout de même une sacrée belle hérésie avancée dans notre travail, et qui ne divise d’ailleurs pas du tout la communauté.

Ce que je ne m’explique pas, c’est l’engouement qu’il y a derrière. La surcouche Tailwind apporte de la complexité inutile. Elle rend le code HTML absolument dégueulasse, tout en garantissant le fait que ce ne sera plus vraiment maintenable après, excepté si la configuration est hyper solide, ce qui revient à bien structurer ses fichiers SASS. Super.

Je ne dis pas que faire du CSS ou du SASS, c’est facile. Clairement, ça ne l’est pas. Cela demande beaucoup d’organisation, beaucoup de rigueur, une connaissance pointue de la spécification et du support dans les différents navigateurs. Entre autres.  Bien que le langage soit simple, c’est compliqué parce que de base, c’est complètement déstructuré.

Ce que je dis, c’est que Tailwind ne résout pas les problématiques qu’il prétend résoudre, et qu’au contraire, il en ajoute.

Enfin bref. J’argumenterai peut-être un jour en détail sur Tailwind, mais là j’ai pas le temps, j’ai piscine. 😀

En attendant, grosse hype autour de cette bouse techno – qui retombe un peu au profit de CSSinJS, mais qui devrait encore se poursuivre cette année.

CSSinJS

Je n’en ai pas implémenté suffisamment pour en avoir une opinion valable. De loin, ça a l’air de rassembler les mêmes défauts que Tailwind: pas maintenable, pas scalable.

Mais je peux me tromper, car le JS côté client va de toute façon très souvent interagir avec du CSS.

A creuser donc. Dans tous les cas c’est une tendance sérieuse en 2024, et des librairies comme Styled Components, PandaCSS, JSS ou encore Emotion ont le vent en poupe.

Vanilla CSS en 2024

Retour aux sources, 2024 va apporter des features vraiment intéressantes en Vanilla CSS:

• Nesting
• Sélecteurs nth-child complexes
• Fonctions trigonométriques
• Palettes de couleurs et fonction oklch()
• Mélange de couleurs avec color-mix()

Pour clôturer la section CSS, voilà un article intéressant et plutôt objectif de Lee Robinson: How I’m writing CSS in 2024

Javascript

En 2014, Javascript est en train de se faire une petite place au soleil. Les premiers frameworks JS font leurs premiers pas.

En 2024, c’est LE langage à la base de toutes les librairies modernes. Angular, React, Vue, et tous les autres frameworks, sont basés directement ou indirectement sur Javascript. Il est omniprésent en front-end, et se taille même une part en back-end avec les runtimes Node, Deno et Bun.

© https://devclass.com/

De l’aveu même de l’un de ses concepteurs, papa du petit JSON, Douglas Crockford, ce n’était pas l’idée à la base.

Ses remords ne vont pas y changer quoi que ce soit: Javascript est parti pour durer, il faudra faire avec ses forces et ses faiblesses.

NaN, les concaténations, les arrondis, les typeof, tout ça, c’est encore et toujours méchamment piégeux en vanilla en 2024.

A côté de ça, pour manipuler le DOM et interagir avec HTML / CSS, Javascript n’a pas (encore) de concurrence.

C’est la troisième brique de base de la sainte trinité du web. Incontournable.

EcmaScript

Le Javascript de 2024 n’a plus rien à voir avec le Javascript à papa.

Imports, classes, scopes, fonctions lambda, fonctions de tableaux, fonctions d’objets, data structures, fetch, formdata, promesses, async / await, template strings … La liste des évolutions de ces 10 dernières années est (très, très) longue.

Et ça va continuer avec ES2024 et des ajouts intéressants dans la spécification.

• Amélioration de la gestion des chaînes Unicode
• waitSync atomique
• Flag v pour les expressions régulières
• Top level await
• Opérateur pipeline |>
• Records et Tuples
• Décorateurs
• API Temporal

Entre les versions drafts et les implémentations effectives, ça prendra un peu de temps.

jQuery

En 2014, c’est l’âge d’or d’une des librairies les plus influentes de ces 20 dernières années:  jQuery.  C’est encore galère pour taper sur le DOM en Vanilla, et jQuery simplifie radicalement l’approche.

Certains l’annonçaient mort en 2017, force est de constater qu’en 2024, jQuery est toujours là. Et les gars ne comptent pas vraiment s’arrêter visiblement, puisqu’ils sortent une nouvelle version majeure.

Son taux d’intégration est encore très élevé, et on en rencontrera encore dans les années qui viennent.

Typescript, le Javascript des bons gens

Né en 2012, Typescript a mis quelques années avant de s’imposer dans la communauté des développeurs.

Comme souvent, il y deux écoles: il y en a des pour, et il y en a des contre.

Encore marginal en 2014, il a été adopté nativement par plusieurs frameworks, et est de plus en plus plébiscité par les entreprises, principalement pour la lisibilité et la robustesse introduites dans la codebase.

On aime ou on n’aime pas, mais c’est un choix solide, et c’est parti pour durer.

Frameworks front-end

Ah, les frameworks front-end Javascript. En 2014, c’est Knockout, Dojo, jQueryUI, Backbones, Angular.js ou Ember.js.

Aujourd’hui, ça pousse comme des champignons.

Les poids lourds

React

Bien que le plus plébiscité, React est en perte de vitesse dans les sondages de fin d’année.

Hyper léger, c’est parfait pour construire de petites SPA, PWA ou embedded applications – voire  des components – from scratch.

Parmi les features les plus intéressantes de React, il y a évidemment les performances, le Virtual DOM, le data binding et … la flexibilité.

Cette flexibilité peut aussi être un défaut. Avec React, dès lors que le projet devient plus conséquent, si on ne s’impose pas des conventions de codage strictes, la souplesse et la permissivité de la techno deviennent – selon moi, des inconvénients.

La gestion d’état est assurée de base via l’API Context. Ca marche, mais… c’est React opiniated, un peu fragile selon moi. Les performances sont moyennes et, surtout, ça devient le bordel quand le projet scale un peu trop. Il faut alors penser à jouer avec quelque chose de plus strucuré comme Redux.

Au niveau du rendu, React c’est JSX. J’ai eu beaucoup de mal au départ avec ça, mais force est de reconnaître que c’est efficace.

Supporté par Facebook, la communauté est énorme (217.000 stars sur Github, tout de même), la documentation est exceptionnelle. C’est et ça restera une valeur sûre en 2024.

Vue

Hyper polyvalent et faisant preuve d’excellentes performances, Vue rassemble un peu les qualités et les défauts de tous les frameworks javascript modernes.

C’est la brique idéale pour construire des SPA / PWA de petite, moyenne et, parce qu’il est nativement suffisamment structuré, de grande envergure.

Vue, c’est évidemment de la légèreté, des performances au-dessus de la moyenne, un virtual DOM, du data binding, de la flexibilité et … des computed properties.

La gestion d’état était historiquement assurée avec Vuex, devenu tout récemment Pinia. Je n’ai pas assez joué avec pour avoir un avis tranché, mais les benchmarks parlent pour eux.

Belle communauté (42.000 stars sur Github), excellente documentation également et, avantage par rapport à ses concurrents, la learning curve est plutôt simple / rapide. Apprendre Vue se fait relativement facilement.

Angular

En perte de vitesse ces dernières années, Angular n’est ni le meilleur taux de rétention, ni le premier choix des développeurs.  Cela s’explique par sa complexité, son côté très “opiniated”, et de manière générale par sa “lourdeur”.

Car oui, c’est le plus lourd des blockbuster, et le moins performant. Normal. Contrairement à ses concurrents, Angular embarque absolument toutes les briques de base au démarrage du projet. Tout y est, y compris ce dont vous n’avez pas besoin.

Angular répond parfaitement lorsqu’il s’agit de construire des applications robustes et conséquentes, et n’est pas adapté aux petits projets.

La gestion des états est assurée via la librairie RxJS. Pour une gestion de store complète, il faudra se tourner vers NgRx. Solide, mais pas simple à appréhender.

Supporté par Google, avec une grosse communauté (93.000 stars sur Github), la documentation est bien faite, mais la bête est tellement velue qu’apprendre sérieusement Angular ne se fait pas en une semaine, d’autant que les versions majeures fleurissent à raison d’une ou deux par an.

Les outsiders

A côté des trois grands, les plus sérieux outsiders en 2024 ont comme points communs la légèreté et les performances accrues.

Svelte

Arrivé en 2018, le petit poucet svelte.js se fait une place de choix et répond à des cas d’utilisation précis.

C’est un framework intéressant pour builder rapidement des embedded app ou des SPA.

Le store est assuré par un module natif, svelte-store.

Supporté à la base par … un gars, Rich Harris (créateur de Ractive aussi, tout de même), Svelte a aujourd’hui une toute grosse communauté (74.000 stars sur Github), et une documentation bien faite… 2024 sera l’année où le petit poucet va s’assoir à la table des grands.

Solid

Présentant les mêmes avantages que Svelte, Solid se démarque par une gestion extrêmement efficace du data binding et une mise à jour du DOM hyper performante.

C’est le framework qui présente le plus haut taux de rétention de la part des développeurs en 2023, ce qui tend à démontre que l’essayer, c’est l’adopter.

La communauté va grandissante (30.000 stars sur Github), la documentation est là, 2024 devrait voir une belle croissance dans le taux d’adoption.

Alpine

Alpine.js se démarque des autres par le fait qu’il soit pensé pour être intégré directement dans du code HTML, sans devoir passer par un build et un système de templating compliqués.

C’est une alternative très intéressante pour ajouter de l’interactivité à un site statique en embarquant directement des components Javascript.

Encore relativement marginal du fait de ses spécifités, Alpine bénéficie d’une communauté intéressante (25.000 stars sur Github), d’une documentation bien ficelée et devrait continuer à se développer en 2024 sur les use cases qu’il attaque.

Htmx

Le petit dernier, qui joue dans la même cour qu’Alpine. HTMX présente la particularité d’être pensé pour intégrer de l’interactivité dans des pages statiques … sans faire de Javascript.

Je ne l’ai pas encore essayé. J’ai parcouru la documentation, le principe est assez simple: ça va se jouer à coups d’attributs HTML.

Belle hype actuellement sur cette librairie, la communauté est respectable (25.000 stars sur Github), c’est simple d’utilisation, ce sera à surveiller cette année.

Node.js

Le game changer. Arrivé sur le marché en 2009, Node.js a démarré doucement pour exploser à partir de 2013 / 2014.

Basé sur le moteur V8 de Chrome, le runtime node.js permet d’exécuter du Javascript côté serveur.  Profitant de l’écosystème NPM et de l’event loop, c’est une technologie qui permet de builder un back-end en 2-2, comme disent les djeun’z.

Le runtime évolue de manière intéressante, et bien qu’il soit aujourd’hui en perte de vitesse, il continuera à se développer dans les années qui viennent.

Frameworks back-end

Même story que pour les frameworks front-end: ça pousse comme des champignons, à la différence que c’est moins qualitatif. Et qu’il y en a tout de même moins sur le marché.

Le runtime node.js étant assez complet, l’apport d’un framework est moins intéressant en back-end. Il est tout à fait possible / concevable de développer une API from scratch en node.js sans avoir recours à un framework. Dépend du use case, mais ça se fait.

Sur le marché, on trouve quelques solutions éprouvées. Je ne vais en aborder que 2:  Express et Nest. Parce qu’Express, c’est Express, et que Nest ça fait tout mieux que les autres.

Express

Souvent imité, jamais égalé. Souvent décrié, toujours utilisé. Toujours maintenu, mais sans évolutions majeures, et on s’en cogne. Express.js is the new Papy fait de la résistance.

En version 5 beta depuis … pffffiou, au moins ça, ça ne bouge plus des masses, et personne ne sait vraiment quand ils vont enfin la release, la v5.

Cela dit, non seulement la 4.18 fonctionne bien, mais la beta 5 aussi. Du coup, en 2024, Express reste une valeur sûre pour builder un back-end ou une API.

C’est bien documenté, c’est hyper simple, c’est performant, ça implémente les briques de bases pour monter un serveur HTTP, faire du routing, du templating. Il y a des middlewares – et ça, c’est de la balle, bref, ça fait le job. Tout simplement.

Nest

Le plus sérieux concurrent d’Express, aka Nest.js supporte Typescript, de base, et vient avec un CLI digne de ce nom.

Conceptuellement, l’architecture est très modulaire.  Ajoutez à ça une gestion native de l’injection de dépendances, et vous obtenez un framework flexible, scalable et maintenable, qui facilite les tests unitaires.

C’est taillé sur-mesure pour builder des applications server side, des API, des microservices, peu importe l’échelle et y compris les applications larges.

Grosse communauté dynamique, une documentation efficace. C’est, selon moi, le framework node.js à maîtriser quand on ne fait pas de l’Express.

Deno is the new node, oui mais…

Pour ceux qui ne le connaissent pas, Deno est le successeur de Node, conçu par la même personne: Ryan Dahl.

Ryan Dahl est un peu comme Douglas Crockford: un repenti. Et tout comme Douglas Crockford, dépassé par le succès de son oeuvre, il ne pourra pas défaire ce qu’il a fait en un coup de cuillère à pot. Personne ne lui en voudra pour ça.

Annoncé comme le nouveau node, une révolution de performances et surtout, de sécurité, Deno n’a pas (encore) décollé comme espéré. Principalement parce que les équipes de développement ne peuvent pas suivre le rythme de la communauté, et qu’en pratique Node.js fonctionne très bien.

Par ailleurs, là où le runtime node – et par extention deno – est resté sans concurrence sérieuse pendant des années, il y a dorénavant un runtime concurrent Bun.js, qui marche très fort, et qui va probablement prendre beaucoup de place à l’avenir.

Persistance et performances NoSQL

Encore majoritairement relationnelles il y a 10 ans, les bases de données web se sont peu à peu tournées vers des alternatives émergentes.

Les SQL server, Oracle, PostgreSQL et autres MySQL ont dû faire de la place à des systèmes plus souples, et surtout plus performants.

C’est ainsi que, marginales voire dissidentes en 2014, les bases de données NoSQL se sont fait une place sérieuse grâce à leur haute disponibilité, leur flexibilité, leur évolutivité et leur scalabilité.

En 2024, ça tape pas mal sur du Redis, MongoDB, DynamoDB, CouchDB, Bigtable, …

Tester dans l’écosystème Javascript

En 2014, c’est Karma.js, Jasmine, Mocha, et en gros c’est plus ou moins tout.

Aujourd’hui, il y a un nombre incalculable de librairies qui tournent autour du testing en Javascript, côté client ou côté serveur.  Pour faire de l’unitaire, de l’intégration, du E2E, du TDD, des mocks, des fixtures, des runners, des benchmarks, de la couverture de code, …

Bref, l’écosystème Javascript dans toute sa splendeur.

Pratico pratiquement, différents acteurs se sont positionnés ces dernières années,  je vais en sortir 4 que le développeur Javascript va rencontrer en 2024: Jest, Mocha, Playwright et Cypress.

Juste à côté…

Fonctionnellement, il est intéressant de proposer une application desktop, accessible via un browser, et une déclinaison mobile qui offre d’autres avantages.

Techniquement, les contraintes d’hier ne sont plus celles d’aujourd’hui. Les API et bases de données sont les mêmes, ou elles sont synchronisées. Et pour les plus audacieux, il est possible d’utiliser la même codebase front-end pour développer en natif et pour le web.

C’est donc intéressant de sortir un peu de sa zone de confort pour aller voir ce qui se fait du côté de React Native, Flutter, Xamarin, Kotlin, Ionic …

Ten years further

Voilà, ça a bien, bien, bien bougé en somme 😀

J’ai essayé d’aller à l’essentiel.  Ce n’est pas simple tellement il y en a partout.  Je n’ai pas creusé les questions de l’IA, du monitoring, de la sécurité, de l’authentification ou du RGPD, mais c’est certain que ce sont des sujets qui seront sur la table.

Etre développeur full stack JS en 2024, c’est sport.

Qu’en sera-t-il dans 10 ans ?!

Difficile à dire, je n’ai pas de boule de cristal. Il semble assez clair que l’intelligence artificielle va bouleverser les habitudes de développement et de consommation du web telles qu’on les connaît aujourd’hui.

Javascript est parti pour durer quelques années de plus sans trop de soucis, je crois. Et dans tous les cas, il y a des tas d’autres technologies intéressantes à explorer en tant que développeur.

Pour le reste, happy dev, just do it, and let’s stay in touch 🙂