GitHub veut développer un nouvel éditeur de texte multiplateforme et ultraperformant basé sur Electron

Version imprimable

06/03/2018, 16h15
Michael Guilloux

GitHub veut développer un nouvel éditeur de texte multiplateforme et ultraperformant basé sur Electron
GitHub veut développer un nouvel éditeur de texte multiplateforme et ultraperformant basé sur Electron
Xray est encore un projet expérimental

GitHub, le développeur de l'éditeur de texte open source et multiplateforme Atom travaille actuellement sur un nouvel éditeur baptisé Xray et basé sur Electron. Encore en phase expérimentale, on ne sait pas encore si Xray sera à terme une refonte d'Atom ou tout simplement un éditeur de texte de nouvelle génération qui sera lancé en parallèle. Mais d'après GitHub, l'objectif à court terme est de « tester rapidement plusieurs idées radicales sans risquer la stabilité d'Atom ». Ce qui suggère qu'il serait question d'ajouter de nouvelles fonctionnalités à Atom. Xray est d'ailleurs hébergé sur le référentiel d'Atom.

Xray est annoncé comme un éditeur de texte multiplateforme conçu dès le départ autour des priorités fondamentales suivantes :
- haute performance : Xray devrait être léger et réactif. Pour toutes les interactions par exemple, GitHub vise, sur le matériel de l'utilisateur médian, une durée de 8 ms pour le défilement, les animations et interactions comme la frappe ou le déplacement du curseur ; une durée de 50 ms pour les interactions telles qu'ouvrir un fichier ou initier une recherche ; une durée de 150 ms pour ouvrir une fenêtre d'application ;
- collaboration : Xray devrait, selon son développeur, rendre le codage en équipe aussi simple que le codage en solo. GitHub dit en effet concevoir des fonctionnalités pour une utilisation collaborative. Les éditeurs et autres éléments d'interface utilisateur pertinents sont en effet conçus pour être occupés par plusieurs utilisateurs en même temps ;
- extensibilité : Xray veut fournir aux développeurs des API pour leur permettre d'ajouter des fonctionnalités non triviales à l'application ;
- compatibilité Web : l'édition dans Xray devrait ressembler à celle sur GitHub. Pour cela, l'entreprise va fournir un composant d'éditeur riche en fonctionnalités qui peut être utilisé sur le web et dans d'autres applications Electron.
Xray doit donc reposer sur une architecture qui pourrait lui permettre d'atteindre ces objectifs ; une architecture que GitHub résume à travers l'image suivante.

https://www.developpez.com/public/images/news/xray.png

L'interface utilisateur de Xray est construite avec Electron, le framework basé sur Chromium et Node.js qui vous permet d'écrire des applications de bureau multiplateformes en utilisant les technologies du Web (JavaScript, HTML et CSS). GitHub reconnait qu'Electron est susceptible de nuire à sa priorité absolue de haute performance. « Cependant, c'est la meilleure approche que nous connaissons pour fournir une interface utilisateur extensible multiplateforme », explique le développeur d'Atom et du framework Electron. « La question fondamentale est de savoir si nous pouvons obtenir les avantages d'Electron pour l'extensibilité tout en atteignant nos objectifs de performance souhaités. Notre hypothèse est que c'est possible – avec la bonne architecture », a-t-il assuré.

Il faut aussi noter que tout le code de l'application de base en dehors de la logique de vue sera écrit en Rust (qui est un langage rapide et sécurisé par défaut) et rendu accessible à JavaScript via les liaisons N-API. Le choix du langage est très important puisque GitHub cible la haute performance. L'éditeur d'Atom explique encore qu'un langage fondamentalement conçu pour le multithreading comme Rust facilitera l'exploitation du parallélisme chaque fois que le besoin s'en fera sentir, alors que la nature monothread de JavaScript rend le parallélisme difficile.

Avec Xray, les packages s'exécuteront principalement dans les worker threads. GitHub estime en effet qu'un package qui ne se comporte pas correctement ne devrait pas avoir d'impact sur la réactivité de l'application. Et la meilleure façon de garantir cela tout en préservant la facilité de développement est d'activer les packages sur les worker threads.

La manière dont le texte doit être stocké et rendu compte également. Ainsi, le texte sera stocké de sorte à permettre les modifications simultanées de manière optimale et la collaboration en temps réel, en tirant parti de l'avantage unique du parallélisme de Rust. Le texte sera également rendu via WebGL, dans le souci principal d'obtenir de bonnes performances.

Entre autres informations concernant l'architecture de Xray, notons également que les interactions du système de fichiers seront acheminées via un serveur central appelé « serveur d'espace de travail ». En outre, React sera utilisé pour la présentation et le style (CSS) sera spécifié dans JS. GitHub a décidé d'utiliser l'approche « CSS-in-JS » qui génère automatiquement des sélecteurs afin de limiter au maximum le nombre total de sélecteurs. Cela se justifie par le fait que les performances et la maintenabilité du CSS se dégradent à mesure que le nombre de sélecteurs augmente.

Dans sa feuille de route pour le premier trimestre de cette année, GitHub a indiqué que l'objectif principal est de valider les idées clés présentées ici et d'avoir une idée de la durée de développement du système envisagé. Plus concrètement, l'objectif de l'entreprise est de livrer un composant d'édition autonome hautes performances adapté à toute application web, quelque chose qu'elle pourrait éventuellement utiliser sur GitHub.com. Cet éditeur autonome permettra de tester un certain nombre de fonctionnalités critiques dans les scénarios de production sans avoir à créer entièrement un éditeur desktop.

Source : GitHub

Et vous ?

:fleche: Que pensez-vous des objectifs de Xray et de son architecture ?
:fleche: Croyez-vous qu'il y a encore de la place pour un nouvel éditeur ?

Voir aussi :

:fleche: Sortie de la première bêta d'Electron 2.0.0, le framework pour le développement d'applications de bureau multiplateformes
:fleche: Faut-il utiliser Electron pour le développement d'applications de bureau ? Quels sont ses avantages et inconvénients ?
:fleche: GitHub et Facebook veulent transformer Atom d'un simple éditeur de texte en « un vrai IDE », avec le lancement d'Atom IDE
:fleche: Une vulnérabilité critique dans le framework Electron pourrait affecter de nombreuses applications populaires comme Skype, Slack et bien d'autres
06/03/2018, 16h35
AoCannaille

Ultra performant avec du JS? Bon courage...
06/03/2018, 16h42
earhater

Encore un ? Après Atom, sublime text, Visual studio code, et brackets d'Adobe ? Il va falloir qu'il ai des arguments pour convaincre
06/03/2018, 17h11
M_Makia

Je suis du même avis que earhater, "encore un ? ".
Bien que le collaboratif puisse être assez important dans certains projets de développement, à ce jour j'ai du mal à voir la vrai valeur ajouté par rapport d'autres éditeurs de texte.
06/03/2018, 17h13
grunk

Citation:

Envoyé par AoCannaille

Ultra performant avec du JS? Bon courage...

Comme le dit l'article ça ne concerne que la partie graphique. Tout le reste sera en Rust donc des performances proches du C

La plus part des rendus html/js se font sur la carte graphique c'est pas complètement déconnant. QT le fait avec le QML par exemple (sans html) avec des performances tout à fait acceptables.

L'intérêt de venir rajouter un énième éditeur est en revanche discutable , effectivement.
06/03/2018, 17h38
4sStylZ

Citation:

Encore un ? Après Atom, sublime text, Visual studio code, et brackets d'Adobe ? Il va falloir qu'il ai des arguments pour convaincre

Je savais que brackets était prévu pour être collaboratif mais je veux bien que tu m’explique comment faire du collaboratif avec Sublime text 3. Je n’utilise que ça et il est déjà pimpé à mort et je n’avais pas réussi à faire de l’edition « Google drive style » avec.
Des tips ?

Edit :*J’avais éssayé ça et pas moyen de le faire tourner. https://github.com/Floobits/floobits-sublime Le paquet n’a plus de commit de puis 6 mois.
06/03/2018, 17h43
Asdra

Mauvaise foi

Citation:

Envoyé par AoCannaille

Ultra performant avec du JS? Bon courage...

Oui, aucun site connu ne fonctionne bien avec du js, a part quelques sites, comme Facebook, Twitter, Netflix, Instagram, youtube...
Ah, et aucune appli non plus, a part VSCode, Discord, Skype, Slack, WhatsApp, Atom...

On pourras rien en faire je pense, en plus github reconnais lui même dans l'article que electron pourrait être un frein aux perfs.
Il faut sans doute avoir une grande connaissance de ce Framework pour produire un résultat performant et optimisé, qui développe électron déjà?
06/03/2018, 18h02
4sStylZ

Citation:

Envoyé par koyosama

C'est pas eux qui ont fait Atom ???

Si si c’est eux qui font Atom. Qui pour le coup est bien moins performant et tourne sur du JS.

D’ailleurs j’y comprend rien. Atom, concrètement l’exécutable c’est quoi, c’est vraiment du JS interprété à la volée ?*Ce n’est pas compilé ?

J’aurai bien aimé mais je n’ai pas encore vu d’IDE*JS performants, et pour ce qui est des distri linux full cloud en HTML/JS c’est la même.
Atom fonctionne. Certains me diront même qu’ils l’utilisent quotidiennement. Moi les lenteurs me rebutent par rapport à mon bon vieux Sublime (qui a des dizaines de plugins bien couteux en perfs).

Je sais pas ce que vous en pensez vous les devs JS avancés mais j’ai toujours pas l’impression que le JS est pas adapté à des applications avec des interfaces hyper riches et industrielles. Pourtant je baigne un peu dans les technos JS dans ma boite et j’ai vu beaucoup de beaux sites web en JS.
Notre appli Angular est un régal à utiliser et l’interface est assez riche et tourne sur toutes les machines. Par contre on arrive à des limites. Malgré pas mal d’optimisation les devs ont des souvent des soucis avec les nombres de bindings qui évoluent de manière exponentielles :*Plus on ajoute de features, plus l’utilisateur utilise l’appli pour aller loin avec et plus celle-ci rame sur les machines modestes.
06/03/2018, 18h50
RyzenOC

Citation:

Envoyé par 4sStylZ

Si si c’est eux qui font Atom. Qui pour le coup est bien moins performant et tourne sur du JS.

D’ailleurs j’y comprend rien. Atom, concrètement l’exécutable c’est quoi, c’est vraiment du JS interprété à la volée ?*Ce n’est pas compilé ?

J’aurai bien aimé mais je n’ai pas encore vu d’IDE*JS performants, et pour ce qui est des distri linux full cloud en HTML/JS c’est la même.
Atom fonctionne. Certains me diront même qu’ils l’utilisent quotidiennement. Moi les lenteurs me rebutent par rapport à mon bon vieux Sublime (qui a des dizaines de plugins bien couteux en perfs).

Je sais pas ce que vous en pensez vous les devs JS avancés mais j’ai toujours pas l’impression que le JS est pas adapté à des applications avec des interfaces hyper riches et industrielles. Pourtant je baigne un peu dans les technos JS dans ma boite et j’ai vu beaucoup de beaux sites web en JS.
Notre appli Angular est un régal à utiliser et l’interface est assez riche et tourne sur toutes les machines. Par contre on arrive à des limites. Malgré pas mal d’optimisation les devs ont des souvent des soucis avec les nombres de bindings qui évoluent de manière exponentielles :*Plus on ajoute de features, plus l’utilisateur utilise l’appli pour aller loin avec et plus celle-ci rame sur les machines modestes.

je dois surement être un ovni mais moi je développe mes IHM avec un moteur 3D panda3D en C++/Python et de l'opengl pour les parties les plus critiques
Maintenant un éditeur de texte c'est assez basique, je pense pas pas que cela requiert de la grande puissance. C'est pas comme afficher un graphique avec 1 milliards de points par exemple.

Par contre je sais pas si en JS on peut ouvrir intelligement un gros fichier de 10Go par exemple. En C par exemple c'est assez facile avec un buffer on ouvre jamais entierement le fichier de 10Go, mais une partie.

Mais en 2018 n'importe quel langage peut produire un éditeur de texte pour lire des petits fichier de quelques mo.
L'aspect collaboratif c'est juste des sockets (dans des threads j’espère :aie:), rien de gourmand quoi.
06/03/2018, 19h04
xarkam

Citation:

Envoyé par 4sStylZ

Si si c’est eux qui font Atom. Qui pour le coup est bien moins performant et tourne sur du JS.

D’ailleurs j’y comprend rien. Atom, concrètement l’exécutable c’est quoi, c’est vraiment du JS interprété à la volée ?*Ce n’est pas compilé ?

J’aurai bien aimé mais je n’ai pas encore vu d’IDE*JS performants, et pour ce qui est des distri linux full cloud en HTML/JS c’est la même.
Atom fonctionne. Certains me diront même qu’ils l’utilisent quotidiennement. Moi les lenteurs me rebutent par rapport à mon bon vieux Sublime (qui a des dizaines de plugins bien couteux en perfs).

Perso, vscode fonctionne vite malgré les 40 extensions dessus.

J'ai utilisé Atom mais le bug d'atom qui ne répond pas au démarrage m'a saoulé et je suis parti sur vscode.

Je ne regrette absolument pas mon choix d'avoir migré sur vscode.

De temps en temps je reviens sur Atom notamment pour Atom IDE mais, on sent la lourdeur.

Dès lors, je suis assez septique sur un nouvel éditeur de code ultra performant.

Par contre, cette manie de déporter sur le gpu la gestion du rendu donnera un sentiment de lourdeur par ce que le gpu est moins puissant que le cpu dans certaines machines modestes, finira par jouer des tours.
06/03/2018, 22h24
Aurelien.Regat-Barrel

Citation:

Envoyé par 4sStylZ

D’ailleurs j’y comprend rien. Atom, concrètement l’exécutable c’est quoi, c’est vraiment du JS interprété à la volée ?*Ce n’est pas compilé ?

La techno sous-jacente s'appelle Electron, et en gros il s'agit d'une fusion de node.js et de Chromium pour avoir à la fois un backend en javascript (node.js) et du html/js pour le front (Chromium).

Le moteur JS utilisé est V8 (celui de Chrome) qui a cassé la baraque à son arrivée car il n'interprète pas le JS mais le compile en langage machine, ce qui donne de très bonnes perf comparés à ce qui se faisait avant. Et dans une certaine mesure face à du C/C++ c'est très correct (ne pas mélanger la perf js brute avec le coût du rendu d'un html volumineux).

Ce qui caractérise node.js c'est l'omniprésence de l'asynchrone : en C, de façon basique, quand tu lis un fichier, ton appli reste bloquée tant que les données n'ont pas été effectivement lues depuis le disque par l'OS. En mode asynchrone, tu fournis une callback qui sera exécutée une fois les données lues. Du coup, en attendant que ça se passe, tu peux exécuter d'autres portions de code, ce qui permet de bonnes perf côté serveur et aussi d'éviter de freezer l'UI côté front.

Pourquoi cette techno est-elle si populaire pour des clients lourds? Quelques pistes (à mon avis):
- portabilité : la portabilité en C/C++ est coûteuse pas tant au niveau du source que de la nécessité de compiler et tester pour chaque plateformes visées. Là on s'appuie sur un framework qui affranchit de tout ça.
- plugins : c'est facile et accessible de développer des plugins en js/typescript + html, par rapport à du Java ou .Net (ne parlons pas de C++) : rien besoin d'installer !
- accessibilité du langage : JS et html est un couple efficace pour faire des UI dynamiques : pas besoin d'apprendre un nouveau langage spécialisé par rapport aux autres technos (QML, XAML...)

Pour moi le plus gros inconvénient est le temps de chargement un peu long (GitKraken en particulier...) et le poids total de l'application (on livre un navigateur web complet...). Niveau perf, dans l'ensemble, ça tourne bien quand même tant que l'UI n'est pas trop chargée ce qui est le cas la plupart du temps quand on développement (la colorisation syntactique de dizaines de Mo de texte, c'est ça qui fait très mal car ça génère un doc html bien bien balaise).
09/03/2018, 15h00
AoCannaille

Mauvaise foi partagée

Citation:

Envoyé par Asdra

Oui, aucun site connu ne fonctionne bien avec du js, a part quelques sites, comme Facebook, Twitter, Netflix, Instagram, youtube...

Tout à fait. Ils fonctionnent tous très bien et utilisent tous plusieurs cinquantaines de méga de ram si ce n'est plusieurs centaines, mais cela fonctionne, tant mieux c'est fait pour. Est-ce que c'est "ultra performant" pour autant? Bof, a part netflix, il n'y a pas de client lourd avec quoi comparer...

Citation:

Ah, et aucune appli non plus, a part VSCode[...]

On parle d'un éditeur de texte pour une utilisation professionnelle avancée, en mode super user.

Entre VsCode et notepad ++, un test simplissime pour montrer l'infériorité du JS face au C++ est de faire une recherche dans tous les fichiers d'un dossier assez conséquent.

Pour mon projet : 150 kloc, 40 000 fichiers, pour trouver 100 occurences, environs 15 sec pour Notepad++, environ 4 minutes (plus passage en "ne réponds pas") pour VsCode.

Perso je reste sceptique, mais je l'essayerais, comme j'ai essayé les autres, on est jamais à l’abri d'une bonne surprise. Mais du coup, je m'attend à du "Au mieux aussi performant" que ce que j'ai déjà, et pas du "ultra performant".

Citation:

Ah, et aucune appli non plus, a part [..] Skype[...]

Skype depuis l'achat de microsoft n'a que baissé en qualité de ce que j'ai vu... Je ne le lance même plus. Je ne suis pas expert, mais ça se trouve ce n'est pas concomitant avec le changement P2P --> Centralisé, mais plus avec le changement de techno du client. Tu fais bien de me le signaler, je n'avais jamais fait le lien.