Atom va améliorer ses performances avec des composants natifs
Atom est l’éditeur de code de GitHub et c’est l’un des plus gros utilisateurs d’Electron, ce framework qui permet de créer des apps multiplateformes en utilisant des technologies du web. Après tout, Electron a été également créé par GitHub pour Atom à l’origine, même s’il est désormais utilisé pour des centaines d’autres projets. Il faut dire que c’est un outil très puissant pour créer un logiciel compatible avec macOS, Windows et Linux avec les mêmes compétences techniques que pour un site web.
En contrepartie, les apps conçues avec Electron ne sont pas aussi optimisées que les apps natives et elles sont parfois des gouffres à mémoire vive. La messagerie instantanée Slack est l’exemple toujours utilisé, mais c’est loin d’être le seul. La popularité de ce framework n’aide pas à changer la perception qu’Electron pourrait être le nouveau Flash.
Au-delà des perceptions, les problèmes de performance sont réels et pour en revenir à Atom, ce choix technologique a toujours posé problème pour ouvrir de gros fichiers. C’est précisément pour corriger ce défaut que la prochaine mise à jour intégrera un module natif en C++ pour gérer le texte et l’enregistrement des fichiers. De quoi certainement améliorer les performances dans le domaine, même si l’essentiel de l’app reste développé en HTML, CSS et JavaScript.
En attendant, Atom 1.18 est disponible et cette version intègre GitHub directement dans son interface. Si vous utilisez le service en ligne, vous pourrez publier des modifications de code et garder un œil sur l’activité du projet sans quitter le logiciel.
Atom 1.18 n’est pas traduit en français et il nécessite OS X 10.8 au minimum.
Atom et Xcode, mes deux usines à code principales, qui intègrent GitHub, ça c'est une bonne nouvelle!
Un gouffre à mémoire vive, en effet.
Pour sympathique qu'il soit, Atom est vraiment lourdingue et il y a suffisamment d'équivalents plus performants sur chaque plate-forme pour ne plus l'utiliser.
@bompi
«…y a suffisamment d'équivalents plus performants sur chaque plate-forme pour ne plus l'utiliser…»
Ou alors on travaille sur des projets concrets, comme le développement de Julia, avec des interfaces spécifiques, comme Juno IDE, et l'on se rend vite compte que
1—Atom est "the only game in town" pour bien intégrer son projet
2—un environnement de travail très agréable, très réactif par rapport aux spécificités du projet, souple et modulaire à souhait.
Rien n'oblige à l'utiliser quand on n'en a pas besoin. Mais quand on en a, on réalise combien Atom facilite le travail. Il faut juste éviter de généraliser.
D'accord pour Julia (sans aucun doute le projet sur lequel travaille la majorité des développeurs, c'est connu).
Mais en-dehors de ça, il ne me paraît pas le choix le plus pertinent,
si j'ose exprimer un point de vue.
@bompi
"si j'ose exprimer un point de vue"
Ne vous retenez surtout pas ?.
J'utilise atom quotidiennement et ne me suis jamais rendu compte de comportement particulièrement énergivore (contrairement a slack oui), que ce soit sur macbook 12", mac pro, station linux, et principalement pour du glsl et du python.
J'ai un usage surement basic du soft (3/4tabs max et pas des milliers de lignes), sur quels type de projets l'utilisez vous pour le mettre a defaut ? Des fonctionnalités en particulier peut etre ?
Pour ma part, Atom est lent à l'ouverture de gros fichiers XML, ou quand je travaille sur un projet à plusieurs millions de lignes. On peut avoir l'impression que c'est une situation très anodine mais en fait ça arrive assez souvent. Sublime Text fait bien mieux dans ces situations.
@filaton
"Plusieurs millions de lignes"
Ah oui ok !
Je comprend pourquoi mes petits shaders glsl , scripts pythons/php de 1000 malheureuses lignes ne le ralentissent pas..
@filaton
Plusieurs millions de lignes ? Tu écris 3 OS dans un seul fichier ? ;-)
Comme je le disais dans mon commentaire, c'est assez facile d'arriver à de telles quantités de code. Le projet principal sur lequel je bosse pour l'instant a 1,8M lignes de C/C++ et 150k lignes de Python. Il y a beaucoup de code qui ne change que très rarement mais on est quand même obligé de tout avoir sous la main, au cas où (et pour l'autocomplétion et toutes les fonctionnalités IDE-like).
Et je me souviens d'une conférence d'un ingénieur de chez Google qui expliquait que chez Google, ils appellent "gros projet" un projet au-dessus de 10M de lignes :D
@Nico S
Il a pas dit "dans un seul fichier". Mais dans l'ensemble du projet.
Un projet avec plusieurs développeurs et/ou avec plusieurs années derrière lui, le million est vite franchi.
@byte_order
"Vite franchi" ? Ou pas : http://www.informationisbeautiful.net/visualizations/million-lines-of-code/
@Nico S
Je ne suis que très modérément fan de David McCandless, mais l'infographie dont vous donnez le lien, certainement une de ses réalisations les plus populaires, est celle que j'abhorre le plus.
Je la donne souvent en exemple à ne pas suivre: comment travestir l'essentiel en jouant la clarté et en feignant la transparence.
Deux failles majeures diminuent l'intérêt que ces données pourraient potentiellement présenter dans le débat qui nous intéresse :
1—Le « nombre de lignes » de code est peu informatif au regard du degré très hétéroclite de complexité des données présentées.
Pour que la comparaison soit valable, il faudrait rendre les variables commensurables à une base commune. Par exemple, en convertissant les codes comparés en un même langage.
On en jaugerait le degré d'informativité moyennant des mesures de complexité définies, telles que la complexité de Kolmogorov (élégante mathématiquement, délicate à manier) ou la complexité de Halstead.
https://en.m.wikipedia.org/wiki/Kolmogorov_complexity
Un exemple clin d'oeil :
https://xkcd.com/1155/
Sans une telle mesure commune de l'information, on risquerait de comparer du charabia et une équation en se basant uniquement sur le nombre de caractères en présence.
2—La deuxième faille majeure est l'absence d'uniformité d'échelle.
Je vois bien d'où McCandless tire son inspiration — "Powers of Ten", de Charles et Ray Eames. Mais si les données suivent une distribution approximativement logarithmique (en réalité hypergéométrique, mais peu importe), les sauts d'intervalle de l'infographie n'en rendent pas compte. Sans avoir une idée préalable des échelles en jeu, impossible de saisir d'emblée la vraie variabilité des tailles comparées. Une simple transformation de puissance aurait clarifié les ordres de grandeur. Mais il eût fallu pour cela vouloir faire vrai : expliquer, au lieu de faire joli.
Sublime Text est léger et ne fournira pas toutes les fonctionnalités d'Atom. Mais il est lui-aussi présent sur les plates-formes principales et vraiment bien agréable.
J'apprécie aussi que sa licence soit une licence personnelle, vu que j'ai plusieurs ordinateurs avec chacun plusieurs systèmes : je peux sereinement l'utiliser sur chacun (en plus de vi bien entendu).
@filaton
Tu as des exemples en ligne de tes réalisations? ça doit être des beaux projets!
Alors, j'ai pas vraiment d'exemples en ligne parce que ce ne sont pas des applications graphiques mais j'ai entre autres travaillé au développement du codec audio Dolby AC-4, qui contient pas mal de code :)
Personnellement, le mieux est d’avoir le core du logiciel dans un langage machine compatible tout OS (C++14, Go, Rust) et d’utiliser les interfaces native pour l’UI/UX (Swift/Objective-C pour iOS/Mac, Java/Android SDK pour Android, C#/XAML pour Windows et Qt/Gtk pour Linux KDE/Gnome).
Pour en revenir à Atom, c’est un bon logiciel pour pas mal d’usage mais je préfère textmate comme éditeur léger et IntelliJ comme EDI.
Je viens d'abandonner, la v1.18 est un veau sans nom. J'utilise quelques plugins genre linter, code completion, et ça lag. Et les nouveaux panneaux rétractables dont les poignées jouent à cache cache. Ras le bol. J'aurais tenu environ un an.
Bref, j'entame mon switch vers PyCharm. Java bien géré par un éditeur semble plus performant qu'Electron et la communauté trop exité à ajouter des extensions de piètres performance.