jQuery fête ses dix ans : une première bêta pour la version 3.0

jQuery fête ses dix ans : une première bêta pour la version 3.0

Adieu jQuery Compat

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

15/01/2016 4 minutes
80

jQuery fête ses dix ans : une première bêta pour la version 3.0

La bibliothèque JavaScript jQuery fête actuellement ses dix ans. Simple projet d’étude au départ, il est devenu presque omniprésent dans le développement web. À cette occasion, une première bêta de la version 3.0 est apparue, et avec elle plusieurs évolutions importantes.

Créé par John Resig en 2006 quand il était à l’université, jQuery avait initialement deux missions simples : permettre une exploration du DOM (Document Object Model) via une interface simple, et réduire les problèmes qui apparaissaient lors du développement sur plusieurs navigateurs. Depuis, le projet a pris une toute autre ampleur.

jQuery, créé pour faciliter l'écriture du JavaScript...

Comme le site officiel aime à l’expliquer, le but premier de jQuery est aujourd’hui de simplifier au maximum l’ensemble des manipulations qu’un développeur JavaScript trouverait « pénibles ». Supprimer autant que possible les routines rébarbatives pour se concentrer sur les actions et interactions. Et le résultat plait, le fondateur du projet rappelant ainsi que sur le million de sites les plus visités, 77,8 % se servent de cette bibliothèque (W3Techs indique 68,5 % pour sa part).

John Resig ne travaille plus sur jQuery depuis 2011 (il travaille pour la Khan Academy), le projet étant géré depuis par toute une équipe. Son développement est très actif (le dépôt GitHub indique que plus de 6 000 commits ont été réalisés) et se fait au sein d’une fondation spécifiquement créée en 2012 pour en assurer les évolutions futures.

... mais parfois remis en cause

Son existence est cependant parfois remise en cause. Une partie des développeurs estime en effet qu’il ne sert plus à rien puisque toutes les opérations effectuées peuvent très bien se faire en JavaScript directement. Un point de vue qui se base sur l’évolution des navigateurs et sur la raison pour laquelle jQuery a été créé. Car s’il existait des différences énormes lorsque l’on voulait faire exécuter du JavaScript à Internet Explorer 6 et Firefox, le contexte a changé avec la guerre des navigateurs et l’explosion du HTML5, la formation via l’ECMAScript et ainsi de suite.

L’explication pourrait cependant se trouver, justement, dans le support des anciens navigateurs. Sur la page consacrée au jQuery sur W3Tech, on remarque que presque 96 % des sites l’utilisant ont en fait une version 1.X, alors que la dernière révision stable est 2.2.0.

jQuery 3.0 : la première bêta est disponible

Et quitte à fêter ses dix ans, jQuery en profite pour être disponible dans une première bêta de sa mouture majeure 3.0. L’occasion pour l’équipe d’annoncer tout de suite un premier changement important : l’abandon de jQuery Compat. Cette version spécifique de la bibliothèque existait essentiellement pour les vieilles versions d’Internet Explorer, surtout la 8. Or, depuis le 12 janvier, chaque Windows depuis Vista n’a plus droit qu’à une seule version d’IE supportée, soit la dernière disponible. Sur Vista, il s’agit d’Internet Explorer 9, mais avec Windows 7 et les suivants, il n’y a plus que la version 11. Internet Explorer 8 a donc disparu, et jQuery Compat n’a plus de raison d’être. Comme l’annonce fièrement l’équipe, il n’y a donc plus qu’un seul jQuery.

L’équipe indique également avoir fait demi-tour sur les modifications apportées aux méthodes show et hide dans la version alpha car ils provoquaient des erreurs, mais précise que les performances ont quand même été nettement améliorées. Parmi les autres changements, on notera que les jQuery.Deferred sont désormais compatibles avec Promises/A+ et ES2015 Promises, le retrait de certains alias devenus obsolètes (.load, .unload, and .error), l’utilisation par défaut de l’API requestAnimationFrame (sauf dans IE9 et dans les versions d’Android antérieures à la 4.4), la possibilité d’ajouter des arguments dans la méthode unwrap ou encore des accélérations significatives de performances sur certains sélecteurs personnalisés.

De l’aveu même de l’équipe de développement, il s’agit d’une évolution en douceur. Cependant, puisque certains changements cassent la compatibilité avec le code utilisé jusqu’à dans la branche 2.X, elle n’avait d’autre choix que de faire un bond dans la nomenclature. Cela étant, la plupart de ces modifications attendent les retours des développeurs et la plupart des éléments sont encore susceptibles d’évoluer d’ici à la version finale.

La récupération de cette première bêta peut se faire depuis cette page.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

jQuery, créé pour faciliter l'écriture du JavaScript...

... mais parfois remis en cause

jQuery 3.0 : la première bêta est disponible

Commentaires (80)


> il ne sert plus à rien puisque toutes les opérations effectuées peuvent très bien se faire en JavaScript directement





Oui et non, c’est faisable mais souvent au prix d’un code beaucoup plus verbeux voir illisible.


D’une manière générale, il y a vraiment des trucs très sympa dans jquery. 



Même aujourd’hui (avec les nav récents), développer avec jQuery / Less c’est autrement plus sympa qu’en JS / CSS pure. 


La fonction dollar déjà les fonction hide et show ça évite pas mal de code et de réinventer la roue ss même parler des appels ajax


Oui et non là aussi avec quelques alias bien placés, et quand les perfs deviennent un peu critiques ça peut aider de partir sur la solution native. :)



Après, en dehors de la façade quant à la manipulation du DOM apportée par JQuery, y a encore d’autres composants que je trouve (personnellement) encore assez utiles :




  • l’aggrégation d’évènements / médiateur

  • tout ce qui a trait aux requêtes AJAX








monpci a écrit :



La fonction dollar déjà les fonction hide et show ça évite pas mal de code et de réinventer la roue ss même parler des appels ajax





C’est sur que document.getElementById(idDiv).style.display = ‘none’; c’est d’un compliqué… et pourtant 70 x plus rapide.









EMegamanu a écrit :



Oui et non là aussi avec quelques alias bien placés, et quand les perfs deviennent un peu critiques ça peut aider de partir sur la solution native. :) 





Bah oui, jQuery étant écrit en JavaScript, tout ce qu’on fait en jQuery peut par définition être fait en JavaScript “pur”, et toujours par définition plus vélocement qu’en passant par une couche intermédiaire…



S’kissraicoool, c’est d’avoir un préprocesseur qui prend du JS avec jQuery pour la lisibilité, et le “compile” en JS natif pour la vitesse.









Krogoth a écrit :



C’est sur que document.getElementById(idDiv).style.display = ‘none’; c’est d’un compliqué… et pourtant 70 x plus rapide.





Maintenant le même chose sur toutes les div qui ont une classe qui commence par un même libellé mais finissent différemment … À oui tu va juste écrire une tonne de JS pour gagner quelques ms la ou tu en a pas vraiment besoin. ;)



Pourquoi jquery n’est pas intégré directement dans les nav ? Ca éviterais de se taper le dl.


Une librairie inventée pour combler les lacunes de java sous les browsers, ce langage qui est une vraie plaie, qui est toujours responsable des plantages, des popups, des pubs et tout ce qu’on déteste, vive les pages HTML pures.








Stel a écrit :



Pourquoi jquery n’est pas intégré directement dans les nav ? Ca éviterais de se taper le dl.





Il y a une extension firefox pour çà <img data-src=" />







Exception a écrit :



Une librairie inventée pour combler les lacunes de java sous les browsers, ce langage qui est une vraie plaie, qui est toujours responsable des plantages, des popups, des pubs et tout ce qu’on déteste, vive les pages HTML pures.







java <img data-src=" />









33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



Bah oui, jQuery étant écrit en JavaScript, tout ce qu’on fait en jQuery peut par définition être fait en JavaScript “pur”, et toujours par définition plus vélocement qu’en passant par une couche intermédiaire…



S’kissraicoool, c’est d’avoir un préprocesseur qui prend du JS avec jQuery pour la lisibilité, et le “compile” en JS natif pour la vitesse.







Y a quand même moyen de s’approcher des perfs natives avec des bibliothèques telles que jQuery ou LoDash.



Certains développeurs débutant en revanche on tendance à faire quelques erreurs, que l’on retrouve partout sur des gros projets en prod (vas y que je te multiplie des milliers de fois des appels à $( this ) dans mon gestionnaire d’évènement).



Accessoirement, enfin c’était surtout à ses débuts, jQuery faisait aussi quelques erreurs d’implémentation d’un point de vue perf.



Sinon ton préprocesseur ça s’appelle Dash, TypeScript ou bien encore CoffeeScript, ainsi que la plupart des outils de transformation/optimisation/minimisation du code. Je dis ça, je dis rien.



Après je ne vais pas dire que tel ou tel est mieux. Y a des questions de contexte et de besoins. En revanche, bien maitriser son outil et en connaître les subtilités… c’est important.





Krogoth a écrit :



C’est sur que document.getElementById(idDiv).style.display = ‘none’; c’est d’un compliqué… et pourtant 70 x plus rapide.





Modification de style inline, pouah c’est caca. Puis ça manque de fluent ou d’une possibilité de modifier plusieurs valeurs simultanément. :o)



Sinon, en dehors des id et des classes il y a HTMLElement.prototype.querySelector et HTMLElement.prototype.querySelectorAll



Pour jouer sur le style, HTMLElement.prototype.classList c’est pas mal aussi.



A quand la prochaine leçon professeur ? :o)



Jquery va falloir le tuer aussi un jours ^^ et passer a des framework JS plus propres.








Exception a écrit :



Une librairie inventée pour combler les lacunes de java sous les browsers, ce langage qui est une vraie plaie, qui est toujours responsable des plantages, des popups, des pubs et tout ce qu’on déteste, vive les pages HTML pures.





http://sametmax.com/la-communaute-js-est-actuellement-une-machine-a-creer-de-la-dette-technique/



Roh c’est l’autre qui a commencé en parlant de hide() et show() comme un des atouts de jQuery :p


beaucoup se débarrasse de Jquery aussi pour des question de perf (rien que le sélecteur dom est d’une lenteur :&nbsphttps://jsperf.com/id-vs-class-vs-tag-selectors/140).



Il y a quelque année les sites se résumé a quelque bout de JS par ci par la, sa n’était donc pas gênant, mais aujourd’hui avec les grosse webapp en JS, se passer de&nbsp;Jquery&nbsp; correspond a une grosse optimisation de son code.



Après pour se qui est du gain de temps a codé en Jquery, dans bien des cas c’est aussi long a écrire en vanilla qu’en JS http://youmightnotneedjquery.com/). Et c’est sans compté sur ceux qui font n’importe quoi et qui te ponde 30 ligne en Jquery la ou en vanilla on peut faire la même chose en 10 lignes.








Exception a écrit :



Une librairie inventée pour combler les lacunes de java sous les browsers, ce langage qui est une vraie plaie, qui est toujours responsable des plantages, des popups, des pubs et tout ce qu’on déteste, vive les pages HTML pures.





Absolument pas. Par contre les bases ont été créées à l’arrache en deux semaines et implémentées tel quel dans Netscape.



Le but était d’offrir un petit langage de script sans grande prétention pour attirer les développeurs amateurs. Le langage du web ça devait être Java (avec une idée d’avoir du code lourd côté client).

Un accord entre Netscape et Sun a été de le nommer JavaScript pour faire de la pub à Java.



Quant aux sources d’inspiration du langage il n’y a pas que Java.




  • quelques objets de base (comme Date) : Java

  • syntaxe :&nbsp; Java (et encore Java s’est inspiré de C pour la syntaxe…)

  • regexp : Perl

  • functions : Scheme

  • prototypage : Self



    En revanche, Java a échoué dans son objectif et JavaScript a évolué depuis vers le monde de l’entreprise en conservant aussi bien ses bonnes et mauvaises idées de départ.









marba a écrit :



http://sametmax.com/la-communaute-js-est-actuellement-une-machine-a-creer-de-la-dette-technique/





Assez orienté son billet. ^^;



Par contre, j’irai un poil dans son sens car je trouve que l’écosystème du JavaScript commence tout doucement à ressembler à celui de Java et sa pléthore de bibliothèques tierces pas toujours compatibles entre elles malgré des specs et objectifs communs…









EMegamanu a écrit :



Par contre, j’irai un poil dans son sens car je trouve que l’écosystème du JavaScript commence tout doucement à ressembler à celui de Java&nbsp;n’importe quoi en informatique et sa pléthore de bibliothèques tierces pas toujours compatibles entre elles malgré des specs et objectifs communs…










v1nce a écrit :





Mwui ?



Pas ma faute si l’éditeur de NXI fait n’importe quoi



Dans ta citation si &nbsp;tu remplaces JAVA par PHP, C ou n’importe quel autre langage de ton choix elle reste valide.

&nbsp; &nbsp;








goldbergg a écrit :



beaucoup se débarrasse de Jquery aussi pour des question de perf (rien que le sélecteur dom est d’une lenteur :&nbsp;https://jsperf.com/id-vs-class-vs-tag-selectors/140).



Il y a quelque année les sites se résumé a quelque bout de JS par ci par la, sa n’était donc pas gênant, mais aujourd’hui avec les grosse webapp en JS, se passer de&nbsp;Jquery&nbsp; correspond a une grosse optimisation de son code.





Un test qui a plus de 4 ans…&nbsp;<img data-src=" />&nbsp;Entretemps, les perfs ont dû nettement évoluer, je serais curieux de connaître l’écart entre JS natif et jQuery avec la dernière version de la lib sur un navigateur récent !



$(<img data-src=" />).show();



J’adore jQuery, correctement utilisé c’est un gain de temps incroyable tout en ayant des performances largement acceptables!

jQuery c’est aussi et surtout jQuery UI<img data-src=" />


Oh mince, j’avais cru lire “adieu javascript”…, dommage, une prochaine fois peut être.


Heureusement que JQuery existe, c’est tellement une plaie manipuler le DOM et compagnie en JS Vanilla…



Apres ce genre d’avis “Une partie des développeurs estime en effet qu’il ne sert plus à rien puisque toutes les opérations effectuées peuvent très bien se faire en JavaScript directement.” c’est quand même peu ridicule… ce genre de propos viens de développeurs qui doivent encore travailler a l’age de pierre, probablement portant un teeshirt “vive linux”, ne jurent que par VIM et le terminal… bref qui sont tres conservateurs d’idéologies tels que performances blablabla, code natif blablabla… En 2016, on a des CPU a 10 cœurs et des smartphones plus puissants qu’une nintendo wii <img data-src=" />


Intégration totale se serait cool cependant il faut convaicre Google, MS, FF, Apple et Opéra en autre….


Bin oui, on a de la ressource au chiotte les optimisation… faisons tous n’importe quoi…

Et sinon sur smartphone avec le peux de ram certain site on beaucoup de mal (surtout qu’on a pas tous un haut de gamme).

Quand je vois certain site qui prenne jusqu’à 1 Go de ram, je les ai pas test sur smartphone, mais a mon avis sa doit pas être joli.


Si je prend ton raisonnement vu que ca rame maintenant ca peut ramer demain c’est pas grave ! on a l’habitude



&nbsp;/facedesk



Ca me rapelle la conférence d’un des grands noms de chez IBMs qui parlait des problèmes de performance des sociétés et qui disait que les gens faisaient de moins en moins attention et qu’on finirait par atteindre une masse “critique” de mauvais / lent qui rattrapera l’évolution de vitesse et qu’a ce moment là les gens commenceront de nouveau à apprendre à coder… (après le mec est un troll aussi, mais je pense qu’il n’a pas tord dans le fond)


Si tu scroll un peux vers le bas tu verra que des test il y en a avec des date beaucoup plus ressente.



D’ailleurs sur jsperf des test de comparaison vanilla vs [insérer le nom d’un framework ici] il y en a la pelle, il suffit de chercher un peux.



Pour le lien c’est vrais que j’aurais pu faire attention a la date et en balancer un plus récent histoire d’être plus crédible, en voici un plus recent&nbsphttp://jsperf.com/zepto-vs-jquery-2013122 avec&nbsp;jquery&nbsp;3, c’est pas forcement mieux ^^


Perso, ce merdier est précisément ce qui me fait lâcher peu à peu le front.

J’envoute les clients pour qu’ils arrêtent de demander des trucs trop cools à la mode qui servent à rien sauf à ralentir le site et foutre la merde dans le code (et pourrir le design - j’entends UX par là - &nbsp;généralement).

Sérieux, on n’est pas bien avec notre html/css paisible, propre, détendu du gl… ?

Pire, c’était plus facile de gérer les multiples navigateurs incompatibles (coucou IE6) que ce bordel sans nom de JS et Cie. Je regretterais presque Flash (nan, je déconne !).

Apprendre 20 frameworks par an, je suis trop vieux et pas assez bien payé pour…

Un reset CSS et go dans l’éditeur vide.

SIMPLE ET PROPRE LE WEB DOIT ETRE.








maestro321 a écrit :



aussi et surtout jQuery UI<img data-src=" />





Ca fait longtemps que les devs sont passés sur Bootstrap, Material, Foundation…









Folgore a écrit :



Heureusement que JQuery existe, c’est tellement une plaie manipuler le DOM et compagnie en JS Vanilla…



Apres ce genre d’avis “Une partie des développeurs estime en effet qu’il ne sert plus à rien puisque toutes les opérations effectuées peuvent très bien se faire en JavaScript directement.” c’est quand même peu ridicule… ce genre de propos viens de développeurs qui doivent encore travailler a l’age de pierre, probablement portant un teeshirt “vive linux”, ne jurent que par VIM et le terminal… bref qui sont tres conservateurs d’idéologies tels que performances blablabla, code natif blablabla… En 2016, on a des CPU a 10 cœurs et des smartphones plus puissants qu’une nintendo wii <img data-src=" />







Etant donné le nombre effarant de sites qui rament et qui m’énervent à longueur de journée, y compris sur un desktop bien puissant, je pense qu’il y a vraiment des coup de pied au cul qui se perdent.



Sérieusement les gars, je faisais des trucs plus fluide il y a 30 ans sur des ordinateurs 8 bits…



Si on m’avait dit à l’époque que les programmeurs deviendraient si mauvais qu’avec l’équivalent d’un supercalculateur de l’époque, on ne parviendrait même plus à afficher une simple page de texte de façon fluide, j’aurais trouvé cela déprimant.



Non seulement le langage Javascript est un langage lent, inefficace ou l’abstraction a un coût CPU élevé. Mais le fait d’y rajouter des framework par dessus ne fait qu’achever le malade tout en finissant de déconnecter les programmeurs des réalités qu’ils manipulent et de les pousser à écrire n’importe quoi sans comprendre ce qu’ils font.



Mais le pire est que ce système catastrophique prends maintenant des allures d’infection zombie. Certains en font maintenant des Os, des systèmes pour IHM.



On trouve même des gens pour vouloir mettre du Javascript dans des objets connectés, comme si la consommation énergétique de l’humanité n’était pas un problème écologique suffisamment sérieux et qu’on pouvait se permettre de multiplier par million des objets basés sur des techniques monstrueusement inefficaces sur le plan énergétique pour la simple raison bassement commerciale qu’il existe quantité de programmeurs qui ne maîtrisent que ça.



Mais au fond, exploiter la médiocrité sera toujours plus rémunérateur que de promouvoir l’excellence. C’est un triste exemple qui montre ou la logique mercantile qui bouffe notre civilisation nous mène…









youri_1er a écrit :



Maintenant le même chose sur toutes les div qui ont une classe qui commence par un même libellé mais finissent différemment … À oui tu va juste écrire une tonne de JS pour gagner quelques ms la ou tu en a pas vraiment besoin. ;)







Non une ligne : document.querySelector(‘[class^=“debut”], [class*=” debut”]’)



Merci, la plupart des sites n’ont pas besoin de faire gagné 10ms sur du code exécuté coté client.

Par contre, le temps de développement lui coute cher. Quand j’entends certains dire que jquery c’est lourd, ca ralenti etc …. c’est comme dire que Photoshop est un programme super lourd, qu’on peut tout faire via paint en pixel par pixel. Oui mais pour produire la MEME image, tu va prendre un temps fou.



Jquery c’est très bien, la manipulation du DOM en + d’être super simple est rapide, JqueryUI c’est encore mieux, on crée des interfaces client intéractive super clean, rapidement, sans se faire chier à gérer des merdes qu’on devrait gérer en vanilla.



Si vanilla peut très bien faire l’affaire pour beaucoup de chose, comme qq1 l’a dit + haut “Maintenant le même chose sur toutes les div qui ont une classe qui commence par un même libellé mais finissent différemment … À oui tu va juste écrire une tonne de JS pour gagner quelques ms la ou tu en a pas vraiment besoin. ;)”

Ca en vanilla, c’est BEAUCOUP BEAUCOUP + qu’une seule ligne en Jquery.



Merci Jquery d’avoir rendu le développement javascript aussi simple intra navigateur.



et j’ai même pas abordé l’ajax….


L’ajax, je connais pas grand monde qui en a fait et c’est pas si compliqué que ça.



J’aurais plutôt dit ça avec le drag’n drop : tuto pour en faire en JS sans Jquery.


A part que tu ne prend pas le problème par le bon coté, faire du vanilla ne veux pas dire se taper systématique le même code bien chiant a chaque fois (et encore bien&nbsp;chiant&nbsp;mais&nbsp;au moins on sait se que l’on fait), de mon coté j’utilise&nbsp;des helper pour allez plus vite.

ex bateau :&nbsp;

function getById(id){&nbsp; &nbsp; return document.getElementById(id);}

Sans compter les IDE avec l’auto complete qui font que l’on a juste a tapé 3 lettre puis tab.

Dans le lien que j’ai donnée précédemment http://youmightnotneedjquery.com/) on nous donne les équivalent de nombreuse fonction jquery, rien n’interdit d’encapsuler les version vanilla dans des fonction pour allez plus vite (c’est justement le but d’une fonction).

Au passage dans le lien on peut constater que certain fonction sont plus rapide a écrire en vanilla qu’en jquery



Donc dire que jquery permet d’accélérer le dev, oui mais non, on peut allez aussi vite sans! ( en ajax avec le XHR 2, c’est vraiment pas bien méchant de faire des requet avec toute sorte de verbe).

&nbsp;

Par contre, et c’est très important, il faut s’avoir que par exemple \(("#monId") (ou dans sa forme optimisé \)(document.getElementById(“monId”)) n’est pas égal document.getElementById(“monId”), jquery transforme l’objet dom en objet &nbsp;jquery (se qui prend du temps), tous sa pour facilité la compatibilité pour le reste du framework, or dans bien souvent cette transformation ne sert a rien si se n’est perdre du temps…

Et malheureusement, il n’y a pas que le sélecteur dom qui soit beaucoup trop lourd vis a vis de sont utilisation principal, se qui fait de jquery un framework non seulement sous exploité et bien trop lourd pour souvent pas grand chose…



Pour ton exemple avec photoshop, sa reviendrait a perdre 30 seconde a lancer photoshop pour au final seulement rogner une image, la ou paint se serait ouvert en 1 sec et avec lequel le boulot aurait été fini avant même que&nbsp;photoshop soit chargé.

&nbsp;

Et quand on couple sa a des mauvais développeur qui veulent te foutre du jquery partout même la ou il n’y en a pas besoin, on se retrouve avec des daube dans se genre :&nbsphttp://codepen.io/karolpodlesny/pen/npKqu

ou en seulement 55 ligne de vanilla j”arrive exactement au même résultat sans aucune libs.

(le mec a du passé 10x fois plus de temps que moi a écrire sont code en jquery que moi en vanilla xD)


Reste plus ‘à faire la boucle pour appliquer le display none à chaque élément, c’est sur que ça vaut pas un :

$(‘div[classe^=“début”]’).hide()



Pour moi le jquery est loin d’être à utiliser 100% du temps, mais il apporte d’énormes avantages de lecture du code, gain de temps et peu de perte de perd si l’on ne fait pas n’importe quoi sur sa page (et là, ce ne sont pas les quelques % de différence entre JS et jquery qui ferons une grande différence pour l’utilisateur).



Le sélecteur ne fait pas beaucoup mieux qu’un getElementBy… Mais il le fait simplement et de manière très lisible.


$(‘div[class^=“début”]’).hide() &lt;&lt; marchera pas si t’as plusieurs classes


Windows, me semble-t-il, voudrait encourager le javascript dans les écoles. N’est-ce pas trop poreux ? (pour la sécurité ?)


Et pourtant ça fonctionne!

Je te laisse tester!



Par contre si tu ne souhaite que les div n’ont que cette classe spécifique

$(“span[class=‘début’]”).not(‘[class=” “]’).hide()


J’aime beaucoup lire les devs.



Dès qu’un soft tiers, un OS, etc., deconne un tant soit peu, rame un tant soit peu, on a des cris d’orfraie.



Par contre, quand ce sont eux qui codent leur site, on lit des aberrations comme “optimiser le code ca sert à rien, c’est pas quelques % qui font la différence, etc. “le end user ne le verra pas”, etc.








youri_1er a écrit :



Et pourtant ça fonctionne!

Je te laisse tester!



Par contre si tu ne souhaite que les div n’ont que cette classe spécifique

\(("span[class*='début']").not('[class*=" "]').hide()





Précision, selon le positionnement de la classe dans la liste des class de la &nbsp;div l'on choisira&nbsp;\)
(“span[class^=‘début’]”) ou&nbsp;$(“span[class*=‘début’]”), si elle est seule on choisira plutôt le ^ (contrairement&nbsp;a mon exemple du dessus … désolé!) pour alléger le filtrage not!









Drepanocytose a écrit :



J’aime beaucoup lire les devs.



Dès qu’un soft tiers, un OS, etc., deconne un tant soit peu, rame un tant soit peu, on a des cris d’orfraie.



Par contre, quand ce sont eux qui codent leur site, on lit des aberrations comme “optimiser le code ca sert à rien, c’est pas quelques % qui font la différence, etc. “le end user ne le verra pas”, etc.





le truc sur le débat ici sur le JS c’est que si tu en arrive a te dire, “mince ça coince” c’est pas une optimisation qu’il te faut, mais repenser ton site.

Quelques ms gagnés par ci ou par la ne changerons rien au fait qu’il y a surement un mauvais choix dans les éléments qui font le travail, tout reporter sur le JS est l’assurance d’avoir un site qui rame chez certains utilisateur alors qu’une bonne utilisation des ressources et langages serveurs assurera des performances sensiblement identiques (et souvent meilleures) chez tous les utilisateurs.



Maintenant il ne faut pas dire&nbsp;“Le end-user ne le vera pas”, mais tout faire pour que ce soit le cas.



il est pas ‘orienté’, il est complètement à côté de la plaque. Il dit critiquer JS alors qu’il ne propose aucun argument contre js.



La seule chose qui semble le défriser c’est la diversité, avec à peu près le même genre d’argument foireux que ceux auquels on a eu droit au siècle dernier vis à vis de l’écosystème linux.








sr17 a écrit :



Mais au fond, exploiter la médiocrité sera toujours plus rémunérateur que de promouvoir l’excellence. C’est un triste exemple qui montre ou la logique mercantile qui bouffe notre civilisation nous mène…





Bien sûr, c’est bien connu: le monde est divisé en deux catégories: les ‘bons’ qui font du low level et écrivent quelques ligbes d’asm chaque matin en se rasant, et les autres, les médiocres, qui font du managé, pas par choix raisonné mais juste parce qu’ils ne doivent pas avoir suffisamment d’intelligence pour arriver à la cheville des bons.



A ce jeu, moi j’ai un autre système de catégorisation: les bons qui comprennent que le génie logiciel c’est une affaire de compromis pour des paramètres multiples et divers (et que la perf est un paramètre parmi tant d’autre, et très rarement le facteur critique) ; et les autres, ceux remplis de certitudes dans leur monde tout noir ou tout blanc.



Quel est l’intérêt face à un simple $(“span.début”)?

si le truc c’est de paramétrer la classe (début-12 par exemple) pourquoi ne pas utiliser les data-X?

&nbsp;


Le hide()/show(), ça me fait penser à un article que j’ai écrit dessus. Je ne les utilise plus.



Si tu veux n’importe quelle classe qui commence par début : document.querySelector(‘[class^=“debut”], [class*=” debut”]’)

[class^=“debut”] &lt;&lt; la première

[class*=” debut”] &lt;&lt; les suivantes

On est obligé de faire 2 règles, c’est du CSS de base.

Et pour qu’il n’y ait qu’une classe tu peux écrire ça document.querySelector(‘[class^=“début”]:not([class=” “])’) mais t’as eu bonne idée de laisser trainer des espaces ça ne fonctionne pas. Avec [class=‘début’], cela ne permet pas de savoir si c’est au début, la classe “post-début” sera acceptée.



En tout cas, je fais un constat au boulot, les gens qui ne codent qu’en Jquery ne savent pas code en JS, ils codent en Jquery, et quand on leur enlève Jquery, ils ne savent plus rien faire.


Franchement je trouve ça encore trop lourd.



L’approche de Lea Verou avec Bliss.js est bien meilleure.



Pour moi jQuery c’est bientôt fini.








zefling a écrit :



Le hide()/show(), ça me fait penser à un article que j’ai écrit dessus. Je ne les utilise plus.



Si tu veux n’importe quelle classe qui commence par début : document.querySelector(‘[class^=“debut”], [class*=” debut”]’)

[class^=“debut”] &lt;&lt; la première

[class*=” debut”] &lt;&lt; les suivantes

On est obligé de faire 2 règles, c’est du CSS de base.

Et pour qu’il n’y ait qu’une classe tu peux écrire ça document.querySelector(‘[class^=“début”]:not([class=” “])’) mais t’as eu bonne idée de laisser trainer des espaces ça ne fonctionne pas. Avec [class=‘début’], cela&nbsp;



Oui mais ça n’a rien a voir avec JS VS Jquery car ce n’est que tu sélecteur CSS.



Enfin si tu trouve plus simple a lire à coder, et a entretenir un JS pure c’est ton choix, le miens est vite fait, je connait le fonctions JS et ce que ça implique en temps et dev’ et les fonctions Jquery et ce que ça fait gagner, utiliser le bon choix au bon moment sera plus pertinent que de dire ‘non je fait pas de jquery/JS’ car je peut faire la même chose en JS/Jquery!

ce sont deux éléments complémentaires.









Stel a écrit :



Pourquoi jquery n’est pas intégré directement dans les nav ? Ca éviterais de se taper le dl.





Ca va c’est pas si lourd jquery et si tu merge bien tous tes js jvois pas le prob

Sans parler des versions jquery qui existent, yen a un paquet









CryoGen a écrit :



java <img data-src=" />





Il doit être commercial <img data-src=" />



jQuery est un peu à la traine ces dernières années, notamment depuis l’arrivée des frameworks (ceci dit je n’ai pas testé cette v3.0). Mais il a fortement contribué à l’émergence d’un web plus dynamique et plus “professionnel”.

Par contre jQuery Mobile c’est une daube complète <img data-src=" />



Pour avoir voir un peu vu certains framework, y’en a pas mal qui reprennent les concepts de Jquery, pas tout. D’ailleurs le $() est repris jusque dans le console de debug des navigateur. Après c’est juste du sucre pour appeler des trucs comme document.querySelector().








sr17 a écrit :



Sérieusement les gars, je faisais des trucs plus fluide il y a 30 ans sur des ordinateurs 8 bits…&nbsp;





Ouai mais en local, un site web par definition passe par le reseau, rien que ca ca change bcp de choses.







sr17 a écrit :



Non seulement le langage Javascript est un langage lent, inefficace ou l’abstraction a un coût CPU élevé. Mais le fait d’y rajouter des framework par dessus ne fait qu’achever le malade tout en finissant de déconnecter les programmeurs des réalités qu’ils manipulent et de les pousser à écrire n’importe quoi sans comprendre ce qu’ils font.





JS est un langage interprete et comparativement aux autres langages du meme type (Python, Ruby, PHP) il est plus rapide.



Au sujet des frameworks, rien de specifique a JS, il y a en pour tous les langages (Rails, .NET, Django, Laravel, Qt, MFC, Boost, Delphi…).

“Deconnecter les programmeurs des realites” ? Vite revenons aux char * et aux malloc, au Fortran ou mieux a l’asm 68000…

&nbsp;



sr17 a écrit :



On trouve même des gens pour vouloir mettre du Javascript dans des objets connectés





Rien de deconnant a ca. Les objets connectes (comprendre a Internet) utilisent logiquement les technos web. Et le langage du web c’est JS. Ca aurait ete du Ruby, du PHP ou du Python ca serait meme ete plus lent que JS.

T’aurais prefere qu’ils mettent du Fortran ?







sr17 a écrit :



C’est un triste exemple qui montre ou la logique mercantile qui bouffe notre civilisation nous mène…





T’as raison, c’etait mieux avant, y’avait absolument pas de logique mercantile. Et les devs avaient tous une barbe parceque c’etait des hommes, des vrais, maintenant c’est tous des puceaux.









brazomyna a écrit :



Bien sûr, c’est bien connu: le monde est divisé en deux catégories: les ‘bons’ qui font du low level et écrivent quelques ligbes d’asm chaque matin en se rasant, et les autres, les médiocres, qui font du managé, pas par choix raisonné mais juste parce qu’ils ne doivent pas avoir suffisamment d’intelligence pour arriver à la cheville des bons.







Ce n’est pas parce qu’on critique un langage ou un environnement que les programmeurs qui l’utilisent doivent pour autant se sentir visé.



Je crois que tous les programmeurs dans leur vie ont un jour programmé avec des trucs pas terrible.



Et ce n’est pas parce que je l’ai aussi fait que pour autant je vais trouver ça bien.





A ce jeu, moi j’ai un autre système de catégorisation: les bons qui comprennent que le génie logiciel c’est une affaire de compromis pour des paramètres multiples et divers (et que la perf est un paramètre parmi tant d’autre, et très rarement le facteur critique) ; et les autres, ceux remplis de certitudes dans leur monde tout noir ou tout blanc.





Sauf qu’a force d’accumuler les mauvais compromis année après année tout en se moquant des performances, on a fini par aboutir à un bouzin infâme qui bouffe toute la puissance et détruit l’expérience utilisateur.



Voila à quoi ça mène de faire des compromis…









sr17 a écrit :



Ce n’est pas parce qu’on critique un langage ou un environnement que les programmeurs qui l’utilisent doivent pour autant se sentir visé.



C’est donc ça ton contre-argument: si on n’est pas d’accord c’est parce qu’on se “sent visé” ?




Ca va chercher loin dis-donc ...      

&nbsp;







sr17 a écrit :



on a fini par aboutir à un bouzin infâme qui bouffe toute la puissance et détruit l’expérience utilisateur.






L'overhead d'une telle solution est déjà faible au regard de la pluissance dispo. Et elle a en plus le bon goût d'être une valeur constante, qui se réduit donc en proportion au gré de l'augmentation exponentielle de la puissance disponible.      






Tu fais surtout silence sur la quantité à peu près incalculable de travail économisé grâce à ce genre de solutions -certes sub-optimales au niveau des perfs mais- incomparativement meilleures en terme d'efficience de développement. C'est autant de projets qui ont pu être menés à bien plus rapidement, avec moins de coûts (au sens large), ou même qui ont tout simplement ont été rendu viables, et ont donc pu voir le jour.      






C'est typiquement l'histoire de la genèse du PHP: un langage super pas efficient en terme de perfs (longtemps des années lumières derrière le JS, d'ailleurs). Bref une "merde absolue" dans ton référentiel étriqué qui prend en compte le seul critère des performances. Pourtant personne aujourd'hui n'osera nier à quel point il a permis de faire exploser les développements web, baisser leurs coûts, et donc enrichir l'offre de services comparé aux CGI qui existaient déjà depuis bien longtemps.      






Autre exemple concret: dans mon monde pro, un homme-jour c'est entre 1.0 et 1.5k€. Un serveur&nbsp; plus puissant c'est 3-5k€, les projets ce sont grand minimum des  centaines d'homme jour. Faisons un calcul trivial: pour un projet de 1000 MD, le plus efficient pour moi serait selon toi une solution technique qui sera (soyons fous) 30% plus efficiente niveau perf (soit -5k€), mais demanderait (soyons sympas) 10% d'homme.jour en plus (soit +100k€) ?      

&nbsp;








tanguy_k a écrit :



Ouai mais en local, un site web par definition passe par le reseau, rien que ca ca change bcp de choses.







Etudie la question, tu comprendra que le réseau n’y est pour rien dans la majorité des sites web qui rament.



Il y a même des sites qui permettent d’analyser finement la question.



D’ailleurs, je suis sur un connexion à 100Mb/s et c’est encore plus rageant de voir toute cette lenteur. Sur un smartphone, c’est encore plus insoutenable.





JS est un langage interprete et comparativement aux autres langages du meme type (Python, Ruby, PHP) il est plus rapide.





Félicitation, utiliser un langage un peu plus rapide que ce qui se fait de pire devrait nous rassurer.



Mais javascript n’est pas le seul responsable du problème. Le rapport mal fichu avec le DOM et les multiples framework “pour encapsuler le caca” participent grandement au problème.





Au sujet des frameworks, rien de specifique a JS, il y a en pour tous les langages (Rails, .NET, Django, Laravel, Qt, MFC, Boost, Delphi…).





Sauf que les framework n’ont pas la même incidence suivant le langage. Dans des langages comme Javacript ou PHP ou tout autre langage non compilé, le cout de l’abstraction est très élevé.





“Deconnecter les programmeurs des realites” ? Vite revenons aux char * et aux malloc, au Fortran ou mieux a l’asm 68000…





Un programmeur qui n’a pas appris le fonctionnement a bas niveau ne programmera jamais correctement un langage de haut niveau.



C’était vrai par le passé, ça l’est toujours aujourd’hui et ça le sera toujours demain.

 



Rien de deconnant a ca. Les objets connectes (comprendre a Internet) utilisent logiquement les technos web. Et le langage du web c’est JS. Ca aurait ete du Ruby, du PHP ou du Python ca serait meme ete plus lent que JS.





Sauf que Js n’est qu’un simple langage de script utilisé dans un navigateur.



Toutes les couches réseau, soit le fondement de l’internet, elles sont écrites en C.



D’ailleurs, l’idéal pour les objets connectés n’est pas de se connecter directement au web, mais d’utiliser un intermédiaire, ce qui leur permet d’utiliser des protocoles bien plus simples et des types de liaison plus adaptés.





T’aurais prefere qu’ils mettent du Fortran ?





Et pourquoi pas du Cobol, pendant que tu y est ?



L’idéal pour programmer des objets connectés, c’est l’assembleur ou à la rigueur le C.



Et quand on parle du C, ce n’est pas une préférence de langage, c’est juste que c’est un langage adapté parce qu’il a été conçu pour ça.





T’as raison, c’etait mieux avant, y’avait absolument pas de logique mercantile. Et les devs avaient tous une barbe parceque c’etait des hommes, des vrais, maintenant c’est tous des puceaux.





Visiblement tu n’as pas compris. Alors je vais le rééxpliquer.



En informatique, aucun langage n’est équivalent. Chaque langage a été conçu avec un but et un objectif donné.



Le langage Javascript n’a pas été conçu pour écrire du code de bas niveau.



Le langage C a été conçu pour écrire du code de bas niveau.



La logique mercantile, c’est de dire qu’on va faire un produit qui va se programmer en Javascript pour la mauvaise raison qu’il y a un marché de xxxx millions de programmeurs front end qui pourront le faire sans effort et que ça facilitera la vente des objets.



Sauf que voila, c’est ce genre de logique qui nous éloigne progressivement de l’idéal technique et aboutit précisément à faire de la merde.



Et c’est d’autant plus vrai que cette mauvaise logique est cummulative et qu’au bout d’un certain temps, le résultat devient catastrophique.



Pour l’instant, vous ne voyez peut être pas encore le problème, mais le cout énergétique de l’internet commence déjà à devenir prohibitif.



Quand les objets connectés vont commencer à sortir du cadre du gadget hype et du jouet pour geek, le problème de la consommation va rapidement devenir un sujet de préoccupation majeur.









sr17 a écrit :



Pour l’instant, vous ne voyez peut être pas encore le problème, mais le cout énergétique de l’internet commence déjà à devenir prohibitif.




Quand les objets connectés vont commencer à sortir du cadre du gadget hype et du jouet pour geek, le problème de la consommation va rapidement devenir un sujet de préoccupation majeur.







Lol, JS qui engendre la multiplication des centrales nucléaires <img data-src=" />



D’ailleurs, c’est bien connu que les iPhones (avec un framework basé sur un dérivé du C) ont une autonomie 10 fois plus importante que les Android (et son méchant Java) à batterie égale.



Tu devrais postuler chez Apple, ils adorent les techno-marketeux de ta trempe <img data-src=" />









brazomyna a écrit :



C’est donc ça ton contre-argument: si on n’est pas d’accord c’est parce qu’on se “sent visé” ?




Ca va chercher loin dis-donc ...









Et pourtant, mes critiques n’ont jamais porté sur les programmeurs mais juste sur des technologies.



Penser qu’une mauvaise technologie impliquerait forcément de mauvais programmeurs, ce n’a jamais été le sens de mes paroles. Donc ne les interprétez pas ainsi.



               





L’overhead d’une telle solution est déjà faible au regard de la pluissance dispo.





C’est malheureusement une pure idée reçue qui se colporte depuis trop longtemps.



Et le résultat, c’est qu’a force de raisonner comme ça, on a accumulé les errements année après année pour aboutir au final à bouffer une puissance démentielle et dégrader l’expérience utilisateur.





Et elle a en plus le bon goût d’être une valeur constante, qui se réduit donc en proportion au gré de l’augmentation exponentielle de la puissance disponible.





Moquons nous de la puissance utilisée, utilisons toujours plus de couches pour programmer vite, de toute façon les ordinateurs de l’an prochain auront doublé de puissance et ça ne se verra plus.



Le seul problème, c’est que ça fait déjà un petit moment que la puissance n’augmente plus comme auparavant et que le mur commence à se rapprocher…





Tu fais surtout silence sur la quantité à peu près incalculable de travail économisé grâce à ce genre de solutions -certes sub-optimales au niveau des perfs mais- incomparativement meilleures en terme d’efficience de développement. C’est autant de projets qui ont pu être menés à bien plus rapidement, avec moins de coûts (au sens large), ou même qui ont tout simplement ont été rendu viables, et ont donc pu voir le jour.





Sauf que l’on peut regretter que la réduction des coûts soit la seule obsession dans l’informatique actuelle et particulièrement dans le monde du web.



Produire rapidement de la merde à bas coût en oubliant que l’utilisateur final est tout à fait sensible au confort d’utilisation des services (et que les critères SEO commencent à l’intégrer) commence à perdre sérieusement de la pertinence.



Mais ce n’est pas le programmeur qu’il faut incriminer mais le marché et l’incompétence des donneur d’ordres qui ont fait du prix le principal critère de choix en informatique.





C’est typiquement l’histoire de la genèse du PHP: un langage super pas efficient en terme de perfs (longtemps des années lumières derrière le JS, d’ailleurs). Bref une “merde absolue” dans ton référentiel étriqué qui prend en compte le seul critère des performances. Pourtant personne aujourd’hui n’osera nier à quel point il a permis de faire exploser les développements web, baisser leurs coûts, et donc enrichir l’offre de services comparé aux CGI qui existaient déjà depuis bien longtemps.





PHP est effectivement une merde absolue sur le plan de l’efficience.



Je suis pourtant d’accord avec toi que ce langage n’a pas apporté que du mauvais. D’ailleurs on peut le dire de beaucoup les langages.



Mais ils serait temps de réaliser que tout ce qui est bon dans PHP pourrait être repris dans un langage bien meilleur. Le bilan énergétique de l’humanité en serait amélioré.





Autre exemple concret: dans mon monde pro, un homme-jour c’est entre 1.0 et 1.5k€. Un serveur  plus puissant c’est 3-5k€, les projets ce sont grand minimum des centaines d’homme jour. Faisons un calcul trivial: pour un projet de 1000 MD, le plus efficient pour moi serait selon toi une solution technique qui sera (soyons fous) 30% plus efficiente niveau perf (soit -5k€), mais demanderait (soyons sympas) 10% d’homme.jour en plus (soit +100k€) ?





Sauf que s’il suffisait simplement de mettre un serveur un peu plus puissant pour absorber le manque d’optimisation, ça se saurait.



Parce que tout ces gens qui ont décrété que l’optimisation c’est un truc d’un autre age et qui l’ont fait tout au long de la chaine, depuis le serveur web en passant par le langage serveur, le langage côté client, les frameworks, tout cela est malheureusement cumulatif… et finit par coûter lourd.



D’ailleurs, le fait que l’expérience utilisateur se retrouve aussi fortement impactée sur un aussi grand nombre de sites web est bien la preuve de l’échec de cette logique.



Et je ne parle même pas des grand services Web tels que Google ou Facebook ou cela fait longtemps qu’ils ont bien réalisé le problème que pose ces technologies mal optimisées et qu’ils travaillent pour améliorer la question. Quand on a des millions de serveurs, le manque d’optimisation, ça se traduit directement par une perte financière récurrente qu’il faut payer tous les mois…












brazomyna a écrit :



Lol, JS qui engendre la multiplication des centrales nucléaires <img data-src=" />







En attendant, c’est bien la réalité.



Chaque cycle processeur a un cout en énergie.



Le web et ses millions de serveurs et clients représentent une énergie importante et en constante augmentation.



Les objets connectés vont augmenter encore cet impact. Parce que la différence sur des petits processeurs est encore plus grande : la différence du nombre de transistors pour faire tourner de l’assembleur simple et du javascript est absolument colossale.





D’ailleurs, c’est bien connu que les iPhones (avec un framework basé sur un dérivé du C) ont une autonomie 10 fois plus importante que les Android (et son méchant Java) à batterie égale.





Le fait qu’une meilleure optimisation aboutisse à un gain d’énergie est une évidence technique.



Mais dans la pratique d’un appareil, d’autres paramètres interviennent.



Par exemple, a consommation équivalente, sur un appareil plus optimisé, on peut aussi décider de faire meilleur usage du capital énergétique pour une meilleure réactivité et une meilleure expérience utilisateur.





Tu devrais postuler chez Apple, ils adorent les techno-marketeux de ta trempe <img data-src=" />





Je te laisse te moquer, je me contenterais d’avoir raison <img data-src=" />



Depuis que je mets de la vanille dans mon chocolat chaud le matin, j’avoue regarder d’un autre angle jQuery.



<img data-src=" />


Tu pourrais pas écrire ton commentaire avec du “HTML pur”.








FDN a écrit :



Tu pourrais pas écrire ton commentaire avec du “HTML pur”.





D’un point de vue utilisateur si.



Oui très longtemps.<img data-src=" />

Risible de prendre des exemples de frontend CSS (ce que n’est pas jQuery UI) dont les widgets sont quasiment tous écrit avec/dépendant de jQuery.<img data-src=" />


J’ai lu tout le site que tu as donné (avant que tu le recites dans ce com). Merci pour le lien au passage, et pour tes explications sur le fonctionnement de Jquery.



A cela j’ajoute que ta réponse est clair, et le ton n’est pas du tout de l’attaque mais bel et bien un objectif de faire comprendre qq chose (ça change). J’ai fait pendant 4 ans du vanilla, 2 ans de scriptaculous (mouais …) et 5 ans de jquery.

Je pense la même chose que toi, jquery n’est pas la solution à tout, un très bon développeur vanilla fera mieux, mais un développeur moyen (ce qui est mon cas, je ne code pas en js tous les jours) sera bien + à l’aise avec Jquery. Le problème de lourdeur est à mettre de coté. On a des processeurs dual/quad core, idem sur tel, à moins qu’on ait véritablement un objectif de performance absolu.

Pour comparer avec une voiture, la clim rajoute du poids et prend des perfs au moteur mais on s’en fou, on n’a pas besoin d’avoir les perfs d’une formule 1. Idem dans ce cas, on ne cherche pas à avoir le site le + optimisé du monde, juste réduire le temps de dev sans connaitre le langage vanilla par coeur. Et quand au poid, 85Ko minimisé sans la compression gzip, je ne parle pas ca qq chose de lourd.

&nbsp;








maestro321 a écrit :



Risible de prendre des exemples de frontend CSS (ce que n’est pas jQuery UI) dont les widgets sont quasiment tous écrit avec/dépendant de jQuery.<img data-src=" />





? Y’a rien de risible




  • jQuery UI n’a rien a voir avec jQuery (si ce n’est le nom et qqs devs en commun) mais s’appuie sur jQuery pour manipuler le DOM

  • jQuery UI&nbsp;propose des widgets

  • Bootstrap, Material, Foundation… proposent aussi des widgets (en plus d’etre des frameworks CSS) et utilisent jQuery pour manipuler le DOM



    =&gt; donc jQuery UI est bien en concurrence avec les widgets Bootstrap et les autres



    jQuery UI n’a pas evolue depuis longtemps et est rarement utilisé pour des nouveaux developpements.

    jQuery UI a fait de la resistance un peu plus longtemps que prevu parcequ’il y avait un datepicker integré.









sr17 a écrit :



PHP est effectivement une merde absolue sur le plan de l’efficience.



Je suis pourtant d’accord avec toi que ce langage n’a pas apporté que du mauvais. D’ailleurs on peut le dire de beaucoup les langages.



Mais ils serait temps de réaliser que tout ce qui est bon dans PHP pourrait être repris dans un langage bien meilleur. Le bilan énergétique de l’humanité en serait amélioré.







Tu parles du PHP 5.0 ou du PHP 7.0 ? Il y a une différence monumentale entre ces deux versions en terme de perf. D’ailleurs, même PHP 5.6, les perfs que je vois pas trop le problème, quand je vois mes temps de calculs, c’est la base de données qui ralenti généralement le temps global.



Et si tu veux améliorer les bilans énergétique de l’humanité, il faut aussi arrêter : Excel, Python, ruby, et… tout ce qui est script ou macro, mais aussi le templating, les parseurs, les logs, etc. et tout passer par du binaire compilé. Si tu savais le nombre de calcul « inutile » qu’il y a dans une appli juste pour gagner du temps lors de son écriture.









gazgaz78 a écrit :



Ca va c’est pas si lourd jquery et si tu merge bien tous tes js jvois pas le prob

Sans parler des versions jquery qui existent, yen a un paquet









Perso je suis a 50ko pret.




  • 1 requete .









zefling a écrit :



Tu parles du PHP 5.0 ou du PHP 7.0 ? Il y a une différence monumentale entre ces deux versions en terme de perf. D’ailleurs, même PHP 5.6,







PHP 7 ne fait que supprimer des inepties techniques qui n’auraient jamais du exister. C’est mieux, mais ça n’en fera pas un langage rapide pour autant.





les perfs que je vois pas trop le problème, quand je vois mes temps de calculs, c’est la base de données qui ralenti généralement le temps global.





Parce que l’utilisation d’une base de données SQL “lourde” pour stocker la moindre petite données est une mauvaise habitude qui s’est généralisée.



Malheureusement, des langages comme PHP sont aussi responsable de cet état de fait car ils poussent vers ce modèle de programmation.





Et si tu veux améliorer les bilans énergétique de l’humanité, il faut aussi arrêter : Excel, Python, ruby, et… tout ce qui est script ou macro, mais aussi le templating, les parseurs, les logs, etc. et tout passer par du binaire compilé.





A mon gout, les “petits langages de script inefficients” se sont un peu trop multipliés ces derniers temps. Et surtout, ils sortent systématiquement de leur petit rôle pour servir à faire de vraies applications de prod.



Quand aux tableurs, ils sont aussi une énorme source de problèmes en entreprise parce que leur usage aboutit à des programmes inefficients et mal structurés.



Le plus amusant dans tout ça, c’est que les gens pensent se simplifier la vie et gagner du temps avec leurs 500 mauvais outils, tout ça parce qu’ils ont peur d’en apprendre un bon (je simplifie, mais c’est l’idée).





Si tu savais le nombre de calcul « inutile » qu’il y a dans une appli juste pour gagner du temps lors de son écriture.





En même temps, ça serait très dur de l’ignorer étant donné que bien souvent ça se voit comme le nez au milieu de la figure, même sans lire le code.









sr17 a écrit :



PHP 7 ne fait que supprimer des inepties techniques qui n’auraient jamais du exister. C’est mieux, mais ça n’en fera pas un langage rapide pour autant.







On pourrait dire ça de plus de la moitié de langage existant qui finissent par s’industrialiser.







sr17 a écrit :



Parce que l’utilisation d’une base de données SQL “lourde” pour stocker la moindre petite données est une mauvaise habitude qui s’est généralisée.



Malheureusement, des langages comme PHP sont aussi responsable de cet état de fait car ils poussent vers ce modèle de programmation.







Tu ne sais même pas comment je bosses, ni la taille de ma bosse, ni le type de base que j’utilise et tu donnes des conseils. Je trouve ça assez prétentieux de ta parts.







sr17 a écrit :



A mon gout, les “petits langages de script inefficients” se sont un peu trop multipliés ces derniers temps. Et surtout, ils sortent systématiquement de leur petit rôle pour servir à faire de vraies applications de prod.



Quand aux tableurs, ils sont aussi une énorme source de problèmes en entreprise parce que leur usage aboutit à des programmes inefficients et mal structurés.



Le plus amusant dans tout ça, c’est que les gens pensent se simplifier la vie et gagner du temps avec leurs 500 mauvais outils, tout ça parce qu’ils ont peur d’en apprendre un bon (je simplifie, mais c’est l’idée).







Dans la vrai vie on a pas tous le temps apprendre l’assembleur pour faire des scripts.







sr17 a écrit :



En même temps, ça serait très dur de l’ignorer étant donné que bien souvent ça se voit comme le nez au milieu de la figure, même sans lire le code.







Oui, mais souvent, c’est des milli-secondes, donc tout le monde s’en fout. Par exemple, j’ai fais un truc qui résous un sodoku pas optimisé, qui fait tout ce qui est possible, sauf que j’ai un résultat en 0,2 s (pour les plus complexes). Quel est l’intérêt ai-je à optimiser ? Je ne compte pas en résoudre de milliers à la suite.



Un dev qui se cantonne à sa techno et qui ne veut pas évoluer est voué à disparaître. Jquery c’est dépassé, faut le laisser tomber maintenant.

Bootstrap pareil hein :)

C’était bien y a 4 ans


Tu préconises quoi à la place de bootstrap?


Un simple pré-processuer css, less ou sass.

Pas besoin d’importer une usine de gaz qui t’empêchera sur le long terme à faire évoluer ton site facilement et proprement, d’autant plus si des besoins spécifiques apparaissent


Je dois redévelopper la partie cliente de mon site pour un nouveau design. J’utilises déjà less c’est très bien d’ailleurs. Par contre je ne trouve pas que ça remplace totalement bootstrap. Il te propose des sélecteurs css tout prêt à l’emploi et adapté totalement au responsive design. Ca évite de réinventer la roue. De plus beaucoup de graphistes connaissent cette techno.


un préprocessing less en remplacement de bootstrap… Moi qui pensais avoir déjà lu un beau tas d’inepties sur ce fil…



C’est à peu près aussi pertinent que de dire que jquery et angular couvrent un domaine similaire. :rolleyes:









zefling a écrit :



On pourrait dire ça de plus de la moitié de langage existant qui finissent par s’industrialiser.







Non.



Un langage qui pendant des années n’avait même pas un cache d’opcode en standard, ça faisait quand même bien tache au 21ième siècle. Même les bons BASIC des années 80 permettaient de sauvegarder et de recharger un programme sous forme d’opcodes.



Il serait bon de réaliser que certains langages ne font même pas l’effort d’implémenter des optimisations évidentes et triviales connues depuis des décennies. Des millions de programmeurs les utilisent sans jamais regarder ce qu’il y a sous le capot.





Tu ne sais même pas comment je bosses, ni la taille de ma bosse, ni le type de base que j’utilise et tu donnes des conseils. Je trouve ça assez prétentieux de ta parts.





Échanger des conseils, c’est la base pour progresser. Et ça sera toujours vrai quelque soit ton niveau, ton expérience ou la taille de la boite ou tu travaille.



Même après plusieurs décennies de métier on se rends compte que l’on progresse toujours…. grâce aux autres.



Au passage, je n’ai pas mis en doute tes compétences, je parlais de ce qu’on peut tous constater dans les projets, en particulier les projets PHP. C’est facilement compréhensible en observant les orientations du langage.





Dans la vrai vie on a pas tous le temps apprendre l’assembleur pour faire des scripts.





Pourquoi penser qu’un langage efficient serait forcément de l’assembleur ou forcément compliqué ?



En informatique comme partout, il faut se méfier de la voie de la facilité. Déjà parce que c’est la voie d’une qualité médiocre, mais aussi parce qu’en regardant mieux le problème, le gain en facilité est souvent discutable in fine.



L’exemple, c’est les variables non typées. On croit gagner du temps au départ, mais en fait, on en perds beaucoup par la suite. Sans tomber dans les extrêmes, il faut se méfier de la fausse facilité.



Mais surtout, il n’y a pas d’excuse à ce qu’un langage moderne n’offre pas en standard un vrai mode compilé et des structures de langage performantes.





Oui, mais souvent, c’est des milli-secondes, donc tout le monde s’en fout.





C’est bien plus compliqué que ça.



Un morceau de code mal optimisé peut coûter de quelques fractions de % à des milliers de % par rapport à un code optimal suivant le cas.



Mais surtout, quand on accumule les couches, on accumule ces manque d’optimisations qui peuvent dans certains cas se multiplier pour représenter des différences énormes.





Par exemple, j’ai fais un truc qui résous un sodoku pas optimisé, qui fait tout ce qui est possible, sauf que j’ai un résultat en 0,2 s (pour les plus complexes). Quel est l’intérêt ai-je à optimiser ? Je ne compte pas en résoudre de milliers à la suite.





Personne ne prétends que l’on doit forcément tout optimiser à mort. Il faut faire preuve d’intelligence, pas de manichéisme.



Mais c’est aussi une question d’habitude et de rigueur. Prendre l’habitude d’utiliser des outils efficients et d’optimiser, c’est apprendre à le faire pour tout et partout. Le problème c’est que l’inverse est aussi vrai.



Le vrai but au final, c’est d’éviter de se retrouver avec de langages de script mal optimisés qui ont été créés sur un coin de table et qui finissent utilisés pour écrire des Os. Ou des bibliothèques plus ou moins bien écrites et qui finissent par être utilisées par des milliers de programmeurs.



Bien sûr, il est évident qu’on ne peut pas blâmer les informaticiens dans le cadre de leur travail qui la plupart du temps se voient imposer aussi bien les outils que les délais. Le tout étant imposé par un marché qui impose un prix comprimé.






Tu sais tu veux faire plus simple : prends la techno en fonction de ton besoin. Perso, quand j’ai un script de 15 lignes à faire, je vais faire du Bash ou un langage de script, quand je faire un blog, le PHP est largement suffisant (un temps de calcul de 0,25 s sur le calcul d’une page sur pour un truc qui sera vu 50 fois par jour déjà bien assez), je veux encore plus, je choisirais autre chose.



Après, ça fait 11 ans que je fais du PHP, mais c’est un des langages que je connais. Il y a pas que des applications web qui demande des temps de réponses de malade avec de la très haute disponibilité. En fait, je dirais même que ses sites sont plutôt rares au vu du nombre de sites qui existe.



Après c’est sûr que tu passes par des frameworks lourds à la base… c’est peut-être aussi un mauvais choix ou une mauvaise utilisation. J’ai vu ça avec des langages compilés, où la perte de temps était juste colossale, non pas parce qu’il était lent, mais parce que c’était imbitable. Tu peux faire de la merde avec n’importe quoi, à typage statique ou non. Actuellement, le code le plus pourri que j’ai vu n’est pas en PHP, mais en Java. Pourtant, de la merde j’en ai vu passer en PHP.



Et pour info, le non typé, je pense que ça n’existe pas, une variable a toujours un type, c’est juste static ou non.








zefling a écrit :



Et pour info, le non typé, je pense que ça n’existe pas, une variable a toujours un type, c’est juste static ou non.





C’est un abus de langage de sa part il parle de typage faible(javascript ou php).

Dynamic ca veut juste dire qu’on ne définit pas le type de la variable. Mais dans certains langages comme python ou C# si tu utilises le mot clé dynamic il existe un type interne. Si il ne correspond pas une exception peut être jetée. Ce n’est bien sur pas le cas de php et javascript qui sont en typage dynamique faible.

Sur le fond je suis partiellement d’accord avec sr17. Perso je me dirigerai toujours vers du langage typé si il existe. Par exemple je compte bientôt utiliser typescript pour remplacer javascript.

Pour les programmes mal codés je pense qu’avec un programme non typé tu as plus de chances de pondre de la merde. Dans les facs du moins il y a quelques années les profs expliquaient les bienfaits du typage fort. C’est pour ça qu’ils ont commencé par enseigner ada aux étudiants qui est particulièrement excessif dans son genre. Un bon langage doit arrêter un maximum d’erreur à sa conception dès la compilation et pas a l’exécution.

Par contre je comprend tout a fait que si on veut faire un projet rapide on a pas envie de sortir l’artillerie lourde je l’ai fais aussi récemment avec PHP. PHP a sa place mais perso je n’utiliserai plus pour des gros projets.









charon.G a écrit :



python ou C# si tu utilises le mot clé dynamic il existe un type interne. Si il ne correspond pas une exception peut être jetée.





En php aussi tu peux avoir des exception si le type n’est pas le bon. Après il est vrai que sur les types de bases ça passera dans la majorité des cas, mais en POO tu n’iras pas loin.



De plus, on a le droit de faire ça depuis un moment :

function (MaClass \(var)

et avec PHP 7 :

function (int \)
var) : String



Oui ils ont ajouté des trucs par dessus mais ce n’est pas applicable à l’ensemble du script php. PHP est bien en typage dynamique faible


C’est un peu comme l’utf8(je ne sais pas si ca été réglé depuis sur php7) mais ils fournissaient bien des api de manipulation utf8. Mais la plupart des api php et et la gestion interne des string ne stockait pas en utf8. Ils avaient du doubler avec tout un tas d’api spécifiques pour gérer les chaines utf8. Ce n’était pas du tout consistant.