Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !
Skype pour Windows se débarrasse de React Native au profit d’Electron

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.

13 commentaires
Avatar de Gilbert_Gosseyn Abonné
Avatar de Gilbert_GosseynGilbert_Gosseyn- 24/06/20 à 09:07:57

Je suppose qu'il s'agit bien de l'app desktop, et pas de l'app UWP ?

Avatar de lucasbfr INpactien
Avatar de lucasbfrlucasbfr- 24/06/20 à 09:21:59

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

Avatar de Zone démilitarisée Abonné
Avatar de Zone démilitariséeZone démilitarisée- 24/06/20 à 09:35:20

J'avais l'impression que c'est justement la version Windows classique qui est toute pourrie.

Avatar de Gorom INpactien
Avatar de GoromGorom- 24/06/20 à 11:20:44

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.

Avatar de cyp Abonné
Avatar de cypcyp- 24/06/20 à 11:56:33

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.

Édité par cyp le 24/06/2020 à 11:57
Avatar de 127.0.0.1 INpactien
Avatar de 127.0.0.1127.0.0.1- 24/06/20 à 12:05:05

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.

Avatar de FennNaten Abonné
Avatar de FennNatenFennNaten- 24/06/20 à 12:42:53

Hello,
Alors Electron c'est un système pour builder des applications qui combine

  • un chromium modifié qui sert à gérer l'interface

  • du node.js pour compléter les APIs de chromium

  • du code glue pour bridger tout ça, notamment en fournissant des APIs javascript additionnelles au process principal, qui vont permettre de toucher certaines fonctionnalités de l'OS (piloter les fenêtres, le systray, les notifications, tout ça)

    ç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 :D

    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.

  • Un autre argument lié à la performance, c'est la complexité de paralléliser les calculs et de bien gérer le CPU avec un moteur JS qui est par nature mono-threadé. Pour le coup c'est vrai, quand on veut faire des choses non-triviales, ce n'est pas évident et il faut bien connaître le moteur. Il est toutefois possible de s'inspirer de VS Code, IDE open source et optimisé au poil, écrit avec Electron. (C'est d'ailleurs assez hallucinant quand on sait que c'est Microsoft qui gère ça, alors qu'à côté leurs autres app Electron faites par d'autres teams sont très loin d'avoir la même qualité niveau perfs)

  • Les applis Electron sont lourdes, en RAM comme en taille d'exécutable. C'est vrai et c'est un argument recevable. Chaque appli Electron package sa propre version de Chromium light et sa propre version de node.js,ce qui fait que toutes les apps Electrons font plusieurs Mo même si on n'a soi-même écrit que quelque ko de code applicatif. Il y a des tentatives pour mitiger ça avec des systèmes pour partager un runtime Electron entre plusieurs apps, mais c'est difficile à gérer à la fois pour les devs (obligés de prendre en compte le fait que leur code pourrait potentiellement tourner sur des versions différentes de node/chromium) et pour les utilisateurs qui ne sont plus dans le simple clic-executable-to-install.

  • La sécurité ne coule pas de source. L'UI est un vrai chromium, étendu pour que le js qui tourne dedans ait accès à des APIs desktop.  Ce qui veut dire qu'une fenêtre d'une app Electron peut de base naviguer vers une url (d'ailleurs c'est comme ça qu'on lui fait loader l'UI, on la lance en lui faisant charger un document html local) qui pourrait potentiellement être n'importe où sur le web. Si un attaquant arrive à exploiter une app chromium, il peut potentiellement lui faire loader du code js remote qui pourra faire bien plus de dégâts que s'il tournait dans un navigateur. Il y a évidemment des mitigations, mais c'est potentiellement plus facile de se tirer une balle dans le pied sans faire exprès qu'avec d'autres technos.

Avatar de jpaul Abonné
Avatar de jpauljpaul- 24/06/20 à 16:06:54

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.

Avatar de FennNaten Abonné
Avatar de FennNatenFennNaten- 24/06/20 à 18:45:50

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:

  • ce sont des outils développés pour faire des app js, intégrer un noyau node, un navigateur avec un V8 et les outils de debugs directement, dont les versions sont à 100% maitrisés avec la distribution, c'était assez bien vu (avec un méchanisme de dogfooding où l'outil sert à se développer lui-même)

  • ça tourne sur tous les OS principaux employés par les 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 ^^"

Avatar de TheKillerOfComputer Abonné
Avatar de TheKillerOfComputerTheKillerOfComputer- 25/06/20 à 04:22:16

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

Le web n'est pas fait pour de l'applicatif local, c'est juste bon pour contenter des développeurs fainéants < vieux con inside.
Édité par TheKillerOfComputer le 25/06/2020 à 04:26
Il n'est plus possible de commenter cette actualité.
Page 1 / 2