El nacimiento y la muerte de JavaScript (2014)

Artículo original ↗ Discusión en Hacker News ↗

La “muerte” y la longevidad de JavaScript

  • Muchos sostienen que JavaScript “nunca morirá”, comparándolo en longevidad con PHP o incluso con C.
  • Otros distinguen entre la “muerte biológica” y la obsolescencia práctica: como COBOL/Fortran, JS puede persistir durante décadas, pero volverse nicho.
  • Algunos señalan que la fuerte exposición de los LLM al código JS también lo afianza más.
  • La predicción de que nadie escribiría JS nunca más se considera incumplida; la gente sigue escribiendo mucho JS puro a pesar de TypeScript.

JavaScript, asm.js y WebAssembly

  • La idea de la charla de que JS se convierta en un destino de compilación en gran medida se hizo realidad: muchos lenguajes compilan a JS o TS.
  • asm.js se considera, de hecho, obsoleto, reemplazado por WebAssembly (Wasm), que algunos ven como el cumplimiento de esa predicción.
  • Otros argumentan que Wasm contradice la tesis porque es explícitamente no-JS y está diseñado como un sustrato de bajo nivel adecuado.
  • Se considera que el progreso de Wasm ha sido más lento de lo esperado; la falta de acceso directo al DOM hace que JS siga siendo necesario para el código de pegamento.

Semántica y rarezas del lenguaje

  • Debate sobre usar null frente a undefined: algunos evitan undefined como valor intencional; otros sostienen que ambos son fundamentales para el lenguaje y los usan las APIs centrales.
  • La discusión toca las semánticas de IEEE 754 NaN y las rarezas clásicas de JS (+0/-0, coerción) como fallos frente a comportamientos conformes a los estándares.
  • A algunos no les gusta JS por sus inconsistencias de “C mutante”; otros dicen que la sintaxis en sí no es el problema principal.

Transpilación y “JS como ensamblador”

  • Patrón repetido: “inventamos un mejor JS, luego lo transpilamos a JS”.
  • TypeScript es ampliamente visto como la forma de facto de escribir JS, especialmente en proyectos grandes.
  • JS suele describirse como la nueva capa de ensamblador de la web, incluso si se usan lenguajes de nivel superior encima.

Electron, aplicaciones multiplataforma y alternativas

  • Se elogia a Electron como la forma más rápida de apuntar a Mac/Windows/Linux con interfaces web familiares, a pesar de ser pesado.
  • Los críticos citan un alto uso de RAM y clientes inestables; algunos consideran “aplicación Electron” sinónimo de mal soporte nativo.
  • Alternativas mencionadas: Flutter (con opiniones mixtas sobre la calidad web/desktop), Qt, interfaces basadas en Rust, stacks basados en Tk y aplicaciones web puras.

SO web y predicciones más amplias

  • Algunos ven WebAssembly y los stacks basados en navegador como un paso hacia un SO de navegador/Wasm; otros señalan que ChromeOS y los sistemas actuales no encajan del todo con esa visión.
  • Se aclara que el JS/asm.js a nivel de kernel en la charla es ficticio; la charla se enmarca como ficción especulativa.

Recepción de la charla y material relacionado

  • La charla es ampliamente elogiada por su ejecución y su visión de futuro, y se usa como inspiración para presentaciones.
  • Las charlas relacionadas “wat” y “Boundaries” se recomiendan y admiran con frecuencia, a pesar de algunas pequeñas inexactitudes técnicas señaladas.