La especificación ECMAScript

Normas y reglas de funcionamiento de Javascript


ECMAScript es la especificación donde se mencionan todos los detalles de cómo debe funcionar y comportarse Javascript en un navegador. De esta forma, los diferentes navegadores (Chrome, Firefox, Opera, Edge, Safari...) saben como deben desarrollar los motores de Javascript para que cualquier código o programa funcione exactamente igual, independientemente del navegador que se utilice.

ECMAScript suele venir acompañado de un número que indica la versión o revisión de la que hablamos (algo similar a las versiones de un programa). En cada nueva versión de ECMAScript, se modifican detalles sobre Javascript y/o se añaden nuevas funcionalidades, manteniendo Javascript vivo y con novedades que lo hacen un lenguaje de programación moderno y cada vez mejor preparado para utilizar en el día a día.

Teniendo esto en cuenta, debemos saber que los navegadores web intentan cumplir la especificación ECMAScript al máximo nivel, pero no todos ellos lo consiguen. Por lo tanto, pueden existir ciertas discrepancias. Por ejemplo, pueden existir navegadores que cumplan la especificación ECMAScript 6 al 80% y otros que sólo la cumplan al 60%. Esto significa que pueden haber características que no funcionen en un navegador específico (y en otros sí).

Además, todo esto va cambiando a medida que se van lanzando nuevas versiones de los navegadores web, donde su compatibilidad ECMAScript suele aumentar.

Versiones de ECMAScript

A lo largo de los años, Javascript ha ido sufriendo modificaciones que los navegadores han ido implementando para acomodarse a la última versión de ECMAScript cuanto antes. La lista de versiones de ECMAScript aparecidas hasta el momento son las siguientes, donde encontramos las versiones enmarcadas en lo que podemos considerar el pasado de Javascript:

Ed. Fecha Nombre formal / informal Cambios significativos
1 JUN/1997 ECMAScript 1997 (ES1) Primera edición
2 JUN/1998 ECMAScript 1998 (ES2) Cambios leves
3 DIC/1999 ECMAScript 1999 (ES3) RegExp, try/catch, etc...
4 AGO/2008 ECMAScript 2008 (ES4) Versión abandonada.
5 DIC/2009 ECMAScript 2009 (ES5) Strict mode, JSON, etc...
5.1 DIC/2011 ECMAScript 2011 (ES5.1) Cambios leves

A partir del año 2015, se marcó un antes y un después en el mundo de Javascript, estableciendo una serie de cambios que lo transformarían en un lenguaje moderno, partiendo desde la específicación de dicho año, hasta la actualidad:

Ed. Fecha ECMAScript Cambios significativos
6 JUN/2015 Clases, módulos, hashmaps, sets, for of, proxies...
7 JUN/2016 Array includes(), Exponenciación **
8 JUN/2017 Async/await
9 JUN/2018 Rest/Spread operator, Promise.finally()...
10 JUN/2019 flat, flatMap, trimStart(), optional error catch...
11 JUN/2020 Dynamic imports, BigInt, Promise.allSettled

En ocasiones, algunos navegadores deciden implementar pequeñas funcionalidades de versiones posteriores de ECMAScript antes que otras, para ir testeando y probando características, por lo que no es raro que algunas características de futuras especificaciones puedan estar implementadas en algunos navegadores.

Una buena forma de conocer en que estado se encuentra un navegador concreto en su especificación de ECMAScript es consultando la tabla de compatibilidad Kangax. En dicha tabla, encontramos una columna «Desktop browsers» donde podemos ver el porcentaje de compatibilidad con las diferentes características de determinadas especificaciones de ECMAScript.

Nota que de ECMAScript 6 en adelante, se toma como regla nombrar a las diferentes especificaciones por su año, en lugar de por su número de edición. Aunque en los primeros temas los mencionaremos indiferentemente, ten en cuenta que se recomienda utilizar ECMAScript 2015 en lugar de ECMAScript 6.

Estrategia «crossbrowser»

Dicho esto, y teniendo en cuenta todos estos detalles, es muy habitual que el programador esté confuso en como empezar a programar y que versión ECMAScript adoptar como preferencia.

Generalmente, el programador suele tomar una de las siguientes estrategias «crossbrowser» para asegurarse que el código funcionará en todos los navegadores:

Enfoque Código escrito Descripción
Conservador ECMAScript 5 Incómodo de escribir. Anticuado. Compatible con navegadores nativamente.
Delegador Depende Cómodo. Rápido. Genera dependencia al framework/librería.
Evergreen ECMAScript 2024+ Cómodo. Moderno. No garantiza la compatibilidad en navegadores antiguos.
Transpilador ECMAScript 2024+ Cómodo. Moderno. Preparado para el futuro. Requiere preprocesado.

Vamos a explicar cada una de estas estrategias para intentar comprenderlas mejor.

Enfoque conservador

El programador decide crear código ECMAScript 5, una versión «segura» que actualmente una gran mayoría de navegadores (incluído Internet Explorer soporta). Este enfoque permite asegurarse de que el código funcionará sin problemas en cualquier navegador, pero por otro lado, implica que para muchas tareas deberá escribir mucho código, código extra o no podrá disfrutar de las últimas novedades de Javascript.

Uno de los principales motivos por los que se suele elegir esta estrategia es porque se necesita compatibilidad con navegadores, sistemas antiguos y/o Internet Explorer. También se suele elegir porque es más sencilla o porque funciona nativamente sin necesidad de herramientas externas.

Enfoque delegador

El programador decide delegar la responsabilidad «crossbrowser» a un framework o librería que se encargará de ello. Este enfoque tiene como ventaja que es mucho más cómodo para el programador y ahorra mucho tiempo de desarrollo. Hay que tener en cuenta que se heredan todas las ventajas y desventajas de dicho framework/librería, así como que se adopta como dependencia (sin dicho framework/librería, nuestro código no funcionará). Además, también se suele perder algo de rendimiento y control sobre el código, aunque en la mayoría de los casos es prácticamente inapreciable.

Hoy en día, salvo para proyectos pequeños, es muy común escoger un framework Javascript para trabajar. Un framework te ayuda a organizar tu código, a escribir menos código y a ser más productivo a la larga. Como desventaja, genera dependencia al framework.

Enfoque evergreen

El programador decide no preocuparse de la compatibilidad con navegadores antiguos, sino dar soporte sólo a las últimas versiones de los navegadores (evergreen browsers), o incluso sólo a determinados navegadores como Google Chrome o Mozilla Firefox. Este enfoque suele ser habitual en programadores novatos, empresas que desarrollan aplicaciones SPA o proyectos que van dirigidos a un público muy concreto y no están abiertas a un público mayoritario.

Enfoque transpilador

El programador decide crear código de la última versión de ECMAScript. Para asegurarse de que funcione en todos los navegadores, utiliza un transpilador, que no es más que un sistema que revisa el código y lo traduce de la versión actual de ECMAScript a ECMAScript 5, que es la que leerá el navegador.

La ventaja de este método es que se puede escribir código Javascript moderno y actualizado (con sus ventajas y novedades) y cuando los navegadores soporten completamente esa versión de ECMAScript, sólo tendremos que retirar el transpilador (porque no lo necesitaremos). La desventaja es que hay que preprocesar el código (cada vez que cambie) para hacer la traducción.

Quizás, el enfoque más moderno de los mencionados es utilizar transpiladores. Sistemas como Babel son muy utilizados y se encargan de traducir de ECMAScript 6 a ECMAScript 5.

En estos primeros temas, tomaremos un enfoque conservador para hacer más fácil el inicio con Javascript. A medida que avancemos, iremos migrando a un enfoque transpilador.

Independientemente del enfoque que se decida utilizar, el programador también puede utilizar polyfills o fallbacks para asegurarse de que ciertas características funcionarán en navegadores antiguos. También puede utilizar enfoques mixtos.

  • Un polyfill no es más que una librería o código Javascript que actúa de «parche» o «relleno» para dotar de una característica que el navegador aún no posee, hasta que una actualización del navegador la implemente.

  • Un fallback es algo también muy similar: un fragmento de código que el programador prepara para que en el caso de que algo no entre en funcionamiento, se ofrezca una alternativa.

¿Quién soy yo?

Soy Manz, vivo en Tenerife (España) y soy streamer partner en Twitch y profesor. Me apasiona el universo de la programación web, el diseño y desarrollo web y la tecnología en general. Aunque soy full-stack, mi pasión es el front-end, la terminal y crear cosas divertidas y locas.

Puedes encontrar más sobre mi en Manz.dev