JavaScript está hoy presente prácticamente en todas partes donde funciona la Web. Anima las interfaces de los sitios, valida formularios, se comunica con servidores, construye aplicaciones completas en el navegador y también puede ejecutarse en servidores, ordenadores, dispositivos móviles, plataformas cloud y herramientas de desarrollo. Esta omnipresencia puede hacer pensar que fue diseñado desde el principio para convertirse en una plataforma universal.
La realidad es mucho más sorprendente.
JavaScript nació en 1995, bajo una enorme presión de tiempo dentro de Netscape. Su primer prototipo fue desarrollado por Brendan Eich en cuestión de días. El lenguaje debía resultar accesible para los creadores de páginas web, integrarse directamente en el navegador y complementar a Java, que recibía una atención extraordinaria. Sin embargo, detrás de ese nacimiento apresurado había ideas originales: funciones de primera clase, objetos basados en prototipos, tipado dinámico e influencias de Scheme y Self.
En tres décadas, un lenguaje pensado para añadir pequeños comportamientos a páginas web se convirtió en uno de los pilares de la informática moderna.
Su historia es también la historia del navegador, de la guerra entre Netscape y Microsoft, de la estandarización ECMAScript, de Ajax, jQuery, los motores JIT, Node.js, npm, los frameworks front-end y TypeScript. También explica muchas características actuales: JavaScript no puede borrar simplemente su pasado porque miles de millones de páginas dependen de su compatibilidad.
La Web antes de JavaScript: páginas principalmente estáticas
A comienzos de los años noventa, la World Wide Web se apoyaba en una idea extraordinariamente sencilla: documentos conectados mediante hipervínculos podían solicitarse y mostrarse en un navegador.
HTML describía el contenido. HTTP permitía pedir recursos a un servidor. Los primeros navegadores mostraban principalmente texto y enlaces, y poco a poco incorporaron imágenes.
La interacción seguía siendo limitada.
Para obtener un nuevo resultado, el usuario generalmente enviaba una petición al servidor y recibía otra página. Una página todavía no disponía de un lenguaje universal capaz de responder directamente a un clic, modificar su contenido o realizar cálculos localmente.
Cuando la Web empezó a atraer a un público masivo, esta limitación se volvió evidente.
Los fabricantes de navegadores comenzaron a buscar la manera de convertir el documento web en un entorno programable.
Netscape y la explosión de la Web comercial
En 1994, Marc Andreessen y Jim Clark fundaron Mosaic Communications, pronto rebautizada Netscape Communications.
Su navegador Netscape Navigator alcanzó un éxito espectacular.
La empresa comprendió rápidamente que el navegador podía ser mucho más que un lector de documentos: podía convertirse en una plataforma de aplicaciones.
En aquella época, Java, desarrollado en Sun Microsystems, generaba un enorme entusiasmo. La idea de ejecutar programas portables en diferentes entornos parecía especialmente apropiada para Internet.
Netscape planeaba integrar Java, pero también quería un lenguaje más ligero que pudiera incluirse directamente en las páginas por autores que no fueran necesariamente programadores profesionales.
Brendan Eich llegó a la empresa en este contexto.
Brendan Eich y los legendarios diez días
Brendan Eich se incorporó a Netscape en abril de 1995.
Inicialmente esperaba trabajar en un lenguaje inspirado en Scheme. Sin embargo, Netscape necesitaba con urgencia un lenguaje de scripting para el navegador.
Eich realizó el primer prototipo en mayo de 1995, en un plazo extremadamente corto que suele resumirse con la expresión «diez días».
Eso no significa que el JavaScript moderno fuera diseñado completamente en diez días. Se refiere a la creación rápida del prototipo inicial a partir del cual el lenguaje continuó evolucionando.
La presión temporal tuvo, no obstante, consecuencias históricas.
Algunas decisiones se tomaron muy deprisa. Algunas peculiaridades se volvieron después imposibles de eliminar porque los sitios ya dependían de ellas.
JavaScript conservaría para siempre huellas de aquel nacimiento acelerado.
Mocha, LiveScript y finalmente JavaScript
El lenguaje no se llamó JavaScript desde el principio.
Durante su desarrollo recibió primero el nombre Mocha.
Posteriormente pasó a llamarse LiveScript en Netscape Navigator 2.0.
En diciembre de 1995, Netscape y Sun anunciaron el nombre JavaScript.
La elección fue en gran medida una decisión de marketing.
Java tenía una visibilidad excepcional y relacionar ambos nombres permitía aprovechar ese entusiasmo.
La similitud generó décadas de confusión.
JavaScript y Java son lenguajes diferentes, con sistemas de tipos, modelos de ejecución e historias distintas. Nuestro artículo sobre la historia de Java explica el camino del lenguaje asociado a James Gosling y permite apreciar claramente esas diferencias.
El nombre JavaScript, sin embargo, sobrevivió y se convirtió en uno de los más reconocibles del desarrollo de software.
JavaScript nunca fue simplemente un pequeño Java
JavaScript adoptó deliberadamente elementos sintácticos familiares para programadores de C y Java: llaves, operadores, bucles y estructuras condicionales.
Pero su modelo profundo procedía de otros lugares.
Brendan Eich se inspiró en Scheme para las funciones de primera clase y en Self para los objetos basados en prototipos.
Una función JavaScript puede almacenarse en una variable, pasarse a otra función o devolverse como resultado.
Históricamente, los objetos no necesitaban ser instanciados desde una clase clásica. Podían delegar la búsqueda de propiedades a otros objetos mediante una cadena de prototipos.
Esta diferencia es fundamental.
Por ello JavaScript ocupa un lugar particular en la historia de la programación orientada a objetos: permite una auténtica programación con objetos sin haber adoptado inicialmente el modelo de clases popularizado por C++ y Java.
El navegador como entorno de ejecución
JavaScript no se volvió poderoso de forma aislada.
Su utilidad procede de su relación con las API del navegador.
El lenguaje puede acceder al documento mostrado, reaccionar a eventos del usuario, programar tareas y, progresivamente, comunicarse con la red.
Por ello es importante distinguir JavaScript, el lenguaje, de las Web APIs suministradas por el navegador.
Array, Object o Promise pertenecen al lenguaje.
El DOM, fetch, localStorage o los eventos del ratón pertenecen al entorno web.
Esta distinción se volvió aún más importante cuando JavaScript abandonó el navegador mediante Node.js.
El mismo lenguaje pudo entonces ejecutarse en entornos distintos con API diferentes.
El DOM convierte la página en una estructura programable
Para que un script pueda modificar una página, el navegador debe exponer el documento de una forma programable.
Ese es el papel del Document Object Model, o DOM.
El navegador representa la página como una estructura de objetos correspondientes a sus elementos.
JavaScript puede localizar un elemento, modificar su texto, cambiar una clase CSS, crear nuevos nodos o escuchar eventos.
Esta capacidad transformó progresivamente la naturaleza de la página web.
El documento dejó de ser simplemente algo descargado y mostrado. Se convirtió en una estructura viva que el programa podía modificar después de la carga.
El DOM no forma parte de JavaScript propiamente dicho, aunque ambos quedaron tan asociados que los principiantes suelen confundirlos.
Microsoft entra en la batalla
El éxito de Netscape atrajo rápidamente a Microsoft.
Internet Explorer se convirtió en una pieza estratégica de Windows y la competencia entre navegadores se intensificó.
Microsoft implementó su propio lenguaje compatible, llamado JScript, en Internet Explorer 3 en 1996.
El riesgo era evidente: si cada navegador desarrollaba su propia variante, los programadores podrían necesitar scripts diferentes para cada uno.
La Web necesitaba un estándar.
Netscape presentó entonces el lenguaje al organismo de normalización Ecma International.
Esta decisión sería decisiva para su supervivencia.
ECMAScript: estandarizar el núcleo del lenguaje
En 1997 apareció la primera edición del estándar ECMA-262.
El lenguaje estandarizado recibió el nombre ECMAScript.
JavaScript siguió siendo el nombre histórico y práctico más conocido, mientras ECMAScript designaba la especificación formal.
Esta separación permitió que diferentes motores implementaran un mismo comportamiento central.
ECMAScript 2 apareció en 1998 y ECMAScript 3 en 1999.
ES3 añadió muchas funciones que formarían durante años la base del JavaScript de la Web: expresiones regulares, mejores operaciones con cadenas, excepciones con try y catch y otros refinamientos.
La estandarización no eliminó inmediatamente las incompatibilidades, pero proporcionó un fundamento común independiente de una única empresa.
La guerra de navegadores y el peso de la compatibilidad
A finales de los años noventa, Netscape perdió progresivamente su dominio frente a Internet Explorer.
La primera guerra de navegadores dejó una Web fragmentada.
Los navegadores ofrecían comportamientos diferentes, API propietarias e implementaciones imperfectamente compatibles.
Los desarrolladores detectaban navegadores, rodeaban bugs y mantenían diferentes rutas de código.
Este periodo contribuyó a la mala reputación que JavaScript tuvo durante años entre numerosos programadores.
También estableció una regla que sigue siendo fundamental: la Web concede un enorme valor a la retrocompatibilidad.
Un comportamiento extraño utilizado por millones de páginas resulta extremadamente difícil de cambiar sin romper sitios existentes.
¿Por qué JavaScript tiene comportamientos extraños?
JavaScript recibe críticas por conversiones sorprendentes, igualdad débil, NaN, el resultado histórico de typeof null o las reglas sutiles de this.
Estas características tienen orígenes diferentes.
Algunas proceden del prototipo inicial.
Otras surgieron durante la estandarización.
Y otras se volvieron prácticamente imposibles de corregir porque las páginas existentes dependían de ellas.
La lección histórica es importante: un lenguaje de la Web no puede evolucionar como un software aislado.
Que código escrito hace décadas siga funcionando es al mismo tiempo un logro extraordinario y una restricción considerable.
Las versiones modernas suelen añadir mecanismos más seguros en lugar de cambiar bruscamente la semántica antigua.
ECMAScript 4: el gran rediseño que fracasó
Durante los años 2000, algunos participantes quisieron transformar JavaScript profundamente.
El proyecto ECMAScript 4 era mucho más ambicioso e incluía clases más formales, tipos opcionales, namespaces y numerosas funciones adicionales.
El comité no consiguió alcanzar un acuerdo.
Las diferencias afectaban a la complejidad, la compatibilidad, el coste de implementación y la dirección general del lenguaje.
El proyecto terminó abandonándose.
Este fracaso condicionó la evolución posterior.
En lugar de una gran ruptura, JavaScript avanzaría cada vez más mediante extensiones compatibles y pasos incrementales.
Parte de las ideas de ES4 reaparecieron posteriormente bajo otras formas.
Ajax: la Web deja de recargar toda la página
A mediados de los años 2000 se produjo una transformación decisiva.
Los navegadores ya disponían de mecanismos que permitían a JavaScript realizar peticiones de red sin recargar completamente una página.
Aplicaciones como Gmail y Google Maps demostraron el potencial de este enfoque.
En 2005, Jesse James Garrett popularizó el término Ajax, Asynchronous JavaScript and XML.
Aunque el nombre menciona XML, la idea era más amplia: una aplicación podía comunicarse con un servidor en segundo plano y actualizar solamente una parte de la interfaz.
La experiencia web cambió radicalmente.
Los sitios comenzaron a comportarse como aplicaciones.
JavaScript pasó de pequeños efectos visuales a ocupar un lugar central en la arquitectura del software web.
jQuery: ocultar las diferencias entre navegadores
Incluso con Ajax, las diferencias entre navegadores complicaban el desarrollo.
En 2006, John Resig presentó jQuery.
La biblioteca ofrecía una API concisa para seleccionar elementos, manipular el DOM, gestionar eventos, realizar animaciones y efectuar peticiones Ajax.
Su lema «write less, do more» encajaba perfectamente con las necesidades de la época.
Sobre todo, jQuery absorbía muchas incompatibilidades entre navegadores.
El desarrollador programaba contra la API de la biblioteca en lugar de resolver cada diferencia manualmente.
Durante años, jQuery se volvió casi sinónimo de desarrollo JavaScript en el navegador.
Su declive posterior no representa un fracaso: muchas funciones que hacía cómodas acabaron incorporándose de manera más coherente a los propios estándares y navegadores.
Los motores JavaScript entran en una carrera de rendimiento
A medida que las aplicaciones web se hicieron más ambiciosas, el rendimiento ganó importancia.
Los fabricantes invirtieron masivamente en sus motores JavaScript.
En 2008, Google lanzó Chrome con el motor V8.
V8 utilizó técnicas de compilación JIT, just-in-time, para transformar dinámicamente el código en instrucciones de máquina optimizadas.
Mozilla, Apple y Microsoft también mejoraron sus motores.
La competencia cambió la percepción del lenguaje.
JavaScript dejó de estar limitado a pequeños scripts ejecutados lentamente.
Aplicaciones mucho más complejas se volvieron viables dentro del navegador.
Esta carrera preparó además una de las mayores rupturas de su historia: JavaScript en el servidor.
2009: Node.js saca JavaScript del navegador
En 2009, Ryan Dahl presentó Node.js.
El proyecto utilizaba V8 fuera de Chrome y lo combinaba con API para servidores, archivos, red, procesos y entrada/salida.
Node.js adoptó fuertemente un modelo de I/O asíncrono y no bloqueante.
Para muchas aplicaciones de red, esta arquitectura permite gestionar numerosas operaciones concurrentes sin crear un thread tradicional para cada conexión.
Su impacto cultural fue igualmente importante.
Los desarrolladores web pudieron utilizar a gran escala el mismo lenguaje en el navegador y en el servidor.
JavaScript se convirtió en una plataforma general.
npm y un ecosistema gigantesco
Node.js estuvo acompañado por otro fenómeno decisivo: npm, su gestor y registro de paquetes.
Publicar e instalar una biblioteca JavaScript se volvió extremadamente sencillo.
El ecosistema explotó.
Aparecieron paquetes para servidores HTTP, bases de datos, herramientas de build, pruebas, línea de comandos, transformación de archivos y prácticamente cualquier necesidad imaginable.
Esta abundancia aceleró enormemente el desarrollo.
También creó problemas: enormes árboles de dependencias, paquetes abandonados, riesgos de cadena de suministro, dependencias transitivas y fragmentación.
npm ilustra un patrón recurrente de la historia de JavaScript: el éxito produce una diversidad enorme y el ecosistema debe después crear convenciones para controlarla.
CommonJS, AMD y el problema de los módulos
Las primeras páginas JavaScript no fueron diseñadas para aplicaciones con miles de archivos fuente.
Cuando los proyectos crecieron, organizar el código se convirtió en un problema fundamental.
Node.js popularizó CommonJS con require() y module.exports.
En el navegador aparecieron alternativas como AMD.
Los bundlers permitieron después combinar muchos módulos en archivos preparados para el despliegue.
Finalmente ECMAScript estandarizó los ES Modules, con import y export.
Puede parecer una cuestión técnica, pero fue un paso esencial.
JavaScript estaba adquiriendo la infraestructura necesaria para organizar bases de código enormes sin abandonar su entorno original.
ECMAScript 5: modernizar sin romper
Después de las dificultades de ECMAScript 4, la comunidad de estándares adoptó una estrategia más prudente.
ECMAScript 5, publicado en 2009, añadió modo estricto, métodos de arrays, mejor soporte de JSON y controles más precisos sobre propiedades de objetos.
El strict mode representa perfectamente la estrategia evolutiva de JavaScript.
En lugar de cambiar la semántica de todos los programas existentes, los desarrolladores podían activar reglas más estrictas para código concreto.
El lenguaje obtenía así un camino hacia prácticas más seguras preservando la Web antigua.
Esta evolución aditiva se convertiría en una característica fundamental.
JSON: una sintaxis inspirada en JavaScript conquista los datos
JSON, popularizado por Douglas Crockford, utiliza una notación inspirada en los literales de objetos y arrays de JavaScript para representar datos estructurados.
Pero JSON no es simplemente «código JavaScript».
Posee su propia gramática y se convirtió en un formato independiente del lenguaje.
Su sencillez lo hizo especialmente útil para las API web.
A medida que Ajax y los servicios HTTP crecieron, JSON sustituyó con frecuencia a XML para intercambiar datos de aplicaciones.
La influencia de JavaScript superó así su propio entorno: una notación inspirada en su sintaxis se convirtió en uno de los formatos de datos más utilizados de la informática.
El event loop y la ejecución asíncrona
Comprender JavaScript moderno exige entender su relación con el trabajo asíncrono.
En el navegador y en Node.js, JavaScript suele operar dentro de un entorno dirigido por eventos.
Un clic, una respuesta de red o un temporizador pueden programar trabajo.
El event loop coordina cuándo pueden ejecutarse las tareas cuando la pila de llamadas queda disponible.
Este modelo permite gestionar muchas operaciones de entrada/salida sin bloquear la ejecución principal esperando cada resultado.
También puede resultar confuso.
Callbacks anidados, orden de microtasks y control de flujo asíncrono generaron una complejidad considerable.
El lenguaje y su ecosistema desarrollaron progresivamente mejores abstracciones.
De callbacks a Promises y async/await
Las primeras API asíncronas utilizaron ampliamente callbacks.
Funcionan, pero una sucesión de operaciones dependientes puede producir estructuras profundamente anidadas conocidas como «callback hell».
Las Promises ofrecen una representación más estructurada de un valor que estará disponible en el futuro.
Fueron estandarizadas en ECMAScript 2015.
Después, async y await permitieron escribir muchas secuencias asíncronas con una apariencia similar al código síncrono.
Estas evoluciones muestran cómo JavaScript aprende de su propio uso.
El lenguaje de 1995 no había sido diseñado para todas las aplicaciones de red de los años 2020, pero consiguió adaptarse sin abandonar su compatibilidad histórica.
ECMAScript 2015: el gran giro moderno
ECMAScript 2015, conocido durante mucho tiempo como ES6, fue una de las mayores evoluciones de JavaScript.
Introdujo o estandarizó let y const, funciones flecha, clases, módulos, Promises, template literals, destructuring, parámetros por defecto, generadores, Map, Set, Symbol y muchas otras funciones.
La versión hizo JavaScript considerablemente más expresivo.
La sintaxis class necesita una precisión importante: no sustituyó el modelo fundamental de prototipos.
Ofreció una sintaxis más familiar para expresar construcciones comunes sobre ese modelo.
Babel y la posibilidad de utilizar hoy la sintaxis de mañana
Las nuevas funciones de la Web se enfrentan a una dificultad recurrente: todos los usuarios no actualizan su navegador al mismo tiempo.
Los desarrolladores querían utilizar sintaxis moderna sin excluir entornos antiguos.
Herramientas como Babel transformaron JavaScript moderno en formas ejecutables por motores anteriores.
Esta técnica, la transpilación, se volvió central durante los años 2010.
Separó parcialmente el lenguaje escrito por los desarrolladores de la sintaxis exacta enviada al navegador objetivo.
Combinada con bundlers, minificadores y servidores de desarrollo, creó una sofisticada cadena de build alrededor de un lenguaje que originalmente se ejecutaba directamente desde una etiqueta <script>.
Angular, React, Vue y la era de los frameworks
Cuando las interfaces se convirtieron en aplicaciones completas, aparecieron frameworks y bibliotecas para controlar la complejidad.
AngularJS y posteriormente Angular propusieron estructuras completas.
React, publicado por Facebook en 2013, popularizó las interfaces basadas en componentes y el renderizado declarativo.
Vue ofreció otra combinación de reactividad, componentes y adopción progresiva.
Svelte, Solid y numerosos frameworks full-stack llegaron después.
Las herramientas concretas cambian, pero la tendencia arquitectónica permanece: los front-ends modernos suelen organizarse alrededor de componentes, estado y descripciones declarativas en lugar de largas secuencias de manipulaciones manuales del DOM.
JavaScript como lenguaje multiparadigma
JavaScript es difícil de encerrar en un único paradigma.
Permite programación imperativa.
Sus funciones de primera clase facilitan estilos funcionales.
Los prototipos y la sintaxis de clases permiten varios estilos orientados a objetos.
Las closures proporcionan otra forma de encapsulación.
Los generadores y el asincronismo añaden modelos adicionales.
Esta flexibilidad explica parte de su éxito, pero también la gran variedad de estilos entre proyectos.
Como el lenguaje no impone una única arquitectura, la disciplina procede a menudo de convenciones de equipo, linters, tipado estático opcional y frameworks.
TypeScript: añadir tipos al mundo JavaScript
Cuando las aplicaciones JavaScript crecieron, el tipado dinámico podía resultar difícil de gestionar en bases de código enormes.
Microsoft desarrolló TypeScript, anunciado en 2012.
El proyecto fue dirigido por Anders Hejlsberg, conocido anteriormente por Turbo Pascal y C#.
TypeScript añade un potente sistema de tipos estáticos estructurales y herramientas de desarrollo sobre JavaScript.
Después produce JavaScript para la ejecución.
Esta estrategia es fundamental: TypeScript no pretende reemplazar la plataforma JavaScript, sino apoyarse en ella.
Su adopción masiva demuestra que el ecosistema puede añadir garantías durante el desarrollo preservando la compatibilidad universal del lenguaje subyacente.
Del servidor al desktop, móvil y cloud
Node.js abrió la puerta a una expansión considerable.
Electron permite construir aplicaciones de escritorio con tecnologías web.
React Native y soluciones relacionadas llevan JavaScript al desarrollo móvil.
Muchas herramientas de línea de comandos están escritas para Node.js.
Plataformas serverless y edge también ejecutan JavaScript o runtimes cercanos.
Un lenguaje creado para Netscape Navigator puede utilizarse así en numerosas capas de un sistema moderno.
Esta ubicuidad facilita reutilizar competencias y bibliotecas.
No significa que JavaScript sea óptimo para cada tarea, pero su coste de adopción suele ser bajo para equipos ya centrados en tecnologías web.
La seguridad como restricción fundadora
Ejecutar dentro del navegador código descargado de Internet plantea inmediatamente problemas de seguridad.
JavaScript funciona por ello en un entorno fuertemente restringido.
Los navegadores aíslan páginas y aplican reglas como la same-origin policy.
Una página no puede leer libremente datos de otro sitio ni acceder al sistema de archivos como un programa nativo ordinario.
Con el tiempo, el modelo de seguridad se hizo mucho más sofisticado: permisos, Content Security Policy, CORS, aislamiento de contextos y defensas frente a numerosas clases de ataques.
JavaScript ha sido moldeado no solo por su sintaxis, sino por el entorno hostil en el que código procedente de múltiples fuentes debe convivir.
Rendimiento y optimización especulativa
Los motores modernos realizan un trabajo extraordinario para ejecutar rápidamente un lenguaje dinámico.
Observan tipos durante la ejecución, construyen representaciones internas optimizadas, compilan determinadas partes y pueden abandonar código especializado si sus hipótesis dejan de ser válidas.
Técnicas como hidden classes, inline caches y compilación JIT consiguen rendimientos inimaginables para los primeros motores.
La mayor parte de esta complejidad es invisible para el desarrollador.
Sin embargo, ilustra un hecho central: el éxito de JavaScript debe tanto a décadas de ingeniería de motores como a la evolución de la especificación.
WebAssembly no sustituye a JavaScript
La llegada de WebAssembly fue presentada en ocasiones como el comienzo del fin de JavaScript.
No ocurrió así.
WebAssembly ofrece un formato de ejecución compacto y eficiente, especialmente útil para código procedente de lenguajes como C, C++ o Rust.
Pero funciona dentro de la plataforma web y coopera frecuentemente con JavaScript.
JavaScript sigue estando especialmente adaptado a las API del navegador, la orquestación de interfaces y la lógica general de aplicaciones.
WebAssembly amplía por tanto las posibilidades de la plataforma en lugar de reemplazar simplemente su lenguaje histórico.
TC39 y la evolución actual de JavaScript
La evolución de ECMAScript se desarrolla dentro de TC39, un comité técnico de Ecma International.
Las nuevas funciones atraviesan varias etapas de propuesta.
Se discuten, experimentan, especifican e implementan antes de alcanzar el estándar final.
Desde 2015, ECMAScript sigue un ritmo de publicación anual.
Optional chaining, nullish coalescing, BigInt, mejoras de módulos, nuevos métodos de colecciones y muchas otras funciones llegaron de forma incremental.
JavaScript moderno evoluciona continuamente, pero prestando una atención extraordinaria a la retrocompatibilidad.
Muchas empresas, un lenguaje compartido
Netscape creó JavaScript.
Microsoft contribuyó a su difusión competitiva y a su historia de estandarización.
Mozilla heredó buena parte del legado de Netscape.
Google aceleró la competencia entre motores mediante Chrome y V8.
Apple desarrolla JavaScriptCore.
Microsoft creó TypeScript.
Meta tuvo una influencia enorme mediante React.
Sin embargo, ninguna de estas empresas controla por sí sola el futuro del lenguaje.
Una especificación abierta, varios motores independientes y la importancia estructural de la Web convirtieron JavaScript en infraestructura compartida.
Esta realidad distribuida permitió al lenguaje sobrevivir al declive o desaparición de varios actores que marcaron su historia.
JavaScript frente a Java, Python y C++
Comparar JavaScript con otros grandes lenguajes permite apreciar su posición original.
C++ pone especial énfasis en el control de recursos, la programación de sistemas y abstracciones de coste controlado.
Java se construyó históricamente alrededor de una máquina virtual, tipado estático y un modelo de clases más clásico.
Python favorece la legibilidad, una sintaxis concisa, scripting, automatización, ciencia y un amplio ecosistema generalista.
JavaScript posee una ventaja histórica única: es el lenguaje programable nativo del navegador web.
Esa posición le proporcionó una distribución que ningún otro lenguaje generalista obtuvo de la misma manera.
Los defectos de JavaScript son también fósiles históricos
¿Por qué algunas conversiones implícitas sorprenden?
¿Por qué this depende de la manera en que se llama a una función?
Resulta tentador imaginar una limpieza completa del lenguaje.
Pero cada posible corrección debe evaluarse frente a décadas de código existente.
La Web funciona como una especie de arqueología permanente del software: antiguas decisiones siguen siendo visibles porque eliminar su comportamiento podría romper sitios todavía accesibles.
Las prácticas modernas suelen rodear estos legados mediante mecanismos más explícitos, linters, tests y sistemas de tipos.
Innovación del ecosistema y fatiga de herramientas
La velocidad de innovación de JavaScript tiene un coste.
Gestores de paquetes, bundlers, transpilers, frameworks, herramientas de pruebas y convenciones han cambiado rápidamente.
Un nuevo desarrollador puede sentir que el ecosistema nunca deja de moverse.
La expresión «JavaScript fatigue» apareció para describir esta experiencia.
Sin embargo, conviene distinguir el lenguaje de su ecosistema.
El núcleo ECMAScript evoluciona mediante un proceso de estandarización relativamente estructurado.
Gran parte de la volatilidad procede de capas construidas para resolver problemas de aplicaciones a gran escala, compatibilidad, despliegue y experiencia de desarrollo.
Con el tiempo, algunas soluciones desaparecen y otras se convierten en convenciones estables o funciones de la propia plataforma.
Un movimiento de vuelta hacia la simplicidad
Una tendencia más reciente intenta reducir la complejidad acumulada.
Los navegadores modernos soportan directamente módulos y numerosas API antes suministradas por bibliotecas.
Nuevos runtimes y herramientas buscan acelerar instalación, pruebas, bundling y ejecución.
Los frameworks exploran cada vez más el renderizado en servidor, generación estática, componentes de servidor y el envío de menos JavaScript al cliente cuando resulta apropiado.
No es un rechazo de JavaScript.
Es una señal de madurez de la plataforma: después de demostrar que casi todo podía ejecutarse en el navegador, el ecosistema pregunta cada vez más qué debería realmente ejecutarse allí.
¿Por qué sobrevivió JavaScript?
JavaScript sobrevivió por varias razones.
Estuvo en el lugar adecuado en el momento adecuado: dentro del navegador cuando la Web se convertía en plataforma mundial.
La estandarización ECMAScript le permitió sobrevivir a Netscape.
La retrocompatibilidad protegió los sitios existentes.
La competencia entre motores mejoró el rendimiento.
Node.js abrió el servidor.
npm creó una enorme red de paquetes reutilizables.
Y el lenguaje siguió evolucionando sin exigir una reescritura completa de la Web.
Esta combinación es extremadamente difícil de reproducir.
El éxito de JavaScript es por tanto ecológico e institucional además de técnico.
Lo que JavaScript enseña sobre los lenguajes
La historia de JavaScript demuestra que un lenguaje no se juzga únicamente por la elegancia de su diseño inicial.
La distribución importa.
La compatibilidad importa.
Las herramientas importan.
Las bibliotecas importan.
La gobernanza y los estándares importan.
Un lenguaje imperfecto pero disponible en todas partes, respaldado por un ecosistema enorme y capaz de evolucionar puede resultar más importante que un lenguaje teóricamente más coherente.
JavaScript quizá sea el ejemplo más espectacular de este principio.
Su nacimiento apresurado no determinó su destino. La Web creó un entorno en el que sucesivas generaciones de desarrolladores, autores de estándares e ingenieros de motores pudieron transformarlo continuamente.
Lo esencial
JavaScript nació en 1995 en Netscape, cuando Brendan Eich creó rápidamente un prototipo de lenguaje de scripting para el navegador.
Primero llamado Mocha y después LiveScript, pasó a llamarse JavaScript cuando el nombre Java gozaba de enorme visibilidad, aunque ambos lenguajes sean profundamente diferentes.
Su diseño combinó sintaxis familiar de la familia C con influencias de Scheme para las funciones y Self para los prototipos.
La estandarización como ECMAScript desde 1997 permitió que el lenguaje sobreviviera más allá de Netscape.
Ajax y jQuery transformaron su papel en los años 2000. Los motores JIT, especialmente V8, mejoraron radicalmente el rendimiento. Node.js lo sacó del navegador en 2009 y npm construyó un ecosistema gigantesco.
ECMAScript 2015 modernizó profundamente el lenguaje. Los frameworks transformaron el desarrollo de interfaces y TypeScript añadió tipado estático sobre la plataforma JavaScript.
Hoy JavaScript ya no es simplemente el lenguaje que añade interactividad a las páginas web.
Es una capa fundamental de la plataforma Web y uno de los mayores ecosistemas de software jamás construidos.
Preguntas frecuentes
¿Quién creó JavaScript?
JavaScript fue creado por Brendan Eich en Netscape en 1995. El prototipo inicial se desarrolló muy rápidamente antes de décadas de evolución y estandarización.
¿JavaScript fue realmente creado en diez días?
Eich produjo el prototipo inicial aproximadamente en ese plazo. El JavaScript moderno es, sin embargo, el resultado de tres décadas de trabajo de estándares, implementaciones y desarrollo colectivo.
¿JavaScript y Java son el mismo lenguaje?
No. A pesar de sus nombres parecidos y cierta sintaxis familiar, sus sistemas de tipos, modelos de objetos, entornos de ejecución e historias son diferentes.
¿Por qué el estándar se llama ECMAScript?
Netscape presentó el lenguaje a Ecma International para crear una especificación independiente. ECMAScript es la especificación normalizada y JavaScript sigue siendo el nombre de uso habitual.
¿Por qué JavaScript utiliza prototipos?
Su modelo de objetos original estuvo fuertemente influido por Self. Los objetos JavaScript pueden delegar la búsqueda de propiedades a otros objetos mediante una cadena de prototipos.
¿Node.js es otro lenguaje?
No. Node.js es un entorno de ejecución JavaScript construido históricamente alrededor de V8 y API para servidores, archivos, red, procesos y otras tareas fuera del navegador.
¿TypeScript sustituye a JavaScript?
No. TypeScript añade un sistema de tipos y herramientas de desarrollo, y produce JavaScript que se ejecuta en plataformas JavaScript compatibles.
¿JavaScript es solamente un lenguaje front-end?
No. Sigue siendo el lenguaje nativo del navegador, pero también se utiliza en servidores, herramientas de línea de comandos, aplicaciones desktop, desarrollo móvil y plataformas cloud.
Porque la retrocompatibilidad es esencial para la Web. Cambiar un comportamiento histórico puede romper páginas y aplicaciones existentes, por lo que normalmente se añaden nuevos mecanismos en lugar de eliminar los antiguos.
¿Va a desaparecer JavaScript?
No hay señales de una desaparición próxima. Su posición en los navegadores, su estandarización abierta, su ecosistema y su evolución continua le dan un papel estructural en la Web aunque los frameworks y herramientas cambien.
