Dans un billet publié cette nuit, le réseau social fait un bref rappel de ses habitudes. Les développeurs peuvent en effet utiliser ce qu’ils veulent, mais beaucoup se servaient de Nuclide, outil interne basé sur Atom et comportant de nombreuses fonctions conçues spécifiquement pour les besoins de l’entreprise.
Nuclide a pris sa retraite en 2018, mais continuait d’être parfois utilisé en interne. Facebook s’est progressivement tourné vers Visual Studio Code, adaptant petit à petit les fonctions internes en extensions, via l’API fournie par l’IDE.
Facebook juge le projet open source de Microsoft fiable et sérieux, au point de recentrer toute sa stratégie de développement dessus, avec comme points fort son aspect multiplateforme (Linux, macOS et Windows) et son interface de programmation pour les extensions.
Mais Facebook annonce surtout qu’elle aidera activement Microsoft dans le développement de la partie « Remote » de Visual Studio, pour améliorer les extensions permettant de travailler sur des environnements hébergés sur des serveurs.
Le travail déjà accompli a permis de se débarrasser de Nuclide, dont les développements ont été rapportés à Microsoft sous forme de pistes d’améliorations. En outre, tous les apports réalisés sur les extensions concernées sont disponibles dans la Marketplace de Visual Studio Code.
Commentaires (10)
#1
Ah ? Parce qu’il y à des gens qui code ces appli qui pèsent plus de 150Mo ?
Franchement c’est une honte de créer un truc pareil, leur seule priorité ça devrait être de faire de FB lite la version de base ! …
#2
Excellente news car les fonctionnalités remote de VSCode sont prometteuses mais encore bugguées.
#3
Tu as testé Atom et Vscode ? (j’ai testé le second hier, je pense que je vais basculer dessus)
Ce sont de vrais IDE, à des années lumière de N++ ou Sublimetext.
#4
#5
J’utilisais à l’époque VScode pour la prise de note quand j’étais sur un PC Windows. C’était pour mon usage le meilleur logiciel de prise de notes (sauvegarde automatique, dark theme etc.)
#6
Certes, mais sur windows phone c’était la même…
J’ai retrouvé une étude de l’exécutable à l’époque qui estimait à 50Mo le nombre de binaires en double…
https://www.igen.fr/app-store/2017/04/facebook-le-microsoft-word-des-temps-moder…
Alors je m’interroge et c’est surement débile mais pourquoi alors qu’on a des outils de plus en plus performants que nos smartphone intègrent des briques logiciel de plus en plus poussées et que les applis consomment de plus en plus de data (et de ressources) doivent elle peser un poids “dément” ?
Facebook n’est rien de plus qu’une interface de lecture de contenues sur laquelle se greffe des outils et des trackers. Pour quelle raison doit elle peser si lourds ?
Quand on voit la consommation énergétique d’un Mo téléchargé on se rend compte qu’une appli téléchargé plusieurs dizaines de millions de fois pourrait faire l’effort de maigrir…
Je connais pas assez le codage mais si vous pouvez me dire pourquoi l’obésité est devenue la règle je suis tout ouïe.
#7
C’est pas ce que je voulais dire par “facebook ce n’est pas qu’une APK pour android. “. Facebook c’est d’abord un site web, une base de donnée, c’est aussi de la recherche (Caffe2 un framework de deep learning par exemple)….
A passage, ce n’est aps des binaire en double, mais plus des ressources/data. Et sur la version suivant, ces duplicata ont été supprimé :https://blog.timac.org/2017/0415-facebook-app-for-ios-v-88-0-cleans-up-duplicate…
Ce qui semble prendre le plus de place, c’est le gros binaire “facebook shared framework”. Au vu du nom, ça semble être la grosse boite à outils de Facebook pour développer leurs applications (j’imagine que Messenger doit aussi traîner ce gros pavé, mais aussi les applications internes, coté serveurs). Ce n’est pas à proprement parlé une application. L’application, je dirais que c’est le binaire “facebook” de 20Mo et les 12Mo de main.jsbundle (qui serait selon moi du javascript)
#8
Merci beaucoup pour le lien !
Je comprend l’idée d’avoir une grosse toolbox “unifiée” mais justement c’est un truc que je pige pas… Je pensais que le poids des appli et leur simplicité c’était le combo ultime (le must à atteindre) et j’ai la douloureuse impression que puisque les réseaux permettent de télécharger plus et la mémoire de stocker plus bah on s’en tamponne et on fait des grosses appli pas ou peu optimisées.
D’ailleurs on le voit bien pour les jeux ou l’opti laisse souvent à désirer… Dans les technos en général le “less is more” revient à la mode (on rejoins plus ou moins la discipline “jugaad” indienne d’ailleurs) une innovation plus frugale. Facebook est d’ailleurs sur ce marché avec sa version lite mais t’as un peu (beaucoup) l’impression qu’ils ont une appli “optimisée et légère” et une autre où ils s’en tamponnent.
#9
Ca peut être géré au niveau de la compilation :
Par exemple, tu écris ton applications, tu utilises les fonctionnalité proposer par une bibliothèque “Toto”. Maintenant vient le moment de compiler et là tu as 2 choix :
Toujours au niveau de la compilation, tu peux choisir entre un binaire de petite taille mais l’exécution nécessitera de faire plein de saut dans le binaire, soit avoir un code plus gros mais l’exécution sera plus linéaire (ce qui est dans les bonne condition plus rapide a exécute)
Aujourd’hui, le poids d’une application est secondaire. Ce que l’on souhaite avant tout, c’est un développement rapide d’application toujours plus complexe. Du coup, on développe moins d’outils interne et on fait appel à des bibliothèques (dans le cas présent, ce n’est sûrement pas le même service qui s’occupe du framework que celui qui fait l’application mobile).
Par exemple, pour les jeux, là où au début des années 90, on développait encore son propre moteur, aujourd’hui, tu ne te fait pas chier, tu utilises Unreal Engine (ou autres) car clairement tu ne peux pas te permettre de développer de zéro un tel bouzin.
Et comme tu peux le voir, de l’autre coté, on a des bibliothèques qui en plus de faire le café, font le thé, proposent des croissants, des toast, de la marmelade et des œufs brouillés.
A ceci, tu rajoutes le bordel des architectures ARM, des API pour chaque version de l’OS…..
#10