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.

avatar Hydrog3n | 

C'est du troll ? Ils utilisaient déjà ajax car je ne sais pas comment tu peux faire des requetes à une API. Passer à reactjs ne veut pas dire qu'ils n'en utilisaient pas avant...
De plus ils utilisent aussi des Websocket pour le temps réél et d'autre features comme les notifications.

Pour info Jira est développé avec Reactjs

avatar marc_os | 

@Hydrog3n

C'est qui "ils", Slack ou Atlassian/Jira ?

Je réagissais essentiellement à ce passage de la brève au sujet de Slack :
« 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 suggère qu'ils n'utilisaient pas d'Ajax.

Quant à Jira chez Atlasian, ils peuvent bien utiliser Reactjs, si ce qu'ils veulent implémenter est foireux, et bien le résultat est foireux.
Exemples de modifications malheureuses :
- Si on veut sélectionner du texte dans la description d'un ticket par un double clic, le champs passe alors en mode édition même si on n'est pas l'auteur du ticket ! Ensuite on doit refaire sa sélection puis cliquer sur le bouton Cancel situé sous le champ, et hors vision si la description est longue et contenant des images, forçant ainsi à scroller.
- Si on choisit d'afficher les tickets ouverts, alors la largeur de la colonne contenant la ilste des tickets avec à droite le contenu du ticket sélectionné, alors cette largeur est fixe et pas très large, résultant en des lignes sur trois lignes ! Pour pouvoir modifier sa largeur, il faut passer en mode avancé.
- As-tu essayé d'éditer des tableaux avec la nouvelle interface ? Une plaie.
Rien à voir avec la techno, les bases même de leur interface a été gâchée lors de leurs dernières mises à jour effectués au fil de l'eau.
- Autre exemple: Nous avons du revoir plein de templates parce qu'ils ont changé la disposition des champs, avec certains qui sont passés de gauche à droite, certains qu'on peut changer de côté, d'autres non, d'autres qui sont masqués.
- Et je ne parle pas de l'espace entre les champs, pour avoir une vue d'ensemble il faut soit dézommer à mort pour avoir au final du texte microscopique, soit afficher le ticket sur un écran 27". (J'exagère à peine.)
Etc, etc.

avatar fte | 

Il y a un truc que vous ne réalisez peut-être pas.

Les applications Electron sont natives. Ce sont des applications natives au web, exécutées dans une application native à chaque plateforme.

Le problème n’est ni que c’est natif ou non, le problème n’est pas qu’il y ait une indirection de plus - il y en a déjà plusieurs sur ce qu’on admet communément comme natif -, le problème n’est pas que ce n’est pas performant ou gourmand.

Le problème, au delà de l’absence d’optimisation, étape délicate, longue, coûteuse, difficile à maintenir, est le web. Le web tout entier est un patchwork d’horreurs mal branlées scotchées ensemble et plongées dans du WD40 pour que ça puisse bouger un peu. Le web est tout pourri. Voilà le problème.

avatar oxof | 

@fte je me disais pareil ce matin. HTML, javascript et CSS c'est juste l'horreur. Pour maîtriser tout ça et avoir une interface un peu réactive sur toutes les plateformes il faut juste être le roi de la bidouille.

A mon avis c'est pour ça que sont apparues les interfaces minimalistes ou "flat". Au moins pour simplifier ce côté là du boulot.

avatar oomu | 

si y a une interprétation, par exemple, un moteur javascript/html/css ( webkit, v8, chrome, etc) alors ce n'est PAS natif.

une app python n'est pas native, combien même évidemment le runtime python est du code natif à la plateforme (j'imaginerais bien un interpréteur python en perl par dessus electron...)

Native c'est que c'est du code interprété directement par le CPU qui appelle les APIS du système d'exploitation, et pas d'intermédiaire.

Dans electron, ça tourne par dessus node.js, et node.js utilise une MACHINE VIRTUELLE.

-
Le plus fou, c'est qu'avec Electron, en plus des millions de bugs et failles de sécurité du systeme d'exploitation on y ajoute ceux du Runtime Electron, qui compile tous ceux des moteurs Webs et tous les vecteurs d'attaques javascript/css.

Bah, c'est pour ça qu'il faut de base, confiner les applications utilisateurs et leur enlever toute flexibilité, hein ? pour votre bien hein ? *sarcasme blasé*

-
le framework est NATIF à macOs (encore heureux), tout comme le plugin FLash était natif à macos

MAIS PAS L'APPLICATIF !

et ça fait une montagne de différence.

C'est la différence entre "oui bon, ça marchote, mais c'est moins cher hein" et "c'est le meilleur logiciel du monde pour Mac, et c'est mieux que sous windows haha ! ha oui, c'est exclusif, ha oui il est vendu plus cher, non c'est pas gratuit..."

Quand vous virez mozilla, electron, chrome, flash, java, et n'importe quoi d'autre vous enlevez un intermédiaire qui est très coûteux.

et en plus de cela oui, javascript, _HTML/CSS_ n'ont jamais été pensé lors de leur conceptualisation puis diffusion comme une plateforme APPLICATIVE.

C'est vraiment du bricolage au forceps, parce qu'apprendre à faire une page web est plus aisé qu'apprendre à faire un logiciel Swift/AppKit ou Windows/MFC/C#
et qu'ensuite, les ingénieurs et leur patron veulent recycler des compétences déjà apprises. (ha ben vi, ça coûte moins cher que de se former à d'autres trucs).

-remarque-
Des fois, des subtilités peuvent compliquer la compréhension et faire qu'on se mélange. Par exemple, avec Objective-C on est presque dans un entre deux, le runtime objective-C étant intégré aux apps pour fournir des services, mais le code objective-C est compilé pour le processeur de la machine. L'app est bel et bien native, malgré la présence d'un moteur de message Objective-C.

avatar fte | 

@oomu

"Native c'est que c'est du code interprété directement par le CPU qui appelle les APIS du système d'exploitation, et pas d'intermédiaire."

Il n’y a pas pas d’intermédiaire. Les processeurs embarquent du micro-code et les instructions hardware ne sont plus depuis longtemps les instructions de l’ISA programmeur. Le code natif n’existe plus, tout est interprété.

Quelle interprétation rentre encore dans le cadre du natif ?

Un compilateur JIT, natif ?

WebAssembly, natif ?

Lua, natif ?

Une app Swift compilée et distribuée en IL, compilée pour installation, est-ce vraiment une app native ?

Une app Marzipan, compilée, mais avec cette surcouche d’API, native ?

Natif veut tout dire et rien dire.

Une app dont l’interface est soignée et conforme aux guidelines de la plateforme sur laquelle est tourne, même en JavaScript pas minimisé et Electron est selon moi plus native qu’une bouse Marzipanifiée sans adaptation ou une app Cocoa à l’interface datant de NeXTSTEP.

Après, chacun peut choisir sa définition de natif.

avatar fte | 

@oomu

"le framework est NATIF à macOs (encore heureux), tout comme le plugin FLash était natif à macos

MAIS PAS L'APPLICATIF !"

Ah. Natif à macOS.

Il n’y a dans ce cas que les apps Swift ou ObjC pure Cocoa qui sont qualifiées.

Une app C++ usant de la librairie standard C++ ne peut l’être. Ni une app Marzipan.

Les apps Adobe ne sont pas natives du coup. Pas mal d’app Apple non plus.

avatar oomu | 

le web est une excellente plateforme de document hypertexte.

avatar fte | 

@oomu

"le web est une excellente plateforme de document hypertexte."

Bof. Quand il faut 5 GB de mémoire pour de l’hypertexte, ce n’est plus tellement excellent. Supportable on dira.

avatar byte_order | 

@fte
> Le web tout entier est un patchwork d’horreurs mal branlées scotchées ensemble et
> plongées dans du WD40 pour que ça puisse bouger un peu.
> Le web est tout pourri. Voilà le problème.

Le web, c'est le chaos.
Mais on a déjà essayé l'option cathédrale, et cela n'a pas produit Internet, cela a produit des réseaux fermés sur eux-même sans aucun dynamisme.

L'entropie galopante est le carburant d'Internet, réseau de tous les réseaux, nulle surprise que les technologies qui la soutiennent en fasse partie.

avatar occam | 

@byte_order

"L'entropie galopante est le carburant d'Internet"

J’aime bien cette observation.
Je travaille actuellement sur les réseaux entropiques (dans des domaines qu’il serait trop long à exposer ici), et ça cadre.
Surtout, la croissance de l’entropie est épatante. Ou effrayante. Ça dépend de l’optique.

avatar Bigdidou | 

« La messagerie instantanée Slack est célèbre parce qu’elle est très utilisée, notamment dans le monde de l’entreprise »

Je connaissais même pas le nom.
C’est étonnant de voir à quel point le monde médical est tradi (fax, répondeur, péniblement les SMS...) et à l’écart du monde numérique alors même qu’il utilise quotidiennement des technologies de pointe.

avatar fte | 

@Bigdidou

Je ne serais pas surpris que le secret médical y soit pour quelque chose.

Je me réjouis que les problèmes de santé de mes proches ne soient pas discutés sur Slack, Hangout ou autres machins dont la confidentialité est tout sauf absolument garantie.

avatar Bigdidou | 

@fte

« Je ne serais pas surpris que le secret médical y soit pour quelque chose. »

Je ne suis par certain qu’un SMS soit plus sécurisé, ou même un mail sachant que l’utilisation des messageries sécurisées dédiées restent un veux pieu.

Par ailleurs il y a bien d’autres sujets de conversation que des cas particuliers non anonymisés... ;)

C’était une réflexion générale à propos des outils qu’on met à notre disposition et qui ont toujours une ou deux (ou même plus) générations de retard.

Il suffit de regarder n’importe quel logiciel de gestion de dossiers médicaux pour s’en convaincre.

avatar oomu | 

@bigbidou

ce n'est pas nécessairement une mauvaise chose;

Slack, salesforce, etc sont très communs en pme/startup/société de service parce que ça porte/externalise des fonctions d'administration de votre entreprise.

Mais il y a des coûts : abonnements, forfaits, dépassement de forfait, licences par utilisateur ou site, etc.

et bien sur, tout ce que vous y mettez n'est pas chez vous mais chez un TIERS, qui vous a promis juré être le meilleur des mammifères bipèdes.

avatar marc_os | 

@Bigdidou
T'inquiètes, tu ne perds pas grand chose à ne pas connaître Slack.
De plus, je n'apprécierais pas que Google entre par la bande dans le monde médical, ils sont déjà assez omni-présents ! Ils sont peut-être déjà dans le monde médical, mais c'est pas la peine de les inviter dans des conversations sensibles !

avatar lord danone | 

Quel est le rapport entre slack et google?

avatar marc_os | 

@lord danone
Chromium.

avatar lord danone | 

@marc_os

Et du coup? Chromium est un soft open-source, je vois pas le rapport

avatar vincentn | 

@lord danone

Chromium, c’est Google. Alors oui c’est Open Source, mais c’est Google qui décide in fine des orientations de ce projet. L’empreinte de Google est tellement prégnante, qu’il existe même une version « fork » ungoogled, pour enlever tous les appels et web services Google présents dans ce soft à la base. Oui ce soft Open Source. Et je parle même pas de la problématique widevine (équivalent Google de FairPlay pour les vidéos avec DRM).

avatar Hydrog3n | 

Pas du tout tu voudrais faire comment pour avoir de la data ?
Par ils je parlait de slack.
Ajax comme tu l’as dit est utilisé depuis très longtemps et dès qu’il y a une application en SPA (single page application)

D’ailleurs react utilise du html aussi juste il a un système de DOM virtuel qui permet de rafraîchir les infos plus simplement et moins lourd.
Je pense qu’en voulant expliquer simplement c’est mal passé pour certain.

Pour Jira, j’irais pas plus loin je ne l’utilise plus depuis 1an mais j’ai vécu la migration affreuse je te l’accorde.

avatar brunofridl | 

Je ne comprends pas la dernière phrase « elle fonctionne mieux si la connexion internet est coupée » ?
Slack ne sert à rien sans internet

avatar byte_order | 

@brunofridl
Je pense qu'on parle de mieux résister aux déconnexions temporaires

C'est sur que si aucune ne réussi jamais, Slack ne sert en effet à rien ;-)

avatar lord danone | 

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

Comment peut on écrire des betises pareilles? Slack tourne également sur n'importe quel navigateur et consomme tout autant que sur electron, et forcément : ce qui consomme de la RAM c'est la VM Javascript (qui sera quasi identique sur n'importe quel browser), c'est le CODE pondu par les devs slack. Comme d'habitude vous faites un procès à Electron alors que le responsable est le combo HTML/JS/Code pourri.

avatar Bil | 

Moi j’ai surtout remarqué qu’il ne parle plus un mot de français !!
Tous mes messages sont soulignés en rouge lorsque je tape un texte

CONNEXION UTILISATEUR