Cuando se publique WebAssembly, ¿afectará el marco front-end? Si es así, ¿qué marco / biblioteca se beneficiará de él?

Todos ellos. Y ninguno de ellos.

Todos los marcos se beneficiarán indirectamente. Serán posibles nuevas herramientas, herramientas que ampliarán lo que puede hacer y ver en la web.

Los motores JavaScript actuales del navegador se han vuelto bastante rápidos, pero aún no se acercan al código compilado en velocidad. Las transformaciones de imagen basadas en el navegador, el cifrado y los componentes de simulación en tiempo real serán posibles, o debo decir que es posible incluso en navegadores móviles donde hoy tales intentos fallan.

Además de las optimizaciones que vienen con WebAssembly pero que se aplican al código JavaScript, ningún marco JavaScript actual se beneficiará, porque una gran parte del objetivo de WebAssembly es ser un objetivo de compilación para lenguajes que no son JavaScript.

¿Se desarrollarán nuevos marcos? Ciertamente. Pero, ¿qué lenguaje compilado reemplazaría a JavaScript?

Mi mejor intuición sería Go, pero con un mejor sistema de plantillas que el predeterminado.

Y, sinceramente, para los marcos de contenido, es difícil superar la flexibilidad de un lenguaje dinámico. Prefiero mi JavaScript con tipos estáticos, ya que soy fácilmente dos veces más productivo con TypeScript, pero el aumento de las restricciones de la mayoría de los lenguajes compilados sería un obstáculo suficiente para la productividad que no valdría la pena el aumento del rendimiento en tiempo de ejecución.

El texto realmente solo necesita ser renderizado tan rápido, después de todo. 1/5 de segundo está bien y 1/20 de segundo es excelente para dibujar una página estática. Necesita animarse a 60 FPS, pero una página bien diseñada no volverá a reproducir el texto en todos los cuadros de animación de todos modos.

WebAssembly es un excelente camino para hacer cosas completamente nuevas en el navegador. Sin embargo, predigo que no reemplazará JavaScript / TypeScript para el 80% de los usos comunes.