Hoy vengo a decir algo que muchos intuyen, pero pocos se atreven a poner en palabras:
las arrow functions en JavaScript no son una evolución natural. Son la consecuencia directa de un mal diseño de base.
Sí, son limpias. Sí, son modernas. Sí, son útiles.
Pero sobre todo, son un parche. Un apaño elegante.
Un intento de solucionar por fuera lo que no se pudo solucionar por dentro.
JavaScript: el lenguaje que nació en 10 días
JavaScript fue creado a la carrera. Literalmente.
Brendan Eich lo desarrolló en 10 días para cumplir con la urgencia de Netscape en 1995.
No hubo planificación. No hubo principios sólidos de diseño.
Y aunque fue una genialidad para su tiempo, arrastró errores estructurales que hoy seguimos pagando.
Uno de ellos: el comportamiento de this
.
El this
de JavaScript es una trampa sutil
En JavaScript, this
no apunta a donde tú crees.
No depende de dónde se define la función, sino de cómo se llama.
Y eso, aunque uno se acostumbre, es una fuente constante de confusión, errores y frustración.
¿Qué hizo la comunidad durante años?
- Guardar
this
en variables tipovar self = this
- Usar
.bind(this)
manualmente - O directamente evitar el uso de
this
siempre que se pueda
Era un desastre encubierto.
Un "así funciona JavaScript", pero sin gusto.
Entonces llegó ECMAScript 6 con su bisturí
Y en lugar de arreglar el problema de raíz —porque eso habría roto la web entera—
decidieron crear algo nuevo.
Así nacieron las arrow functions.
Funciones que ya no tienen su propio this
.
Funciones que toman el contexto externo y se comportan de forma... menos traicionera.
Y sí, cumplen su propósito.
Pero lo hacen desde fuera del lenguaje, no desde dentro.
Ahora convivimos con dos realidades
Dos formas de declarar funciones:
- Una con
function()
, que tiene suthis
propio (y problemático). - Otra con
=>
, que se comporta distinto y que muchos no entienden del todo.
¿Y qué pasa con los nuevos desarrolladores?
Aprenden lo moderno. Imitan. Copian. Usan flechas sin entender.
Porque nadie les cuenta que esto no es una mejora pura, sino una herida mal cerrada.
¿Qué deberían haber hecho?
Nada.
Porque no podían.
Si hubieran corregido this
en function()
, habrían roto millones de líneas de código en producción.
Y eso, en el mundo real, no se puede hacer.
Así que lo único que quedaba era lo que hicieron:
crear una alternativa… y venderla como “lo nuevo y mejor”.
Pero yo lo veo. Y tú también.
Las arrow functions son útiles.
Pero también son el resultado de una necesidad, no de una visión limpia.
Son una muleta elegante.
Una forma de ocultar que JavaScript nunca estuvo bien diseñado en su base.
Y que ahora, más de 25 años después, seguimos pagando los efectos de su nacimiento improvisado.
Las arrow functions son el resultado de un pecado original.
Y como todo pecado bien disfrazado…
el lenguaje te lo muestra con belleza, pero te obliga a pagar el precio si no entiendes lo que hay debajo.
Yo ya lo veo.
Y tú que estás leyendo esto, probablemente… también.