La Década Perdida del Frontend y la Brecha de Desigualdad de Rendimiento

Soy Alex Russell, soy un gerente de producto, lo cual es raro decir. Hago un trabajo de ingeniería, hice un trabajo de ingeniería antes de unirme al equipo de Edge durante 12 años en el equipo de Chrome en Google, y antes de eso pasé una década en TC39, construyendo frameworks y bibliotecas de JavaScript, y cuando me uní al lado de los navegadores del mundo, fui a intentar asegurarme de que el borde final pudiera avanzar para encontrarnos al frente de donde se estaba desarrollando la web. Queremos que las experiencias se hagan con lo mejor porque muchas de las cosas en el ecosistema son difíciles de mover, ¿verdad? Es difícil lograr que las personas cambien sus dispositivos, es difícil lograr que las personas cambien sus sistemas operativos, y en muchos casos, lo más fácil que puedes hacer es lograr que las personas actualicen su software.

Por eso me uní al equipo de Chrome, para construir algo llamado ChromeFrame donde insertamos Chrome como un complemento en IE. ¡No preguntes! Todo eso es para decir que todo ese trabajo desde que cambié de camiseta para trabajar en navegadores ha sido un intento, ya sabes, trabajando en TC39, ayudando a liderar equipos que diseñaron y promesas, y service workers, y clases, y proyecto Fugu, y todo ese tipo de cosas. Todo eso ha sido sobre intentar acercarnos a lo que los desarrolladores nativos esperan que haga una plataforma, no porque haya algún tipo de envidia, sino porque lo que parece ganar para una plataforma es que los usuarios pasen más tiempo usando aplicaciones que están construidas en esa plataforma.

Todos estamos conectados aquí bajo este techo como un ecosistema, incluso si no nos conocemos individualmente. Es el éxito de nuestros compañeros y los productos que están a la izquierda y a la derecha de nosotros lo que nos hace más exitosos o menos capaces de entregar. Para hacer un buen trabajo en eso, tenemos que aplicar los principios de ingeniería, ¿verdad? Tenemos que entender cuáles son las limitaciones a las que vamos a construir, y luego tenemos que construir soluciones a los problemas que la gente nos presenta, y usar lo que sabemos para construir a esas limitaciones. Lo cual es decir que cualquier cosa que puedas ver en una encuesta, un concurso de popularidad efectivamente, es irrelevante para la cuestión de si estás haciendo un buen trabajo como ingeniero, porque la función de aptitud para la ingeniería no es si tu herramienta es popular.

La función de aptitud para la ingeniería es si el resultado funciona bien para los usuarios finales, las personas para las que realmente estás construyendo y diseñando. Bien. Así que, tomemos eso como la estrella del norte. Eso es lo que queremos hacer. Queremos hacer ingeniería. ¿Cómo lo hacemos? Bueno, tenemos que entender nuestros factores limitantes. ¿Cuáles son las cosas que, ya sabes, estamos construyendo debajo? ¿Cuál es el entorno en el que estamos construyendo para resolver los problemas? Porque eso debería determinar, ya sabes, por ejemplo, qué materiales usamos, qué propiedades deberían tener, cuánto de ello podemos permitirnos, ¿verdad? Va a haber un presupuesto. Todas esas cosas son importantes en otros tipos de ingeniería y son igual de importantes en nuestra ingeniería.

¿Cuáles son nuestros factores limitantes y realmente estamos construyendo para ellos? Vamos a averiguarlo. Así que tenemos un par de restricciones. La primera es, por supuesto, la cantidad de rendimiento de gráficos de CPU y rendimiento de almacenamiento que tenemos en cualquier dispositivo específico. Eso es un recurso compartido en la web. Estamos fuertemente aislados. Siempre digo que los desarrolladores web no envían edictos por el cable. Envían esperanzas. Es programación orientada a la influencia. Envías algo desde el centro de datos y tienes mucha suerte si sale del otro lado de alguna de las maneras que esperabas debido a diferentes tiempos de ejecución de navegadores, extensiones, navegadores mediando tu contenido de maneras que no esperas, y la enorme diversidad de dispositivos a los que la web apunta.

No estamos apuntando a un único ecosistema estrecho de un conjunto específico de usuarios. Estamos apuntando a todos los usuarios en la web. Así que el conjunto de todos los usuarios a los que te gustaría dirigirte, las propiedades de sus dispositivos se convierten en un gran problema para nosotros, al igual que las redes a las que se conectan. Eso es una enorme diversidad. Eso no es un objetivo estrecho. Por supuesto, los navegadores que los usuarios utilizan definen el ecosistema de software al que podemos programar. Solo podemos apuntar a las APIs que creemos que están disponibles. Así que estas son las tres cosas que creo que deberíamos tener en mente cuando nos sentamos a intentar resolver un problema para un usuario. Esto es, notarás que no hay nada aquí sobre frameworks, ¿verdad?

Esto trata sobre el hardware y las redes en las que la plataforma está operando. Estas son las verdaderas limitaciones. Nada de lo que prefieres escribir o cómo te gustaría escribir tus corchetes angulares tiene algo que ver con estas propiedades.

Entonces, ¿cómo se ve el fallo? Desafortunadamente, tenemos algunos ejemplos muy contundentes y destacados de ese modo de fallo. Estas son las tasas de aprobación para Coro vitals, el conjunto de histogramas derivados del informe de experiencia de usuario de Google Chrome, que conocerás como interacción hasta la siguiente pintura, pintura de contenido grande y cambio acumulativo de diseño.

Así que solo el 38% de los sitios móviles están aprobando Coro vitals. Esto no es una calificación aprobatoria en ningún curso que haya tomado. Me sorprendería si lo fuera para ti. Es decir, incluso en páginas secundarias donde grandes cantidades de, con suerte, el primer contenido de nivel superior están en caché, porque usas la oportunidad de ir a la página principal para llegar a la segunda página, solo la mitad están aprobando en móviles.

Y el móvil es donde están los usuarios. Reuní algunos de los datos del almanaque web del año pasado para tratar de entender por qué es que las herramientas populares o qué es lo que las herramientas populares están haciendo en términos de ayudarnos. ¿Estamos obteniendo lo que esperábamos de nuestras inversiones en las herramientas que verás fuertemente comercializadas y apareciendo en la parte superior de las encuestas de las que escuchaste esta mañana? Y la respuesta es que muchas de las herramientas que están más financiadas, más utilizadas y más comercializadas, específicamente, dejaron a sus usuarios en la estacada.

Es decir, que los desarrolladores en los sitios que adoptaron esas herramientas específicamente, los ganadores del concurso de popularidad, se encontraron con los peores resultados cuando Coro vitals pasó de la demora de la primera interacción a INP. Lo que quiere decir que cuanto más honestas se volvieron las métricas sobre lo que realmente era la experiencia del usuario final, peor se veían los sitios. Estas herramientas estaban manipulando la experiencia del usuario en las métricas, y cuando las métricas se volvieron más honestas e intentaron reflejar más precisamente lo que los usuarios ven todo el día, resultó que las personas que habían invertido en estas herramientas se encontraron en más problemas que aquellos que invirtieron en pilas más simples.

Esto es difícil de tragar, y creo que lleva a un par de cosas. Primero, ya sabes, ahora es obvio que la gente no está pasando tanto tiempo como creo que parecería para tener éxito en la web en sus dispositivos móviles. Esto es una competencia. Las plataformas son una competencia y la web está perdiendo dramáticamente. Puedes verlo desde el espacio.

Estos son datos de los Estados Unidos y esto quiere decir que el uso de la web como fracción del tiempo en el dispositivo es bajo y está cayendo. A una tasa base, es estable en términos absolutos, pero el tiempo pasado en dispositivos no es absoluto. Si eres un desarrollador web, esto debería asustarte mucho. Así es como se ve tener tu ecosistema eclipsado por otra cosa. Así es como se ve perder. Así que retrocedamos. No necesariamente estamos teniendo éxito. ¿Qué deberíamos estar haciendo? Bueno, si quieres construir para un buen objetivo para los usuarios en los márgenes, que es donde cada mercado se hace, siempre haces tu mercado en el margen, no puedes estar construyendo para el último MacBook Pro. Los límites de este dispositivo son estratosféricos en comparación con lo que la mayoría de la gente tiene, porque lo que cuesta es estratosférico en relación con sus presupuestos. Lo mismo es cierto para los dispositivos móviles. El objetivo real se ve algo así.

El objetivo real se ve algo así. Este es un Surface SE. Este es un dispositivo que mi empresa vendió principalmente a escuelas. Cuenta con la versión de $250 vendida con un chip N4020 Celeron, que es un dispositivo de dos núcleos, dos hilos, cuatro gigabytes con eMHC muy lento, todo encerrado en policarbonato, por lo que la refrigeración es deficiente. Siempre estás limitado térmicamente en este dispositivo. El portátil más vendido frecuentemente en Amazon es este dispositivo, que se lanzó en 2022 aproximadamente al mismo tiempo que el Surface SE.

Este es el HP Stream 14. Utiliza el mismo chip, el N4020 o el 4120. El 4120 te dará cuatro núcleos y cuatro hilos. Tiene muy poca caché, porque el espacio que asignas a la caché, es decir, hacer que las cosas vayan rápido, es muy caro en comparación con otros tipos de cosas que pondrías en el mismo chip. También cuenta con muy poca memoria y un eMMC muy, muy, muy lento. Tengo ambos dispositivos en mi escritorio en el trabajo, porque es importante para nosotros probar en estos dispositivos reales, porque esa es la única manera en que realmente podemos entender dónde está el mercado.

Pero la mayoría de las computadoras hoy en día son teléfonos. La mayoría de las cosas que pueden ejecutar un navegador web hoy en día son teléfonos. No hay navegadores heredados en los teléfonos. Simplemente, a primera aproximación, no existen. Casi todo el mundo tiene un navegador que fue construido en los últimos tres años en un teléfono. No tienes que pensar en IE en un teléfono. Tienes que pensar en el hardware y el software, porque este dispositivo tiene nominalmente ocho núcleos. Son núcleos Cortex A73 y A53, lo que quiere decir que son deficientes. Principalmente, esos núcleos no están activados. La gran mentira es que vas a mantener esos núcleos encendidos, y por eso tu sistema va a ser rápido. Eso nunca sucede. La batería, en ese mismo estuche de policarbonato, tiene que alimentar el maldito aparato todo el día.

Así que no estamos manteniendo los núcleos activos. No obtienes ocho núcleos. Tienes suerte si tu sitio web obtiene uno o dos. Tal vez cuatro si estás en la fase de carga y estamos haciendo cosas como la decodificación de imágenes. Esto nos lleva de nuevo a entender la economía que alimenta las preguntas de cómo es realmente el panorama de dispositivos. Los precios de venta promedio de los teléfonos en todo el mundo, nuevos, desbloqueados, han estado rondando entre $270 y $350 durante una década. Es decir, que el dispositivo mediano, el dispositivo vendido al precio promedio, porque el promedio y la mediana son en realidad muy cercanos en estos casos, no ha acelerado en precio de la manera que probablemente lo ha hecho el dispositivo que llevas. Si eres un desarrollador adinerado, es muy probable que tu teléfono solía costar alrededor de $500 y luego alrededor de $600, y luego obtuviste un teléfono de $1,000 y luego obtuviste un teléfono de $1,200, y eso es lo que llevas ahora. Pagas por lo que obtienes en muchos casos.

Para las laptops, que es la forma dominante para las PC, el precio de venta promedio está rondando alrededor de $650. Pero es peor que eso porque la mayoría de estos dispositivos son antiguos. La mayor parte del panorama en el que estás desplegando tu software no está compuesto por dispositivos que se vendieron este año o en los últimos seis meses. Las vidas útiles de estos dispositivos definen dónde está realmente la mediana, o dónde está el percentil 75 o el percentil 90, que es lo que realmente nos importa, 90, 95. Esos dispositivos tienen vidas útiles que significan que el teléfono mediano se vendió a $350 hace dos años y la laptop mediana se vendió hace unos cinco años por $650. ¿Estás construyendo tus pruebas para eso? Porque eso es lo que tus usuarios están llevando. Así que tenemos buena telemetría de Edge.

Podemos ver muchas métricas donde el navegador de bandeja de entrada en Windows, así que algo así como un tercio de la flota de la que obtenemos telemetría tiene discos duros giratorios o tienen cuatro gigabytes de RAM o menos, o tienen cuatro núcleos o menos. Este es nuestro segmento de gama baja. Y este segmento de gama baja no está disminuyendo tan rápido como te gustaría. Este mismo conjunto de pruebas solo ha disminuido en un 7% en los últimos dos años. Bien. Así que lo que necesitas entender sobre el mundo en el que realmente estás poniendo tu software es que la mayoría de los dispositivos son antiguos, mucho más antiguos que los que probablemente llevas. Son principalmente teléfonos, y no están ejecutando Mac OS o iOS. Esa simplemente no es la realidad. Así que si te gustaría hacer un buen trabajo para resolver problemas para los usuarios y la sociedad bajo estas restricciones, necesitas entender cómo construir para ellos. Bien. Sé que hay un gran riesgo de que me levante aquí y haga mi blog en forma de 20 minutos en el escenario. Pero diré que comencé a prestar atención a esto porque cuando construimos PWAs, cuando el equipo que estaba liderando construyó PWAs en 2013, 14 y 15, comenzamos a trabajar con muchos socios, muchas personas que querían construir buenas experiencias móviles competitivas. Y lo que estábamos encontrando una y otra vez era que estaban tomando las herramientas y marcos que tenían sentido en el antiguo consenso de escritorio, y estaban tratando de aplicarlos a móviles.

Ningún otro ecosistema intentó esto. Y ha sido un desastre absoluto, un fiasco total. No ha funcionado. Porque la mayoría de los teléfonos entonces y ahora son Androids cada vez más baratos. Bien. Ahora podrías estar diciéndome, Alex, pero obtenemos... La muerte de la Ley de Moore está muy exagerada. Y hasta cierto punto técnico, eso es cierto, en el sentido de que obtenemos más transistores cada 18 meses más o menos. Y la tendencia continúa, especialmente en lugares como el centro de datos donde estamos obteniendo plena utilización de estos núcleos.

Pero esa no es la historia que importa, porque la mayoría de los teléfonos, la mayoría de las computadoras están funcionando con baterías, y la energía es ahora el factor limitante para esos dispositivos. Tener más transistores, si no pueden ser encendidos, no importa para el rendimiento. No importa cuál sea tu modelo de subprocesos. Simplemente no importan. Y la escala de Denard terminó hace más de una docena de años.

Lo que esto significa efectivamente es que aunque obtenemos más transistores, no podemos encender más transistores, y no van más rápido. Los gigahercios se detuvieron. Lo que ves en la parte superior es que tu número total de gigahercios para reducciones de tamaño de chip no aumentó. Lo que significa que el mismo programa que solía acelerarse de manera confiable cada año porque la escala de Denard significaba que nuestro mismo programa de un solo subproceso iría más rápido en la siguiente generación de hardware, eso se acabó. No sucede. Y todo nuestro ecosistema de JavaScript fue efectivamente construido bajo la premisa de que esto iba a seguir sucediendo.

Ocurrió durante toda la década de 2010. Se acabó. Está terminado. Así que lo que tenemos ahora son más núcleos oscuros. No están encendidos. Están apagados. Están en el estado de menor consumo de energía la mayor parte del tiempo porque eso es lo que las baterías requieren de nosotros. Son más lentos, ¿verdad?

Sigo intentando construir este gráfico, y la investigación es realmente bastante difícil de obtener en conjunto. Pero es mi fuerte expectativa que el rendimiento máximo de la CPU probablemente se alcanzó en 2017. Probablemente hemos estado en una tendencia a la baja en la mediana desde entonces porque los teléfonos han explotado mientras que el mercado de PC y escritorio ha sido efectivamente una función fija.

OK. Hay buenas noticias, lo cual es decir que los navegadores recibieron el mensaje. Nos adaptamos bastante. Nos movimos a móviles. Hicimos todo en hilos. Cuando nos das una carga de trabajo diseñada para funcionar de la manera en que funciona la web en lugar de la forma en que tal vez JavaScript funciona, hoy en día hacemos todo en hilos, ¿verdad? La decodificación de imágenes está fuera de hilo.

De hecho, gran parte de la compilación en segundo plano para tu JavaScript ahora es fuera de hilo. Esto es importante porque estamos obteniendo muchos más núcleos, pero en la mayor parte del mercado no estamos obteniendo dispositivos más rápidos. Verás que me enfoco aquí en las puntuaciones de un solo núcleo porque esto es lo que define el rendimiento de tu JavaScript, ¿verdad? Aquí es donde tu código como desarrollador web se está ejecutando en el hilo principal.

Ese Galaxy 825 en la tercera ranura hacia abajo a la derecha, ese es el dispositivo de $350. El dispositivo de $300 hoy en día. Notarás que es... ¿Qué es eso? Aproximadamente un tercio de la velocidad de un iPhone. Bien. Entonces, si llevas un iPhone, lo que tienes en tu bolsillo no es la vida real. Y parte de esto se debe a que cuando pagas mucho por un teléfono, lo que obtienes es un montón de caché hoy en día, ¿verdad? Como 40 megabytes de caché. Es ridículo.

Lo que Apple ha hecho con Silicon es ridículo. Eso es porque venden a un grupo adinerado de personas, lo cual es decir, no a la mayoría de la gente. Bien. Ese es nuestro factor limitante. Nuestro factor limitante es el hecho de que vivimos en un entorno extremadamente hablador, interpretado o JITed en el cual la localidad de datos es difícil de razonar.

Y eso significa que tu JavaScript se ejecutará muy rápido en dispositivos con mucho caché. No tienes que pasar mucho tiempo esperando la memoria principal. En la mayoría de los teléfonos, no hay caché. Cada vez que fallamos en predecir una rama, cada vez que te desoptimizan en V8, pobre de ti porque probablemente estás detenido. Esto significa que cada vez que apuestas por JavaScript para ofrecer tu experiencia, estás haciendo una mala apuesta.

Bien. Bueno, tengo malas noticias. Y buenas noticias. La buena noticia es que las redes están mejorando. Y la mala noticia es que están comenzando desde una base muy mala. Nuevamente, la historia predominante de los últimos 15 años de la informática no es lo que se te ha comercializado como alguien relativamente adinerado. Es que la gente obtuvo sus primeros smartphones en grandes partes del mundo. Miles de millones de personas obtuvieron computadoras por primera vez. Y esos teléfonos eran androids, androids baratos, $100, $150, tal vez $200, nuevos desbloqueados.

Y así, la situación de la red en los mercados en crecimiento, en los lugares donde realmente se obtiene el margen, sigue siendo bastante difícil. En muchos lugares, es muy variable. Pero en los mercados en crecimiento, todavía está mejorando rápidamente. Pero está mejorando desde una base de 3G a 4G lenta. Bien. Lo que quiero que entiendas en esta conferencia de JavaScript, de alguien que pasó una década en TC39 trabajando en el lenguaje para darte promesas y clases y funciones de flecha y ese tipo de cosas, es que JavaScript siempre ha sido y siempre será la forma más lenta de hacer cualquier cosa en la web. Hacer un programa de JavaScript rápido requiere que lo pienses de la misma manera que harías un programa rápido en Python.

Delegas a las bibliotecas de C++ que están a la izquierda, derecha y centro y pasas el menor tiempo posible en tu lenguaje. Tu trabajo como fontanero, estás conectando la entrada de algún analizador a algún otro sistema que lo manejará en el mundo de C++. Lo que quiere decir que, cada vez que estás ejecutando código en la ruta crítica de una interacción de usuario, la has cagado. Y esto importa porque vas a escuchar mucho en los próximos días sobre herramientas que son populares.

Y muchas de esas herramientas se han vendido con la idea de que su popularidad significa que son buenas, o que no tienes que preocuparte por los factores de los que acabo de hablar. Y eso es una tontería. Es una tontería porque no se centra en la cuestión de si estamos resolviendo un problema de manera efectiva para los usuarios. Específicamente, usuarios en los márgenes. Ahí es donde está el negocio. El negocio siempre está en el margen.

Así que si no estás construyendo tu propio modelo mental, y no estás construyendo tu propio entorno de pruebas para entender cómo vas a poder ofrecer bien a esos usuarios, ofrecer las experiencias que crees que son los productos de mejor calidad para tu negocio o para tu empresa, entonces te estás engañando a ti mismo. Bien. Todo esto lo puedes encontrar en un millón de publicaciones de blog. No necesitas que te diga cómo ir rápido en la web. Envías menos código. Ejecutas menos código. Dejas que el sistema debajo de ti haga la mayor parte del trabajo. Pasas el menor tiempo posible en tu propio código. Específicamente en JavaScript.

Porque JavaScript, de nuevo, es la forma más lenta de hacer cualquier cosa en la web. Y así que si es la única forma de hacer algo en tu stack, has fallado por defecto para llegar a los usuarios en los márgenes o necesitas una disciplina extrema. Una de las dos. Tienes que intentar llegar al usuario marginal. De lo contrario, estás decepcionando a tu negocio. Eso es lo que significa hacer un trabajo de calidad en nuestra profesión. Así que si no nos importa la calidad, nada de esto realmente importa. Pero si nos importa la calidad y esperamos que la gente nos pague por hacer un trabajo de calidad, entonces sí importa. Y no podemos desear que estos factores desaparezcan. Pero podemos hacerlo bien.

Así que esto es de una transición que estamos pasando internamente en Edge. Lo estamos llamando Web UI 2. Gran parte del navegador hoy en día está construido con cosas de la web. Está construido en el caso de Edge, mucho de React y muchos de los sistemas de datos que te imaginarías. Y esta es la página de configuración. A la izquierda está el sistema antiguo que estaba basado en React. Y a la derecha hay un nuevo sistema que ha sido totalmente reconstruido para estar construido sobre lo que la plataforma puede hacer. Podría contarte sobre el stack, pero no importa. Lo que cambió aquí en esta reconstrucción que lo hizo, ya sabes, un buen 40% más rápido. Eso es aproximadamente lo que estamos viendo en general a medida que reconstruimos estas superficies y nos deshacemos de React y todas las abstracciones que se construyeron para la web de 2011. Lo que estamos viendo es que estamos mejorando la experiencia del usuario porque decidimos preocuparnos por la experiencia del usuario. Lo más importante no era la herramienta. Era el enfoque. Decidimos centrarnos en la calidad para los usuarios en los márgenes y eso ha dado forma a cada decisión en el otro lado.

No aceptes la idea de nadie sobre cómo deberían ser tus herramientas y stack. Plantea una prueba. ¿Es bueno? ¿Son buenos los resultados? Eso es lo único que importa. Gracias. La primera pregunta aquí es por qué no usas una herramienta como Browser Stack en lugar de comprar un portátil para probar estos dispositivos? Es una gran pregunta. Puedo recomendar encarecidamente, como quieras decirlo, webpagetest.org.

Tener un entorno repetible que esté ajustado para baja latencia, lo siento, baja variación y permita ajustar los parámetros que impactan la latencia, tener un banco de pruebas de baja variación en el que puedas repetir cosas dentro de tu ciclo de desarrollo es increíble. En Microsoft hemos construido nuestra propia versión interna, levantado nuestra propia instancia de este producto de código abierto con un montón de configuraciones y opciones que son específicas para nuestros flujos, nuestros flujos de autenticación, nuestros diversos entornos de prueba en Microsoft. Emula ese servicio SE. Hemos ajustado nuestra instancia de webpagetest. Lo llamamos el servicio de analizador de rendimiento. Hemos ajustado PaaS para emular ese dispositivo de servicio SE. Y así, a cada desarrollador con el que trabajamos, les decimos que por favor pongan sus cosas en PaaS. Lleva tus recorridos críticos de usuario a PaaS. Automatízalo. Puedes hacer lo mismo con webpagetest.org. Y si no tienes un banco de pruebas como ese, necesitas conseguir uno, ¿verdad? Puedes tener dispositivos físicos. Diría que uno de los trucos más fáciles que puedes hacer es dar a tus gerentes de producto portátiles y teléfonos baratos. Podrías decir, oh, bueno, eso es un dispositivo nuevo. La buena noticia es que son realmente baratos, así que no tienes que preocuparte tanto por ello. Hacemos eso. Tiende a cambiar las mentes porque cuando las personas pueden realmente experimentar lo que sus usuarios están experimentando en lugar de, ya sabes, tener un gráfico frente a ellos sobre cómo va, eso tiende a ser bastante efectivo para cambiar la narrativa.

Sí, puedo imaginarlo. La siguiente pregunta aquí es, veamos, ¿qué tan relevante es la incompatibilidad del navegador hoy en día? Quiero decir, obviamente es relevante. Este es uno de los lugares donde las encuestas, por mucho que las critique sobre la elección de frameworks, son bastante reveladoras, ¿verdad? Vemos consistentemente en los comentarios tanto inicialmente de las encuestas de necesidades de desarrolladores de MDN como de las encuestas de estado que el hecho de que Safari esté muy atrás en el borde relativo a lo que la web puede hacer hoy es un gran costo que todos pagamos, ¿verdad? Se convierte en un problema real para nosotros. Si te gustaría ayudar a impactar esa situación, si te gustaría que Apple no solo tomara el 95%, 90% de los $20 mil millones al año que ganan de la web y se quedaran con eso como ganancia pura, puedes hablar con la gente de OpenWeb Advocacy, únete a ellos. Están tratando de hacer que la competencia real para los navegadores sea una realidad para los usuarios que son adinerados, lo que tendría un gran impacto en el ecosistema general y ya ha entregado cambios grandes e importantes en la trayectoria de muchos de estos navegadores.

El esfuerzo de Interop se mencionó anteriormente, y creemos que una gran razón por la que Apple está invirtiendo más es que Interop y herramientas como esta están mostrando cómo se ve la brecha. Sí, totalmente. Hay un dicho que si algo puede ser construido en JavaScript, eventualmente será construido en JavaScript. ¿Cuál es tu opinión sobre esto mientras JavaScript es la forma más lenta? Que puedas no significa que debas, ¿verdad? De nuevo, ¿qué es hacer ingeniería? Es identificar el problema que el usuario realmente tiene y luego encontrar la mejor manera de resolverlo para ellos, ¿verdad? Siempre entendemos tu contenido como HTML analizado en DOM, que luego se empareja con CSS, que luego se convierte en un árbol de diseño, que luego se convierte en instrucciones rasterizadas, que luego se suben a la GPU, y luego esperamos las instrucciones. Ese es el ciclo. Eso es lo que hacemos todo el día, todos los días. Si pones JavaScript en el medio, estás tomando las riendas y diciendo, yo me encargo de esto.

¿Existe la posibilidad de que las aplicaciones web progresivas dominen completamente la web y las aplicaciones móviles y web finalmente se reúnan? Los datos que te mostré antes sugieren que eso está muy lejos, ¿verdad? Para que la gente quiera más de la experiencia, si piensas en lo que estábamos tratando de construir cuando creamos las PWAs. Las PWAs son una especie de respuesta a la pregunta de tengo un montón de usuarios en la parte superior de mi embudo, están llegando a mi sitio, y están usando mi sitio, pero luego quieren experiencias de compromiso más profundas con él, ¿verdad? Algunos de ellos quieren notificaciones push, resulta que es cierto. Algunos de ellos quieren que su ícono esté en la pantalla de inicio. Quieren poder volver a él, ver sus mensajes no leídos, ese tipo de cosas. Todo eso es consecuencia de que la experiencia sea buena en el front end. Si lo piensas como un embudo, si lo piensas como un flujo, el éxito de las PWAs probablemente dependa de que las experiencias web sean buenas en primer lugar. Hasta que tengamos experiencias web que no sean malas, como ese 50% de usuarios que están teniendo una mala experiencia en la mayoría de los sitios web, en sus teléfonos, hasta que lo hagamos mejor que eso, ¿por qué esperaríamos que las PWAs triunfen? Esta es una cuestión de calidad. Nuestro ecosistema está en competencia, y esa competencia se trata de calidad. Totalmente.

Esta siguiente no es realmente una pregunta, pero la cambiaré aquí. Dice, digámoslo de esta manera, ¿crees que la mayoría de las empresas deberían optimizar principalmente para dispositivos premium ya que ahí es donde está el dinero, a menos que estés construyendo servicios sociales del gobierno? No puedo decirte la cantidad de equipos con los que he trabajado que vivían en esta burbuja de privilegio, hasta su cadena de gestión, personas que llevan dispositivos rápidos en redes rápidas la mayor parte del tiempo, que se sorprendieron al descubrir que toda la tontería, absoluta basura, porquería que había sido vendida por el ecosistema de influenciadores de JavaScript sobre cómo la gente tiene dispositivos rápidos ahora, lo cual es obvio en los datos, es una tontería, se sorprendieron al descubrir que cuando hicieron sus sitios web dos o tres veces más rápidos, les hizo ganar mucho dinero, o aumentar el compromiso, o lo que fuera su métrica principal. No es uno a uno. No puedes decir si hago esto un 1% más rápido, voy a obtener un 1% más de negocio. No funciona de esa manera. Hay muchas cosas situadas. Tienes que averiguar cuáles son los flujos, optimizarlos, de principio a fin, y cada negocio es diferente. Pero como cuestión de nivel superior, la idea de que vas a optimizar, por cierto, no estamos hablando de optimizar, estamos hablando de no optimizar. La idea de no optimizar, y creer que tus usuarios pagarán el costo por tu acceso es una buena estrategia de negocio, requiere mucha evidencia. Y así creo que todos podemos decir que esto es obviamente una tontería, porque las personas que lo ofrecen no aportan ninguna evidencia. Si tuvieran este gran montón de datos que diera sentido a esto, que de alguna manera hiciera que todos estos diferentes puntos de datos encajaran de una manera que tuviera sentido, podríamos decir que sí.

Incluso las personas que venden bolsos de mano de producto están vendiendo cultura aspiracional, lo que significa que las personas que los compran principalmente no son los ultra-ricos. Son personas que les gustaría ser vistas de esa manera. Gracias. Veamos. Aquí hay otra. ¿Tienes la sensación de que la nueva generación de desarrolladores omite aprender la plataforma y salta directamente a usar un framework? ¿Es eso bueno o malo? No quiero... Es raro escucharme decir esto, pero realmente no quiero arruinarle la diversión a nadie. No quiero decirte que lo estás haciendo mal si aprendiste un framework para empezar.