Un regard sur Remix et les différences avec Next.js

Dans la communauté des développeurs, il est très courant de voir apparaître chaque jour de nouveaux frameworks et outils. Certains d’entre eux proposent une approche différente pour résoudre des scénarios qui sont actuellement résolus avec d’autres outils. D’autres apportent un nouveau concept ou une nouvelle idée, proposant une manière différente d’aborder les projets. Comme le charpentier dispose de différents outils pour effectuer différentes tâches, les développeurs disposent de nombreux frameworks et bibliothèques disponibles qui conviennent parfaitement à différents cas d’utilisation.

Parlons de Remix, le (sorte de) nouveau framework pour créer des projets JavaScript en utilisant le rendu côté serveur. Passons en revue ses principales fonctionnalités et concepts et voyons les similitudes et les différences avec un autre framework JavaScript populaire : Next.js.

C’est quoi Remix ?

Selon son site officiel, Remix est un framework de pile complète qui permet aux développeurs de créer des expériences utilisateur exceptionnelles en se concentrant sur les normes Web. Avec lui, vous pouvez créer votre application Web en utilisant React et JavaScript pour le rendu côté client et le rendu côté serveur.

Comme il est construit sur l’API Web Fetch, les applications créées avec Remix peuvent s’exécuter n’importe où. Remix utilise le rendu côté serveur pour manipuler les données et restituer le contenu HTML sur le serveur, en envoyant le moins de JavaScript possible au client.

Remix était à l’origine un framework premium basé sur un abonnement mais, il y a moins d’un an, il a été lancé en tant que framework open source. Après cela, la communauté des développeurs et des utilisateurs de Remix a commencé à se développer et à devenir plus populaire.

Caractéristiques principales de Remix

Soulignons quelques-unes des principales fonctionnalités fournies par Remix :

• Itinéraires :
  Comme d’autres frameworks, Remix permet aux développeurs de gérer les différents itinéraires de leurs projets Web à l’aide de fichiers JavaScript/TypeScript contenant des fonctions de gestion. Nous sommes en mesure de générer des itinéraires sur notre site Web en créant des fichiers qui suivent la hiérarchie du système de fichiers de nos projets, en créant des URL analogiques pour nos pages. Les routes Remix fonctionnent à l’aide de la fonction de routage partiel fournie par React-Router. Avec cette approche à l’esprit, nous pouvons souligner les avantages suivants.

• Composants imbriqués :
  Remix vous donne la possibilité de gérer des pages et des composants imbriqués. Nous pouvons créer un fichier pour gérer un certain itinéraire et, au même niveau dans le système de fichiers, un dossier portant le même nom. Tous les fichiers que nous créons dans ce dossier seront des composants imbriqués de la route parente, au lieu de différentes pages.

• La gestion des erreurs:
  Les composants imbriqués apportent un autre avantage : si une erreur se produit lors du rendu d’un certain composant, cela n’affecte pas les autres parties imbriquées de la page. Ainsi, nous pouvons encapsuler l’erreur uniquement dans la section où elle s’est produite, au lieu d’obtenir une erreur de page générale.

• Formes:
  Comme Remix se concentre sur les standards du web, il utilise des méthodes natives (POST, PUT, DELETE, PATCH) pour gérer les formulaires au lieu d’utiliser JavaScript pour cela.

• Chargeurs et actions :
  Remix fournit deux types de fonctions différents pour créer du contenu dynamique côté serveur. La loader les fonctions sont utilisées pour gérer GET Requêtes HTTP dans le serveur, principalement utilisées pour obtenir des données de différentes sources. La action moniteur de fonctions POST, PUT, DELETEet PATCH demandes, axées sur la manipulation et la modification des données.

Maintenant que nous avons parlé de certaines des principales fonctionnalités de Remix, comparons-le avec l’un des frameworks React les plus populaires et les plus utilisés de nos jours : Next.js.

Quelles sont les différences entre Remix et Next.js ?

Si nous jetons un coup d’œil rapide, Next.js et Remix peuvent sembler suivre le même objectif – et, probablement, ils le font. Mais si nous analysons les fonctionnalités et les approches qu’ils proposent, nous identifierons les similitudes et les différences, et nous pourrons penser à des scénarios résolus de manière plus appropriée avec l’un des frameworks plus qu’avec l’autre.

Basé sur la réaction

Les deux frameworks ont été créés au-dessus de React, mais Remix essaie de s’en dissocier. Nous pouvons voir que Remix fournit des niveaux d’abstraction plus élevés. De plus, différents membres de la communauté Remix ont travaillé sur différentes implémentations en utilisant d’autres frameworks, comme Vue.js, Angular et Svelte. Next.js dépend de React, et il n’est pas prévu de changer cela pour le moment.

Rendu côté serveur

Outre les fonctionnalités que nous avons mentionnées ci-dessus, nous pouvons voir que Remix et Next.js offrent un rendu côté serveur (SSR) pour générer le balisage et le contenu de nos pages à partir du serveur Web avant de l’envoyer au client.

Alors que probablement Next.js s’appuie sur l’approche d’hydratation côté client, native de React, Remix essaie de générer autant de contenu que possible côté serveur. Cela permet d’éviter d’envoyer du code JavaScript, de générer du contenu et de récupérer des données du client.

Génération de sites statiques

D’autre part, Next.js offre la possibilité de pré-générer des pages et du contenu statiques au moment de la construction, en utilisant la génération de site statique (SSG), contrairement à Remix. Selon le type de pages que nous voulons créer, cette fonctionnalité peut apporter de grands avantages. Avec SSG, nous pouvons récupérer des données et afficher des pages au moment de la construction, en ayant des pages statiques avant que les utilisateurs ne visitent notre site Web, sans avoir à attendre que le contenu soit généré.

Mais SSG pourrait également devenir problématique : chaque fois que nous appliquons des modifications au code ou au contenu de notre application, nous devons attendre qu’un processus de génération génère la nouvelle version des actifs statiques. Cela pourrait devenir un point douloureux, car le temps de construction augmentera si notre projet devient de plus en plus gros. Pour gérer ce problème, l’équipe de Vercel a développé une fonctionnalité appelée Régénération statique incrémentielle (ISR), et le tout nouveau ISR à la demande.

Obsolète pendant la revalidation

Pour diffuser le contenu le plus rapidement possible, Remix s’appuie sur la directive de mise en cache obsolète pendant la revalidation (SWR). Au lieu de pré-générer du contenu statique, il amorce le cache lorsque l’application reçoit du trafic. Les pages et les documents sont servis depuis le cache, tandis qu’ils se revalident en arrière-plan pour le prochain visiteur.

Navigation côté client

L’une des fonctionnalités utilisées par Next.js pour offrir une navigation fluide aux utilisateurs est prélecture. Nous pouvons utiliser le <Link> composant pour faire en sorte que notre site Web précharge la page qui <link> redirige vers lorsque l’élément apparaît dans la fenêtre. Si nous visitons la page d’accueil d’un site Web et que nous voyons un lien « Contact » sur la page, Next.js téléchargera et récupérera le contenu lié à la page de contact. Ainsi, lorsque nous cliquons sur le lien, nous n’avons pas à attendre que la page soit téléchargée.

Mais il y a une limitation : Next.js n’offre la prélecture que pour les pages qui ont été pré-construites à l’aide de la génération de site statique (SSG). Si nous avons des liens vers des pages générées dynamiquement, la fonctionnalité ne sera pas déclenchée.

Remix n’a pas cette limitation. Comme il utilise le HTML <link rel="prefetch"> tag (au lieu d’un cache comme Next.js), nous pouvons pré-extraire non seulement des liens, mais en fait n’importe quelle page.

Bord d’abord

Lorsque nous récupérons des données et rendons du contenu à partir du serveur, nous devons également évaluer la distance entre le serveur qui exécute le code et les utilisateurs qui envoient les requêtes HTTP. Si mon serveur principal est situé au Brésil et qu’un utilisateur visite mon site Web depuis la Chine, le processus de chargement de la page sera plus lent que le mien si je visite la même page depuis l’Argentine. Ceci est lié à la distance géographique que la requête HTTP doit parcourir jusqu’au serveur le plus proche qui l’évalue et exécute le code.

Même si les applications modernes s’appuient sur les CDN pour fournir du contenu statique, le code côté serveur qui est traité pour générer du contenu dynamique est généralement exécuté dans le centre de données, s’exécutant dans un emplacement particulier. Une solution de contournement à ce scénario consisterait à utiliser la directive de mise en cache SWR, avec la mise en garde de servir éventuellement du contenu obsolète pendant que le CDN actualise la ressource.

Ayant ce problème à l’esprit, ces dernières années, un nouveau concept a vu le jour : Edge computing. L’idée est de suivre la même approche que celle utilisée par les CDN, en répliquant la logique du serveur dans différents serveurs et emplacements, en exécutant le code dynamique le plus près possible de l’utilisateur. Alors que Remix est défini comme « Edge First », ce qui signifie que le framework a été pensé pour fonctionner sur Edge dès sa conception, Vercel a lancé le Fonctions de bord en tant que fonctionnalité supplémentaire pour l’application déployée dans la plate-forme.

Code côté serveur

Lors de la description des principales fonctionnalités de Remix, nous avons dit que le framework utilise des méthodes HTTP natives pour gérer les formulaires à l’aide de action et loader les fonctions. Un formulaire, un serveur, un POST requête qui transporte les données sérialisées du formulaire vers le serveur, une action côté serveur, une nouvelle page suite à notre requête. Retour aux standards du web.

Remix fournit le <Form> élément, une version optimisée du formulaire HTML. Avec elle et le action fonctions, nous pouvons avoir le code client et le code serveur liés à nos itinéraires dans le même fichier. Remix saura gérer l’interface utilisateur de nos pages et le comportement côté serveur attaché aux requêtes. Pas de contexte, pas de gestion d’état.

Next.js, quant à lui, s’appuie sur du code JavaScript pour savoir gérer l’état de l’application, que les API appellent, revalident les données et mettent à jour l’interface de la page web. Utilisant Itinéraires d’APInous pouvons avoir des fichiers séparés qui exécutent des fonctionnalités côté serveur et renvoient des données à notre interface.

Comme nous l’avons dit, et comme vous pouvez le voir, Remix a une façon de muter les données qui tente de revenir à l’essentiel, rappelant l’époque où PHP était la grande affaire.

Dépendance Node.js

Comme nous l’avons déjà dit, Remix est basé sur l’API Web Fetch, au lieu de dépendre de Node.js. Cela nous donne la possibilité d’exécuter des applications Remix non seulement sur des serveurs Node.js (comme Vercel ou Netlify), mais aussi sur d’autres types de plateformes (comme Cloudflare Workers ou le nouveau Deno Deploy).

Conclusion

Remix est devenu open-source il n’y a pas si longtemps, mais il a déjà une communauté très active qui collabore et crée des projets suivant les standards du web. Le cadre a un avenir prometteur. Voyons comment il évolue, quelles fonctionnalités sont ajoutées, quels projets connexes sont créés pour améliorer l’expérience des développeurs et quels autres scénarios il tente de résoudre.

Lectures complémentaires sur Smashing Magazine

(nl, il)