ECMAScript 202X: qué esperar del futuro de JavaScript

JavaScript lleva casi tres décadas siendo el lenguaje de la web. Comenzó como un lenguaje con el cual escribir scripts para dar dinamismo a las páginas estáticas, pero hoy se usa en aplicaciones completas, tanto en el frontend como en el backend y hasta en aplicaciones móviles o de escritorio. Es uno de los pocos lenguajes que literalmente se usa en todas partes. Cada año, la especificación oficial del lenguaje conocida como ECMAScript se actualiza con nuevas funcionalidades.

Pero, ¿quién decide cómo evoluciona este lenguaje que usamos millones de desarrolladores a diario? ¿Quién define qué nuevas funcionalidades llegarán a JavaScript el próximo año? La respuesta está en un grupo de trabajo llamado TC39 que sigue un proceso estructurado. En este insight veremos cómo funciona exactamente ese proceso y qué cambios podrían llegar pronto al lenguaje.

TC39

El TC39 es el comité responsable de definir la especificación oficial de JavaScript, conocida como ECMAScript. Está compuesto por desarrolladores de empresas como Google, Microsoft, Apple, Mozilla o Meta, así como miembros independientes de la comunidad y expertos de proyectos como Babel o TypeScript. Ninguna empresa "manda": su funcionamiento se basa en el consenso y cada decisión requiere que todos los miembros estén de acuerdo en que un cambio beneficiará al lenguaje y a su comunidad.

El trabajo del TC39 consiste en evaluar, debatir y aprobar nuevas características para JavaScript. Cada propuesta pasa por varias etapas, empezando como una simple idea hasta convertirse en parte oficial del lenguaje. Una de las características que ha permitido que JavaScript llegue tan lejos ha sido su capacidad de evolucionar sin romper el pasado. Por eso, esas actualizaciones siguen una regla de oro:

Don’t break the web

Esta frase significa algo muy concreto, ningún cambio en el lenguaje puede hacer que una web antigua deje de funcionar. Puede parecer obvio, pero es una de las restricciones más duras e importantes en el mundo del desarrollo de software. En otros lenguajes, los equipos que mantienen el lenguaje pueden introducir "breaking changes" en nuevas versiones: eliminar APIs, cambiar comportamientos, forzar migraciones. Los desarrolladores deciden si actualizan o no, y las versiones antiguas pueden seguir conviviendo. En la web, eso no es posible.

Esto plantea una restricción enorme para el TC39. No pueden eliminar funciones obsoletas ni cambiar comportamientos inconsistentes, incluso cuando todos están de acuerdo en que algo fue un error. En su lugar, deben construir sobre lo existente, añadiendo nuevas funcionalidades mientras se mantiene la compatibilidad. Es un equilibrio delicado entre avanzar y preservar, y es lo que ha permitido que la web siga funcionando sin fragmentarse. Gracias a este principio, una web escrita en 2005 sigue siendo válida hoy y puede coexistir en el mismo navegador que una aplicación moderna.

Proposals

La evolución de JavaScript no ocurre de forma improvisada ni por decisión unilateral. Cada nueva funcionalidad que acaba formando parte del lenguaje comienza como una propuesta dentro del comité TC39 y atraviesa un proceso estructurado.

Este sistema de proposals está diseñado para garantizar que cada idea se evalúe desde múltiples perspectivas: técnica, práctica y de compatibilidad. No basta con que una característica sea "interesante", debe resolver un problema real, ser consistente con el resto del lenguaje y poder implementarse de forma segura en todos los motores JavaScript.

Las cinco etapas de una propuesta

El proceso se divide en cinco etapas (stages), que marcan el grado de madurez de cada idea:

• Stage 0 Strawman: Cualquiera puede presentar una idea, un miembro del TC39 o un colaborador externo. Aquí se busca abrir el debate, sin necesidad de una especificación formal. Es el terreno de la experimentación, donde surgen ideas que a veces se convierten en estándares y otras se abandonan.

• Stage 1 Proposal: La idea toma forma. Se define el problema que intenta resolver, ejemplos de uso y posibles diseños. En esta fase, el comité decide si merece explorarse en serio.

• Stage 2 Draft: La propuesta se redacta en lenguaje de especificación técnica, casi como aparecería en el estándar. Se empieza a discutir con los implementadores de motores para valorar viabilidad y rendimiento. A partir de aquí, el diseño puede cambiar, pero la dirección general ya está clara.

• Stage 3 Candidate: El texto está prácticamente cerrado. Los navegadores y entornos comienzan a implementarla detrás de flags o versiones experimentales, para que la comunidad pueda probarla y reportar feedback. Si se detectan problemas, se ajusta la especificación antes de su aprobación final.

• Stage 4 Finished: La propuesta ha sido implementada y probada en múltiples entornos. Entra oficialmente en la siguiente edición del estándar ECMAScript.

Es un proceso largo y lento, pero esto es intencionado. Cada etapa funciona como un filtro para evitar decisiones precipitadas y asegurar que el lenguaje evolucione de forma coherente. Por ejemplo, async/await tardó varios años en pasar de idea a realidad, pero cuando lo hizo, se convirtió en una de las adiciones más sólidas y adoptadas de la historia del lenguaje. De igual forma, propuestas como optional chaining (?.) o nullish coalescing (??) demostraron cómo el proceso del TC39 consigue incorporar ideas potentes sin romper el código existente.

Gracias a este sistema de propuestas, JavaScript no avanza a golpe de moda ni de frameworks, sino mediante un consenso técnico entre desarrolladores, empresas y comunidad, con un fuerte compromiso hacia la estabilidad a largo plazo.

Propuestas interesantes

Cada año, decenas de ideas circulan dentro del TC39: algunas se quedan en el camino, otras avanzan hasta convertirse en parte del estándar. Entre todas ellas, hay un puñado de propuestas que destacan por su potencial para cambiar la forma en que escribimos JavaScript en los próximos años.

A continuación, repasamos algunas de las más esperadas o prometedoras, algunas ya muy maduras, otras todavía en debate, que muestran hacia dónde se dirige el lenguaje. Si te interesa conocer más propuestas interesantes y su estado puedes consultarlas en github.com/tc39/proposals.

Temporal

Date ha sido siempre una de las partes más criticadas del lenguaje. Diseñada con prisas en los 90, tiene múltiples inconsistencias: zonas horarias confusas, mutabilidad, y un manejo de fechas y tiempos que a menudo lleva a errores sutiles.

Durante años, la comunidad suplió esas carencias con librerías externas como Moment.js, date-fns o Luxon. Pero desde que los propios creadores de Moment.js anunciaron su deprecación y mantenimiento limitado, la necesidad de una solución oficial, moderna y fiable dentro del propio lenguaje se hizo aún más evidente. Ahí es donde entra la Temporal API, un nuevo sistema para trabajar con fechas y tiempos de forma precisa, clara y predecible.

const start = Temporal.PlainDateTime.from("2025-01-01T09:00");
const end = Temporal.PlainDateTime.from("2025-01-01T17:00");
// Calcular el tiempo entre dos fechas
const duration = end.since(start);
console.log(duration.hours); // 8

// Añadir o restar tiempo
const nextMeeting = start.add({ days: 1, hours: 2 });
console.log(nextMeeting.toString()); // 2025-01-02T11:00

Temporal no sustituye a Date, sino que lo complementa, manteniendo la compatibilidad con el código existente. Ya está en Stage 3, y varios entornos han empezado a implementarla experimentalmente. Por fin JavaScript tendrá una API nativa a la altura de las necesidades actuales para trabajar con fechas.

Pipe operator |>

Otra propuesta muy debatida es el pipe operator, inspirado en lenguajes como Elixir o F#. Permite encadenar llamadas de forma más legible, evitando anidar funciones en paréntesis:

// Sin pipeline
const result = capitalize(trim(format(input)));

// Con pipeline
const result = input |> format |> trim |> capitalize;

Su objetivo no es añadir azúcar sintáctico sin más, sino hacer más expresivo el estilo funcional que cada vez es más común en el ecosistema JavaScript. El debate actual está en definir la sintaxis final.

Decorators

Los decoradores llevan años siendo una de las propuestas más esperadas del lenguaje. La idea original surgió hace casi una década, inspirada en lenguajes como Python o Java, donde los decoradores permiten anotar y modificar el comportamiento de clases, métodos o propiedades de forma declarativa. Por ejemplo, se pueden usar para añadir lógica común a métodos sin modificar su cuerpo:

function logCall(value, context) {
  if (context.kind === "method") {
    return function (...args) {
      console.log(`→ ${context.name}(${args.join(", ")})`);
      return value.apply(this, args);
    };
  }
}

class Calculator {
  @logCall
  sum(a, b) {
    return a + b;
  }
}

new Calculator().sum(2, 3);
// → sum(2, 3)

Durante años, los decoradores fueron una de las características más demandadas por la comunidad de JavaScript, especialmente desde que TypeScript y Angular empezaron a utilizarlos. Sin embargo, la falta de un estándar y los múltiples rediseños del concepto provocaron mucha confusión. Diferentes versiones coexistían en librerías y frameworks, sin una semántica clara ni soporte nativo. Tras varios intentos fallidos y años de debate dentro del TC39, los decoradores finalmente alcanzaron Stage 3, lo que significa que el diseño está casi finalizado.

Array.fromAsync

Array.fromAsync es una propuesta que simplifica la creación de arrays a partir de iterables asíncronos, algo que antes requería combinaciones más complejas de for await...of o Promise.all. Esto es especialmente útil cuando trabajamos con streams de datos, APIs asíncronas o cualquier fuente que produzca valores de manera diferida.

// Generador asíncrono que produce números multiplicados por 2
async function* asyncGen(n) {
  for (let i = 0; i < n; i++) {
    yield i * 2;
  }
}

// Usando `for await...of` para recolectar los valores en un array
const arr1 = [];
for await (const v of asyncGen(4)) {
  arr1.push(v);
}
console.log(arr1); // [0, 2, 4, 6]

// Equivalente usando `Array.fromAsync`, mucho más conciso
const arr2 = await Array.fromAsync(asyncGen(4));
console.log(arr2); // [0, 2, 4, 6]

Pattern Matching

Inspirado en lenguajes como Rust, Swift o Scala, el pattern matching va más allá de los tradicionales switch, permitiendo desestructurar y comparar estructuras de datos complejas de forma declarativa. Por ejemplo:

match (res) {
    when ({ status: 200, body, ...rest }) {
    handleData(body, rest);
    }
    when ({ status: 301 | 304, destination: url }) {

    handleRedirect(url);
    }
    when({ status: 404 }) { retry(req); }

    else { throwSomething(); }
}

Aunque aún se encuentra en una fase temprana del proceso y la sintaxis todavía está en debate, su llegada podría simplificar enormemente el manejo de datos y flujos condicionales.

Conclusión

JavaScript no deja de cambiar. El lenguaje no necesita una revolución para seguir creciendo, sino pequeñas mejoras que harán que escribir código sea un poco más fácil y agradable. Cada nueva propuesta mejora el lenguaje sin romper lo que ya funciona, y eso es justo lo que lo mantiene vivo después de tantos años. Y al final, eso es lo que realmente importa: que el lenguaje siga creciendo.