Hoy me ha pasado algo curioso mientras repasaba las diferencias entre ECMAScript 5 y ECMAScript 6. Al estudiar las famosas arrow functions (=>), no pude evitar pensar:
“Esto parece un parche. Literalmente un apaño encima de un fallo original del lenguaje.”
Y como no me gusta quedarme con una sensación sin escarbar, me puse a hablar con mi asistente de IA —que, por cierto, se explica de maravilla— y le planteé esta intuición. Lo sorprendente es que el asistente lo confirmó sin dudar. No porque lo haya dicho Brendan Eich (el creador de JavaScript), ni porque lo haya escrito algún gurú en un blog, sino porque es evidente al analizar el diseño del lenguaje en profundidad.
¿De dónde viene todo esto?
JavaScript, en sus versiones iniciales, siempre tuvo un comportamiento extraño con this. En ES5, this dependía de cómo se llamaba la función, no de dónde estaba definida. Eso generó confusión, errores, y la necesidad de trucos feos como:
var self = this;
// o
func.bind(this);
// o
var _this = this;
Durante años, convivimos con estos malabares. Los aceptábamos, como quien se acostumbra a vivir con goteras.
Entonces llegó ES6, y con él, las arrow functions. Nos dijeron que eran más limpias, más breves, más modernas. Y lo son. Pero su verdadera razón de existir no era solo la estética:
era evitar el comportamiento conflictivo de this en funciones tradicionales.
¿Qué hicieron entonces?
No corrigieron function(). No lo reescribieron.
No arreglaron el problema de raíz porque eso habría roto millones de sitios web.
Así que hicieron lo que cualquier lenguaje con una base instalada gigante haría:
crearon otra forma de declarar funciones, que se comporta de otra manera.
Una función que ya no tiene su propio this, sino que captura el del contexto donde fue definida.
Una solución que sí, es útil…
pero que no deja de sentirse como un añadido artificial para tapar una herida vieja.
¿Parche o evolución?
Muchos cursos, tutoriales y documentación presentan las arrow functions como si fueran simplemente una alternativa más limpia.
Pero pocos —muy pocos— te explican el porqué real de su existencia.
Y cuando lo descubres, como lo he hecho hoy con mi asistente, no puedes evitar ver la doble cara del lenguaje:
- Por un lado, sí: JavaScript ha evolucionado, y las arrow functions son extremadamente útiles.
- Pero por otro, son también el resultado de no poder rehacer lo anterior sin romperlo todo.
¿Y qué conclusiones saco de esto?
- Entender el lenguaje no es solo aprender su sintaxis. Es conocer por qué fue diseñado así.
- Lo moderno no siempre es más “correcto”, a veces es simplemente lo menos destructivo posible.
- Las decisiones que tomaron los que diseñan lenguajes como JavaScript son a veces políticas, no técnicas.
- Y lo más importante: si algo te huele raro, escarba. Porque muchas veces, tienes razón.
Así que sí: las arrow functions son una mejora. Pero también son un parche elegante sobre un diseño que, desde el principio, no fue del todo limpio.
Y entender eso es mucho más valioso que saberse la sintaxis de memoria.
Hoy lo entendí. Y lo escribo para no olvidarlo.
