JavaScript en la Gran Pantalla: Creando Apps de TV

♪ Hola a todos. Gracias por unirse a esta sesión. Estoy muy emocionado de hablar sobre JavaScript en las pantallas grandes y cómo puedes crear aplicaciones de TV usando JavaScript. Estoy muy emocionado de estar aquí contigo en JS Nation este año.

Un poco sobre mí. Mi nombre es Mo. Encabezo el equipo móvil en el Reino Unido de Theodore y Bam. Theodore Group es un grupo de alrededor de 700 expertos digitales, y Bam es el equipo especialista en móviles dentro de eso. Hemos estado en el espacio móvil desde aproximadamente 2015 y somos adoptantes tempranos de React Native, y también hemos estado usando React durante mucho tiempo. He estado muy involucrado en el ecosistema de JavaScript durante bastante tiempo y estoy emocionado de hablar y compartir algunos de nuestros aprendizajes contigo hoy.

JavaScript está en todas partes. Así que comenzó desde la web, y encontré esta imagen muy genial de un libro hablando sobre Netscape JavaScript en la versión 1.2. Creo que este libro es de finales de los 90. Hoy en día, más del 99% de las páginas web utilizan JavaScript. Está en todas partes. No puedes construir una aplicación web sin JavaScript. Y cada vez más frameworks de JavaScript han surgido a lo largo de los años y se están utilizando en el mundo real, y estamos muy familiarizados con ellos. Por otro lado, JavaScript ha encontrado su camino en el mundo del desarrollo móvil. Esta es una cita a la que siempre sigo refiriéndome, que es de Steve Jobs en 2007 cuando anuncia el iPhone 3G, donde expone la visión básicamente para las PWAs. Es realmente interesante ver que siempre hay esta idea de que JavaScript se puede utilizar para construir aplicaciones realmente buenas en teléfonos móviles. Y esa visión avanzó a pesar de la adopción de aplicaciones nativas a través de herramientas como Cordova, más tarde Ionic sobre eso, y React Native, que te permite crear aplicaciones nativas utilizando JavaScript. Por lo tanto, JavaScript se ha convertido en una parte integral del ecosistema móvil también. ¿Y incluso en el backend, verdad? Hemos estado viendo cada vez más entornos de ejecución en el backend o entornos de ejecución del lado del servidor de JavaScript. Por lo tanto, JavaScript se puede utilizar de manera efectiva en toda la pila.

Pero, ya sabes, mientras estás en casa navegando en tu teléfono, mirando a través de tu computadora portátil, y todas estas experiencias de JavaScript, hay una experiencia más que está en segundo plano y también está impulsada por JavaScript. Y esa es la TV. Y te sorprendería entender cuánto del ecosistema de la TV está siendo impulsado por JavaScript.

Así que hagamos un breve aparte, y luego quiero volver a entender dónde encaja JavaScript con la TV. Pero para establecer algunos de los requisitos previos y los fundamentos de esta charla, solo quiero cubrir rápidamente cuáles son algunos de los componentes principales de una aplicación de TV. Entonces, si miramos una pantalla en blanco, tenemos... En cualquier aplicación de TV, tenemos una navegación de nivel superior, y luego tienes una cuadrícula o un conjunto de carruseles. Y el factor clave aquí es que las TVs se interactúan principalmente con un control remoto, efectivamente. Así que volvamos a hablar de JavaScript ahora. Si observas el panorama de los sistemas operativos de TV, verás que en realidad está increíblemente fragmentado, mucho más allá de lo que ves en las aplicaciones móviles. Y en cuanto a los navegadores web, los navegadores web suelen estar muy igualados en cuanto a funciones y están dominados en gran medida por Chromium en estos días. Mientras que en el espacio de la TV, tienes tantos sistemas operativos diferentes, cada uno con una gran cuota de mercado. Android TV representa aproximadamente el 41% de la cuota de mercado. Pero también está Tizen, que es el sistema operativo de TV de Samsung. Está WebOS, que es de LG. Tienes el Fire OS, que es de Amazon, y luego otros como Roku, TV OS y muchos otros. Así que hay tantos sistemas operativos diferentes para las TVs, y realmente no puedes apuntar a uno solo. Realmente necesitas apuntar a casi todos ellos para tener una fuerte presencia en los medios. Y cuando agrupas todos estos, hay aproximadamente un grupo de sistemas operativos de TV que son nativos, y hay sistemas operativos de TV basados en web. Así que echemos un vistazo y veamos cómo JavaScript encaja con cada uno de ellos. Ahora, la web es bastante autoexplicativa, ¿verdad? Los sistemas operativos basados en web pueden ser objetivo de cualquier aplicación JavaScript.

Ejecutan aplicaciones basadas en HTML y JavaScript. Por lo tanto, es muy común que las aplicaciones de TV utilicen React. Es un framework popular al final del día. Pero la gente también ha comenzado a usar Preact bastante ampliamente. Conozco muchas aplicaciones de TV que utilizan Preact en la actualidad debido a su menor peso y su menor impacto en el rendimiento de la aplicación.

De manera similar, Solid. Y curiosamente, en realidad hay un framework especializado en TV, del cual hablaré con más detalle más adelante, llamado Lightning.js. Y Lightning.js utiliza Solid para definir la interfaz de usuario de tu aplicación. Por lo tanto, hay mucho uso y también se centra en la optimización. Solid y Preact también entran en la historia, lo cual es bastante interesante de ver. También ha habido proyectos de código abierto en el espacio de TV basado en la web.

Específicamente, la BBC es en realidad un gran defensor de la creación de aplicaciones de TV basadas en la web. Hace varios años, anunciaron el proyecto de código abierto Tal, que es una capa de aplicación de TV. El objetivo de Tal era crear muchas utilidades y componentes que se pudieran utilizar para construir eficientemente aplicaciones de TV que fueran de alto rendimiento y también pudieran dirigirse a una amplia gama de TVs diferentes. Desde entonces, se ha dejado de usar y ahora se han centrado en proyectos de código abierto más pequeños y modularizados. Solo para nombrar algunos, uno de ellos es el Proyecto Espacial LRED, que es una biblioteca de navegación para TVs, de la cual hablaremos un poco más adelante. Pero también han abierto el código de algunos fundamentos básicos para crear reproductores en HTML5 y JavaScript que también pueden ejecutarse en TVs.

Ahora, si nos alejamos de las personas basadas en la web y nos enfocamos en las personas nativas, es un poco más complicado. Si observamos los cuatro principales sistemas operativos nativos, tvOS de Apple utiliza Swift. Debes construirlo como lo harías con una aplicación de iOS. Android TV y Fire TV utilizan Kotlin, y la razón de esto es que Fire TV es en realidad solo una abstracción sobre Android TV. Utiliza el proyecto de código abierto de Android para crear una versión personalizada de Android que se ejecuta en dispositivos Fire TV y dispositivos Fire. Por lo tanto, debes dirigirte a ellos con aplicaciones basadas en Kotlin o Java. Y Roku utiliza BrightScript, que es un lenguaje propietario y bastante limitado, específicamente para crear aplicaciones basadas en Roku. Por lo tanto, si eliminamos a Roku de la imagen, porque Roku es un entorno muy cerrado y no se puede dirigir realmente con otras tecnologías, cuando observamos tvOS, Android TV y Fire TV, lo que encontramos es que debes conocer Swift y Kotlin como lo harías en el espacio de desarrollo móvil. Naturalmente, las personas han intentado abordar esto con React Native. Y si has estado en el espacio, conocerás React Native tvOS. Esto solía ser una parte fundamental de React Native en sí. React Native agregó soporte para Apple TV en los primeros días, efectivamente.

Y eventualmente, esto se migró a su propia bifurcación, que se mantiene muy sincronizada con el repositorio principal de React Native. Y así, React Native tvOS te permite dirigirte a TVs tanto para Android, tvOS y Fire TV. Esta es el proyecto de código abierto que básicamente alimenta a React Native en TV. Y lo genial de React Native en TV es que básicamente puede crear esta visión de la aplicación de TV universal. Puede dirigirse a tvOS. Puede dirigirse a Android TV y Fire TV, pero también utilizando React Native para Web, puede dirigirse a Tizen, WebOS, y cualquier otra plataforma que entre en esa categoría. Por lo tanto, de manera integral, cuando miras esta imagen, lo que puedes ver es que, excepto Roku, se puede construir para cualquier otra plataforma utilizando JavaScript, y puedes utilizar JavaScript para dirigirte a ellas.

La gran mayoría del mercado de TV, JavaScript puede ser dirigido. Ahora, al construir aplicaciones de TV, hay muchas consideraciones diferentes, pero dos de las principales que quiero analizar hoy son las interacciones del usuario y la gestión del enfoque, y en segundo lugar, el rendimiento.

Comencemos con las interacciones del usuario y la gestión del enfoque. Dado que la mayoría de las personas aquí son desarrolladores web y desarrolladores móviles, cuando estás construyendo algo para la web, digamos que tenemos algún tipo de elemento interactivo. Naturalmente, en la web, las personas interactúan con el cursor. Tendrás cosas como estados de hover. Así es como se muestran las interacciones en la web, y estados de enfoque, y así sucesivamente. En el lado móvil, todo se basa en el tacto. Sin embargo, en la TV, es un poco diferente. Tienes tu control remoto y las interacciones se realizan utilizando lo que llamamos el D-pad, que son las flechas izquierda, derecha, arriba y abajo. Entonces, efectivamente, cuando haces clic en un botón específico, luego pone las cosas en foco, y luego necesitarás seleccionar ese elemento para interactuar con él. Por lo tanto, la funcionalidad y las interacciones son mucho más limitadas en comparación con la web y los dispositivos móviles. Por lo tanto, la forma en que diseñas tu interfaz de usuario debe adaptarse a eso. Y la gestión del enfoque en la TV o la navegación espacial en la TV no es un problema trivial.

Y solo voy a pasar por dos ejemplos muy básicos para mostrar esto. En primer lugar, digamos que tienes un elemento seleccionado, el que está en el lado izquierdo de la pantalla en este momento, y el usuario hace clic en el botón derecho. Lo que haces efectivamente es calcular qué elemento está a la derecha de él con la distancia más baja o más pequeña. Y en este caso, hay tres elementos equidistantes a la derecha del elemento existente, pero ¿cuál es el correcto para navegar? Esta es una decisión que deberás tomar en tu implementación y no hay una respuesta correcta para casos como este. Veamos otro ejemplo. Digamos que tienes una cuadrícula. Este es un problema mucho más común que puedes enfrentar con la gestión del enfoque. Si el usuario hace clic en la flecha hacia abajo, ¿a qué dirección vas o en qué elemento te enfocas a continuación? ¿Te enfocas en el elemento directamente debajo del elemento actualmente enfocado o vas hasta el principio de la lista para la siguiente fila? Estos son algunos de estos casos límite que son muy comunes y que deben tenerse en cuenta cuando se trata de la gestión del enfoque. Por lo tanto, efectivamente, hay dos divisiones dentro del espacio. Algunas personas optan por un enfoque basado en coordenadas y la idea principal de esto es que todo se basa en distancias, por lo que hay una definición implícita de cómo debe comportarse la gestión del enfoque en la pantalla y cómo se disponen los elementos afecta qué elementos se seleccionarán cuando hagas clic en cualquiera de los botones para izquierda, derecha, arriba o abajo. Y luego está el enfoque declarativo. Un enfoque basado en coordenadas es implícito. Se basa en distancias. Con un enfoque declarativo, tienes una definición más explícita para esto.

Entonces, defines, basado en tu code, puedes definir y decir dónde se diseñarán las cosas con, y pueden ser completamente diferentes de cómo se representan visualmente las cosas. Eso no suele ser lo habitual, y no debería serlo, pero tienes un control más explícito y detallado sobre cómo defines los elementos que se están diseñando en la pantalla y cómo se supone que los comportamientos afectan la navegación en la pantalla.

Entonces, nuestro equipo en BAM ha pasado mucho tiempo construyendo aplicaciones de TV basadas en React, ya sea en React o React Native, y hemos abierto el código de una biblioteca de navegación espacial que tiene como objetivo simplificar todo el enfoque declarativo. Puedes escanear el código QR para verlo en GitHub, pero solo quiero mostrarte un ejemplo rápido de cómo funcionaría el enfoque declarativo.

El primer paso sería configurar el control remoto porque cada control remoto será diferente. Los controles remotos basados en web serán diferentes a los de Android TV en comparación con el control remoto de tvOS. Entonces, defines un suscriptor de control remoto que asigna las flechas a un cierto evento que puede ser despachado por la capa nativa, o en el caso de los basados en web, un escuchador de eventos de ventana para el evento keydown, y lo emparejas con un desuscriptor para cuando la biblioteca ya no se esté utilizando y la aplicación se ponga en segundo plano.

Y envuelves toda la pantalla de tu aplicación en una ruta de navegación espacial. Luego envuelves cada elemento dentro de un nodo de navegación espacial, para decir que este es un elemento del cual la navegación espacial debe ser consciente. Y luego, para aquellos que realmente deseas que el usuario pueda interactuar, enfocar y seleccionar, defines una propiedad isFocusable, y luego puedes darle estilo dependiendo de si ese elemento está enfocado específicamente. Ahora, este es un ejemplo muy simple con dos elementos en la pantalla que se renderizarán de arriba a abajo, y efectivamente serán enfocables con el D-pad y ese efecto, pero hay muchas propiedades adicionales que se introducen en esto y más componentes que puedes revisar en el repositorio de GitHub real.

Entonces, hemos analizado la interacción del usuario y la gestión del enfoque. El siguiente gran problema cuando estás construyendo aplicaciones de TV está relacionado con el rendimiento. Así que retrocedamos un poco. Hoy en día, hay una abundancia de recursos cuando se trata de los dispositivos que usas a diario. Si tomamos un MacBook Pro M3 Max, que muchos desarrolladores tendrán, las puntuaciones Geekbench son simplemente increíbles. Tienes 3,000 para una puntuación de un solo núcleo de la CPU y cerca de 21,000 para la puntuación multinúcleo. Mantén esos números en mente porque los compararemos a medida que avancemos. Pero el M3 Max tendrá varios núcleos. Creo que son 16 núcleos en el procesador y cuatro gigahertzios por núcleo, y la memoria también es de alrededor de 64 gigabytes. Echa un vistazo a los teléfonos móviles. El iPhone 15 Pro tendrá una puntuación Geekbench de alrededor de 7,300, más o menos, para la puntuación multinúcleo. Tiene una CPU de seis núcleos. Tiene 3.78 gigahertzios por CPU, por núcleo de esa CPU, como frecuencia, y tiene ocho gigabytes de RAM. Estos son los dispositivos para los que normalmente construyes cuando desarrollas para web y móvil.

Ahora, si miramos las TVs, por otro lado, hay una caída astronómica en términos de las puntuaciones. Esta es una TV basada en Android. Tampoco es una TV de gama baja en términos de las especificaciones que se incluyen en el hardware, pero obtiene una puntuación de un solo núcleo de 225 y una puntuación multinúcleo de 460. Tiene un procesador de cuatro núcleos con una frecuencia base muy baja, y la memoria es de apenas cuatro gigabytes. Y esto no es una anomalía. Esto probablemente está en el rango más alto, y si lo comparas con algunos teléfonos, estarás viendo el OnePlus 2, que era un teléfono Android de gama baja de 2015, hace casi 10 años, y obtiene resultados de Geekbench casi idénticos. Esta es la escala con la que estás trabajando cuando desarrollas aplicaciones de TV, y este es el nivel de optimizaciones de rendimiento que necesitarás hacer, como si lo estuvieras ejecutando en un dispositivo Android de gama baja de mediados de la década de 2010. Esto no es anormal.

Nuevamente, solo para darte otro ejemplo, el Fire TV Stick tiene un rendimiento muy similar. Tiene una CPU ligeramente mejorada, pero una menor cantidad de RAM integrada. Entonces, efectivamente, es un conjunto de rendimiento muy estándar, y en realidad, estos son dispositivos de gama alta. En el pasado, hemos apuntado a cajas de configuración, que son las cajas que vienen con tu proveedor de Internet o tus proveedores de servicios de Internet, y esos dispositivos pueden ser mucho peores que lo que acabamos de ver. Tuvimos que optimizar para un dispositivo que tenía solo alrededor de 200 megabytes de RAM, y eso fue una tarea realmente difícil para asegurarnos de que el uso de memoria siempre se mantuviera bajo control. Nuestro equipo dio una charla este año sobre cómo mejorar el rendimiento de la memoria, especialmente cuando se trataba de TVs Android nativas que funcionaban con muy poca memoria. Recomiendo encarecidamente ver ese video también, y el código QR está ahí. Entonces, el rendimiento se convierte en la principal prioridad, y si ves lo que han hecho otras personas, Netflix decidió en realidad...

Ellos usan React para su TV, pero han decidido no usar React DOM y en su lugar crear su propio renderizador basado en WebGL llamado React Gibbon. Desafortunadamente, no lo han hecho de código abierto, pero la idea principal es aprovechar los gráficos acelerados por hardware en estas smart TVs para obtener un mejor rendimiento y no depender de la implementación del DOM. Algunas personas en la comunidad prefieren este enfoque, como Lightning.js, que utiliza Canvas y está basado en WebGL. Otro proyecto de código abierto similar es React Ape, que también es una implementación basada en WebGL y Canvas para aplicaciones basadas en React que se dirigen a TV u otros dispositivos de gama baja.

El problema con ambos enfoques es que, en el caso de Lightning.js, tiene muy poco soporte de la comunidad. Tiene una comunidad muy pequeña, especialmente en comparación con el mundo de React. Tiene alrededor de 50 estrellas en su repositorio más popular, lo cual es equivalente a un proyecto de fin de semana en el ecosistema de React que no se mantiene activamente. Por otro lado, React Ape no ha sido mantenido durante aproximadamente dos años, por lo que estos enfoques son menos populares. La mayoría de las personas optarán por seguir utilizando el DOM y las vistas nativas cuando se trata de estas plataformas nativas.

En la práctica, esto significa que cuando estás utilizando el DOM, necesitarás memoizar intensamente para minimizar las renderizaciones repetidas. Necesitarás crear variantes más simples de los componentes existentes en la comunidad. No será tan simple como tomar algunos componentes que funcionan en la web y usarlos en las TVs. Deberás asegurarte de que todo lo que uses esté hiper-optimizado y no consuma más recursos de los que puedes permitirte usar. Muchas veces, los componentes de código abierto lanzados por la comunidad están optimizados para interacciones de cursor y toque, que son relevantes para la web y los dispositivos móviles, pero no son necesarios para las TVs. El rendimiento es la prioridad número uno. A menudo es mejor construirlo tú mismo con un uso mucho menor de la CPU o menos pérdida de rendimiento al usar soluciones preconstruidas. Otra cosa importante es evitar cálculos pesados en la pintura, especialmente en el diseño. Por último, en las TVs y aplicaciones de TV, se utiliza mucha virtualización y reciclaje para minimizar el número de componentes que se renderizan en la pantalla. Te daré un ejemplo.

En el espacio de React Native, en los dispositivos móviles, la gente a menudo se queja de FlatList. FlatList es la implementación de lista predeterminada en React Native y es conocida por ser lenta. La gente se ha quejado de esto durante años y Shopify incluso lanzó su propia versión llamada FlashList de un componente de lista para asegurarse de que las listas sean fluidas y tengan un buen rendimiento en las aplicaciones de React Native. Naturalmente, este componente FlatList también existe en las TVs y algunas personas intentan usarlo, pero no es una buena idea. FlatList está virtualizada, pero no tiene un mecanismo de reciclaje interno. Por lo tanto, una de las cosas importantes es poder reciclar tantos elementos como sea posible. Cuando tienes un carrusel, no quieres montar y desmontar componentes a medida que el usuario se desplaza por el carrusel, ya que eso es una operación computacionalmente costosa. En su lugar, utilizas los mismos componentes y a medida que el usuario recorre la lista, tomas componentes desde el principio de la lista y los mueves al final de la lista y actualizas los datos que se muestran. De esta manera, siempre tienes un cierto número de elementos que se renderizan y solo cambias lo que se muestra para cada uno de ellos y ajustas su posición de manera efectiva.

Y de esta manera, no tienes que lidiar con las llamadas computacionalmente costosas de montar y desmontar componentes y volver a renderizar toda la lista como resultado. Cuando realizamos algunas pruebas de referencia y comparamos la lista plana, la lista flash y la lista virtualizada espacial que hemos creado internamente como parte de la biblioteca de navegación espacial de React TV, descubrimos que supera a ambas. Este aumento es increíblemente importante para las aplicaciones basadas en TV. Cuando observas aquí, tiene un rendimiento un 41% mejor en términos de uso promedio de la CPU en comparación con la opción de lista plana que viene por defecto en React Native. Por lo tanto, la virtualización intensiva y el reciclaje son muy importantes cuando se trata de aplicaciones de TV. Escribí un poco más detalladamente sobre por qué la lista plana no es una buena opción para las TVs en este artículo de blog que publiqué hace un tiempo, y esto está alojado en el blog de React Native TV que hemos iniciado con algunas otras personas, algunas personas de BAM y algunas personas del equipo de la tienda de aplicaciones de Amazon. Recomiendo encarecidamente que le eches un vistazo y encontrarás algunos buenos recursos sobre cómo construir aplicaciones de TV con React Native. Así que hagamos un breve resumen. Nos estamos quedando sin tiempo. Existe una fragmentación masiva en el espacio de TV. La buena noticia es que puedes apuntar a la mayoría de las TVs con JavaScript. Y cuando haces eso, debes recordar que las interacciones del usuario son fundamentalmente diferentes en la TV en comparación con la web y los dispositivos móviles, y hay enfoques diferentes que puedes tomar para manejar la gestión del enfoque y la navegación espacial, a saber, el enfoque cartesiano o el enfoque declarativo. Y luego, lo último que realmente debes tener en cuenta es posiblemente el punto más importante al construir para las TVs, y es que el rendimiento en las TVs es absolutamente terrible. Por lo tanto, hacer buenas aplicaciones de TV es un verdadero desafío y estarás luchando por cada bit de CPU y cada bit de RAM que puedas obtener. Pero también es una gran experiencia de aprendizaje y es un buen desafío. Aprendes mucho a través de ese proceso y definitivamente recomendaría que lo intentes. Muchas gracias por quedarte con la charla y si estás interesado en hablar más sobre aplicaciones de TV o tienes alguna pregunta, no dudes en agregarme en LinkedIn o en Twitter y estaré encantado de responder cualquier pregunta de forma remota.