Brunni (./169) :
Ouais enfin bon, la plupart de ces choses sont quand même à priori bien, et là pour une certaine raison. Alors oui le javascript client devient une usine à gaz ça sans doute, mais une bonne partie de ces choses on les a, voire on les attend par défaut, dans pratiquement tous les langages client.

Je ne suis pas vraiment d'accord. D'un, beaucoup de code client est toujours écrit en C++98 voire en C, où toutes ces histoires de closures, promises etc. sont des mots totalement étrangers. On s'est très bien passés de ces concepts pendant des décennies. Et de deux, je ne vois pas pourquoi toute cette complexité aurait sa place dans un navigateur! Un navigateur sert à la base à naviguer, c'est-à-dire présenter du texte avec des liens cliquables, ce n'est pas à la base une VM à applications arbitraires. Un navigateur était – il y a encore quelques années seulement – quelque chose de simple, il y avait plusieurs navigateurs légers tout à fait utilisables. Maintenant, essaie d'utiliser par exemple Dillo ou Lynx… Une partie de plus en plus grande du web ne marche qu'avec les "gros" moteurs qu'on peut compter sur les doigts d'une main, qui semblent tous participer à une compétition où le gagnant est celui qui consomme le plus de place sur le disque, de RAM, de temps CPU etc.

Et aujourd'hui ben on fait en Javascript des applications qui paraissent parfois plus natives qu'avec d'autres toolkits (ex. Atom).

Alors là, pas du tout! Atom est l'application pour laquelle a été créé le toolkit Electron, une énorme usine à gaz qui se veut toolkit desktop. En gros, quelqu'un qui voulait absolument coder une application desktop en JavaScript (Atom, en l'occurrence) s'est rendu compte que Node.js et Chromium partagent le même moteur JavaScript (V8) et que Node.js permet l'accès à des ressources locales comme les fichiers, mais est démuni d'interface graphique, alors que Chromium permet de créer des interfaces graphiques en HTML+CSS, mais pas l'accès aux ressources locales. D'où l'idée de mélanger les deux en un seul processus, voilà donc Electron.

Electron est un bordel absolu à packager proprement, tout leur développement repose sur le bundling de blobs binaires précompilés: la compilation d'Electron utilise par défaut un binaire précompilé de libchromiumclient (la bibliothèque qui embarque leur fork de Chromium), et les applications redistribuent par défaut un binaire d'Electron. Les licences ne sont souvent pas respectées: Chromium contient du code sous LGPL qu'on n'a pas le droit de redistribuer sans les sources, mais les gens ne redistribuent en général que le binaire précompilé proposé par le projet Electron. (Et Electron ne documente pas clairement les licences, ils présentent leur licence permissive MIT, au maximum la licence BSD de Chromium, mais ne mentionnent pas du tout la LGPL, qui pourtant s'applique à des composants essentiels de Chromium comme le code WebKit/Blink.) Le respect des licences et le packaging dans les distributions GNU/Linux sont aussi compliqués par le fait que le projet Electron ne distribue pas de tarballs complets, ni même un dépôt git complet, mais des scripts de compilation qui récupèrent les sources sur le web à la minute, donc il faut d'abord récupérer toutes les sources pour pouvoir les repackager en un tarball source tel que la LGPL l'exige. (Il faut au moins: 1. toutes les sources des composants sous LGPL et 2. tous les fichiers source et/ou objet linkable nécessaires pour remplacer les composants LGPL par des versions modifiées. C'est-à-dire, si on linke tout Chromium dans un gros libchromiumclient.so, il faut soit toutes les sources, soit tous les fichiers objet .o, de libchromiumclient, plus les sources des parties sous LGPL.) Quant au packaging, les systèmes de compilation des distributions GNU/Linux ne permettent pas d'aller récupérer du code sur le web pendant la compilation, il faut donc le récupérer avant et créer un tarball.

Quant à l'apparence native, je ne vois pas où tu vois ça, parce qu'Electron n'a absolument rien de natif: Tout le look&feel est codé à la main en HTML+CSS par l'application, donc ce n'est pas plus natif qu'un site web. Même les contrôles HTML n'utilisent pas le look&feel natif (même si on ne les reskinne pas en CSS), Chromium utilise maintenant depuis plusieurs releases son propre look&feel Aura pour ça. Si une application Electron apparaît native, c'est qu'elle a pris une capture d'écran des contrôles de ton système d'exploitation et les présente en CSS, ce qui, d'un, crée des soucis de droits d'auteur, et de deux, fait que l'application ne paraîtra pas du tout native si tu changes de thème ou si tu utilises un autre système d'exploitation.

Quand il y a eu jQuery on ne s'en est pas offensé.

Si. Je m'en suis offensé parce que c'était avec ça que les sites incompatibles avec KHTML ont commencé, à une époque où KHTML n'était pas encore aussi mort que maintenant. (jQuery marche maintenant plus ou moins sous KHTML, mais ça a pris du temps. C'est KHTML qui a dû adapter son code parce que jQuery a refusé de supporter explicitement KHTML depuis la version 2.) [EDIT: Et jQuery 3 nous rejette à zéro de nouveau, ça ne marche plus du tout sous KHTML.]

Ces transpilers pour pouvoir utiliser ES6 ou ES2016 c'est surtout parce qu'on veut être en avant et que la réalité n'y est pas, donc c'est assez cool d'avoir un wrapper.

Euh non, ce n'est pas cool du tout. Ça donne des usines à gaz énormes. C'est cette attitude des développeurs web "je veux utiliser ça, le navigateur n'a qu'à le proposer, ou sinon je passe par tous les hacks qu'il faut pour lui faire avaler mon code ultra-moderne" qui fait que les sites web soit rament à fond, soit ne marchent pas du tout avec certains navigateurs. Développeurs, si votre code ne marche pas sous mon navigateur, ou s'il a besoin d'une "transpilation" à la con pour marcher, c'est que votre code est foireux! C'est au code à s'adapter aux navigateurs, pas l'inverse!

Jusqu'à il n'y a pas trop longtemps, il y avait encore au moins le souci de compatibilité IE6 à freiner cette course aux fonctionnalités, mais maintenant, plus personne ne se soucie d'IE6. Et des hacks comme "Modernizr" ou les transpilateurs ont été créés pour adapter le navigateur au code au lieu de l'inverse, ce qui donne des sites qui rament à fond (on parle de temps d'exécution en minutes ou pire; les développeurs oublient que les navigateurs qui n'ont pas les fonctionnalités dernier cri n'ont pas non plus une performance JavaScript illimitée, alors leur envoyer des tonnes de code supplémentaire pour contourner les limitations est un très mauvais plan).

Dans le même esprit que jQuery a permis de dire "fais ça" à un navigateur et que… ça se fasse, même si le navigateur n'est pas à jour derrière ou s'il faut bypasser des dizaines de bugs.

jQuery 1 a encore essayé de gérer à peu près tous les navigateurs, jQuery 2 a déjà été beaucoup plus exigeant. [EDIT: Et jQuery 3 est encore pire.]

Bref on peut enfin coder.

On a toujours pu coder. Il suffit de s'adapter aux fonctionnalités du langage tel qu'il est. Le JavaScript a toujours été Turing-complet.

Là c'est la même chose. Javascript passe d'un langage de script juste prévu pour préprocesser un formulaire ou afficher une alerte à un vrai langage normalisé, avec des features modernes et plus de sécurité à un langage avec lequel on fait de vraies applis complètes et fonctionnelles.

Ce que je vois, moi, c'est que JavaScript passe d'une norme fixe, où tout développeur JavaScript savait ce que le langage propose quel que soit le navigateur et son âge, et où tout développeur de navigateur savait exactement quoi implémenter pour que tous les sites passent, à une norme modifiée sans arrêt, où on attend des navigateurs qu'ils proposent de plus en plus de fonctionnalités inutiles dont on se passait très bien et qui alourdissent le moteur JavaScript (et il en est de même pour le HTML 5, malheureusement). (Ça ne m'arrive pas souvent de dire du bien de Microsoft, mais pour le web, ils avaient réussi longtemps à freiner cette course folle aux fonctionnalités qui rend le web un objectif d'implémentation qui s'éloigne sans arrêt quand on s'y rapproche (le fameux "moving target"). Malheureusement, Microsoft participe maintenant aussi à la course.)

Et je ne vois pas non plus pourquoi on veut absolument faire "de vraies applis complètes et fonctionnelles" dans le navigateur, il n'est pas du tout fait pour ça. Il existe des langages (C++) et toolkits (Qt) bien plus adaptés pour ça.

Et HTML/CSS en terme d'UI c'est sans doute dans ce qui se fait de mieux à l'heure actuelle

Hein?! Non, absolument pas!

(ça n'inclut juste pas les contrôles qu'on attend usuellement d'un desktop OS comme les treeviews et autres mais c'est ultra puissant)

L'absence de ces contrôles (sans bibliothèques tierces, qui ne peuvent de par les limitations de la plateforme proposer aucune intégration au look&feel natif) rend le HTML+CSS totalement inadapté pour le développement d'applications desktop. Et je ne vois pas en quoi "c'est ultra puissant", ça ne propose même pas les fonctionnalités de base d'un toolkit desktop.

donc comme les outils client sont là et relativement matures désormais, coder des applis desktop qui en plus peuvent s'ouvrir directement dans un browser c'est plein de sens je trouve.

Je ne trouve pas, moi. Je ne vois pas du tout le sens. Pourquoi un site web ne peut-il pas rester un site web et une application desktop ne peut-elle pas rester une application desktop? Je ne comprends pas cette manie de vouloir à tout prix mélanger les deux. On n'obtient au final que les désavantages des deux.

La seule chose qui manque pour l'instant c'est une vraie standardisation sur encore plein de domaines jeunes de ces technos. C'est un peu comme un C++ dont la STL serait codée par la communauté petit à petit, et où le marché lui-même choisirait ce qui doit rester ou pas, avec un layer en plus qui permet pour l'instant à chacun d'utiliser des bouts de sa STL et de les compiler chez quelqu'un qui préfère utiliser d'autres bouts. Et à l'occasion un gros framework qui définit et standardise un layer supplémentaire de la lib de base arrive.

La fragmentation empire effectivement le problème, mais même s'il y avait une seule usine à gaz "standard", ça resterait une usine à gaz.