J'ai récemment été approché par un client au sujet d'une application javascript « d'évaluation financière » sur son site Wordpress qui ne fonctionnait plus. Il y avait de nombreux problèmes et, en fin de compte, le moyen le plus simple était de le reconstruire.

Dans cette application, les utilisateurs peuvent saisir des informations financières et personnelles de base, et l'application leur indique s'ils sont sur la bonne voie en termes de planification financière. Ce n'est pas une logique très complexe, mais il y en a pas mal.

Je ne suis pas principalement un développeur frontend. Je suis plus à l'aise sur le backend. Mais j'ai implémenté des projets dans Vue, Angular, React... Ils fonctionnent, mais je ne leur fais pas entièrement confiance. Et au fil des mois et des années, je développe toujours une anxiété rampante quant à l'obsolescence des dépendances, y compris de la chaîne d'outils de développement elle-même.

Entrez dans Lueur

Gleam est un langage convivial pour créer des systèmes de type sécurisé et évolutifs !
~ Site Web de Gleam

Je suis enthousiasmé par Gleam depuis qu'ils ont déclaré pour la première fois que la v1 était prête pour la production. Son style fonctionnel, son immuabilité, sa correspondance de modèles exhaustive, son inférence de type et la simplicité et la stabilité de Go signifiaient que Gleam touchait tous mes points forts.

Le système de types garantit à peu près que si votre code est compilé, il fonctionne. Je n'ai pas encore rencontré de bug dans mon code Gleam qui n'était pas une version de "mon mal, j'ai oublié de finir de l'implémenter".

Entrez dans le lustre

Gleam a été conçu pour fonctionner sur BEAM (la légendaire VM testée au combat d'Erlang), mais il dispose également d'une cible de compilation Javascript. Cela signifie qu'il peut facilement être expédié vers Node et le navigateur.

Lustre est le framework frontend prééminent de Gleam. Il s'agit d'un portage fidèle d'Elm à l'écosystème Gleam et présente l'architecture de gestion d'état "Modèle -> Vue -> Mise à jour" d'Elm.

Il s'agit d'un modèle conceptuel considérablement plus simple que les autres frameworks frontend. Plutôt que d'offrir la gestion de l'état en tant que bibliothèque opt-in (je vous regarde redux), le modèle de gestion de l'état de Lustre est son cœur battant.

Vous décrivez simplement chaque verbe qui peut avoir lieu pour modifier l'état dans votre application et mappez ce verbe à une opération pure de type sécurisé qui renvoie une version mise à jour du modèle. Les fonctions de vue (également pures) découlent directement de l'état de ce modèle unitaire.

Lustre fournit également un système d'effets gérés afin que même en cas d'échec de diverses opérations d'E/S, votre code d'application puisse être implémenté à l'aide de fonctions entièrement pures.

Ce qui est cool avec les fonctions pures ? Ils sont garantis de toujours fournir le même résultat avec la même entrée. Cela les rend prévisibles, faciles à tester et extrêmement stables. Les fonctions pures ne se cassent pas. Mathématiquement, ils ne peuvent pas.

Passe-partout sucré et sucré

Lustre peuvent impliquer un un peu plus de configuration standard de l'application et de création de tous les types, etc. Mais ...

Jamais il n'y a eu de cadre plus approprié auquel le terme « passe-partout » a été appliqué. Cela me donne le même sentiment de confiance que j'obtiendrais en enfonçant un rivet dans une tôle d'acier. Une fois en place, cette chose ne va n'importe où.

J'ai du mal à exprimer à quel point cela semble différent de mes expériences antérieures avec javascript. Mon application aurait pu avoir moins de LOC si je l'avais fait dans un autre cadre. Mais est-ce que je lui ferais confiance pour ne pas se casser ? Serait-ce aussi simple à comprendre ?

Le produit final

J'ai expédié mon application dans les délais et dans les limites du budget. Le client en est vraiment content. Et je dors tranquille en sachant que ce projet est bel et bien réalisé.

Non seulement cela, mais il vit confortablement dans Wordpress de tous les endroits. J'ai créé un shortcode pour charger les ressources compilées, je l'ai affiché sur la page, et c'est tout.

Le bundle JS fait 18,1 Ko, minifié et compressé. C'est presque aussi petit que htmx. Pour avoir crié à haute voix !

J'ai quelques réserves quant à l'envoi d'un projet en utilisant ce qui est encore un langage et un cadre relativement obscurs. Mais ces réserves sont apaisées en sachant que l'application ne tombera pas en panne et que Gleam lui-même peut être appris en un après-midi.

Le plus important : honnêtement, je ne pense pas que j'aurais autant confiance dans le produit final, dans la stabilité de la chaîne d'outils ou dans ma capacité à la mettre à niveau à l'avenir, si je l'avais construit en utilisant autre chose. .

Ma fréquence cardiaque

J'en viens maintenant à toute ma motivation pour écrire ce post : le sentiment d'avoir une application Lustre en production

Cela fait quelques semaines que cette application a été lancée, et j'aime toujours la revoir de temps en temps. Pas parce que le client a demandé des modifications. Juste pour regarder le code.

Je me sens presque gêné de dire cela, mais la plupart de mes autres codes semblent être un handicap à un certain niveau. Surtout javascript. Même si c'est Typescript, même s'il y a des tests. Cela me rend anxieux, comme si c'était parsemé de mines terrestres cachées et de pièges.

C'est peut-être un problème de compétences. Peut-être que j'ai été brûlé trop de fois.

Regarder mon code Gleam/Lustre me fait me sentir calme.

C'est ça. C'est le tweet.

En conclusion, je souhaite sincèrement que d'autres développeurs essaient Gleam et Lustre, afin qu'eux aussi puissent profiter de ce même bonheur zen lorsqu'ils contemplent leur code frontend.

Merci d'avoir lu.