Pregunta: ¿Por qué webassembly no será a medio plazo una debacle para javascript si por lo general es tan vilipendiado? Brendan Eich dijo que tenía claro que eso no sería un problema pero yo nunca entendí el motivo. No entiendo el motivo de que por ejemplo siga desarrollándose clojurescript después de existir webassembly. – @spectrumgomas

Hay varias preguntas aquí, con mayor o menor carácter especulativo.

Por un lado podemos tener una pregunta relativamente neutra que podría ser: “Asumida la existencia de Wasm, ¿[por qué] sigue siendo necesario JavaScript?”. Luego hay otras dos preguntas más: “¿Por qué Brendan Eich dijo lo que dijo?” y “¿Qué efecto tendrá Wasm sobre el desarrollo en web en general (JavaScript y otros?”.

Desde un punto de vista técnico, se puede concluir que sí, que tal como está diseñado Wasm, se ha dejado -¿intencionadamente?- que JavaScript siga siendo necesario para algunas cosas, al menos por ahora. Hay algunos planes para ir solucionando algunas de estas cosas, pero son planes a bastante largo plazo y que aún pueden cambiar enormemente.

En concreto, JavaScript sigue siendo necesario hoy en día porque, por diseño, Wasm no puede acceder directamente a las APIs Web, sólo comunicarse con código JavaScript y que este lo haga. Es cierto que esto no supone una enorme limitación, ya que se trata de “glue code” y sería relativamente sencillo tener una capa “estándar” implementada en JavaScript y olvidarnos del tema (de hecho, Emscripten ya incluye una capa así para bastantes APIs). Pero sea como sea, lo cierto es que, por diseño, Wasm se ha intentado orientar más hacia dejar que JavaScript mantenga el control: Módulos de alto rendimiento compilados a Wasm, que son usados desde una lógica de aplicación implementada a alto nivel (i.e. en JavaScript).

(A día de hoy, y aunque también “hay planes”, WASM tampoco proporciona Garbage Collection. Esto también es una limitación técnica relevante.)

Por otro lado hay argumentos no exclusivamente técnicos. Hay argumentos de coste, por ejemplo. Ya no se trata de que sea necesario hacer algo en JavaScript sino de evaluar hasta qué punto algunas partes sea más razonable seguir haciéndolas en JavaScript. Pensando en esto, yo diría que efectivamente hay partes de la aplicación que a corto y medio (y quizá largo) plazo sigue siendo más barato hacerlas en JavaScript. Para valorar este coste hay que tener en cuenta tanto el coste de desarrollo como el valor del código obtenido.

Según mi experiencia (¡Peligro! Opiniones en la calzada más adelante), el coste de desarrollo de código JavaScript tiende a ser algo más barato (los sueldos en front están siempre un escalón por debajo) pero además el valor del código de front es notablemente más bajo, al estar mucho más sometido a cambios constantes.

Seré breve: No lo sé, no lo puedo saber :) Puedo aventurar que pensara en algunos motivos como los anteriores, quizá, pero mi impresión va más por otro camino:

• Creo que por un lado existen motivos “publicitarios”, por llamarlos de alguna forma. Existía una cierta necesidad social de presentar WASM como algo no disruptivo, algo que no rompiera la web y que no supusiera un gran shock ni para los desarrolladores web, ni para los desarrolladores de la web (navegadores, motores, estándares, etc). No haberlo presentado así, podría haber dificultado bastante más su aceptación.
• Creo también que Eich mantiene la idea de que “JavaScript ya es inmortal” (o poco menos). Es decir, que no es que no quisiera matarlo, si no que aunque quisiera, no podría. Esto es discutible, pero creo justo admitir que, como poco, matar JavaScript es francamente difícil.

Esto, claramente, es puramente especulativo. Sobre todo, ¿quién soy yo para creer que puedo adivinar el futuro? ;)

Pero sí puedo decir que entiendo por lo menos una parte de esta preocupación. En el caso del ejemplo -¿por qué seguir existiendo Clojurescript en lugar de hacer Clojure→Wasm?-, creo que efectivamente puede haber cambios. Pero serán cambios a largo plazo. También creo que en realidad no importa demasiado en la mayoría de casos, y que un cambio que tenga consecuencias significativas tendrá que pasar por ser algo que ya antes tenga un uso amplio. Por ejemplo, imaginemos que el uso de TypeScript creciera pero mucho. Si entonces decidieran (y pudieran llevarlo a cabo) hacer que TypeScript compilara directamente a WASM, algo así sí que podría tener consecuencias más notables.

A día de hoy, sin embargo, creo que la mayoría de lenguajes que ya habitualmente compilan a JavaScript, seguirán haciéndolo. Más que nada porque viven en ese ecosistema y les conviene más seguir aprovechándolo que tener que implementar un montón de cosas “de cero”. Otra cosa diferente es que, en ciertas áreas específicas -p.ej. juegos-, sí que pueda merecer la pena, pero esto está más relacionado con otro tipo de lenguajes y situaciones, y compite de modo mucho más concreto contra la herencia de plug-ins o entornos “cerrados” como ActiveX, Flash, Applets Java, Silverlight, PNaCl, Unity u otros plugins específicos (estoy pensando en el primer Quake Live, por ejemplo).

En cualquier caso, prefiero no especular demasiado con estas cosas.