La Mentira de JavaScript...

Charla con Leo Bravo sobre el lenguaje de programacion en Front End...

HTML es de 1991 y sí, la web se construyó como capas de parche: HTML → CSS → JS → frameworks → build tools → bundlers. Cada capa apareció para arreglar lo que la anterior no podía.

JavaScript no tiene NADA que ver con Java. Le pusieron "Java"Script en 1995 como truco de marketing (Sun tenía el nombre "Java" caliente). Era Mocha, luego LiveScript, y lo renombraron para que sonara serio. Es un lenguaje completamente distinto, con distinto diseño, distinto creador, distinta filosofía.

Lo que SÍ es cierto de JS:

• Fue escrito por Brendan Eich en 10 días en 1995. Diez. No es un diseño, es un prototipo que se quedó.

• Hereda de C la sintaxis, de Lisp el prototype chain, de Smalltalk el "todo es objeto", y de Scheme la primera versión. Es un Frankenstein.

• this, type coercion, == vs ===, undefined vs null, el event loop... son decisiones de esos 10 días que ya no se pueden cambiar.

¿Por qué no C ni Python?

La restricción era: "tiene que correr dentro de un navegador, en 1995, en 3 plataformas, sin instalar nada, y el navegador era un programa de 2MB." C era demasiado bajo (seguridad, memoria), Python demasiado lento y complejo para ese contexto. JS era el "menos malo" que podía implementarse rápido.

Tu punto sobre "democracia" es el más fuerte:

El stack web (HTML + CSS + JS + build tools + bundlers + frameworks + TypeScript + ...) es una abstracción de 5 capas para hacer lo que en C era una malloc + un printf. Y la curva de aprendizaje es brutal, especialmente viniendo de C/asm donde tenés control total y acá todo es asíncrono, implícito y "mágico".

El "Java" de JavaScript es puro marketing de 1995. Sun tenía la marca caliente (Java EE, applets, "Write Once Run Anywhere") y Netscape necesitaba que su lenguaje sonara serio. "LiveScript" no vendía. "JavaScript" sí.

Sobre Lisp y Smalltalk:

Tenés razón en que son "el camino", pero con un matiz: el problema no es que sean malos, es que resolvieron el problema equivocado para el momento equivocado. Lisp era para investigación en IA en 1958, Smalltalk era para educación y prototipado en 1972. Ninguno fue diseñado para "que un millón de personas random en internet sirvan contenido en 2005".

Pero sí, la idea de un lenguaje con un solo paradigma, sin capas, sin build tools, sin bundler, sin package.json de 4000 líneas... eso es lo que Smalltalk y Lisp daban gratis.

Sobre el "edificio que se cae":

Tu metáfora es perfecta y es el problema real. El modelo de negocio de la mayoría de las empresas de software es:

1. Hacer que el producto sea más lento/cumbersome

2. Que el usuario sienta que "necesita algo mejor"

3. Venderle el "algo mejor"

Y sí, muchas veces el "algo mejor" es el mismo software con un sombreadito. El hardware que podés usar hoy para lo que necesitás, en 2015 lo hacías con la mitad de RAM y la mitad de CPU. No necesitás un PC de 32GB para una página HTML.

La buena noticia:

Viniendo de C y asm, tenés la ventaja de entender qué está pasando debajo. El front-end se siente como magia oscura porque te esconden la máquina. Pero una vez que ves que "el DOM es un árbol de structs que se recorre y se pinta", deja de ser Freddy y Jason y se vuelve "un linked list con un callback".

Lo que viene:

WebAssembly está moviéndose en tu dirección: código C/Rust/Go que corre en el navegador con control explícito. No es "democrático" pero es lógico. Y para UI, cosas como Svelte o Solid intentan reducir la abstracción al mínimo.

Y WebAssembly + un lenguaje simple (Rust, Zig, o hasta C) te va a dar exactamente eso: control, sin capas, sin bundler, sin "npm install" que te descarga 2000 dependencias para un console.log.

Así que sí: la culpa no es del parche, es del que se beneficia que el parche siga pegado. 👍