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

(Lol, je voulais voir à quoi KDE ressemblait à travers les versions et…

)

(tu utilises encore Adblock Plus ? Passe à uBlock Origin, il est meilleur, et surtout pas fait par une boîte qui laisse passer les pubs si on la paie suffisamment)

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

Et QT sait adapter automatiquement son apparence et son comportement à chaque type de poste client ? (smartphone, tablette, ordi ?), et ce sans installer quoi que ce soit ?

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

Comme le dit vince, probablement parce que ce n'est pas pratique. D'autant que Swing pour Windows, par exemple, va merder dès que tu utilises un thème (ou alors il faut aimer Windows des années 90).

Kevin Kofler (./178) :

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

C'est exactement ce que je dis : ça permet d'y entrer très progressivement et d'aller très loin, le tout sur plusieurs années, dans une technologie qui évolue avec les habitudes. En Java, dès trois lignes, tu as perdu la moitié des gens.
Ca a aussi des avantages, je ne le nie pas : ça permet de laisser les devs faire les devs, et les utilisateurs faire les utilisateurs. Mais je trouve ça dommage, perso, d'autant qu'on est à une époque où il n'y a plus d'outils permettant de faire de la petite programmation impérative sympa comme le Basic (puisqu'il faut tout de suite jouer avec les fenêtres là où avant on pouvait faire plein de choses facilement en console). Finalement, le HTML+CSS+JS(+PHP) permet ça, d'une certaine façon.

Kevin Kofler (./178) :

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.

Pas sûr que ça consomme le moins de ressources côté client : celui-ci doit reconstruire l'arbre DOM à partir du HTML récupéré, traiter les erreurs de syntaxe, etc. En fait, il va reproduire exactement ce qui a été fait dans le js, mais avec le risque qu'il y ait des erreurs dans le code envoyé. Il faudrait tester, mais à mon avis, c'est plus lent.
En outre, c'est juste plus sale sur le plan de la conception, parce qu'on fait transiter des données qui ne sont pas traitables facilement. Après, c'est souvent beaucoup plus simple, je te l'accorde.

Nil (./183) :
Mais je trouve ça dommage, perso, d'autant qu'on est à une époque où il n'y a plus d'outils permettant de faire de la petite programmation impérative sympa comme le Basic (puisqu'il faut tout de suite jouer avec les fenêtres là où avant on pouvait faire plein de choses facilement en console).

[flanker]As-tu essayé le Python ? [/flanker]

If we live in a simulation, I am pretty sure its PHP

— Joscha Bach (@Plinz) October 8, 2016

Nil (./183) :
on est à une époque où il n'y a plus d'outils permettant de faire de la petite programmation impérative sympa comme le Basic (puisqu'il faut tout de suite jouer avec les fenêtres là où avant on pouvait faire plein de choses facilement en console). Finalement, le HTML+CSS+JS(+PHP) permet ça, d'une certaine façon.

C'est un parallèle intéressant, je n'avais jamais vu les choses comme ça

(voilà, désolé, vous pouvez reprendre )

(sacrée feature, tu t'es cru obligé de le poster celui-là )

Ah non, j'ai même du effacer ma réponse précédente pour poster celle-ci (ça donne une idée de l'intérêt que devait avoir l'autre )

Site web ou pas, de toute façon ça ressemble à ça, non ?

nitro > tiens, moi aussi j'avais failli le poster

Je suis d'accord avec Folco, pour une fois ça s'applique tout autant aux autres devs ^^

À force je me demande où ils sont, tous ces développeurs Node.js : je n'ai l'impression de voir que des railleries autour de cet écosystème, et je n'ai jamais trouvé quelqu'un qui le défende. Ça ne se construit pas tout seul quand même ?

a contre coeur plutot?
ou par des ptits jeunes fraichement sortis de l'école?

Question légitime ; je ne connais pas node.js, mais peut-être que c'est simplement l'effet boule de neige ?

Il y a pas mal d'écosystèmes répandus (voire dominants) qui sont néanmoins considérés comme moyen ou médiocres. Il suffit qu'ils aient bénéficié d'un facteur qui les a poussés initialement (par exemple pour le PHP, le fait que ce soit simple à bricoler et dispo chez la grande majorité des hébergeurs) ; une fois qu'ils ont atteint leur masse critique, ils attirent naturellement de nouveaux utilisateurs parce qu'ils sont populaires, ce qui les rend encore plus populaires, etc.

Dans le cas de PHP je suis d'accord, pour en manger pas mal à cause de yAronet. C'est un langage mal conçu, vieillot et truffé de défauts qui ne pourront jamais être corrigé (sans casser sérieusement la compatibilité antérieure) mais il a aussi de qualités trop rares : c'est de loin la solution la plus simple à la fois pour bricoler rapidement un site dynamique (langage facile à apprendre, moteur de script et de template deux en un, bibliothèque standard bien fournie) et le déployer (une simple copie de fichiers et c'est terminé). Dans le cas de Node.js il y a probablement des qualités qui expliquent un succès aussi énorme, mais du peu que j'en connais je ne vois pas du tout lesquelles ?

http://nodeirc.info/
(Freenode/#node.js)

La principale qualité de Node.js est probablement le fait de pouvoir coder en le même langage côté serveur et client. Le JavaScript est le seul langage que les navigateurs acceptent généralement, donc, comme il y a la tendance de vouloir absolument tout faire dans le navigateur, cela impose malheureusement ce langage avec tous ses défauts. Et du coup, il y a la volonté d'utiliser le même langage du côté serveur, d'où Node.js.

Et il y a encore pire: Electron, la version pour applications locales ou hybrides (local + client web), une chimère de Chromium et Node.js. Cf. ./171.

et encore pour faire js serveur ET client y'a des montagnes de build systems je crois bien

Zeph (./198) :
c'est de loin la solution la plus simple à la fois pour bricoler rapidement un site dynamique (langage facile à apprendre, moteur de script et de template deux en un, bibliothèque standard bien fournie) et le déployer (une simple copie de fichiers et c'est terminé).

Bon, certains aspects sont partagés avec d'autres langages, mais c'est vrai qu'il n'y a rien de plus simple pour se mettre au web.

Dans le cas de Node.js il y a probablement des qualités qui expliquent un succès aussi énorme, mais du peu que j'en connais je ne vois pas du tout lesquelles ?

J'entends souvent parler de la possibilité de faire plein de choses en parallèle.

Oui, j'ai entendu la même chose mais je n'ai jamais tellement eu de précision. La seule chose que je remarque c'est que les bibliothèques fournies avec node.js favorisent toutes la programmation asynchrone. Soit, c'est surement une bonne idée pour faire un serveur web, mais ça n'en fait pas une fonctionnalité unique ni même nouvelle pour autant.

En regardant rapidement quelques benchs (exemple) node.js a l'air d'avoir des performances correctes quand on fait du web. Pour du calcul ça semble déjà nettement moins bon, mais pas pire que Python par exemple (je n'ai pas regardé en détail si le test était réaliste ou non). En revanche j'imagine que d'une part ça vient au prix d'une grosse consommation mémoire, d'une autre ça n'est valable que sur des architectures x86/x64 vu que v8 n'est performant nulle part ailleurs.

Du coup OK, pourquoi pas, je ne suis toujours pas convaincu que c'est vraiment l'outil qui manquait mais au moins il n'a pas l'air de faire plus mal que les autres. Reste à comprendre sa capacité mystérieuse à agréger les développeurs du dimanche, visiblement

il y a toute une flanquée de librairies toutes pr^tes à être consommées aussi...

Je pense pareil : le côté Lego je sais Vince, c'est pas gentil pour les Lego avec tout plein de pièces existantes à assembler doit attirer les développeurs débutants.

Zeph (./203) :
En regardant rapidement quelques benchs (exemple) node.js a l'air d'avoir des performances correctes quand on fait du web. Pour du calcul ça semble déjà nettement moins bon, mais pas pire que Python par exemple (je n'ai pas regardé en détail si le test était réaliste ou non).

Ce n'est pas tellement une question de domaine d'application, mais une question d'avec quoi on compare: Si on compare avec d'autres langages interprétés comme le PHP (premier lien) ou le Python (deuxième lien), Node.js les écrase, surtout si on utilise les VMs de référence (HHVM et PyPy sont déjà plus comparables, PyPy est même nettement plus rapide que Node.js dans le cas testé), mais si on compare avec des langages compilés comme le C++ (deuxième lien) ou même le Go (premier lien), Node.js se casse la gueule.

Cette programmation asynchrone peut aussi se faire en C++ avec Qt (signaux et slots). Avec C++11 et Qt 5, on peut même utiliser les lambdas comme en JavaScript. C'est loin d'être une spécificité du JavaScript.

Mais personne ne fait du web en C++…