El nacimiento y la muerte de JavaScript (2014)

• Recorre la historia de JavaScript y de la programación desde 1995 hasta 2035 en formato de ciencia ficción, comedia y charla seria
• El alcance se amplía no solo a JavaScript, sino también a la historia de la programación en general
• Adopta una perspectiva neutral que no se pone ni a favor ni en contra de JavaScript
• Aborda con franqueza los defectos del lenguaje, pero evalúa de forma muy positiva su impacto final en la industria
• El mensaje central es que, a pesar de sus defectos, JavaScript dejó un gran impacto positivo en la industria de la programación

---

Resumen de la charla

• Sigue la historia de JavaScript y de la programación en general desde 1995 hasta 2035
• La charla mezcla elementos de ciencia ficción, comedia y una exposición completamente seria
• No es una charla ni a favor ni en contra de JavaScript, y no se resume en una sola postura
• Los defectos de JavaScript se tratan con franqueza, pero su impacto final en la industria se evalúa como muy positivo

[GN⁺]

Comentarios de Hacker News

• Sí predijo con precisión que llegaría un desastre global entre 2020 y 2025, pero se equivocó solo en el tipo de desastre, y eso está bien(?)
  Muy propio de JavaScript

  • Se podría decir que tuvo una precisión de casi NaN%

• Me sorprende que todavía nadie haya mencionado que esta persona nos dejó esta obra maestra
  Si no la han visto, les recomiendo parar lo que estén haciendo y verla. Cinco minutos que garantizan ser los mejores del día
  https://www.destroyallsoftware.com/talks/wat

  • Todas sus charlas son excelentes
    Boundaries fue el video más revelador sobre arquitectura de software que he visto, y todavía recuerdo sus lecciones cuando diseño aplicaciones complejas
    También es un muy buen material introductorio para enseñar a pensar como programador funcional a quienes están acostumbrados a la lógica imperativa con estado disperso por todas partes
    https://www.destroyallsoftware.com/talks/boundaries
  • Esta charla tiene algunos errores; anoto solo dos de los que vi
    Dice que después de llamar a Array(16) hay 16 separadores, pero en realidad solo hay 15, así que el chiste de Batman se cae un poco
    También usa {}+[] y explica que está sumando una lista a un objeto, para luego burlarse de que el resultado es distinto de []+{}, que da [object Object]; pero en realidad, si escribes ({}+[]), también obtienes [object Object]
    Dejo como acertijo por qué {}+[] da algo distinto. Pista: Gurer vf ab bowrpg gurer.

• JavaScript sí terminó convirtiéndose en un objetivo de compilación; en el video de esa época era asm.js, pero ahora existe WebAssembly
  Viendo que realmente se implementó y corre casi a velocidad nativa, diría que la predicción fue bastante acertada
  Yo uso principalmente TypeScript, y gracias a Electron, las tecnologías web se empaquetaron como apps de escritorio, haciendo que la sintaxis web también entrara en los programas comunes
  Se dice que Electron es pesado y no muy bueno, pero también es la forma más rápida de dar soporte a Mac, Windows y Linux de una sola vez
  La “muerte” de la que se habla aquí sería un estado en el que ya no se escribe JavaScript directamente, sino que se convierte en una capa base presente en todas partes, y yo diría que eso sí pasó

  • También está Flutter, que no solo soporta sistemas operativos de escritorio sino también iOS y Android
    Yo diría que la velocidad de desarrollo también es bastante buena
    Eso sí, no tengo claro cómo se compara en rendimiento frente a Electron o frente a apps nativas
    Si eres un equipo pequeño, suele ser mucho mejor enfocarse en lanzar de verdad que en optimizar la velocidad
  • JavaScript vendría siendo una nueva capa de ensamblador
    Por definición, un compilador traduce código legible por humanos a lenguaje máquina
    La ventaja de JavaScript es que Google lo llevó al límite con V8 y que NodeJS creó un entorno atractivo en el backend; después de eso, quedó en todas partes como un PDF, y una vez que lo usas, puedes usarlo donde sea
    La razón por la que hasta ahora ha mantenido ventaja sobre WebAssembly es esa versatilidad; WebAssembly no está tan ampliamente desplegado como JavaScript
    Hoy en día JavaScript se ha vuelto prácticamente sinónimo de TypeScript, y eso fue un salto enorme. Yo diría que el héroe oculto aquí fue Angular 2
    Angular eligió TypeScript desde el principio y también ofrecía una versión en JavaScript nativo, pero, siendo honestos, esa versión era casi inutilizable y en ese momento recibió críticas muy fuertes
    Curiosamente, el último refugio que no presenta TypeScript como opción por defecto es React, pero con proyectos importantes como NextJS dependiendo de TypeScript de manera predeterminada, ReactJS también terminará cediendo
    No sería la primera vez que la innovación aparece primero en otros proyectos y luego ReactJS la sigue; también aquí yo diría que Angular va por delante
    Si eliges JavaScript y Python, rara vez te equivocarás mucho
  • Si esa “muerte” significa que JavaScript se vuelve una capa base que ya no se escribe directamente, entonces debe ser una línea temporal distinta de la que yo vivo
    La gente todavía escribe cantidades enormes de JS de forma directa, y WebAssembly todavía no domina el entorno de ejecución habitual de las aplicaciones web
    Puedes encontrar empresas construyendo cosas sobre WebAssembly, pero no hay que confundir eso con el tipo de gran transición del que hablaba Gary
  • En la charla del video se decía que el JIT se volvería lo bastante bueno como para eliminar la memoria virtual y la protección de memoria
    Eso no pasó en absoluto
  • Si una página web basta, ¿por qué habría que hacer una app?
    No hace falta ejecutar varios navegadores web para eso

• Cada pocos años inventan un JavaScript mejor y luego lo transcompilan a JavaScript otra vez

  • La adopción masiva siempre le gana al buen diseño
  • Al final todo es código ensamblador
    No hay nada intrínsecamente malo en compilar a JavaScript, y los lenguajes de alto nivel pueden implementar muchas garantías que JavaScript puro no ofrece directamente
    Casi todas las garantías de lenguaje que hemos usado hasta ahora pueden romperse en ensamblador puro

• El problema es que la velocidad de desarrollo de Wasm no ha sido tan rápida como se predecía aquí
  Como no hay manipulación del DOM, todavía hay que usar JS como código pegamento; o, si no, abandonar por completo HTML y CSS y renderizarlo todo en canvas, como Flutter o algunas GUI en Rust
  Pero da pena perder el conjunto de capacidades de la web

  • Quienes eligen Flutter probablemente dirán que la consistencia que ofrece canvas en todos los navegadores vale más que obtener un conjunto de capacidades web implementado de forma desigual
  • DOM y JS son inseparables
    La API del DOM fue diseñada bajo la suposición de que se accedería a ella desde JS, y el diseño de JS y algunas de sus características “peculiares” también provienen en parte de haber sido creados para usarse junto con el DOM
  • JS es muchísimo más accesible que WASM
    Puedes depurarlo al vuelo, puedes pasárselo a un LLM, y como no hay wrappers, es mucho más fácil de tocar, experimentar y trabajar con él

• En 2014 vi a Gary Bernhardt dar esta charla en vivo en la Canadian Undergraduate Software Engineering Conference (CUSEC)
  PNaCl había salido justo el año anterior, y Google lo estaba usando dentro de Chrome y ChromeOS para compilar de forma cruzada, ejecutar y aislar en sandbox clientes de OpenSSH y RDP, mientras que Mozilla/Firefox propuso asm.js como respuesta a eso
  En ese momento solo me pareció gracioso, pero ahora me sorprende ver cuántas partes de esa idea sobrevivieron

• La charla relámpago Wat de Gary Bernhardt fue una de mis presentaciones favoritas
  Fue apenas 2 años antes que la charla del título de este artículo
  [1]: https://www.destroyallsoftware.com/talks/wat

• Casi todo pasó tal como estaba escrito en el guion
  Ahora solo queda esperar otro sistema operativo completamente basado en tecnologías del navegador, o un WASM OS
  webOS y Firefox OS al menos se adelantaron 20 años a su tiempo

  • Para nada
    WASM no confirma esa tesis, la refuta
    Esa tesis sostiene que el código fuente compatible con JavaScript se convertiría en la base del futuro, y que un motor de JavaScript altamente optimizado para interpretar eficientemente un subconjunto compatible, a pesar de que JavaScript común es una base pésima, podría volverse la plataforma universal del futuro
    WASM rechaza eso de raíz al crear una nueva base, incompatible con JavaScript, diseñada para ser un objetivo de bajo nivel
    Decir que WASM confirma esa tesis es tan raro como decir que un futuro donde todos tengan un intérprete de Rust dentro del navegador confirmaría esa tesis
    Si vas a argumentar eso, al final solo estás diciendo que los navegadores web van a ejecutar algún tipo de código en cualquier lenguaje, y eso ya pasa
    El video claramente trata de posibilidades “sorprendentes”, así que no tiene sentido verlo como si coincidiera literalmente con cualquier futuro posible y totalmente normal
  • ¿Hay alguna razón técnica por la que no mencionaste ChromeOS?
    Lo pregunto por mera curiosidad
    Y las capturas de pantalla de webOS que vi me hicieron desear su regreso. No solo en smart TVs, sino también en otros lugares

• Ya pasamos la mitad del cronograma hacia 2035 de Bernhardt
  JavaScript todavía no está muerto, pero sí parece claro que está escribiendo su propio elogio fúnebre dentro de WebAssembly

  • Incluso después de que hayan muerto varias generaciones de tu familia, es muy probable que la última instrucción de JS siga ejecutándose
    A menos que haya una guerra nuclear global, yo apostaría a que JS va a sobrevivir más que la mayoría de los seres humanos
  • Cada mes reviso sitios de varios clientes, y todos usan JavaScript de alguna forma
    Nunca va a morir, igual que PHP

• JavaScript es el mejor lenguaje de programación de todos los tiempos