Mais ? Le développement front-end est un bordel sans nom ?! - Page 6

C'est une raclette dans un bun!

Une raclette avec du vrai fromage de merde Américain (oui parce qu'ici tout ce qui n'est pas écrit avec un super label genre c'est authentique n'est pas vrai, donc ton pain, ta Turquie et je sais pas quoi d'autre qu'il y a dedans ne t'attends pas à ce que ce soit vrai).

Real Cheese !

parce que les autres c'est pas du vrai cheese !?

robinHood (./148) :
https://medium.com/friendship-dot-js/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558#bananaramanana

Godzil (./149) :
un troll quoi

Un troll? Les dépendances qu'il relève sont vraiment abusives! L'adware qui envoie des likes en le nom de l'utilisateur, l'Encyclopedia Britannica bundlée pour une seule définition utilisée dans un easter egg inutile, l'image énorme cachée en easter egg dans le code source, dans les 3 cas: WTF?!

Apprends a lire et verifer les sources.

Ah, c'est un fake? Dans ce cas, je comprends mieux l'appellation "troll".

C'est dingue. Je cherche un outil pour faire quelque chose et j'en trouve un, malheureusement écrit en node.js, mais il réponds vraiment a mes besoins.

Problème, l'outil n'est pas maintenu depuis plusieurs mois et certaines choses on changé, et il ne fonctionne plus complètement correctement, en partie, mais ya des choses qui foirent. Comme ce jour la je suis motivé, je cherche un peu a comprendre le probleme, fini par trouver un truc, et fait dans mon coin des modifications pour que ca fonctionne. (a la 1664 bien entendu) je vois que le projet original que certains personnes rencontrent le meme probleme que moi, et comme j'était d'humeur sympa, je décide de partager les changement que j'ai fait, au travers d'un fork sur github du dit projet, et applicant une partie de mes changements (en backportant certains trucs).

Bien sur, comme le projet d'origine est fait en mode node.js il faut faire certaines etapes entre le code ecrit et le machin qui va s'executer, et j'avoue que c'est loin d'etre limpide, quand j'ai fait mes modifs dans mon coin ce n'était pas sur le code d'origine (du typescript) mais directement sur le JS généré, erreur de ma part surement mais bon, je ne pensais pas sortir le truc.

Comme certains avaient du mal (je peux comprendre moi aussi, je viens juste de comprendre un truc la) j'ai décidé de packager le machin de la meme maniere que l'original, c'est a dire au travers de NPM. Sacré bordel que ce truc soit dit en passant, enfin une fois que ca marche, ca marche c'est sur, mais a configurer c'est hum un gros WAT.

Bref, j'ai eu un repport de bug hier ou ajd parceque un truc marche moyen, truc qui marche sur ma version 1664 parcequ'elle est plus en "avance" que la version publié, mais c'est tellement le bordel ce que qu'il faudrait tout reecrire, et donc pour corriger ce bug je fait les quelques modifs qu'il faut sur le code d'origine, et publie.

Le fork que j'ai fait a été téléchargé 139 fois le mois dernier (sachant qu'il a été originellement publié il y a 15 jours en gros) .. C'est dingue o_o (ok c'est probablement petit par rapport a certains projet quelque soit la plateforme, mais aucune pub, rien, juste probablement du google)

pas mal

A vrai dire ca me fait plutot chier...

étonnifiant

Moralite: ne jamais faire un truc poru "rendre service a d'autre" ...

Si je veux vraiment mettre a jour ce truc il va falloir passer par une etape de reecriture quasi complete, c'est lourdingue

je crois que tu veux pas

t'as fait ton taf, t'as fait une correction utile, apres c'est open source donc ils ont qua se démerder? Au pire tu donnes a quelques malheureuses bonnes volontés le droit de commit sur ton repo, ou tu les laisses forker pour corriger le reste

Dison que certain changement me serait utile a moi en premier... mais bon oue j'ai vraiment aps envie de perdre du temps sur ce truc

-

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

Je ne sais pas si c'est réaliste, mais c'est "amusant" à lire ^^
(et si la vie des développeurs web ressemble vraiment à ça, je vous plains, sincèrement)

Ça résume bien la situation. Je ne sais pas si rire ou pleurer. Et le problème est que tout ce bordel que le développeur se voit "obligé" de rajouter est finalement régurgité à l'utilisateur.

Zerosquare (./165) :
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

Je ne sais pas si c'est réaliste, mais c'est "amusant" à lire ^^(et si la vie des développeurs web ressemble vraiment à ça, je vous plains, sincèrement)

En fait, la situation est pire : là il ne liste que les technos à utiliser, alors qu'en plus il faut faire gaffe au contenu si tu veux faire les choses proprement jusqu'au bout (les 15 versions de la favicon, la CSS qui doit s'adapter à tous les écrans, les images en deux tailles, …)

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. Et aujourd'hui ben on fait en Javascript des applications qui paraissent parfois plus natives qu'avec d'autres toolkits (ex. Atom).

Quand il y a eu jQuery on ne s'en est pas offensé. 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. 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. Bref on peut enfin coder. 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. Et HTML/CSS en terme d'UI c'est sans doute dans ce qui se fait de mieux à l'heure actuelle (ç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), 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.

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.

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.

Kevin Kofler (./171) :
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 suis assez d'accord, mais en tant qu'utilisateur de Linux, ça devrait te réjouir : ça te donne accès à des applications qui n'auraient jamais été portées sur ton OS en natif, parce qu'il n'y a pas assez d'utilisateurs comparé à l'effort que ça représente)

C'est marrant, bien qu'on ne progresse pas avec un avis aussi tranché que celui de Kevin ("le web, c'est du texte avec des liens"), je peux comprendre son point de vue dans le sens où par facilité ou incompétence, par manque de concertation ou besoin de productivité immédiate, que sais-je, le progrès du dev internet est bordélique, et c'est évidemment dommage à plusieurs égards.

Kevin Kofler (./171) :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.

Vive le AUR de Arch, alors \o/

Plus sérieusement, je suis d'accord avec certains arguments de Kevin, mais pas tous.
D'une part, les usages changent, et la création d'applications universelles (tous OS) est un réel besoin, parce que les gens veulent pouvoir utiliser la même application sur leur ordinateur fixe, portable ou leur téléphone mobile, mais de façon à ce que ladite application sache tirer parti des spécificités de chaque environnement.
Finalement, l'ensemble JS/CSS/HTML arrive à proposer (pas totalement mais en grande partie) ce qui était attendu de Java, à plusieurs détails près :
- Les usagers ont fait d'Internet le centre de leur activité.
- Le contenu et/ou les "applications web lourdes" est indexable par les navigateurs, et est accessible du monde entier sans installation ni déploiement.
- Le contrôle aux accès des applications peut être centralisé (mine de rien, pour le déploiement en entreprise, c'est un point critique : plus besoin de politique de déploiement sur les postes : un navigateur, une URL, et tu gères droits et comptes de façon centralisée)
- Java propose une UI très riche, mais visuellement déprimante pour l'utilisateur (très 80's). Ca peut éventuellement être supportable dans un environnement pro, mais c'est impensable dans un environnement domestique où les écrans sont partout. Et même aujourd'hui, le rapport à l'outil informatique dans le milieu du travail a changé : les utilisateurs veulent un confort d'utilisation et un look'n feel qui soit au moins au niveau de ce à quoi ils ont accès chez eux. Du coup, la souplesse d'HTML+CSS (qui vient en fait de son absence de socle de base et où, du coup, on doit tout faire) apporte un plus. En fait, c'est un défaut qui a amené une qualité
- HTML/CSS/JS permet au plus débutant des débutants de faire une page simple et d'avoir l'impression de pouvoir communiquer au monde entier. Java ne permet pas ça. Du coup, tu vas avoir un taux de pénétration des outils qui sera différente, des compétences qui vont se développer autrement, etc.

Après, pour devoir me plonger dans le dev frontend un peu plus que d'abitude, je trouve ça assez chiant, mais c'est surtout parce que je ne maîtrise pas la moitié de la souplesse (puissance ? faiblesse ?) offerts par le JS. Je viens de langages beaucoup plus "traditionnels", donc je suis vite dépassé. À tel point que, parfois, j'ai juste envie de mettre à jour mes div avec des innerHTML reçus du serveur plutôt que de travailler avec de l'XML à traiter (mais je me retiens ˆˆ)

KK> oui, on a bien compris que personne ne devrait utiliser ce dont tu n'as pas besoin. Mais faut croire que personne ne t'écoute et que les dév' préfèrent se concentrer sur les besoins des gens

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

Au contraire, c'est bien plus uniforme maintenant qu'il y a 10 ans.

Zerosquare (./172) :

Kevin Kofler (./171) :
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 suis assez d'accord, mais en tant qu'utilisateur de Linux, ça devrait te réjouir : ça te donne accès à des applications qui n'auraient jamais été portées sur ton OS en natif, parce qu'il n'y a pas assez d'utilisateurs comparé à l'effort que ça représente)

Pas du tout, parce que ça rend nettement plus facile de polluer GNU/Linux avec des applications propriétaires, et la disponibilité d'un logiciel propriétaire gratuit est un gros frein au développement d'alternatives libres (parce que pas mal des développeurs potentiels se contentent du blob propriétaire).

Ces applications web sont non seulement presque toutes propriétaires, mais en plus, le mode de déploiement fait que tu perds totalement même le peu de contrôle qui te restait avec les logiciels propriétaires locaux: on peut à tout moment te remplacer le service par une version "améliorée" qui ne fait plus ce dont tu as besoin, le rendre payant, ou le supprimer carrément (ou te bannir ). (Et cela même si le logiciel est théoriquement libre, d'ailleurs, tant que tu n'héberges pas ta propre copie.)

Et le pire, c'est que les gens disent: "Je n'utilise que des logiciels libres, j'utilise Firefox." alors qu'en réalité, le logiciel qu'ils utilisent n'est pas Firefox, mais ce qui tourne à l'intérieur.

KK a de bons arguments dans son post, y compris des trucs que je ne savais pas (notamment concernant le toolkit Electron). C'est agréable merci. Ceci dit, je trouve que HTML/CSS reste pour moi le meilleur langage de description de contenu, couplé au Javascript et à quelque chose comme jQuery pour manipuler le DOM. On peut tout faire, même des jeux, preuve que c'est très puissant et complet. Tout le monde a essayé, du côté de Windows avec leur XAML, du côté de Qt avec QML, etc. et au final le HTML est juste le truc qui reste le plus complet, pouvant absolument rendre n'importe quoi tout en gardant une sémantique permettant d'indexer et même rendre le site accessible aux malvoyants. Alors oui je vais nuancer, pas forcément avec un look natif, et il est vrai que "look natif" n'a plus beaucoup de sens de nos jours ; le flat, autant qu'on puisse en avoir marre, a permis à chaque produit d'apporter sa touche visuelle propre (quitte à recoder depuis zéro) tout en restant relativement cohérent et facile a appréhender pour chacun.

Et je pense que c'est pour ça qu'on arrive à un stade pour moi où Javascript/HTML5/CSS sont plus ou moins universels, c'est facile à appréhender et maîtrisé par une base jusque là inégalée de développeurs, bien documenté et on trouve des astuces pour faire absolument tout, multiplateforme, suffisamment léger si nécessaire (on parle pas d'un site desktop bien sûr), sans nécessiter de déploiement (un autre avantage pour les compagnies c'est qu'elles peuvent aliéner un peu plus l'utilisateur par la même occasion, se protéger du piratage et mettre à jour le contenu silencieusement tout en faisant disparaître toute preuve de comportement foireux d'un jour à l'autre) et plus brièvement déjà un standard de facto.

Posté avec un clavier QWERTY en mode US.

Nil (./174) :
D'une part, les usages changent, et la création d'applications universelles (tous OS) est un réel besoin, parce que les gens veulent pouvoir utiliser la même application sur leur ordinateur fixe, portable ou leur téléphone mobile, mais de façon à ce que ladite application sache tirer parti des spécificités de chaque environnement.

Qt sait faire ça très bien, tu peux coder une application et elle marchera partout. Même QtWidgets est supporté sur Android et iOS. Sinon, en QML, tu as par exemple Kirigami, développé par le projet KDE pour automatiquement adapter ton application aux conventions PC et mobile.

- Java propose une UI très riche, mais visuellement déprimante pour l'utilisateur (très 80's). Ca peut éventuellement être supportable dans un environnement pro, mais c'est impensable dans un environnement domestique où les écrans sont partout. Et même aujourd'hui, le rapport à l'outil informatique dans le milieu du travail a changé : les utilisateurs veulent un confort d'utilisation et un look'n feel qui soit au moins au niveau de ce à quoi ils ont accès chez eux.

Utiliser le look&feel natif en Swing est une seule ligne de code. (Je ne comprends pas pourquoi ce n'est pas le choix par défaut.)

Sinon, il y a aussi SWT et Qt Jambi (mais ce dernier n'est plus très actif, il y a un portage Qt 5 fait par une seule personne et qui n'a toujours pas été intégré à la version "officielle"). Mais le Java n'est pas non plus le centre du monde.

Du coup, la souplesse d'HTML+CSS (qui vient en fait de son absence de socle de base et où, du coup, on doit tout faire) apporte un plus. En fait, c'est un défaut qui a amené une qualité

En HTML+CSS, tu dois coder tout ton look&feel à la main et ça ne s'intègrera à rien. Tu peux avoir ça aussi avec Swing, il suffit de coder ton propre look&feel Swing. Ou même avec Qt si tu veux absolument casser l'intégration native de Qt, Qt permet même d'utiliser du CSS pour modifier le style.

- HTML/CSS/JS permet au plus débutant des débutants de faire une page simple et d'avoir l'impression de pouvoir communiquer au monde entier. Java ne permet pas ça. Du coup, tu vas avoir un taux de pénétration des outils qui sera différente, des compétences qui vont se développer autrement, etc.

Il est trivial d'écrire un Hello World en HTML statique, mais ça ne t'apportera aucune connaissance de tout le bordel de technologies JavaScript.

Après, pour devoir me plonger dans le dev frontend un peu plus que d'abitude, je trouve ça assez chiant, mais c'est surtout parce que je ne maîtrise pas la moitié de la souplesse (puissance ? faiblesse ?) offerts par le JS. Je viens de langages beaucoup plus "traditionnels", donc je suis vite dépassé. À tel point que, parfois, j'ai juste envie de mettre à jour mes div avec des innerHTML reçus du serveur plutôt que de travailler avec de l'XML à traiter (mais je me retiens ˆˆ)

Pourquoi te retenir? C'est la solution la plus compatible et qui consomme le moins de ressources côté client.

Kevin Kofler (./178) :
Utiliser le look&feel natif en Swing est une seule ligne de code. (Je ne comprends pas pourquoi ce n'est pas le choix par défaut.)

probablement parce que gérer des composants dont on ne connais pas à l'avance le comportement/les dimensions peut poser problème pour la composition

Brunni (./177) :
et il est vrai que "look natif" n'a plus beaucoup de sens de nos jours

Je ne suis pas d'accord du tout. Il n'y a pas que le flat au monde.

(un autre avantage pour les compagnies c'est qu'elles peuvent aliéner un peu plus l'utilisateur par la même occasion, se protéger du piratage et mettre à jour le contenu silencieusement tout en faisant disparaître toute preuve de comportement foireux d'un jour à l'autre)

Pour l'utilisateur, tout ça, ce sont des désavantages (énormes).