Xray, un nouvel éditeur de texte ultra-performant basé sur Electron

Nicolas Furno |

Les apps qui reposent sur Electron sont devenues très populaires en quelques années, parce qu’elles permettent de développer assez simplement des apps qui fonctionneront sur macOS, Windows et Linux. Ce framework repose sur des technologies du web pour concevoir interfaces et fonctions : HTML, CSS et surtout JavaScript. Cela réduit la difficulté par rapport aux langages de développement utilisés traditionnellement par les logiciels pour ordinateurs, et cela permet aux développeurs web, nettement plus nombreux, de créer des apps.

Tout ceci est bien beau sur le papier, mais les apps développées grâce à Electron sont aussi plus lourdes que les apps natives, et souvent plus lentes. Ce problème de performance est tel que certains comparent Electron à Flash et que de plus en plus d’utilisateurs refusent systématiquement toutes les apps qui reposent sur Electron (lire aussi : Voici pourquoi certains développeurs utilisent toujours Vim). Pour contrer le phénomène, les développeurs d’Atom, l’éditeur de code développé par GitHub et pour qui le framework a été créé, essaient d’améliorer les performances, notamment en utilisant du code natif pour certaines fonctions.

Mais GitHub expérimente aussi autour d’une idée plus radicale avec Xray, un nouvel éditeur de texte dont le développement vient juste de commencer. Son principal objectif est d’être extrêmement performant, au niveau des meilleures applications de la catégorie, tout en étant multiplateforme. L’idée est toujours d’utiliser Electron, mais uniquement pour l’interface, tout le reste de l’app sera développé en Rust, un langage de bas niveau créé par Mozilla et qui vise à remplacer C ou C++.

L’architecture prévue pour Xray.

Rust a été développé pour Firefox, il est pensé pour être extrêmement optimisé et très rapide, notamment en fonctionnant massivement en parallèle. C’était précisément l’un des points faibles du JavaScript utilisé jusque-là exclusivement pour les apps Electron comme Atom, ce langage de haut niveau ne pouvait pas facilement travailler en parallèle et obtenir de meilleures performances est très difficile.

Si la performance est une priorité, pourquoi ne pas abandonner totalement Electron ? Les créateurs de Xray défendent leur choix en indiquant que cela restait la meilleure option pour créer des interfaces compatibles avec toutes les plateformes et faciles à modifier. C’est en effet l’un des points forts des logiciels développés sur cette base, ils peuvent facilement être remodelés avec des thèmes qui peuvent changer toute l’interface en quelques lignes de CSS. C’est donc un point qu’ils voulaient maintenir, mais tout le reste de l’architecture sera différente.

Est-ce que Xray sera finalement aussi rapide que souhaité aujourd'hui ? Ses concepteurs visent des performances dignes des meilleures apps natives, comme par exemple l’ouverture d’une fenêtre en 150 ms seulement, mais le curseur doit bouger en moins de 8 ms. Ces valeurs médianes font qu’une interface semble parfaitement fluide et elles seront visées tout au long du développement. D’autres objectifs ont été ou seront fixés, notamment la quantité de RAM consommée qui devra rester minime ; c’est en effet souvent un autre problème avec Electron.

Les créateurs de Xray ont réfléchi systématiquement avec les performances en tête, ce qui implique des choix importants à tous les niveaux, de la manière d’enregistrer et d’afficher le texte aux traitements qui seront faits en parallèle pour ne jamais bloquer l’interface. Ce sont autant de points qui compliquent le développement par rapport à une « simple » app Electron, mais qui devraient offrir de bien meilleures performances à l’arrivée.

Du moins, en théorie, puisque Xray n’est même pas encore un prototype fonctionnel à ce stade. GitHub a prévu d’allouer 12 semaines de développement au projet et on en est à la deuxième, à un stade où l’on ne s’occupe encore que des bases. Le développement est entièrement open-source et peut-être suivi sur GitHub également. Vous pouvez y participer, simplement en spectateur ou en contributeur, si vous avez les compétences nécessaires.

Si tout va bien, on devrait avoir un concept plus ou moins fonctionnel dans quelques mois. À partir de là, GitHub pourrait choisir de passer à la vitesse supérieure en matière de développement. Et pourquoi pas, si tout va vraiment bien, faire de Xray le successeur d’Atom à l’avenir. Mais on en est encore loin et l’idée de base doit encore prouver son intérêt à l’usage.

Image de couverture : photo sergiok (CC BY-NC 2.0) et le logo d’Electron

avatar Neo_007 | 

Ultra-performant + Electron ? c’est possible ?

avatar Nicolas Furno | 

@Neo_007

C’est tout l’enjeu en effet !

Mais on peut faire bien mieux qu’Atom ou Slack, en effet. Dans le domaine, Microsoft fait un super boulot avec Visual Studio Code, par exemple.

avatar ovea | 

Si j'ai tout pas bien compris :

Le problème vient d'Electron qui repose sur la base Chromium, qui ne vise que … pour Microspore, la compatibilité Google Chrome, qui reste programmé avec des langages «asexuée» du point de vu du déploiement d'applications … au même titre que JavaScript !?!?

avatar reborn | 

Sublime text pour moi, je reste allergique à ces apps cross platforms etc..

avatar BeePotato | 

@ reborn : « Sublime text pour moi, je reste allergique à ces apps cross platforms etc.. »

Je comprends fort bien cette allergie. En revanche, j’ai du mal à voir comment elle conduit à choisir Sublime Text, qui est justement une applications multi-plateformes.

avatar reborn | 

@BeePotato

C’est en code natif, une app "normal" quoi

avatar bompi | 

Et c'est une excellente application, réactive, souple, etc.
Certes, ce n'est pas un IDE mais l'avantage est sa légèreté.

avatar lepoulpebaleine | 

@bompi

+1 pour Sublime Text

Léger, rapide, très rapide, extrêmement rapide !
Jamais vu un éditeur aussi rapide !!!
Et avec son système de plugins, on est à mi-chemin vers un IDE.

avatar C1rc3@0rc | 

@ BeePotato

Une application peut etre portée sur plusieurs plateforme tout en etant adaptée a chacune. Il y a du multiplateforme qui n’est pas du crossplatform.
Dans certains cas c'est uniquement l'interface qui est adaptée, dans d'autres il faut adapter les "moteurs"... On peut même utiliser des frameworks comme Qt qui permettent de concevoir une application « virtuelle» qui sera compilée nativement pour chaque OS…

SublimeText existe sur les 3 principales OS du marché en version native (bien que l’interface reste assez rustre par rapport au canon de MacOS)
VIM lui aussi est multiplateforme, et ultra efficace sur toutes, mais bon en terme d’interface c’est du terminal pur, donc on aime ou pas.

A l’inverse Atom c’est une application virtuelle qui tourne sur un moteur vraiment pas optimisée sur… rien en fait, c’est du pur Web app, qui veut tourner (mal) en local et en bouffant de la ressource comme pas permis: une catastrophe écologique.

Ce qui me gêne avec le projet présent c’est qu’il ressemble méchamment a XUL. XUL c’etait le principe d’utiliser le moteur de rendu de Firefox pour créer des applications qui devaient tourner sur absolument tout les OS (ou tournait Firefox).

A priori Mozilla a enterré XUL avec Firefox 57… pour de bonnes raisons.
Pourquoi alors se relancer dans l’histoire?

Le problème que je comprends c’est qu’un éditeur de texte c’est principalement une interface graphique, donc quelque chose de très spécifique a la plateforme. Le développement crossplateform est inadapté pas essence. Mais lorsqu’on a pas les ressources pour adapter et maintenir le projet sur chacune, il faut bien trouver une solution. Ça aurait pu être Qt (ou similaire) mais il semble que ça satisfaisait pas les objectifs et contraintes. On verra bien si ça a plus d’avenir que XUL…

avatar Thaasophobia | 

+1
Sublime Text rules !

avatar PiRMeZuR | 

Génial ! Hâte de voir le résultat ! Effectivement, Atom n’est pas super rapide mais il y a un tel écosystème de packages qu’il faut peut-être davantage le comparer à un Eclipse ou un outil Jetbrains qui n’ont pas non plus la réactivité d’un simple éditeur de texte.

avatar ovea | 

N'peux pas être plus en accord !

Mais c'est tout l'enjeu du déploiement qui revient sur le haut du panier. Après, y'en aura encore des lignes de programme mortes pour l'évolution. Microspore nous l'a tellement revendu la reConnection du
Mothership industriel de l'informatique … pendant qu'Appel nous jouait du Funkadelic !

avatar lord danone | 

@MacG Je sais que l'electron bashing est une mode mais vous n'arrivez pas à faire un seul article parlant d'electron sans tomber dedans.
Une application electron est juste un browser qui execute un site web, donc quand vous dites que les applications electron sont lentes, c'est complètement faux, ce qui est potentiellement lent c'est l'application web qui tourne dans electron, et ça c'est la responsabilité du développeur web, pas d'electron.
Alors bien sûr si vous vous amusez à vouloir refaire un photoshop ou un after effects en js, bien sûr que l'application sera lente par rapport à du code natif puisque tout est executé sur un seul thread (et encore on peut multithreader du js avec des workers), mais pour 99% des usages sur 99% des configurations, une application js conviendra parfaitement tant que c'est pas codé avec les pieds.

avatar C1rc3@0rc | 

@ lord danone

Explique moi comment tu fais pour paralléliser massivement un éditeur de texte et en quoi du multithread pourrait ameliorer les performances sur ce type d'application?

«ce qui est potentiellement lent c'est l'application web qui tourne dans electron, et ça c'est la responsabilité du développeur web, pas d'electron.»

Ce qui est lent c'est que tout le code (moteur et interface) doit etre interpreté et executé a l'utilisation.
Le moteur d'un navigateur Web c'est une application qui reçoit deux flot de données pour afficher une page. Le premier flot c'est le contenu de la page, l'autre c'est le formatage.

Le principe est le meme que si on essayait de faire des applications avec Word ou LaTeX...

Que l'on ajoute de l'interactivité aux pages Web pour offrir une meilleure présentation de la données, permettre une saisie des formulaires plus attractifs et ergonomiques, oui c'est une bonne idee, mais vouloir remplacer des applications native en se reposant sur un moteur de formatage de page Web... c'est une ineptie.

avatar lord danone | 

Oui ca s'appelle une application web. Et on est en 2018. Il existe une multitude d'applications web très bien codées qui ont des performances tout à fait honorables, en tout cas assez honorables pour ne pas dire que c'est lent. Qui ici va me dire que l'interface de Gmail est lente? Ou Discord? Si je fait une application electron qui redirige simplement vers Google, est-ce que mon application sera lente parce que j'ai utilisé electron?

Dire qu'electron est lent est aussi stupide que de dire qu'un navigateur web est lent. Comme je l'ai écrit plus haut, 99% des usages sur 99% des configurations peuvent tourner sans accroc en HTML/CSS/JS, encore faut il que le code soit propre.

Maintenant il est évident qu'une application native sera plus légère, plus rapide et moins gourmande qu'une application web. Est-ce qu'on a besoin d'une application native pour tous les usages? Non. Est-ce que pour des usages spécifiques, une application native sera meilleure qu'une application web? Bien évidemment...

Electron n'est responsable d'aucune lenteur supplémentaire par rapport à un browser classique (au contraire), il est donc totalement faux de pointer du doigt electron alors que le problème se situe au niveau des technologies employées (HTML/CSS/JS non compilés et éxecutées dans un browser vs code natif compilé). Et c'est bien pour ça que des initiatives sont créées depuis un moment pour améliorer les performances de la stack web (par exemple compiler le JS avec WebAssembly).

avatar reborn | 

@lord danone

Et l’on se retrouve à lancer la grosse machine que chrome est, juste pour taper du texte. Et chaque applications electron lance sa propre instance de chrome.

C’est sur que ceux qui ont du 16-32 go de ram ça ne derange pas.

Mais il faut penser ceux qui ont 8 go de ram et le navigateur chrome deja ouvert avec une vingtaine d’onglets.

Pour moi c’est un gaspillage de ressources et d’énergie.
De base le javascript est téléchargé compilé et exécuté sur l’instant, donc c’est gourmand en processeur et donc en énergie.

Apple n’est pas encore tombé là dedans. ??

avatar C1rc3@0rc | 

«Electron n'est responsable d'aucune lenteur supplémentaire par rapport à un browser classique»

Deja repond a ma question:«Explique moi comment tu fais pour paralléliser massivement un éditeur de texte et en quoi du multithread pourrait ameliorer les performances sur ce type d'application?»
Parce que tu affirmes quand meme que la lenteur vient du monothreading...

Ensuite le probleme c'est qu'avec toutes les conneries qu'on demande - par incompetence ou manque de moyens - de realiser par le navigatteur web, le navigateur web est en train de devenir un gros et gras PC virtuel qui doit tourner a multiple dans un PC, bouffant 100% des ressources pour faire 2 operations...
Tu reconnais que l'erreur est d'utiliser le navigateur web pour des usages totalement inadapés. Ok mais alors pourquoi jsutifier les absurdités "d'optimisation de performances"?

Exemple: le moteur V8 de Chrome est une petite merveille de puissance et d'optimisation, mais s'il s'agit d'une mecanique d'art, c'est totalement absurde, autant qu'un moteur de fusee monté sur un velo!

WebAssembly, parlons en: une ineptie totale: pour ameliorer un peu les performances excecrables des page web surchargées imbecilement alors on developpe... une machine virtuel a pile!!! Ce qui rajoute encore une couche virtuelle dans ce qui est en train de devenir un millefeuilles...

On peut faire moins primitif et plus securisé, mais ce serait moins primitif et plus securisé...

Une page Web, c'est un contenu formaté et balisé pour etre indexable automatiquement, "navigable" par lien semantique et consultable en consommant le minimum de ressources sur le client et sollicitant le moins possible le serveur, faut quand meme se souvenir de ça!
Ca demande un langage de balisage simple et efficace et au maximum un langage de script minimaliste et efficace pour gerer les interactions de formulaire...
Realiser ça demande du langage de haut niveau, pas du niveau assembleur!

Pourquoi ne pas se lancer dans la realisation d'application programmées en TeX, au moins c'est un vrai langage (definition de Turing) des le depart...

avatar occam | 

Pour échapper à cette discussion, ainsi qu'à l'Atom-bashing (et Electron-bashing concomitant) qui semble de rigueur à chaque fois qu'on évoque Atom, je propose l'adoption universelle de Lime.
https://github.com/limetext/lime

Libre, inspiré de Sublime Text, à compiler soi-même de source (ce qui aura l'effet de filtrer tous ceux qui sont remontés contre Atom mais n'ont en réalité aucun besoin d'un éditeur plus rapide), nécessitant Go pour le backend et QML pour le frontend (au choix, termbox) — autre filtre, puisqu'il faut a minima apprendre Go, ce qui a le mérite de l'adéquation des besoins et des capacités.

Quand on s'est tapé Lime, et qu'on l'a vraiment fait avancer, on est légitimé pour enfoncer Atom. Grand-croix et chapeau bas.

Tous les autres, ceux qui utilisent (comme moi) quotidiennement les innombrables packages pour lesquels Atom est indispensable, peuvent s'estimer heureux qu'un Stringbag* polyvalent comme Atom existe — en attendant Xray, parmi la soixantaine d'éditeurs de texte multi-plateforme à notre disposition, et en choisir un autre pour les tâches nécessitant une plus grande célérité.

———
* Stringbag, sobriquet de l'avion d'attaque Fairey Swordfish de la Royal Navy. Biplan (!) leeeeeent, vulnérable et obsolète, il est cependant resté en service de 1936 à 1945, survivant à son successeur désigné.
Et il a coulé le Bismarck. (Bon, pas tout seul, mais il l'a rendu incapable de manoeuvrer, sitting duck pour les tirs groupés.)

avatar Malum | 

Le titre de l’article est faux. Il faudrait ajouter le verbe être au futur, ou mieux encore la combinaison du verbe devoir au conditionnel et être à l’infinitif.

avatar Bigdidou | 

@Malum

"Le titre de l’article est faux. Il faudrait ajouter le verbe être au futur, ou mieux encore la combinaison du verbe devoir au conditionnel et être à l’infinitif."

J'ai beau chercher, je ne vois aucun verbe petre ni avoir dans le titre, puisqu'il est éludé.
Ça pose quand même un gros problème pour les conjuguer.

avatar Hasgarn | 

Le simple fait de lire que ce sera développé avec Rust me rassure. Rust est un fantastique projet avec une philosophie intelligente : reprendre le meilleur de chaque langage sans les problèmes inhérent à ces langages. Il ne fera pas des trucs nouveaux mais il fera tout bien.
https://fr.wikipedia.org/wiki/Rust_(langage)

avatar ovea | 

Pour peut que,
« les blocs match permettant le filtrage par motif, » qui «pourraient déconcerter les développeurs arrivant de langages strictement impératifs ou orientés-objets»,
ne viennent pas encore et toujours refiler des boutons.

Whouha hahahaaaa ;)

Enfin bref ! pour les non-Angiospermes, avec le C++, il reste encore LeX et Yacc … mééé ! C'est dur de changer une équipe gagne jamais

avatar Shralldam | 

C’est dommage que Visual Code Studio utilise Électron, d’ailleurs. Je l’ai essayé récemment et l’ai trouvé plutôt bon, mais pas aussi réactif que Sublime. J’ai vite compris pourquoi… Vraiment dommage car c’est un éditeur de code intéressant, et très personnalisable.

CONNEXION UTILISATEUR