Slack optimise son client desktop sans abandonner Electron

Nicolas Furno |

La messagerie instantanée Slack est célèbre parce qu’elle est très utilisée, notamment dans le monde de l’entreprise, mais aussi parce que cette app est notoirement gourmande en mémoire vive. Le client macOS peut facilement consommer plusieurs gigaoctets de RAM, alors même qu’il ne s’agit « que » d’une messagerie basée essentiellement sur le texte.

La raison de cette gourmandise est bien connue : plutôt que de créer des apps natives sur chaque plateforme, Slack fait confiance au framework Electron qui permet de créer des apps avec les technologies du web. C’est pratique et rapide, mais ce framework créé par GitHub est connu pour sa gourmandise, au point que certains le comparent même à Flash.

Slack 4 sur macOS.

Bonne nouvelle toutefois, Slack a sorti une toute nouvelle version de son client Desktop ! L’entreprise annonce avoir « reconstruit » l’app avec comme objectif une optimisation des performances et surtout une réduction de la mémoire vive consommée. Ce n’est pas une réécriture complète néanmoins et Electron est toujours utilisé sous le capot, ce n’est pas plus une app native qu’avant. Mais comme Microsoft l’a prouvé avec son éditeur de code Visual Studio Code, une app Electron peut être correctement optimisée et même afficher des performances proches d’une app native.

L’ancienne version de Slack était construite comme un site web traditionnel, essentiellement en HTML, ce qui imposait certaines contraintes. L’intégralité de la fenêtre devait être mise à jour dès qu’un élément changeait, ce qui n’est pas optimal, et surtout, il y avait un espace distinct pour chaque équipe Slack utilisée. C’est là que le problème de mémoire se posait : il fallait compter entre 300 et 400 Mo de RAM par équipe ou encore plus de 2 Go pour cinq équipes.

Avec la nouvelle version, l’app fonctionne totalement différemment. L’interface est générée avec React, le framework JavaScript de Facebook qui sert aussi à créer des apps iOS et Android. L’avantage de cette approche est la modularité, chaque composant de l’interface est indépendant et peut-être mis à jour seul. Par ailleurs, toutes les données sont chargées quand c’est nécessaire uniquement, ce qui accélère les opérations. Et surtout, il n’y a plus qu’une seule instance de Slack, quel que soit le nombre d’équipes que vous utilisez au quotidien.

Consommation de mémoire vive de l’ancienne version de Slack à gauche, la nouvelle à droite. Si vous n’avez qu’une seule équipe, vous ne verrez pas vraiment de différence, mais au-delà, c’est spectaculaire.

Ce dernier changement est le plus significatif en termes d’optimisation mémoire, puisque Slack ne devrait plus jamais dépasser les 500 Mo de RAM en utilisation. Une optimisation très appréciable si vous utilisez l’app avec plusieurs équipes, mais si vous attendiez une app native plus proche de macOS, ce n’est pas cela du tout. Les créateurs de Slack ne connaissent manifestement pas très bien le système d’Apple d’ailleurs, sinon auraient-ils choisi le raccourci ⌘, pour afficher les raccourcis clavier ? Rappelons qu’il sert normalement à afficher les préférences d’une app…

Cette quatrième réécriture complète de l’app desktop de Slack ne convaincra sans doute pas ses détracteurs, mais les optimisations sont toujours bonnes à prendre. Outre la consommation réduite de RAM, Slack devrait aussi se lancer 33 % plus vite et elle fonctionne mieux si la connexion internet est coupée. Si vous utilisez l’app, que pensez-vous de cette mise à jour ?

avatar fte | 

Pour ma part, je n’ai guère remarqué de différence.

Mais je soupçonne que deux facteurs expliquent au moins en partie cela. D’une part mes machines sont gavées en mémoire, et d’autre part j’ai une partie de mes chats qui se sont déplacés vers Microsoft Teams. Je remarque une grande différence entre Slack et Teams par contre. Teams est très efficace.

avatar occam | 

@fte

"Teams est très efficace."

Idem.

avatar Ded77 | 

L’app iOS étant adaptée pour l’iPad, le coût pour la passer en app native sous mac devrait être faible (Project Catalyst).
Il reste encore un espoir…

avatar pat3 | 

@Ded77

Les apps iOS ne peuvent pas être écrites à partir du framework Electron? Elles doivent nécessairement être natives ?

avatar Ded77 | 

@pat3

J’ai pas bien pigé la question.

Électron est un framework qui permet de faire une coquille « native » autour d’un site web pour mac.

On peut faire pareil pour une app iOS : une app native qui embarque une webview qui affiche un site web.

Ces applis sont écrites en HTML/JavaScript.

Une « vraie app native » est développée avec Xcode et est écrite en Swift (ou Objective-C).

avatar jean_claude_duss | 

@Ded77

Y’a plein d’autres trucs pour faire de vrai apps natives sans qu’elle soit en objc ou en swift.

avatar MacTHEgenius | 

@jean_claude_duss

Non. Une app est qualifiée native lorsqu’elle est développée avec le Software Development Kit (SDK) du développeur de la plateforme. Ici on parle d’Apple avec tous les framework disponibles pour iOS: UIKit, CoreData, CloudKit, CoreLocation, etc. (C’est simplifié, il y en a une petite centaine, je crois)

Le reste (soit React Native, Xamarin, Ionic Cordova) est une surcouche par-dessus le SDK d’Apple avec tous les problèmes que cela peut engendrer. C’est un beau rêve le _cross-platform_, mais impraticable de manière concrète.

Le seul framework qui soit intéressant pour le faire c’est SwiftUI, fait par Apple pour Apple. Cependant, ce n’est pas du _code once, run everywhere_, mais du _learn once, apply everywhere_. (tirer d’une des présentations de SwiftUI à la WWDC 2019) Chaque plateforme, chaque paradigme, chaque manière d’interagir avec l’écran demandera une implémentation différente de la logique de présentation. Seulement les bases seront les mêmes.

avatar Ded77 | 

@MacTHEgenius

Réponse parfaite 👌

avatar byte_order | 

@MacTHEgenius
> C’est un beau rêve le _cross-platform_, mais impraticable de manière concrète.

Attention à ne pas confondre impraticable (ne fonctionne pas en pratique) avec expérience non homogène (fonctionne mais pas de manière identique partout).

Car le cross-plateform c'est ce que est pratiqué par les technologies du Web, de HTTP 1.0 + HTML 1.0 jusqu'au dernières technos, et ce depuis près de 20 ans déja : quelque soit votre plateforme, le service est accessible. Ca marche depuis des PC Windows, Linux, des macs, des smartphones sous iOS, Android, des trucs bizarres comme les TV connectées ou l'écran de votre véhicule connecté.

Enfin, sauf quand son développeur a volontairement cibler qu'une plateforme et une seule.
Mais, ça, y'en a aura toujours des gens comme ça.

avatar MacTHEgenius | 

@byte_order

Oui effectivement, vous avez raison. J’aurais dû préciser le cross-platform entre interaction souris+clavier et interaction tactile.

avatar SimR69 | 

J’ai surtout remarqué que le script shell que je lançais après chaque mise à jour pour passer l’application en «mode sombre» (bidouillé) ne fonctionne plus désormais.
À la lueur des explications de votre article, c’est plutôt logique finalement, mais ça reste regrettable pour moi qui n’ai que des applications en mode sombre à côté.
J’espère qu’ils proposeront nativement l’option dans un avenir proche.

avatar Ramlec | 

@SimR69

De mémoire il est possible de changer les couleurs de l’interface en rentrant un code hexadécimal dans le chat. Et d’avoir un mode sombre du coup mais je ne sais plus si cela prend la fenêtre du chat en elle-même 🤔

avatar reborn | 

Toujours 500 mo de RAM pour une app de tchat.

avatar fte | 

@reborn

La mémoire est cheap, utilisons-la. Sauf chez Apple, OK. Dammit.

avatar reborn | 

@fte

Bien sur, maintenant faut avoir 32 go de RAM pour faire de la bureautique et du web

avatar fte | 

@reborn

Yep. 32 GB étaient assez pour mes usages depuis... 2008 ? Cette année, mon standard bureau est passé à 64 GB.

C’est plutôt pas mal comme durée de vie, 11 ans.

avatar vincentn | 

Quelle plaie Electron. Lourd, consommateur de ressources, pas vraiment et totalement intégré au système…
J’ai le sentiment que de plus en plus de boîtes ou fondations, même les plus grosses ayant pourtant les moyens, passent par ce framework pour développer leurs apps multiplateformes, plutôt que faire du natif. Cela en est désolant. Dernier exemple en date que j’ai découvert : la prochaine version majeure de Zotero, pourtant déjà non native, qui passe à Electron abandonnant ses fondations Firefox.

Il y a aussi un effet de bord que l’on a tendance à oublier. Electron est basé sur Chromium/Blink, donc Google, qui a la main mise sur la direction prise par ce dernier. Cela renforce ainsi le poids de Google sur le web, ce qui est mauvais pour la diversité voire dangereux et inquiétant.
Les développeurs créent une app Electron, transposent cette experience sur le web, et l’on se retrouvent avec un web optimisé et adapté pour Chrome, laissant de côté Firefox, WebKit, etc. Retour à la situation et époque d’Internet Explorer, en pire.

avatar reborn | 

@vincentn

la prochaine version majeure de Zotero, pourtant déjà non native, qui passe à Electron abandonnant ses fondations Firefox.

😱🤮

avatar marc_os | 

@vincentn
Fort heureusement le site web de Slack fonctionne correctement avec Firefox. Je l'utilise au quotidien. Mais y a peut-être des trucs que je n'ai pas vus.
Quoiqu'il en soit, quelque soit la techno utilisée, l'interface de Slack, son concept, c'est juste a pain in the ass.

avatar occam | 

@vincentn

"un web optimisé et adapté pour Chrome, laissant de côté Firefox, WebKit"

Effet Reversi.

On peut maximiser ses gains à court et moyen terme en clôturant son pré carré. Comme Apple.
Mais à plus long terme, celui qui rafle la mise est celui qui contrôle de facto les standards.

avatar Tahoooe | 

Si toute l’interface était en HTML, c’est d’autant plus drôle qu’ils mettent des mois à déployer leur dark mode. Corrigez moi si je me trompe, mais trois règles CSS suffiraient à faire le travail...

Je vais tester cette mise à jour par curiosité mais je resterai sûrement sur Sblack rien que pour ça, qui n’est pas forcément plus léger mais qui au moins n’arrache pas les yeux quand tout le reste de l’interface de l’ordi est sombre.

avatar Deckard | 

D'un côté on a des jeux qui affichent 120 images/s avec de la 3D très réaliste et d'un autre on a des client de chats qui bouffent 500 MB de RAM.

avatar byte_order | 

Les jeux 3D qui affichent 120 images/s aussi consomment beaucoup de mémoire pour cela.

avatar Deckard | 

Oui mais ils n'affichent justement pas que du texte mis en forme...

avatar marc_os | 

Les développeurs de Slack découvrent l'Ajax seulement en 2019 ??
Sont vachement en avance les mecs avec cette techno qui date de plus de 10 ans.
Pas étonnant que cette merde soit une si belle bouze.
Depuis un an notre direction a choisi ce machin, et j'ai vite fini par abandonner l'app (côté Mac) pour le site web. Le concept de l'interface est tout aussi pourri sur le web, vu que c'est le même, mais le site est plus fiable.
Pas d'historique de navigation, recherche sur des conversation de plus d'une ou deux semaines pénibles, possibilités de formatage du texte foireuses, la pseudo aide qui affiche les codes de formatage qui s'affichent quand ils veulent sous le champ de saisie, mais jamais en édition pour modification, la liste est longue, et je ne parle pas de la gestion des "préférences".
Tout ça pour une messagerie.

Ça me fait penser à Atlassian.net qui a "modernisé" son interface de Jira pour en faire une grosse merde qui fait râler tout le monde chez nous, et ils n'ont visiblement pas fini. Ou alors ils ont oublié plein de trucs y compris la QA sur leur bazar... Bref.

Pages

CONNEXION UTILISATEUR