El blog de LiveCommerce

Un blog de comercio electrónico y tiendas online

Las Arrow Functions son el resultado de un pecado original

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 tipo var 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 su this 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.

Compártelo:

¿Tienes alguna consulta?

Si tienes alguna pregunta o sabes la respuesta sobre algún comentario, no dudes en contribuir.
Responderemos rápidamente.
Puedes utilizar etiquetas BBCode para escribir negrita, enlaces, imágenes, etc...
Más información en la página oficial de BBCOde http://www.bbcode.org/ Ejemplo:
[url=http://google.com]links[/url], [color=red]colores[/color] [b]negrita[/b]...

¿Has visto los videos en nuestro canal de Youtube?

En nuestro canal de Youtube publicamos periódicamente mejoras y funcionalidades del software de ecommerce.