Commentaires

  1. Avatar de SylvainPV
    • |
    • permalink
    Le loose mode de Babel permet de bien simplifier le code ES5 produit, même s'il n'est pas 100% spec compliant et donc introduit un risque de régression. Après, les "horreurs" ne m'ont jamais trop dérangé puisque j'utilise Babel uniquement pour le build de production aux côtés de Uglify, donc j'ai un code imbitable dans tous les cas à la fin. Mais je n'ai jamais constaté de régression entre ES6 et ES5 transpilé. Le code est peut-être illisible, mais il fonctionne impec. Certes au prix de ~30/40% de taille de bundle et de coût à l'éxécution.

    Je pense que la technique du script module est un bon compromis qui devrait donner un résultat acceptable pendant quelques années, le temps qu'IE meurt pour de bon (allez on y croit). Les nouveaux navigateurs grand public ont tous des mises à jour auto, ça devrait réduire considérablement le travail de Babel avec le preset-env.

    Pour ce qui est de supprimer des parties du langage dans les versions de JS, je ne pense pas que ce soit une bonne idée. Il faut comprendre pourquoi ces parties sont obsolètes, avant de juger qu'elles doivent être éliminées. Par exemple, l'instruction `with` est coûteuse et confusante, et donc déconseillée à l'usage. Mais elle est utilisée en minification pour réduire la taille du code, dans des cas où le coût à la compilation est négligeable par rapport au gain en taille. Donc l'instruction reste utile, même s'il ne faut plus l'utiliser en développement. De la même façon, certaines instructions sont moins pratiques à l'usage mais plus performantes, comme les `getElementsBy`. Elles ont donc tout à fait leur place dans le code de bilbiothèques/frameworks, mais moins dans du code utilisateur.

    Au final, le "nettoyage" du langage est plus un travail à faire du côté de la formation, des linters et des précompilateurs, que du langage lui-même. Maintenir plusieurs subsets du langage au sein d'un compilateur JIT est aussi compliqué, voire davantage, que de maintenir le code des instructions dépréciées. Mais ça ne devrait surprendre personne, c'est une habitude en informatique de construire par-dessus les ruines du passé (cf modèle OSI).
  2. Avatar de danielhagnoul
    • |
    • permalink
    @SylvainPV :
    Il existe une solution pour distinguer les environnements "modernes" des dépassés, et utiliser directement du JS moderne tout en préservant la compatibilité grâce à Babel et aux polyfills: <script type="module"> et <script nomodule>.
    C'est pratique pour les utilisateurs qui utilisent ES2015+ et qui veulent fournir aux navigateurs obsolètes une solution de repli.

    Je connais et j'ai déjà utilisé. C'est justement à ces occasions que Babel produit ce que j'appelle des "horreurs".

    Si vous êtes soucieux de performance, comparer donc un code, non simpliste, en ES2015+ et sa traduction ES5 par Babel.
  3. Avatar de danielhagnoul
    • |
    • permalink
    @grunk :
    const et let sont donc des ajouts très intéressant au langages, mais ne remplaceront pas var
    Je vous assure que var est la cause de bien des problèmes (par exemple : la portée globale, la déclaration de paramètre après usage dans une fonction, la perte de la valeur d'un paramètre dans une boucle). La portée bloc est un plus indéniable, car elle impose plus de rigueur et permet de concevoir des arrangements de code impossible autrement.

    J'ai eu le cas récemment avec IE10 et 11 qui sont supposé être compatible ES2015
    Non compatible ! Obsolète ! Abandonné par Microsoft : https://www.microsoft.com/fr-fr/wind...-of-ie-support

    Pour ce qui est de la compatibilité , comment on fait avec tous les sites écrit en js non moderne ? Du jour au lendemain on condamne des millions de sites ? Plein de petits sites sont en ligne , utiles mais non maintenu pour X raisons.
    Avec la première solution : il suffirait d'indiquer au navigateur d'utiliser la version JS adéquate.
    Avec la seconde solution : il suffit de ne pas utiliser l'instruction "use strict".

    La seul contrainte que ça apporte c'est éventuellement de freiner l'adoption des nouvelles versions (on change pas quelque chose qui marche).
    Cette réflexion illustre mon propos, c'est un signe indéniable de la maladie de JS.
  4. Avatar de Namica
    • |
    • permalink
    Je propose deux solutions :
    1. Donner un numéro de version à JS, avec un grand ménage sur les instructions qui existaient avant ES2015.
    2. Réviser le contenu de l'instruction "use strict" dans le sens ci-dessus et promouvoir largement son usage.
    Belle idée, mais quel système de version ? Celui de I.E., de Firefox, de Chrome, autre... ? Et ça ne résout pas le problème des sites anciens.
  5. Avatar de Invité
    • |
    • permalink
    Bonjour à tous

    Si je puis me permettre quelques petits ajouts:

    Le «ShaderGraph» était déjà implémenté dans les versions 2x, toujours maintenues par [URL="https://github.com/akien-mga"]Rémi Verschelde[/URL] (A.K.A akien-mga - Project manager, release manager, et représentant de Godot Game Engine)
    Dans les version 3x, et particulièrement la version 3,1 (dont la release stable est attendu avec une grande impatience, dont moi-même), la communication entre les logiciels de création 3D tels Blender et Godot Engine sera plus aisée et il semblerait que l’export de shaders depuis Blender + Cycles ou EEVEE par exemple serait grandement facilitée.

    [B][URL="https://godotengine.org/article/abandoning-gles3-vulkan-and-gles2"]Source[/URL][/B]

    Concernant le langage utilisé pour les shaders dans Godot, il s’agit du GDSL très proche du GLSL ou Open GL Shading Language (voir :[URL="https://alexandre-laurent.developpez.com/tutoriels/OpenGL/OpenGL-GLSL/?page=page_1"] Introduction à la programmation de shaders GLSL[/URL])

    J’aimerais aussi ajouter, si vous le permettez, le lien vers le forum des développeurs:

    [URL="https://godotdevelopers.org/forum/"]Godot Developers Forum[/URL]

    Je dois avouer qu’étant inscrit là-bas depuis maintenant 2 ans, j’ai rarement vu une telle gentillesse de la part des membres et les nouveaux-venus et trouvent toujours réponse à leur question éventuelles. On peux aussi poser ses questions sur
    [URL="https://godotengine.org/qa/"]Godot Engine Q&A[/URL]

    Dans les deux cas, même les développeurs du moteur eux même répondent aux questions posées si celle-ci étaient d’un ordre plus technique.

    D’autres parts, Une traduction de la documentation officielle vers le français est en cours sur Weblate:
    [url]https://hosted.weblate.org/projects/godot-engine/godot-docs/fr/[/url]

    Il suffit de s’inscrire pour participer. :)
  6. Avatar de SylvainPV
    • |
    • permalink
    Il existe une solution pour distinguer les environnements "modernes" des dépassés, et utiliser directement du JS moderne tout en préservant la compatibilité grâce à Babel et aux polyfills: <script type="module"> et <script nomodule>. C'est ce que propose le framework Vue.js avec son option Modern Build: https://cli.vuejs.org/guide/browser-...ml#modern-mode
  7. Avatar de Grulim
    • |
    • permalink
    2 choses me choquent :
    1) Babel qui produirait du code moisi : Babel transpile le code de façon conforme au proposition du TC39 (cf https://github.com/babel/proposals).
    2) Je produis pas mal de code JS, je dois bien dire que je ne vois plus l'utilité de var (et très peu let).
  8. Avatar de lmontout
    • |
    • permalink
    C'est au niveau de ton éditeur de code de te suggérer des évolutions de codes pertinents.
    J'aime bien les outils (langage, edi, progiciel etc....) qui me garantissent de bien fonctionner à chaque montée de version sans passer des mois à lire les "breaking changes" et à imaginer les patch.
  9. Avatar de melka one
    • |
    • permalink
    on..." au lieu du performant et versatile "addEventListener
    addEventListener a été créé après les evenements on.... pour palier au problème de cumule d'evenement le plus connu étant onload qui cumulé supprime l' evenement onload précédent et sa permet simplifie la mise en place de plusieurs scripts. removeEventListener donne la possibilité de supprimer l'execution d'une fonction sans retirer l'evenement complètement
  10. Avatar de grunk
    • |
    • permalink
    "var" au lieu de "const" et "let" ;
    const et let n'ont pas vocation à remplacer var. var n'est pas devenue une vieillerie avec l'apparition de const et let

    const= constante
    let = variable à portée limitée au bloc , ce qui est parfois très bien mais peux aussi être génant auquel cas var prend du sens.
    const et let sont donc des ajouts très intéressant au langages, mais ne remplaceront pas var

    écrire du code ES2015 et en faire une horreur avec Babel alors que tous les navigateurs d'aujourd'hui sont parfaitement compatibles y compris pour les modules ES2015+.
    J'ai eu le cas récemment avec IE10 et 11 qui sont supposé être compatible ES2015 et qui ne supporte pas TypedArray.prototype.slice(). Peut être que dans ce cas précis j'aurais évité un beau bug


    Pour ce qui est de la compatibilité , comment on fait avec tous les sites écrit en js non moderne ? Du jour au lendemain on condamne des millions de sites ? Plein de petits sites sont en ligne , utiles mais non maintenu pour X raisons.

    Quand on commencera à avoir des utilisateurs qui utilisent que des navigateurs evergreen on pourra envisager de casser la rétrocompatibilité , mais je pense qu'on à encore quelques années de souffrance devant nous , en particulier dans le monde pro.

    Perso je vois pas le mal à gardé d'anciennes fonctionnalités à partir du moment ou elle ne mettent pas en péril le langage. Après libre à chacun d'être formé et d'utiliser les dernières nouveautés ou non. C'est comme en C++ tu peux faire un programme en C++98 comme en C++17. Idem en JAVA. La seul contrainte que ça apporte c'est éventuellement de freiner l'adoption des nouvelles versions (on change pas quelque chose qui marche).
    Mis à jour 17/08/2018 à 11h59 par grunk
  11. Avatar de danielhagnoul
    • |
    • permalink
    @sirthie : j'ai pris exemple sur le titre du livre sur Java, mais en effet mon choix est discutable.
  12. Avatar de goldbergg
    • |
    • permalink
    "var" au lieu de "const" et "let" ;
    Je ne vois pas ou est le problème a utiliser "var" partout ? Sa impact les perf?
    Et sinon, même sous ie "const" est supporté depuis longtemps.

    "getElementBy..." au lieu des versatiles et performants "querySelector" et querySelectorAll" ;
    "querySelector" est ce qu'il y a de moins performant (en dehors de Jquery qui est encore pire), il y a enormement de test sur jsperf qui le prouvent.
    Les "getElementBy" ne sont surtout pas a écartée si on veut un code optimale...


    écrire du code ES2015 et en faire une horreur avec Babel alors que tous les navigateurs d'aujourd'hui sont parfaitement compatibles y compris pour les modules ES2015+.
    Pour ce point je suis d'accord, je ne comprend pas pourquoi certains s'acharne a absolument utiliser Babel qui génére du code tous moisi...


    certains utilisateurs, même de nouveaux utilisateurs du langage, se complaisent à utiliser des vieilleries alors que le langage dispose d'instructions plus performantes, parfois depuis longtemps.
    Moué, ou pas...
    Les sucre syntaxique tel que "class" n'ont rien de plus performent et n'ont rien d'une évolution (au contraire).
    Comme dit plus haut, ton exemple avec les sélecteur rajoute au contraire de la lenteur (et je ne parle pas des mauvais usage a vouloir faire une sélection via des sélecteur CSS hyper chiadé, la ou souvent on pourrait faire bien plus simple).
    Bref, je ne vois vraiment pas ou est le problème a utiliser des api qui date (mais qui on fait leurs preuves) plutôt que des nouvelles qui ne sont pas forcement top et qui risque d'être déprécié (malheureusement c'est arrivé plus d'une fois...)
  13. Avatar de danielhagnoul
    • |
    • permalink
    @Hyome : oui c'est plus lent pour des utilisations basiques dans les tests qui bouclent X milliers de fois la même opération. Mais sur une page web, la différence est à peine perceptible.

    Avantage : il y a les sélecteurs CSS élaborés et la recherche d'éléments dans un autre élément du DOM.

    Les méthodes "getElementBy..." sont celles de l'objet document alors que les méthodes "querySelector" existent sur chaque élément du DOM : Element.querySelector().

    ----

    @scandinave : ES2015 et suivant sont les numéros de version d'ECMAScript pas de JS.

    C'est au développeur de se former et de se tenir à jour. Ce n'est pas au langage de corriger des lacunes.
    L'histoire de Python et de Java montre que sans un mécanisme externe (pour JS, navigateur ne prenant plus en compte les instructions obsolètes) seule une petite partie des utilisateurs suivent et appliquent les nouveautés. La sortie de ES2015 c'était il y a 3 ans déjà.
  14. Avatar de sirthie
    • |
    • permalink
    JavaScript est-il malade de la compatibilité ascendante ?
    Ça serait pas plutôt la compatibilité descendante ?

    https://fr.wikipedia.org/wiki/Compat...et_descendante
  15. Avatar de scandinave
    • |
    • permalink
    Pour ce qui est des "vieillerie", il a encore beaucoup de windows 7 + IE en fonctionement crois moi.

    Sinon le mythe de, je limite a mort le langage pour éviter que les dêveloppeur fasse de la merde est vieux comme le monde mais n'a jamais résolu quoi que ce soit.

    C'est au développeur de se former et de se tenir à jour. Ce n'est pas au langage de corriger des lacunes.

    Pour la version, ca existe, tu l'a cité, ça s'appelle ES 2015, 2016 etc.

    Enfin tu cite java. C'est justement sa rétrocompatibilité qui fait ça grande force. Tu es sûr que le code continuera a tourner quoi qu'il arrive. Regarde comment les gens on hurler du passage de angularjs a Angular 2.
    Heureusement qu'il y avait la force de frappe de Google derrière, sinon cela aurait été un échec.

    Bref, pour moi rien n'ai à changé et tout fonctionne. Je ne me sens aucunement limité. Je pense que les mecs qui font Emacscript savent ce qu'il font.
  16. Avatar de Hyome
    • |
    • permalink
    "getElementBy..." au lieu des versatiles et performants "querySelector" et querySelectorAll" ;
    querySelectorAll vs getElementsByTagName
    https://jsperf.com/queryselectorall-...mentsbytagname
    getElementsByTagName: 962 582 895 op/sec
    querySelectorAll: 38 070 op/sec --> 25 284 fois plus lent !

    querySelector vs getElementById
    https://jsperf.com/getelementbyid-vs-queryselector
    getElementById: 837 269 329 op/sec
    querySelector: 3 095 559 op/sec --> 270 fois plus lent !

    Donc querySelector(All) c'est bien pour des selecteur CSS élaborés, mais dire qu'il est performant comparé à getElementBy... est faux.
  17. Avatar de Songbird_
    • |
    • permalink
    Citation Envoyé par Dhafer1
    Excellent projet ! Manque plus que le support de Python
    En effet, mais honnêtement quand je vois déjà le boulot à faire pour les trois langages ciblés, je pense qu'il va falloir attendre un bon moment.

    Stratégiquement, le support de Python pourrait être une très bonne nouvelle.
  18. Avatar de François DORIN
    • |
    • permalink
    J'ai rajouté un petit morceau de code. Est-ce plus parlant ainsi ?
  19. Avatar de lamaison
    • |
    • permalink
    Grand merci pour cet article très clair et très agréable à lire.
    Cependant je bute sur l’explication finale (à partir de "Qu'est-ce que cela signifie ?[...]").
    Pourriez-vous détailler un peu plus le fonctionnement ? Je suis frustré de coincer sur la partie qui explicite le tout
  20. Avatar de Arnard
    • |
    • permalink
    On retrouve comme autre cas TcpClient. En version 4.5, Dispose est non accessible. Dans la version 4.7 elle est publique et une méthode Dispose(bool) a été ajoutée.
Page 1 sur 2 12 DernièreDernière