La naissance et la mort de JavaScript (2014)

 (destroyallsoftware.com)
1 points par GN⁺ 6 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Parcourt l’histoire de JavaScript et de la programmation de 1995 à 2035 sous la forme d’une conférence de SF, comique et sérieuse
  • Le périmètre s’étend au-delà de JavaScript jusqu’à l’histoire de la programmation dans son ensemble
  • Adopte un point de vue neutre, sans se ranger pour ou contre JavaScript
  • Aborde honnêtement les défauts du langage, tout en évaluant très positivement son impact final sur l’industrie
  • Le message central est que, malgré ses défauts, JavaScript a laissé un impact très positif sur l’industrie de la programmation

Aperçu de la conférence

  • Suit l’histoire de JavaScript et de la programmation dans son ensemble de 1995 à 2035
  • La conférence mêle SF, comédie et exposé entièrement sérieux
  • Ce n’est ni une conférence en faveur de JavaScript ni une conférence contre lui, et elle ne se résume pas à une position partisane
  • Les défauts de JavaScript sont abordés avec franchise, mais son impact final sur l’industrie est évalué de manière très positive

À lire aussi

1 commentaires

 
GN⁺ 6 시간 전
Réactions sur Hacker News

  • Il avait bien prédit avec précision qu’une catastrophe planétaire arriverait entre 2020 et 2025, il s’est juste trompé sur sa nature, et c’est ça qui est bien (?)
    Très JavaScript, en somme

    • On peut considérer que c’était précis à NaN %

  • Étonnant que personne n’ait encore mentionné qu’il nous a laissé ce chef-d’œuvre
    Si vous ne l’avez pas vu, je recommande d’arrêter ce que vous faites et de le regarder. Cinq des meilleures minutes de votre journée garanties
    https://www.destroyallsoftware.com/talks/wat

    • Toutes ses présentations sont excellentes
      Boundaries est la vidéo la plus éclairante que j’aie vue sur l’architecture logicielle, et je repense encore à ses leçons quand je conçois des applications complexes
      C’est aussi une très bonne introduction pour apprendre à penser comme un programmeur fonctionnel quand on est habitué à une logique impérative avec de l’état dispersé partout
      https://www.destroyallsoftware.com/talks/boundaries
    • Cette présentation contient quelques erreurs, et je vais juste en noter deux que j’ai remarquées
      Après avoir appelé Array(16), il dit qu’il y a 16 séparateurs, alors qu’en réalité il n’y en a que 15, ce qui gâche un peu la blague sur Batman
      Il utilise aussi {}+[], explique qu’il ajoute un objet à une liste, puis se moque du fait que le résultat diffère de []+{} qui donne [object Object], mais en réalité, si on écrit ({}+[]), on obtient aussi [object Object]
      Je laisse comme énigme la raison pour laquelle {}+[] donne autre chose. Indice : Gurer vf ab bowrpg gurer.

  • JavaScript est effectivement devenu une cible de compilation ; dans la vidéo de l’époque c’était asm.js, mais aujourd’hui il y a WebAssembly
    Quand on voit que c’est réellement implémenté et que ça tourne à des performances proches du natif, on peut dire que la prédiction était assez juste
    J’utilise surtout TypeScript, et avec Electron, les technologies web ont été empaquetées en applications desktop, ce qui a aussi fait entrer la syntaxe du web dans les programmes classiques
    On dit souvent qu’Electron est lourd et pas terrible, mais c’est aussi le moyen le plus rapide de supporter Mac, Windows et Linux d’un coup
    La “mort” dont il est question ici, c’est le moment où on n’écrit plus JavaScript directement, mais où il devient une couche de base présente partout, et à mon avis c’est bien ce qui s’est passé

    • Il y a aussi Flutter, qui supporte non seulement les systèmes d’exploitation desktop, mais aussi iOS et Android
      Je trouve que la vitesse de développement y est plutôt bonne
      En revanche, je ne sais pas vraiment comment ses performances se comparent à Electron ou aux applications natives
      Pour une petite équipe, il vaut largement mieux viser la mise en production effective que l’optimisation des performances
    • JavaScript est, en quelque sorte, la nouvelle couche assembleur
      Par définition, un compilateur traduit du code lisible par des humains en langage machine
      L’avantage de JavaScript, c’est que Google l’a poussé dans ses retranchements avec V8, puis NodeJS en a fait un environnement backend attractif ; du coup, comme le PDF, il est partout, et ce qu’on écrit peut tourner partout
      S’il a gardé l’avantage sur WebAssembly jusqu’à présent, c’est grâce à cette polyvalence ; WebAssembly n’est pas aussi largement déployé que JavaScript
      Aujourd’hui, JavaScript est pratiquement devenu synonyme de TypeScript, et ça a été un bond immense. Le héros caché ici, à mon avis, c’était Angular 2
      Angular a choisi TypeScript dès le départ tout en fournissant aussi une version en JavaScript natif, mais honnêtement cette version était presque inutilisable et s’est fait fortement critiquer à l’époque
      Fait intéressant, le dernier refuge à ne pas proposer TypeScript comme option par défaut, c’est React, mais vu que des projets majeurs comme NextJS reposent par défaut sur TypeScript, ReactJS finira lui aussi par céder
      Ce n’est pas la première fois que l’innovation apparaît d’abord dans d’autres projets avant que ReactJS ne suive, et ici aussi je pense qu’Angular est en avance
      On se trompe rarement gravement en choisissant JavaScript et Python
    • Si cette “mort” signifie que JavaScript devient une couche de base qu’on n’utilise plus directement, alors ce n’est clairement pas la même timeline que celle dans laquelle je vis
      Les gens écrivent encore directement d’énormes quantités de JS, et WebAssembly n’a toujours pas pris le contrôle de l’environnement d’exécution standard des applications web
      On peut trouver des entreprises qui construisent des choses sur WebAssembly, mais il ne faut pas confondre cela avec le grand basculement dont parlait Gary
    • Dans l’histoire racontée par la vidéo, les JIT deviennent suffisamment bons pour faire disparaître la mémoire virtuelle et la protection mémoire
      Cela ne s’est absolument pas produit
    • Pourquoi faudrait-il créer une application quand un site web suffit ?
      Pas besoin de lancer plusieurs navigateurs web pour ça

  • Tous les quelques années, on invente un meilleur JavaScript, puis on le transpile vers JavaScript

    • L’adoption à grande échelle l’emporte toujours sur une bonne conception
    • Au final, ce n’est que de l’assembleur
      Il n’y a rien d’intrinsèquement mauvais à compiler vers JavaScript, et les langages de haut niveau peuvent implémenter beaucoup de garanties que le JavaScript pur n’offre pas directement
      Presque toutes les garanties des langages que nous utilisons aujourd’hui peuvent être brisées en assembleur brut

  • Le problème, c’est que l’évolution de Wasm n’a pas été aussi rapide que ce qui était prédit ici
    Comme il n’y a pas de manipulation du DOM, il faut toujours utiliser JS comme code de glue, ou alors abandonner complètement HTML et CSS et tout rendre sur un canvas, comme Flutter ou certaines GUI en Rust
    Mais ce serait dommage de perdre l’ensemble des fonctionnalités du web

    • Ceux qui choisissent Flutter diront probablement que la cohérence offerte par le canvas sur tous les navigateurs vaut davantage que le fait d’obtenir un ensemble de fonctionnalités web implémentées de manière disparate
    • Le DOM et JS sont inséparables
      L’API du DOM a été conçue en partant du principe qu’on y accéderait depuis JS, et la conception de JS ainsi que certaines de ses caractéristiques “particulières” viennent en partie du fait qu’il a été pensé pour être utilisé avec le DOM
    • JS est bien plus accessible que le WASM
      On peut le déboguer à la volée, le donner à un LLM, et comme il n’y a pas de wrappers, c’est beaucoup plus simple à manipuler, expérimenter et utiliser

  • En 2014, j’ai vu Gary Bernhardt présenter ce talk en direct à la Canadian Undergraduate Software Engineering Conference (CUSEC)
    PNaCl venait de sortir l’année précédente, et Google l’utilisait dans Chrome et ChromeOS pour cross-compiler, exécuter et sandboxer des clients OpenSSH et RDP, tandis que Mozilla/Firefox proposait asm.js en réponse
    À l’époque, ça m’avait juste fait rire, mais en le revoyant aujourd’hui, c’est surprenant de constater qu’une bonne partie de ces idées a survécu

  • Le lightning talk Wat de Gary Bernhardt a toujours été l’une de mes présentations préférées
    Il n’a que deux ans d’avance sur la présentation mentionnée dans le titre de cet article
    [1]: https://www.destroyallsoftware.com/talks/wat

  • Presque tout s’est passé comme prévu
    Il ne reste plus qu’à attendre un autre système d’exploitation entièrement fondé sur les technologies du navigateur, ou un WASM OS
    webOS et Firefox OS avaient au moins 20 ans d’avance sur leur temps

    • Pas du tout
      WASM ne confirme pas cette thèse, il la réfute
      Cette thèse dit qu’un code source compatible JavaScript deviendra la base du futur, et que, même si le JavaScript ordinaire est une base médiocre, des moteurs JavaScript extrêmement optimisés pour interpréter efficacement des sous-ensembles compatibles pourront devenir la plateforme généraliste de demain
      WASM rejette fondamentalement cette idée en créant une nouvelle base, incompatible avec JavaScript, conçue pour servir de cible de bas niveau
      Dire que WASM confirme cette thèse est presque aussi étrange que d’affirmer qu’un futur où tout le monde aurait un interpréteur Rust dans son navigateur la confirmerait
      Si on pousse ce raisonnement, on ne dit plus que les navigateurs web exécuteront du code sous une forme ou une autre, quel que soit le langage, et c’est déjà le cas aujourd’hui
      La vidéo traite clairement de possibilités « surprenantes », et il n’est pas raisonnable de prétendre qu’elle correspond littéralement à tous les futurs possibles, même les plus ordinaires
    • Y a-t-il une raison technique pour laquelle tu n’as pas mentionné ChromeOS ?
      Je pose la question par pure curiosité
      Et les captures d’écran de webOS que j’ai vues m’ont donné envie de le voir revenir, pas seulement sur les smart TV, mais ailleurs aussi

  • Nous avons déjà dépassé la moitié du calendrier de Bernhardt pour 2035
    JavaScript n’est pas encore mort, mais il semble clairement être en train de rédiger son propre éloge funèbre dans WebAssembly

    • Il est fort probable que la dernière instruction JS s’exécute encore longtemps après la mort de plusieurs générations de ta famille
      À moins d’une guerre nucléaire mondiale, je parierais que JS survivra à la plupart des humains
    • J’audite chaque mois les sites de plusieurs clients, et ils utilisent tous du JavaScript sous une forme ou une autre
      Comme PHP, ça ne mourra jamais

  • JavaScript est le meilleur langage de programmation de tous les temps