La nouvelle mouture 15.61 de Skype change donc de base technique. Il s’agit en fait d’une harmonisation, puisque toutes les autres moutures pour ordinateurs sont déjà basées sur Electron.
Il y a des nouveautés communes à toutes les plateformes, puisque cette version 15.61 est en fait la 8.61 pour les autres. En plus des corrections et améliorations diverses de stabilité, les utilisateurs peuvent maintenant supprimer plusieurs contacts d’une traite.
Notez, dans le cas de Windows 10, que la nouvelle version n’est plus compatible avec la fonction Partage du système et la synchronisation des contacts avec Outlook. Microsoft promet leur retour pour plus tard.
Les versions mobiles (Android et iOS) gagnent également plusieurs fonctions, dont le floutage de l’arrière-plan et la compatibilité avec Android Auto.
Commentaires (13)
#1
Je suppose qu’il s’agit bien de l’app desktop, et pas de l’app UWP ?
#2
Mmm la version Windows est en 8.61 donc je pense que c’est la version Windows Store toute pourrie qui change. (je ne pige pas pourquoi ils ont 2 branches différentes avec des fonctionalités incompatibles…)
#3
J’avais l’impression que c’est justement la version Windows classique qui est toute pourrie.
#4
En parlant de truc pourri, j’ai lu plusieurs fois des avis plutôt négatifs sur le framework electron de la part de personnes versées dans le développement, n’étant pas dev moi-même qu’est ce qui fait qu’il est décrié à ce point ?
Pour ma part en tant qu’utilisateur et possédant une machine sous Linux Mint, je constate en tout cas que ça permet d’accéder à des logiciels multiplateformes à fonctionnalités égales comme Signal Desktop ou Teamviewer, plutôt positif à mon niveau.
#5
Les principale reproche concerne généralement la boulimie en espace disque et en mémoire de ce type d’application par rapport à une application native.
En gros une appli électron c’est grossièrement une archive avec une version bridé de Chromium ainsi que l’application web concerné et toutes les librairie nécessaire au fonctionnement de tout ça.
Du coups c’est potentiellement beaucoup de fichiers dupliqués (entre les applications electron et/ou ton navigateur web) et niveau mémoire on retrouve les même problème de gourmandise que sur le web “moderne” amplifié par la non mutualisation des process.
Pour ne rien améliorer certaines sont packagé un peu vite fait et embarque souvent des ressources pas nécessaire (sdk, outils de debug…) ce qui n’aide pas trop à leur bonne réputation.
#6
Il me faudra bientôt plus d’espace RAM que SDD pour lancer toutes les applis Office de Ms (toutes basées sur Electron: outlook, teams, skype…)
On sent bien que leur objectif de MS c’est d’avoir une offre full web. L’installation locale étant juste un mode “offline” a base d’Electron.
#7
Hello,
Alors Electron c’est un système pour builder des applications qui combine
ça permet de faire des applis en utilisant des technos web, tout en étant en mesure de les builder et de les déployer vers à peu près tous les systèmes sur lesquels on peut faire tourner chromium et node.js… Soit beaucoup
Ceci dit, les détracteurs avancent différents arguments plus ou moins recevables:
- Il y a les gens qui n’aiment pas javascript et diront que ce n’est pas fait pour faire de l’applicatif et qu’il faut arrêter d’étendre les usages du langage. Je mets cet argument en premier pour l’évacuer parce que pour moi c’est de l’ordre de la querelle de paroisse et des gens qui veulent conserver leur pré carré, souvent avec une pointe de crainte en voyant les mêmes technologies devenir de plus en plus universelles (peur de voir se dévaluer certaines compétences spécialisées par exemple, ou d’un “nivelage par le bas” du milieu du développement chez ceux qui n’ont jamais considéré les développeurs web comme de “vrais développeurs”)
- Il y a ceux qui n’aiment pas la façon de faire une UI en techno web. Les goûts et les couleurs…
- Il y a l’argument de la performance: Même si JS tourne bien, on peut faire mieux avec un langage compilé, et parfois encore mieux en allant faire des optimisations obscures à la mano. Dans l’absolu, c’est vrai. Maintenant est-ce que toutes les applis sont CPU/GPU-intensive au point d’avoir besoin d’aller dans le low level? Comme toujours avec les sujets perfs, c’est très cas-par-cas, et le mieux est parfois l’ennemi du bien. D’autant plus que node.js permet d’écrire des modules en C++ au besoin.
#8
En gros beaucoup de bricolages et de bric à brac pour éviter de former ses équipes à autre chose que le JS.
Et je dit ça en tant développeur front-end à temps plein.
Les langages et frameworks (autant Java Swing que Qt ou Gtk ou autres …) pour faire des applis desktop ont évolué pendant presque 3 décennies. Et on en est encore à réécrire des contrôles basiques comme des menus contextuels, laisser à la merci du développeur ce qui se passera à l’activation d’un contrôle ou autres à quasi chaque nouvelle appli. Je ne parle même pas de l’accessibilité qui devient carrément une feature du produit (et qui souvent, n’est pas jugée comme prioritaire)
Certes ces frameworks ont les défauts de leur grand age, mais qui sont surtout dus au désinvestissement complet dû à l’essor de l’application web. Mais ils ont aussi d’énormes qualités et en premier lieu d’être le bon outil pour le travail d’afficher une interface à l’utilisateur qui soit raccord avec son OS et qui réagisse aussi bien au clavier qu’à la souris sans qu’on aie besoin de s’en soucier.
Qui se souvient du passage de Spotify de Qt vers le web ? Une appli de quelques mo, hyper réactive pesait soudainement des centaines de mo.
En tant que dev, je me sens un peu comme pris au piège des Gafam : ils soufflent le chaud et le froid sur les technos que l’on doit utiliser pour nos applis métier.
Après avoir répété pendant des années (et moi le premier) qu’un développeur n’était pas un technicien mais quelqu’un capable de traduire un métier en (beau, si possible) code qui s’exécute et rend le service voulu, je me rend compte du piège : l’informatique “pure” n’évolue plus en dehors des équipes R&D des Gafam. Et ça mène à des situations où Apple et Google deviennent les seuls acteurs du monde à pouvoir sortir des OS, des architectures, des machines … les plus fermées possibles, avec juste assez d’ouverture pour permettre au développeur manant d’exécuter son “business code” dans une sandbox et récupérer une petite taxe au passage.
ps : j’ai rien contre le code simple et sandboxé ni ne prône l’écriture d’applications métier en C. Je ne fait que soulever le fait qu’on laisse le pouvoir technique entre les mains de quelques entreprises.
#9
En fait, il faut remettre ça en contexte, à la base Electron c’est le core d’Atom, un IDE orienté technos web made in Github (avant le rachat par Microsoft).
Dans ce contexte là, (puis VS Code dans la lignée directe) ça faisait 100% sens, et ça n’avait rien à voir avec vouloir éviter des formations aux devs:
Il y avait donc un business case très fort pour ce type de solution.
Après, est-ce que c’était pertinent d’extraire le framework et de le mettre à dispo de tout le monde, et est-ce que toutes les utilisations qui en sont faites par des entreprises sont bien appropriée ? Il est probable que parfois oui, parfois non, c’est du cas et par cas et il faudrait voir les tradeoffs faits par chacun. (comme je n’arrête pas de le répéter à mes collègues: nous ne sommes pas Google, c’est pas parce que c’est bon pour eux que c’est bon pour nos problématiques.)
Le truc, c’est que ce type de solution, tout comme les PWA dans une autre mesure, ça répond à un vrai besoin, le fameux “write once, run anywhere” promis par Sun avec Java avant le rachat par Oracle. Il s’agit pour les boîtes d’essayer de trouver le moyen de garder la main sur le canal de distribution malgré la disparité des plateformes, tout en réduisant les coûts. (et oui, dans les coûts en question il y a la formation, la réputation et l’attractivité pour le recrutement, ne nous leurrons pas là-dessus) Et quand on tente de résoudre ça, on se rend vite compte que le seul moteur quasi ubiquitaire, c’est le combo V8+blink (évidemment, sauf sur iOS, parce qu’il en faut toujours un qui mette un verrou…)
On peut regretter que les innovations viennent des gros, mais ça coûte cher la R&D, et eux ils ont des piles de cash à mettre dedans ^^”
#10
Ce qui m’ennuie avec Electron, c’est quand ça déborde dans des domaines où ce n’est pas du tout fait pour ça touss Warcraft 3 Reforged touss et du coup la consommation en ressources explose. Parfait, on parle d’écologie mais on externalise les conséquences de cette façon de développer sur X millions de clients finaux. Après tout, qu’est-ce leur infliger le surcoût qu’engendre l’usage de l’application en question tant que ça réduit les coûts du codage…
#11
#12
Je réponds un peu tardivement mais merci pour ta réponse très claire !
#13
Merci également pour ta réponse très détaillée
" />