WebAssembly en producción y el "campo minado" de Smart TV: una entrevista con Andrei Nagih

El interés en WebAssembly es grande, pero hasta ahora rara vez se encontrará con personas que utilicen esta tecnología en un proyecto de trabajo. El desarrollo de aplicaciones para Smart TV también es "JavaScript atípico", cuando todos se enteraron de algo, pero pocos lo intentaron personalmente.

Y Andrei andreynagih Nagih tiene experiencia en ambas áreas: anteriormente trabajó en aplicaciones de Smart TV del proyecto Peers.TV, y en los últimos meses se ha familiarizado tanto con WebAssembly que finalmente hizo un informe sobre esto en nuestra conferencia HolyJS. Y en la transmisión en línea de HolyJS, le preguntamos sobre ambos.

Y ahora decidieron que también podría ser interesante para los lectores de Habr, e hicieron una versión de texto editada de la entrevista.

(Si alguien se siente más cómodo con el formato de video, en lugar de leer la publicación, puede ver el video original ).

Evgeny phillennium Trifonov: Hiciste una presentación aquí sobre WebAssembly. ¿Hubo muchas preguntas de la audiencia, y fueron de "teóricamente interesado", o ya te encontraste prácticamente usando?

Andrei Nagikh: Después del informe, respondí preguntas completamente diferentes en el área de discusión durante una hora, me sorprende que haya tantos en el espectro. Básicamente, las preguntas fueron de aquellos que son "simplemente curiosos", pero había personas que ya lo estaban usando. Lo que es sorprendente, porque esas personas son pocas. Había preguntas bastante prácticas.

Eugene: Anteriormente, solían decir sobre WebAssembly "tan pronto como haya madurado y se haya convertido en aplicable". Y ahora la tecnología es qué tan "madura"?

Andrey: La tecnología en sí misma ya está funcionando bastante, puede usarse en la producción. Lo estamos usando Pero el problema es con las herramientas. El compilador en sí es bastante bueno, ya que resultó ser más antiguo que la tecnología en sí, está disponible en la versión anterior, con asm.js. Pero las herramientas de depuración, los mapas de origen, el depurador, esto sigue siendo difícil. Creo que en el próximo año o dos navegadores sacarán estos puntos.

Eugene: Y debido a lo que inicialmente necesitaba WebAssembly: ¿qué tipo de proyecto y cuál es el beneficio de esto?

Andrew: Uno de nuestros proyectos, ByteFog es una tecnología para la entrega de contenido de video P2P. Probablemente tengamos el caso de usuario más ideal que se le ocurra para WebAssembly. Ya teníamos una gran base de código en C ++, no queríamos reescribirlo en otro idioma, y ​​lo necesitábamos en el navegador. Por lo tanto, esta tecnología parece encajar cien por ciento aquí.

Al principio pensamos que lo tomaríamos, simplemente lo compilaríamos y funcionaría. Pero, por supuesto, esto no sucede en la vida, por eso nació este informe sobre el rastrillo y, de hecho, sobre cómo arrastrarlo todo a la producción.

Oleg olegchir Chirukhin: ¿Y cuáles son los principales problemas que surgieron?

Andrew: El principal problema es que no tenemos acceso al sistema. Teníamos una aplicación nativa, podía hacer cualquier cosa. Cuando lo trasladamos al navegador, no podemos hacer nada más que JavaScript. Y necesita vivir de alguna manera con él, necesita usar las API del navegador.

El proceso de portabilidad de nuestra aplicación tomó, condicionalmente, ocho meses. Es cierto que durante este período realizamos una buena refactorización de nuestra base de código, que, en general, es buena. Y ahora podemos portarlo a otro lado.

Oleg: Tulling ya se ha mencionado, pero ¿es posible con más detalle? Depuración, rastreo, creación de perfiles, eso es todo.

Andrew: En resumen, todo está mal. Pero hay pequeños destellos de cosas buenas.

Bueno, el compilador se ha establecido más o menos: es Emscripten (estoy hablando de C ++, en otros tiempos de ejecución - Rust, Go, Kotlin / Native - de una manera diferente).

Depuración: Firefox admite mapas de origen, lo que en sí mismo no es malo. Google Chrome solo le permite ver el código del ensamblador, puede poner puntos de interrupción allí, pero esto es así.

El generador de perfiles funciona mejor en Firefox, en Chrome un poco peor. La diferencia es que Firefox desenrolla los nombres, es decir, los convierte en lo que son en el código fuente. Chrome muestra nombres destrozados, y debes entrecerrar los ojos para entender de qué se trata.

Oleg: ¿Cómo se adapta la gente de JavaScript a C ++ y viceversa?

Andrey: Probablemente, puedes mirarme aquí, inicialmente el front-end, que ahora tocó el código nativo. Pero, para ser honesto, incluso antes del proyecto tenía el deseo de intentar orinar algo de forma nativa. Así que probablemente no soy muy representativo.

Hablamos mucho con mi colega Yura, quien habla en el proyecto en el lado de C ++: me contó sobre las "ventajas", le conté sobre JavaScript. Y estaba interesado en JavaScript. Coincidencia: diez de cada diez: nativo quiere que JavaScript aprenda cuando era? Y tenemos un buen equipo.

Todavía hay una tercera persona: este es Kolya, un arquitecto que generalmente miró el código del ensamblador y dijo: “Chicos, de todos modos se puede depurar. Bueno, mira, todo está claro: esta es una máquina apilada, aquí trabajamos con memoria, aquí aritmética ... muchachos, ¿por qué necesitamos mapas fuente? Bueno, él sabe escribir para sistemas embebidos, en su tiempo libre lo hace.

Oleg: ¿Y tuvo alguna sorpresa especial de C ++: del lenguaje, de la usabilidad, de trabajar con él?

Andrei: Bueno, por supuesto, estaba listo para esto. La sorpresa más importante es que después de hablar con las ventajas durante el proyecto, nos dimos cuenta de que JS y C ++ tienen mucho en común. Parece que los idiomas son completamente diferentes, pero puedes encontrar los puntos de intersección. Incluso puede hacer un informe por separado sobre este tema, tendrá que pensarlo.

Eugene: Y ahora, después de uno y otro, ¿en qué quieres escribir?

Andrew: En realidad, no estoy listo para escribir en producción en C ++. Haría algo al respecto por mí mismo. Pero JavaScript, ¿a dónde va?

Oleg: ¿Y qué pasa con el hecho de que C ++ es rápido y con un montón de características interesantes como plantillas? ¿Podrían las plantillas ayudar al front end al escribir algún código súper estándar?

Andrei: Hay una broma: "si tienes un problema y quieres resolverlo con una expresión regular, felicidades, ahora tienes dos problemas". Tengo la sensación de que algo es similar con las plantillas. En nuestro proyecto, tratamos de no usar plantillas, el arquitecto es muy resistente cuando los desarrolladores de C ++ intentan implementar algo allí. El problema surge con la depuración: nunca está claro dónde salió mal exactamente.

Oleg: Es decir, ¿no está claro qué sucede en el código que se generó? ¿No puede construir el mapa fuente a la fuente?

Andrew: Hasta donde yo sé, incluso en C ++ nativo con plantillas, la depuración es difícil. Cuando lo arrastremos bajo WebAssembly, tendremos problemas con la depuración bajo WebAssembly. Por lo tanto, creo que será un infierno por completo. (mira atentamente a la cámara) ¡ Niños, no utilicen plantillas C ++!

Oleg: Sin plantillas, se convertirá en C. Será posible escribir en C. puro

Andrew: ¿Pero qué hay de los objetos?

Oleg: Bueno ... "C con clases", sí. Solo creo que escribir código en C con clases y en C ++ idiomático con plantillas son dos métodos completamente diferentes.

Andrew: Sí, es posible.

Oleg: La pregunta filosófica: ¿no crees que cuando se agrega WebAssembly a los navegadores, se abre un portal al infierno?

Andrew: Parece que sí. Porque ahora, probablemente, estará de moda tomar cualquiera de las bibliotecas o programas C ++ que se hayan escrito para toda la existencia de C ++, intente compilarlo en el navegador y ver qué sucede. Hoy mostré una demostración de Windows 2000 en el navegador.

Oleg: Quiero decir, ¿esto es solo un Windows 2000 completo?

Andrew: Sí, este es el mismo Windows 2000, que era hace 18 años y que necesitaba una computadora completa para funcionar, y ahora Chrome lo necesita.

Oleg: ¿Y qué hay de las cosas que requieren el modo kernel, eso es todo?

Andrew: Ella se ejecuta en el emulador QEMU y portado personalmente por WebAssembly por Fabrice Bellar (autor de QEMU). Allí, por supuesto, no puede acceder al sistema de archivos, a la red. Pero esto es Windows 2000, se inicia, se dispersa y todo está ahí. Puedes ver

Oleg: Pasemos al tema de las aplicaciones para Smart TV. Por cierto, ¿puedes hacer algo interesante con WebAssembly allí?

Andrew: Sería posible si fuera compatible allí. ¿Cuál es el problema con Smart TV? Este desarrollo es como el desarrollo de la interfaz hace diez años, porque los televisores inteligentes no se actualizan. Un hombre compró un televisor, lo colgó en la pared y lo cuelga allí durante años.

Oleg: Pero constantemente tengo "espera, el firmware se está cargando". Ya enfurece.

Andrei: El firmware puede estar cargando, pero, que yo sepa, no actualiza directamente el sistema, el navegador. Como resultado, todavía admitimos televisores de hace muchos años, en los que el navegador aparece como Chrome 5.

Oleg: Ni siquiera recuerdo eso.

Andrew: Yo tampoco me acuerdo. El desarrollo para Smart TV, especialmente los antiguos, es un campo minado, similar al front-end de la guerra del navegador.

Oleg: ¿Entonces tuviste que hacer un diseño super-cross-browser, que funcionará tanto en versiones antiguas como nuevas?

Andrew: si. Allí, de hecho, el problema no es tanto con el diseño como con JavaScript: incompatibilidad por API, ahora no mencionaré todo.

Oleg: ¿Y qué más de los disponibles en los navegadores quieres usar en Smart TV, pero no?

Andrew: Un millón de cosas, comenzando con flexiones (ni siquiera es JavaScript) y terminando con WebRTC. ByteFog usa WebRTC. Sería genial si sacamos el código que ya tenemos en Smart TV ...

Eugene: Y además del problema mencionado, desarrollo para Smart TV, ¿cómo es? ¿Cuáles fueron las sensaciones?

Andrew: A veces parecía que a los desarrolladores de los navegadores de Smart TV no les gustaban los programadores que desarrollaron aplicaciones para Smart TV, porque las herramientas de depuración eran muy pobres, prácticamente no había ninguna. Esto no se aplica a las plataformas modernas de Tizen y webOS, les fue mejor allí. Pero hice esto antes, luego había plataformas viejas, y todo estaba mal allí. La mejor herramienta de depuración fue weinre , que no es realmente un depurador: no puede detener JavaScript allí; Este es el tipo de puerto Chrome DevTools que se ejecuta en sockets web. En general, era posible depurar el diseño, pero con JavaScript era prácticamente imposible hacer nada. De alguna manera vivimos.

Oleg: ¿Pero por qué depurar en Smart TV, si puedes ejecutarlo en un navegador?

Andrew: En el navegador, tenemos JavaScript y hay una API que nos proporciona el navegador. Estas son dos cosas diferentes. Del mismo modo, en el televisor tenemos JavaScript, tenemos la API del motor del navegador ...

Oleg: Lo más probable es que este sea WebKit.

Andrew: Sí, como regla. Y hay otra categoría de API: las que ofrece la plataforma de este televisor. En primer lugar, este es un reproductor, luego otras características: control remoto, etc. Estas API no estarán en el navegador.

Hay emuladores, los fabricantes realmente los proporcionan, pero no coinciden completamente con el hardware. Por lo tanto, no es un hecho que la depuración en un emulador funcione en un televisor. Y viceversa: puede que no funcione en el emulador, pero funcionará perfectamente en el televisor. Entonces, al final, llegamos a la conclusión de que no usamos emuladores, sino que intentamos depurar en hardware real. Resulta más rápido: no pierdes el tiempo en errores que no están allí.

Oleg: ¿Y con cuántas plataformas tuvo que lidiar, y con el tiempo se hicieron más pequeñas o más grandes?

Andrei: Cuando participé en Smart TV, hubo una transición de los fabricantes de los sistemas operativos antiguos, que se llamaban condicionalmente Linux y cada uno tenía su propia salsa, a algunos nuevos. Luego tuvimos que escribir tres aplicaciones diferentes: para Samsung, LG y Panasonic. Estas aplicaciones, relativamente hablando, copiaron el código. Y luego, casi simultáneamente, sale la noticia de que Samsung está cambiando a Tizen, LG está cambiando a webOS y Panasonic se está cambiando a Firefox OS (después de eso no sobrevivió, y Panasonic ahora se bifurca).

En general, parece que todos están cambiando la plataforma, ¿por qué no converger en una? Sería mucho mejor para todos, especialmente para los desarrolladores: habría más software, los usuarios recibirían más programas útiles. Pero no, todavía escribimos diferentes aplicaciones.

Oleg: ¿Es posible llenar de alguna manera en todas las plataformas?

Andrew: Bueno, al final llegamos a un marco único, sustituimos cosas específicas de la plataforma e intentamos escribir una lógica comercial multiplataforma. Pero parece que esto podría haberse evitado.

Oleg: ¿Y hay televisores con Android?

Andrew: Hay, y dos tipos. ¿Cómo lo hiciste antes? Insertamos un Android normal en el televisor y lo dejamos pasar. Y luego Google creó una rama especial de Android TV, mejor optimizada para el D-Pad, es decir, el control remoto. También hay tales televisores. Pero esta es una historia separada y una tienda separada.

Y si en los dispositivos móviles Android todos ganaron y una variedad de fabricantes se decidió por este sistema operativo, entonces Google no podría hacer esto con los televisores. En lugar de que todo se limite a una plataforma, hay una más, como en la imagen xkcd.



Eugene: Tengo un televisor debajo de mi Android TV con pantalla 4K, pero realmente acepta 4K desde la entrada HDMI, pero el Android incorporado está ahí en 720p. ¿Por qué está pasando esto? Dado que el televisor es económico para los estándares 4K, ¿es probable que el fabricante esté ahorrando en hardware?

Andrei: Sí, creo, aquí descansan contra el hecho de que el sistema operativo no puede representar una imagen 4K en este hardware. De hecho, esta es una situación común cuando Smart TV (es decir, la parte del televisor que proviene de las aplicaciones) no utiliza la resolución de pantalla completa. FullHD se filtró a HD Ready, 4K a FullHD o incluso 720p. Este es un momento tan interesante cuando no podemos mostrar contenido 4K en un televisor 4K, aunque tenemos tanto televisión como contenido.

Los televisores generalmente tienen una interfaz, desafortunadamente, este es el flagelo de las plataformas de Smart TV. Además, en Yandex.Market, no marque "TV que no se ralentizará" ni lo filtre. Al parecer, queda por venir a la tienda y elegir allí.

Oleg: ¿Y cómo afecta esto al desarrollo de aplicaciones? Si agrega muchos divs, ¿la aplicación se vuelve cada vez más lenta?

Andrew: por supuesto. Si necesita renderizar una lista grande, tiene que pervertir y renderizar no todo, sino partes. Podríamos tener doscientos de ellos en la lista de canales, y no podríamos representar la lista completa; luego tenía frenos al desplazarse.

Estoy hablando de la situación hace un par de años. En los televisores que se están lanzando ahora, las cosas podrían ser mucho mejores. Pero, nuevamente, las personas rara vez cambian de TV.

Oleg: ¿Qué piensas, cuál es el futuro de todo lo que vemos ahora en Smart TV?

Andrew: soy pesimista. Espero que mi pronóstico no se haga realidad, pero vimos el declive de la tecnología 3D en los televisores, cuando todos los fabricantes dijeron: "Está bien, nadie compra esto, este no es un factor clave al elegir un dispositivo". Parece que Smart TV puede sufrir este destino, aunque no quisiera.

Oleg: ¿Y cuál es el patrón principal para usar esto si no tienes Smart TV? ¿Tomar una PC grande y gorda y pegarla en el televisor?

Andrew: Una computadora grande, creo que nadie se quedará. Las consolas pueden ser la mejor opción, pero Smart TV y las consolas tienen una cosa en común: el control remoto. Y hacer un buen control remoto es muy difícil. A veces hacen joysticks con un acelerómetro, es decir, implementan control de gestos o emulan un mouse, pero esto tampoco es ideal. En general, el problema con Smart TV radica más en el área UI / UX. En parte, el control por voz puede ayudar al UX del televisor: en Peers.TV, es compatible con el teléfono inteligente del usuario, y ahora estamos trabajando en un control remoto especial con un micrófono.

Eugene: Sí, veo que Google está liderando diligentemente la televisión en la dirección del control por voz. Si bien esto está sucediendo con diferentes éxitos. Pero luego terminamos la conversación así: ¡esperemos que en algún futuro sea suficiente para que nuestros espectadores digan "comience a transmitir HolyJS para mí"!

Si tiene alguna pregunta mientras lee sobre WebAssembly o Smart TV, pregúntele a Andrey en los comentarios.

Y también preste atención a que del 24 al 25 de mayo se realizará el próximo HolyJS en San Petersburgo. Su programa aún no se ha anunciado, pero probablemente también habrá un lugar para un "javascript atípico" que va más allá del front-end habitual, y los boletos se están volviendo gradualmente más caros.