En étudiant l'annonce Développeur(se) back-end en CDI de Brief.me j'ai été intrigué par :

Migrer notre front-end existant de Nuxt.js vers HTMX.

Je me suis demandé quelle est la motivation de passer d'un framework de type Nuxt.js, NextJS ou SvelteKit à htmx 🤔.

J'utilise SvelteKit depuis deux ans, qui est comparable Nuxt.js, principalement en mode SSR avec Hydration, et je suis totalement satisfait. Ma Developer eXperience est excellente. Je trouve ce framework minimaliste, conforme au principe Keep it simple, stupid! (KISS), et performant.

Après réflexion, j'ai réalisé que mon expérience de développeur (DX) serait moindre si j'héritais d'un backend codé dans un langage autre que Javascript : Python, PHP, Ruby, Golang…

Et Brief.me semble être dans ce cas de figure :

• Back-end : Django, PostgreSQL, RabbitMQ, Celery
• Front-end : HTMX
• Tests : pytest
• Infra : Platform.sh

Je me suis connecté à mon compte Brief.me et en regardant ce que me retourne Wappalyzer, je constate que le site est effectivement propulsé par Nuxt.js, VueJS.

En regardant ce qu'il se passe dans l'onglet Réseau de mon navigateur, je constate que https://app.brief.me est un site web de type SPA. Le contenu des articles est chargé via l'api https://www.brief.me/api/ qui est propulsée par Django REST framework.

Si je résume, la stack est la suivante : PostgreSQL => Django => Django REST framework <=> Nuxt.js => Rendu HTML via VueJS.

Je suppose que ce qui motive la migration de Nuxt.js vers HTMX est la suppression de couches.
Plus précisément, je suppose que l'équipe tech de Brief.me souhaite supprimer les couches suivantes :

• Django REST framework
• Nuxt.js
• VueJS

Et utiliser simplement le système de template de Django en SSR pour afficher le contenu des articles et implémenter les quelques éléments dynamiques côté browser avec HTMX.
De mon point de vue, ceci a pour avantage de largement simplifier la stack, de simplifier le déploiement et d'accélérer le chargement des pages.

Ma conclusion : la librairie HTMX semble être un choix très pertinent quand elle est utilisée dans une stack non NodeJS.

Un ami me partage la satisfaction qu'il a à utiliser la version 3 de Nuxt :

Nuxt3 est devenu magnifique avec le combo Nuxt/Font, Nuxt/i18n, Tailwind CSS, sa couche server pour proxy une api sous le boisseau. Ça en fait un framework redoutable.

Suite à la lecture de ce commentaire, #JeMeDemande s'il est autant satisfait de Nuxt3 que je le suis de SvelteKit 🤔.

Je souhaite depuis longtemps — début 2023 — réaliser ces deux projets :

• Projet - 2 "Réaliser un petit projet basé sur NextJS pour le comparer avec SvelteKit"
• Projet 3 - "Réaliser un petit projet basé sur Nuxt pour le comparer avec SvelteKit"

pour être en capacité de donner mon opinion éclairée de comparaison entre ces trois frameworks NextJS, Nuxt et SvelteKit.

Pour le moment, je me contente de recevoir avec plaisir le bonheur de mon ami et je garde en mémoire son expérience, pour la partager le jour où un ami de demandera mon avis au sujet de Nuxt.

Date de la création de cette note : mardi 30 avril 2024 .

Quel est l'objectif de ce projet ?

Pour les mêmes raisons qui me motive à réaliser Projet - 2 "Réaliser un petit projet basé sur NextJS pour le comparer avec SvelteKit", je souhaite réaliser la même chose pour Nuxt.

Contexte : J'utilise SvelteKit depuis avril 2022, j'apprécie très fortement l'élégence de toutes les fonctionnalités de routing de SvelteKit.

Mon objectif est de créer un projet de type #POC pour apprendre les bases de Nuxt et de comparer ce framework avec SvelteKit.

Artefacts à produire :

• Un repository GitHub qui contient le projet de type POC que j'aurais réaliser pour apprendre à utiliser Nuxt
• Une note d'opinion qui présente ma comparaison entre SvelteKit et NextJS