1 points par ohah173 2 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Une sorte d’Electron-like fait avec Zig.
Le titre fait plus stylé qu’il ne l’est en réalité, mais c’est simplement un framework desktop créé avec Zig.
Je pense qu’Electron est en fait une solution difficile à éviter quand on développe des applications de bureau.

Surtout quand il faut prendre en compte en même temps les environnements Mac et Windows, tout en gardant une forte productivité, je trouve qu’il n’existe pas de framework aussi attractif qu’Electron.

On peut réutiliser tel quel l’écosystème JS, c’est une solution éprouvée sur le marché (vscode, slack, discord, etc.)

Avec sa polyvalence et ses avantages, il est utilisé dans beaucoup de cas, donc ses défauts sont eux aussi bien connus, et c’est un framework qui se fait souvent critiquer.

Je fais moi aussi partie de ceux qui ont ces frustrations.

Comme ça me déplaisait, j’ai essayé Tauri, mais Tauri a lui aussi la limite chronique (?) du webview système, et si on utilise Tauri, le langage backend est limité à Rust ;

avec Electron, il est limité à Node ;

avec Wails, il est limité à Go.

Bien sûr, on peut intégrer d’autres langages avec du FFI, mais…

En réalité, surtout à une époque comme aujourd’hui où les barrières entre langages se sont beaucoup réduites, je n’aimais pas l’idée d’avoir des contraintes de langage imposées par le framework.

zig, rust, go, lua, node

peuvent chacun être choisis comme langage backend, et il est aussi possible d’en sélectionner plusieurs à la fois pour configurer plusieurs backends en parallèle.

Je compte continuer à ajouter autant de langages backend que possible.
Python ou Ruby aussi.

Comme plusieurs langages peuvent être inclus, chaque backend peut aussi communiquer avec les autres via IPC.

Par exemple, pour appeler SQLite depuis Node,

il faut installer better-sqlite3, mais dans le cas de SQLite, c’est inclus comme plugin intégré, et Node l’utilise en appelant directement Zig.

Il est aussi possible de compiler pour mobile, mais pour l’instant tout sauf Mac reste instable.
Pour des raisons de politique, seul iOS ne permet pas d’utiliser Node comme langage backend.

À l’heure actuelle, sur Mac, on peut réellement builder et livrer un produit ; Windows et Linux ont encore besoin de quelques améliorations.
Le support mobile est également prévu.

À cause des inconvénients du webview système rencontrés avec Tauri,

sur Mac, je ne compte pas utiliser le webview système.

J’ai reproduit autant que possible l’API et l’usage d’Electron,

et comme la documentation et les spécifications sont pensées pour être faciles à exploiter par une IA, il suffit en pratique de fournir le lien de la doc pour qu’elle vérifie d’elle-même jusqu’à l’E2E ; on peut donc voir ce framework comme ayant une productivité IA écrasante par rapport aux autres frameworks « concurrents » (?).

En fait, je l’ai simplement créé parce qu’Electron et Tauri m’agaçaient,
et personnellement, quand je fais maintenant des outils DX ou des applications desktop, je les développe avec suji.

Je me trompe peut-être dans mes mesures, mais je suis encore plus satisfait, car la communication inter-langages avec cette architecture me semble plus rapide qu’un appel via FFI.

Pour créer rapidement des applications simples ou sortir quelque chose sans être limité par le langage, j’ai l’impression que c’est plus rapide qu’Electron ou Tauri, donc personnellement j’en suis satisfait.
Mais je me demande aussi si c’est seulement parce que c’est moi qui l’ai fait, et j’aimerais savoir ce que les autres pensent de cette idée et de cette approche, donc je poste ça ici !

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.