DEV Community

Cover image for JavaScript y su ecosistema: un tocahuevos con capas de abstracción
SatanDev
SatanDev

Posted on

JavaScript y su ecosistema: un tocahuevos con capas de abstracción

Vamos a hablar claro. Sin proteger a nadie. Porque JavaScript está tan sobrevalorado que hasta da risa. O pena. Depende del día.

Mira, el problema no es que JS sea malo. El problema es que JS es como ese amigo que no sabe decir "no" a nada. ¿Quieres hacer backend? "Sí, yo puedo". ¿Frontend? "También". ¿Apps móviles? "Claro, mira React Native". ¿Machine learning? "Anda, TensorFlow.js, qué tontería". ¿Un sistema operativo? "Ya mismo sale NodeOS, espera".

Y lo peor no es que lo intente. Lo peor es que la comunidad se lo cree. Se lo traga entero. Con cada nueva herramienta que intenta resolver un problema que nunca debió existir, aplauden como focas. Y cuando alguien dice "oye, igual esto es una locura", le cae la manada encima: "Es que no entiendes la reactividad", "Es que el ecosistema es maduro", "Es que State Management, Mongo, microservicios, blockchain, NFT, mira te vendo un curso".

Pero seamos honestos. La mayoría de las páginas web solo necesitan un poco de HTML, CSS, y cuatro alertas. En lugar de eso, tenemos un monstruo de mil cabezas. Porque cada vez que JS resuelve un problema, crea tres nuevos. Y esos tres nuevos requieren tres frameworks distintos que desaparecerán el año que viene. Y para cuando aprendiste uno, ya no sirve. Y tu experiencia vale menos que un "Hola mundo" en PHP de 2005.

El ciclo es perfecto. Y está diseñado para mantenerte enganchado. Porque si el lenguaje fuera fácil y eficiente, ¿quién compraría los cursos? ¿Quién seguiría a los influencers? ¿Quién pagaría por el bootcamp de 8 semanas que promete convertirte en "arquitecto full-stack cibernético"? Nadie.

Por eso JS no se arregla. Porque la complejidad es el negocio.

Y luego está el elefante en la habitación: la calidad. ¿Cuándo fue la última vez que viste una aplicación JS que no consumiera 500 MB de RAM para mostrar una lista de tareas? ¿O una página que no tardara 3 segundos en cargar porque el bundle pesa más que la Biblia en piedra? Pero no pasa nada. El usuario está acostumbrado. El usuario ya no sabe lo que es la fluidez. Le ponemos un skeleton loader, un spinner bonito, y ya está. Mientras tanto, el CPU del móvil llora en silencio.

Y a todo esto, los que defienden JS te dirán: "Pero si lo usan Google, Facebook, Netflix". Sí, claro. Y también usan C++, Rust, y equipos de mil personas para parchear lo que JS no puede hacer bien. Pero esa parte no la cuentan en los vídeos de YouTube, ¿verdad? No vende.

Yo ya no odio JavaScript. Le tengo lástima. Es como un perro que ladra a su propia sombra, persiguiéndose la cola sin saber que el problema es él mismo. Y encima, si se lo dices, te muerde. O peor, te responde con una promesa. Y luego con un callback hell. Y luego con un polyfill para que funcione en Internet Explorer 11, que ya ni existe.

Lo triste es que no hay alternativa real. Si trabajas en web, estás atrapado. Puedes ponerle TypeScript, puedes usar WebAssembly para lo pesado, pero al final del día, JS está ahí. Mirándote. Esperando a que tu useEffect se ejecute una vez más de la cuenta. Riéndose de ti mientras tu app se renderiza tres veces sin motivo.

Así que seguimos aquí. Programando con un lenguaje que nació en diez días, que no distingue entre enteros y decimales, que te dice que "1" + 1 es "11" y que "1" - 1 es 0. Porque la coherencia es para débiles.

Pero bueno. Algún día todo esto cambiará. O no. Mientras tanto, me voy a hacer un café. En JavaScript. Porque ya hasta las cafeteras tienen su propia API.


Postdata (por si alguien se ofende):

Esto es humor. Humor negro, sí, pero humor. Si te dolió, probablemente eres parte del problema. Y si te reíste, bienvenido al club de los que saben que el emperador está desnudo, pero igual tenemos que vestirlo porque es lo que hay.


Fin del desahogo… por ahora.


![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bqeaf1p47vlv5oekjuzw

Top comments (0)