S01E30 — 27-08-2024.
L’or invisible en binaire.
jour 30.
La migration du nouveau tokenizer s’est bien déroulée, mon langage commence à se modernisé. Quand, tu sais que le JavaScript a été écrit en deux semaines, tu te demandes comment ils ont pu valider un tel projet. En deux semaines, tu n’as pas le temps de réfléchir à tous les cas d’usage possible, d’effectuer des tests unitaires, en tout cas moi, je ne peux pas et je ne veux pas.
Un langage doit s’écrire avec le temps, une syntaxe doit être vu comme un grand cru. Seul, le temps te fera réaliser si la syntaxe choisis traversera les jours, mois et années, mais la base doit avoir été pensé pour obtenir le meilleur résultat. La première chose que les gens verront, c’est la syntaxe. En 15 secondes, ils vont se faire une idée en mode : j’aime, je n’aime pas, ça m’intrigue mais je ne sais pas.
J’ai fais en sorte d’avoir une syntaxe qui me mets dans la troisième catégorie: ça m’intrigue mais je ne sais pas. C’est un moyen de marquer l’esprit. On verra ce que ça donne. Maintenant que je commence à intégrer les possibilités à avoir un langage de balisage. J”ai de nouvelles recherches à faire comme comment va fonctionner les interactions entre le serveur et le client ? Comment je construit des interfaces avec ? Du coup qu’est-ce que je mets sous le capot de ma Peugeot 205 GT Turbo pour répondre à ce besoin. En vrac, j’ai en tête :
-blade
Une bibliothèque à surveiller, elle me fait de l’œil depuis un long moment. La contrainte est qu’il y a peu de documentation et il faut créer une GUI au dessus de cette caisse. Je n’ai pas les capacités pour cela. Donc je me suis penché vers egui qui est une GUI très simple d’utilisation. Sauf qu’un jour, le créateur de blade entre temps à sorti blade-egui. Je me dis que c’est exactement ça qu’il me faut. D’ailleurs, nn observant plus en détail les dépendances utilisées dans l’éditeur de texte Zed, j’ai vu qu’il y a du blade sous l’abitable. Tiens, tiens, tiens, coïncidence ? Je ne crois pas ! Donc je continu d’investiguer le repo Zed et je tombe sur un dossier gpui. C’est quoi encore ce truc. Je lis le README.
GPUI is a hybrid immediate and retained mode, GPU accelerated, UI framework for Rust, designed to support a wide variety of applications.
Ô pu-taing ! C’est exactement ce qu’il me faut. En plus l’API est plus proche du HTML et du CSS donc plus simple à développer de mon côté. Parce que si je cherche à créer la même chose avec egui. C’est une tout autre façon de penser qui fait que je vais passer mon temps à réfléchir comment je retranscrit un CentralPanel en bloc, div, section, etc. Alors que gpui intègre un système de flexbox. C’est ça le turfu. Je garde egui en second choix mais mes premiers tests se feront avec gpui. Faut que je vois si c’est possible de viser le webassembly avec, je n’ai pas vu grand chose car la documentation n’existe pas. Seules deux-trois examples fournis mais rien de folichon. J’ai encore le temps d’y penser de toute façon.
-green threads
C’est aussi, une technologie que j’aimerai avoir dans zo, un baye à la Erlang serait le turfu. Pas encore sûr de vouloir aller vers la machine virtuelle d’Erlang. J’ai vu une caisse Rust qui s’appelle lunatic qui est un runtime à la manière d’Erlang mais pour le webassembly. Je me tate de ouf. Après mettre connecter au Discord de la communauté. Ce que j’avais conclu en zyeutant le projet semble se confirmer. Le projet n’est pas abandonné mais il va avancé très lentement. L’auteur à mit le focus et son intérêt sur un autre projet. A voir…
-htmx
Ça m’intrigue mais je ne sais pas. Tu vois on y revient (rire). L’approche choisit me parle beaucoup et je pourrait facilement m’inspirer du concept pour l’adopter greffer avec zsx. Avec en mode SSR tout se faire côté server mais en mode client avoir un runtime qui reproduit le concept de state sans passer par le serveur.
A voir tout de même si l’approche d’htmx est efficace pour des applications temps réelles types — multi-joueur, collaboration, navigation de cartes type Google Map.