IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Autres EDI Discussion :

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


Sujet :

Autres EDI

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 875
    Points : 86 930
    Points
    86 930
    Billets dans le blog
    2
    Par défaut 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.


    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 ?

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

    Voir aussi :

    Sortie de la première bêta d'Electron 2.0.0, le framework pour le développement d'applications de bureau multiplateformes
    Faut-il utiliser Electron pour le développement d'applications de bureau ? Quels sont ses avantages et inconvénients ?
    GitHub et Facebook veulent transformer Atom d'un simple éditeur de texte en « un vrai IDE », avec le lancement d'Atom IDE
    Une vulnérabilité critique dans le framework Electron pourrait affecter de nombreuses applications populaires comme Skype, Slack et bien d'autres
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 412
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 412
    Points : 4 729
    Points
    4 729
    Par défaut
    Ultra performant avec du JS? Bon courage...

  3. #3
    Membre éprouvé
    Homme Profil pro
    Consultant en technologies
    Inscrit en
    Juin 2013
    Messages
    277
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant en technologies
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juin 2013
    Messages : 277
    Points : 1 011
    Points
    1 011
    Par défaut
    Encore un ? Après Atom, sublime text, Visual studio code, et brackets d'Adobe ? Il va falloir qu'il ai des arguments pour convaincre

  4. #4
    Membre averti Avatar de M_Makia
    Homme Profil pro
    dev
    Inscrit en
    Février 2008
    Messages
    121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Saône (Franche Comté)

    Informations professionnelles :
    Activité : dev
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2008
    Messages : 121
    Points : 338
    Points
    338
    Par défaut
    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.

  5. #5
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    Citation Envoyé par AoCannaille Voir le message
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  6. #6
    Membre éprouvé Avatar de 4sStylZ
    Homme Profil pro
    Null
    Inscrit en
    Novembre 2011
    Messages
    314
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Null
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2011
    Messages : 314
    Points : 1 056
    Points
    1 056
    Par défaut
    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.

  7. #7
    Nouveau membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2015
    Messages
    19
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Mars 2015
    Messages : 19
    Points : 31
    Points
    31
    Par défaut Mauvaise foi
    Citation Envoyé par AoCannaille Voir le message
    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à?

  8. #8
    Membre éprouvé Avatar de 4sStylZ
    Homme Profil pro
    Null
    Inscrit en
    Novembre 2011
    Messages
    314
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Null
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2011
    Messages : 314
    Points : 1 056
    Points
    1 056
    Par défaut
    Citation Envoyé par koyosama Voir le message
    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.

  9. #9
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par 4sStylZ Voir le message
    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 ), rien de gourmand quoi.

  10. #10
    Membre éprouvé
    Profil pro
    Développeur .NET
    Inscrit en
    Février 2005
    Messages
    363
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2005
    Messages : 363
    Points : 1 034
    Points
    1 034
    Par défaut
    Citation Envoyé par 4sStylZ Voir le message
    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.

  11. #11
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 749
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 749
    Points : 10 666
    Points
    10 666
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par 4sStylZ Voir le message
    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).

  12. #12
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 412
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 412
    Points : 4 729
    Points
    4 729
    Par défaut Mauvaise foi partagée
    Citation Envoyé par Asdra Voir le message
    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...

    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".

    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.

Discussions similaires

  1. Réponses: 59
    Dernier message: 20/12/2019, 17h05
  2. Réponses: 1
    Dernier message: 22/01/2014, 18h35
  3. Réponses: 26
    Dernier message: 20/10/2010, 20h38
  4. Réponses: 209
    Dernier message: 16/10/2010, 16h03
  5. Texte dans la marge DU BAS sur chaque page
    Par kwazikwantik dans le forum Mise en forme
    Réponses: 2
    Dernier message: 19/05/2008, 19h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo