Smashing Podcast Episodio 45 con Jeremy Wagner: ¿Qué es JavaScript responsable?

Este episodio ha sido amablemente apoyado por nuestros queridos amigos de Wix, la plataforma para que los profesionales construyan sitios de clientes, administren proyectos complejos y hagan crecer negocios en línea. ¡Gracias!

En este episodio, estamos hablando de JavaScript responsable. ¿Qué significa que el código sea responsable y cómo debemos abordar los proyectos de manera diferente? Hablé con el experto Jeremy Wagner para averiguarlo.

Mostrar notas

• Sitio web JavaScript responsable
• Compra el libro en A Book Apart
• Sitio web personal de Jeremy
• Jeremy en Twitter

Actualización semanal

• Ley de Fitts en la era del tacto escrita por Steven Hoober
• Diseño web bien hecho: Perfectamente inútil escrito por Frederick O'Brien
• Todo lo que desea saber sobre la creación de interfaces de usuario de voz escrito por Nick Babich y Gleb Kuznetsov
• Implicaciones de que WordPress se una al protocolo de bloque escrito por Leonardo Losoviz
• Reflexiones sobre Markdown escrito por Knut Melvar

Transcripción

Drew McLellan: es escritor técnico, nerd del rendimiento web, desarrollador y orador, y actualmente trabaja en Google. Ha escrito para A List Apart, CSS-Tricks y Smashing Magazine, y es el autor de un nuevo título, JavaScript responsable para A Book Apart. Sabemos que es un técnico y comunicador experto, pero ¿sabías que quiere dar la vuelta al mundo en una tabla de remo? Mis grandes amigos, denle la bienvenida a Jeremy Wagner. Hola Jeremy, ¿cómo estás?

Jeremy Wagner: Estoy genial. ¿Cómo estás?

Drew: Estoy muy bien. Gracias. Quería hablarles hoy sobre esta idea de JavaScript responsable. ¿Se trata de algún tipo de nuevo enfoque o técnica, o literalmente está hablando de usar JavaScript de manera responsable?

Jeremy: Literalmente estoy hablando de usar JavaScript de manera responsable. Según el archivo HTTP, hemos visto un aumento promedio de casi el 58 % en la cantidad de JavaScript descargado por dispositivos móviles de aproximadamente 290 kilobytes a casi 500 kilobytes en el último año.

Drew: Guau.

Jeremy: Entonces, cuando hablo sobre el uso responsable de JavaScript, es un primer enfoque del usuario decir... evaluar críticamente qué es lo que estamos construyendo y cuál es el objetivo de lo que estamos construyendo servido por las prácticas modernas de desarrollo web, así que hablar. Y supongo que eso es una especie de... tal vez no sea una broma, pero no estaba criticando el desarrollo web moderno, pero un subproducto del desarrollo web moderno es que es muy fácil agregar dependencias a los proyectos. Todo está a una instalación de MPM y cada instalación de MPM tiene un costo, ese costo varía. Pero lo que sí vemos es que en los datos del archivo HTTP, el percentil 95... es decir, el 5 % de las experiencias que son las más lentas... o no las más lentas, pero que envían la mayor cantidad de JavaScript, que aumentó en el último año en alrededor de 875. kilobytes a alrededor de 1,4 megabytes.

Drew: Guau.

Jeremy: Así que es una gran cantidad de JavaScript que se transfiere y tiene implicaciones tanto en el rendimiento de carga como en el rendimiento de tiempo de ejecución.

Drew: Así que mencionaste el rendimiento allí. Parece que la experiencia web moderna desde mi punto de vista es como 10% HTML y CSS y 90% JavaScript. Y tiene que haber una especie de consideraciones de rendimiento para eso. Quiero decir, usted habló sobre la cantidad de datos que estamos transfiriendo, pero hay otras consideraciones de rendimiento al tener mucho JavaScript.

Jeremy: Correcto. Entonces, tener una conexión a Internet lenta y ya sabes... donde vivo en los Estados Unidos, si vas lo suficientemente lejos fuera de una ciudad importante, se vuelve un poco difícil dependiendo de a dónde vayas... para hacer frente a lo lento que puede ser el Internet en una especie de estas áreas rurales y es importante que la gente viva en áreas como esta. Entonces, el aspecto del rendimiento de carga ya es lo suficientemente desafiante cuando comienzas a enviar megabytes de JavaScript, pero también podrías estar tratando con alguien que no tiene un iPhone... como un iPhone X o como un iPhone 13.

Jeremy: Es posible que solo estén en un teléfono con funciones o simplemente como un teléfono Android económico, simplemente tratando de navegar por la vida. Quiero decir, piense en cosas como banca en línea, asistencia por desempleo u otra asistencia gubernamental, portales como ese para aplicaciones. Aprendizaje en línea, hay muchos lugares donde JavaScript excesivo realmente puede tener un efecto perjudicial para las personas que podrían no tener la suerte de vivir en áreas metropolitanas grandes o incluso en áreas metropolitanas que no cuentan con un buen servicio de Internet de banda ancha y aquellos en dispositivos más lentos. . Creo que, como desarrolladores, tenemos esta tendencia a mirar... compramos MacBooks o estos dispositivos de gama alta, y a veces no vemos realmente dónde pueden surgir estos problemas cuando abusamos de JavaScript.

Drew: Y como mencionaste allí, a veces son las personas que tienen más que perder al no poder acceder a un servicio las que son penalizadas por este tipo de cosas. Esas personas sin conexiones de datos rápidas o sin dispositivos muy capaces a veces acceden a servicios que significan todo para... significa todo para ellos a los que pueden acceder. Así que se convierte casi en una cuestión de derechos humanos en algunos aspectos.

Jeremy: Sí. Quiero decir, tendemos a ver el rendimiento web enmarcado en términos de valor comercial. Yo era un consultor de rendimiento para algunos e-com y como una gran empresa de alimentos, un e-com importante... como una tienda, como una tienda de electrónica y es muy tentador hacer eso, ¿verdad? Porque cuando trabajas para una empresa, quiero decir, obviamente quieres que las finanzas sean saludables y creo que el rendimiento web juega un papel en eso. Creo que hay una serie de estudios de casos que lo prueban. Sin embargo, existe ese aspecto humano e incluso para las empresas, como las tiendas de comestibles y ese tipo de cosas. Sí, están impulsados ​​por los ingresos. Quieren tener finanzas saludables y, por lo tanto, el rendimiento web es parte de eso, pero también están atendiendo una necesidad crítica, ¿verdad? Como si tuvieras que comer, ¿verdad?

Jeremy: Y como algunas personas pueden estar en casa por una razón u otra. Es posible que no puedan subir fácilmente a un automóvil. Puede que no tengan coche. Así que confían en estos servicios para obtener sustento, pero más que eso, asistencia si la necesitan y especialmente como intervención en crisis y ese tipo de cosas. No creo que sea terriblemente descabellado decir que una pareja que ha sido abusada y expulsada de su hogar puede recurrir a su teléfono inteligente y presionar a Google para tratar de encontrar un portal de intervención y asistencia en caso de crisis. Y JavaScript puede interponerse en el camino de ese tipo de objetivos y para satisfacer esas necesidades humanas. Cuando tenemos la tendencia de apoyarnos demasiado en él.

Drew: Quiero decir, hemos visto una especie de vislumbre de eso en los últimos 18 meses más o menos con COVID y personas que se aislan y, como dices, que necesitan ordenar la entrega de comestibles. La web se convierte en un salvavidas para ellos en ese momento. Se sienten mal, no pueden salir de su alojamiento porque se están aislando y tienen que conseguir alimentos y suministros esenciales. Así que sí, creo que es una parte cada vez más importante de la vida cotidiana para todos nosotros.

Jeremy: Exacto. Y volviendo al tipo de historia del dispositivo, Tim Kadlec escribió un artículo increíble hace un par de años, creo que fue hace dos años, tal vez hace tres años, pero se tituló Prioritizing the Long Tail of Performance. Y cuando miras eso... entonces, en la jerga de rendimiento web, hablamos de datos de laboratorio versus datos de campo. Y los datos de laboratorio son como cuando está ejecutando Lighthouse o lanzando un sitio web en una prueba de página web para ver cómo le está yendo. Esas son todas herramientas realmente útiles, pero cuando miras esos datos de campo, realmente comienzas a obtener una imagen más amplia y una visión más amplia de quién es realmente tu audiencia. Y en este artículo, Tim Kadlec habla sobre lo que significa priorizar la cola larga del rendimiento. Es decir, todos estos dispositivos que... tal vez no sean tan robustos y poderosos como los dispositivos que tenemos los desarrolladores.

Jeremy: Y la idea detrás de ese artículo es que si podemos centrarnos en ese percentil 90 o 95 estamos... y mejorar esa experiencia para esas personas, estamos construyendo una web más rápida para todos, incluidos aquellos en dispositivos rápidos. Y atacar un punto de datos sobre eso en los EE. UU. Y esto es solo de statcounter.com. Algo así como 28 puntos... alrededor del 28% de las personas están en un dispositivo iOS que captura esta herramienta. Y alrededor del 21% de ellos son Android. Y Android tiende a representar una buena parte de esa larga cola de dispositivos, porque Android no es monolítico. Múltiples fabricantes de dispositivos fabrican teléfonos Android, pero para contrastar eso con el mundo, porque el mundo es más que solo Estados Unidos, es alrededor del 16% de las personas que usan iOS y alrededor del 41% de las personas que usan Android. Por lo tanto, realmente vale la pena priorizar esas experiencias más lentas o potencialmente más lentas.

Drew: Leí en su libro sobre la aceleración térmica del dispositivo, que no es algo que realmente haya considerado antes. ¿Cuáles son las preocupaciones allí?

Jeremy: Las preocupaciones están ahí, y no soy como un experto en microprocesadores de ninguna manera. Solo soy el desarrollador web que probablemente escribe demasiado, pero... entonces la idea detrás del estrangulamiento térmico y esto existe en todos los sistemas, no solo como teléfonos y tabletas, es que un microprocesador... cuando asume cargas de trabajo excesivas o realmente solo cargas de trabajo en general, el producto de desecho de ese trabajo es el calor. Y entonces los dispositivos tienen formas de mitigar esto. Al igual que su computadora portátil, tiene un dispositivo de enfriamiento pasivo y activo.

Jeremy: Entonces, un dispositivo de enfriamiento pasivo es como un disipador de calor o algún tipo de disipador de calor. Y la parte activa de eso es como un ventilador para dispersar el calor de manera más eficiente. Algunas, como las compilaciones de PC personalizadas, pueden usar refrigeración líquida, que es una especie de ejemplo más relativamente extremo, pero un teléfono móvil no tiene eso porque ¿dónde va a encajar realmente un ventilador en todo eso, si la portabilidad es lo tuyo? cosa, ¿verdad?

Jeremy: Entonces, para que estos dispositivos puedan hacer frente a estas cargas de trabajo pesadas, pueden reducir artificialmente la velocidad del procesador, como reducir la frecuencia del reloj hasta que el dispositivo entre en un estado en el que se pueda aumentar la frecuencia del reloj. Y eso tiene implicaciones porque si estás masticando toneladas y toneladas y toneladas y toneladas de JavaScript, tienes como estos grandes fragmentos que llegan por el cable, bueno, eso inicia el procesamiento, ¿verdad? Entonces, es mucho procesamiento a través de la evaluación y el análisis en la compilación y luego la ejecución. Y si está haciendo eso con uno o dos megabytes de JavaScript, y tiene muchos otros procesos en segundo plano, como diferentes pestañas, ese tipo de cosas que pueden poner su estado... eso aumenta la probabilidad de que el dispositivo puede entrar en un estado de estrangulación térmica, lo que significa que será menos capaz de asumir ese trabajo adicional.

Drew: Así que es una especie de ciclo de retroalimentación negativa. ¿no es así? Le das mucho trabajo al dispositivo. Se calienta mucho y luego es menos capaz de ejecutar ese trabajo porque tiene que reducir la velocidad.

Jeremy: Correcto. Y de nuevo, no soy un experto en microprocesadores. Estoy seguro de que si, si, si un ingeniero que estuviera íntimamente familiarizado con esto, probablemente podría corregirme en algunos de los detalles, pero la idea general es que sí, a medida que aumenta la presión ambiental, el dispositivo es menos capaz de hacer frente a estas pesadas cargas de trabajo hasta que la presión disminuya.

Drew: así que estamos escribiendo JavaScript para todo el espectro de dispositivos del último Apple M1 Max es el nuevo procesador, ¿no es así? Desde computadoras portátiles hasta dispositivos que apenas tienen suficiente memoria RAM para mostrar una página web. Pero la web no comenzó así, a los oyentes más jóvenes les podría interesar saber que solíamos crear experiencias web interactivas sin ningún tipo de JavaScript. Nuestro marco grande y pesado será nuestra perdición.

Jeremy: Yo diría que los marcos tienen un tiempo y un lugar y aquellos que leen extractos de este libro pueden tener la idea de que estoy en contra del marco. Y definitivamente critico varios marcos, pero cumplen un propósito y es posible usarlos de una manera que preserve una buena experiencia de usuario o pueda resultar en una buena experiencia de usuario. Pero lo que no creo que hagamos lo suficiente es evaluar críticamente estos marcos en términos de cómo dañan... el rendimiento del tiempo de ejecución, ¿no? Entonces, el tipo de cosas de las que estoy hablando, donde si hace clic en un botón, y el dispositivo tarda como un segundo, tal vez dos, en responder a esa entrada, porque están sucediendo muchas cosas en el fondo. Tiene cosas de JavaScript de terceros, como recopilar análisis, y luego tiene otras cosas que se ejecutan en subprocesos.

Jeremy: Y que si no evalúa de forma crítica el rendimiento del tiempo de ejecución de un marco, podría estar dejando algunas oportunidades sobre la mesa para servir mejor a sus usuarios. Entonces, un buen ejemplo, que siempre me gusta usar, es reaccionar versus actuar previamente. He estado golpeando este tambor por un tiempo. Hice un artículo para CSS-Tricks hace un tiempo que perfilaba una interacción de clic básica para un menú de navegación móvil. Y suena trivial, pero lo que encuentra es que en todos los dispositivos, React ofrece un mejor rendimiento en tiempo de ejecución, pero tiene básicamente la misma API. Hay diferencias, hay algunas pequeñas diferencias y cosas que se pueden disimular con compatibilidad previa al acto, pero así de simple... y no debería decir una elección simple, pero esa elección, esa elección fundamental puede ser la diferencia entre una experiencia que funciona muy bien para todos los usuarios o al menos para la mayoría de los usuarios, o una experiencia que solo funciona bien para algunos. Esperemos que eso tenga algún sentido.]

Drew: Quiero decir, con todos los marcos y herramientas de compilación, parecen estar mejorando todo el tiempo en hacer cosas como sacudir árboles y optimizar los paquetes que envían y cómo se entregan al navegador. Al usar grandes marcos, ¿hay un punto de inflexión en el que cree que está escribiendo una aplicación tan grande, con tanto código propio, que el marco le permite enviar menos código debido a toda su abstracción?

Jeremy: Esa es una pregunta difícil de responder. Un aspecto de eso es que el marco en sí mismo representa una cantidad de código que nunca se puede optimizar. Entonces, tener un marco delgado, como un pre-acto o cualquier número de similares... O como un hechizo, por ejemplo, eso ayuda mucho. Pero el problema que he visto y creo que los datos del archivo HTTP respaldan este punto es que parece que cada vez que tenemos estos avances en microprocesadores y redes cada vez más rápidos, tendemos a consumir esa ganancia, ¿verdad?

Jeremy: Tendemos a estar en esta cinta de correr en la que nunca avanzamos realmente. Y no sé, como si no fuera clarividente sobre cuál es la historia de... o lo siento, cómo es el futuro de los marcos. Estoy seguro de que se pueden obtener algunas ganancias de eficiencia. Pero lo que vemos en el campo en términos de cuánto JavaScript sin procesar es... solo se está utilizando la cantidad sin procesar de JavaScript. No me dice que este es un problema que podemos automatizar para salir. Creo que tenemos que... tenemos que ser seres humanos e intervenir y tomar decisiones que sean en el mejor interés de los usuarios. De lo contrario, no nos veo saliendo de esta rutina, tal vez no en mi carrera, pero no lo sé.

Drew: En el libro, usted habla sobre sitios web y aplicaciones web y cómo comprender la diferencia y con cuál está trabajando lo ayuda a elegir su estrategia para desarrollar y optimizar. Cuéntanos un poco sobre eso.

Jeremy: Esa es una muy buena pregunta. Y escribo sobre esto en el artículo homónimo que escribí para A List Apart llamado JavaScript responsable Parte uno, que es una especie de preludio de este libro. Es que cargamos mucho en esta terminología. Como escritor técnico, veo que los dos se usan indistintamente. Lo que veo es con los sitios web, la implicación es que es una especie de experiencia de varias edades, ¿verdad? Es una colección de documentos. Ahora, un documento... esos documentos pueden tener una funcionalidad integrada como estas pequeñas islas, como ha sido el término últimamente, estas pequeñas islas de funcionalidad que permiten a las personas hacer las cosas.

Jeremy: Pero luego están las aplicaciones web y las aplicaciones web tienen esta connotación de funcionalidad similar a la aplicación nativa. Así que estamos hablando de aplicaciones de una sola página, estamos hablando de grandes cantidades de JavaScript para impulsar una interactividad compleja. Y hay momentos en que el modelo de aplicación web tiene sentido. Como por ejemplo, Spotify es un buen ejemplo de esto. Eso funciona mejor como una aplicación web. Realmente no querrías intentar usar eso o diseñarlo como una aplicación de varias páginas. Como un sitio web tradicional, pero creo que no es un valor predeterminado sostenible porque cuando su valor predeterminado para cada proyecto es decir: "Bueno, todo lo que necesitamos para enviar una aplicación de una sola página, como un enrutador del lado del cliente y un marco pesado y descargar todo de este procesamiento de representación del servidor al cliente”. Creo que ahí es donde comienzas a llegar a un punto en el que estás excluyendo a los usuarios, aunque sin querer, pero excluyéndolos de todos modos.

Drew: ¿Hay un gran abismo, crees que entre las personas que adoptan el enfoque de que vamos a publicar un sitio web y puede tener cualquier funcionalidad interactiva y aquellos que dicen: "Somos una empresa de software, somos hacer un producto, un producto de software y nuestra plataforma a través de la cual lo entregaremos es la web, en lugar de aplicaciones nativas para múltiples plataformas”. ¿Es probable que estén abordando el problema de maneras completamente diferentes? ¿Las consideraciones son diferentes dependiendo de su perspectiva en ese momento?

Jeremy: Esa es una pregunta difícil. Entonces-

Drew: Fue difícil para mí decirlo.

Jeremy: Yo diría que una empresa que… así que un buen ejemplo sería como una noticia, ¿no? Están bien atendidos por el tipo de modelo de sitio web, porque literalmente es una colección de documentos, artículos. Y las personas que desarrollan esas experiencias probablemente tendrán un conjunto de habilidades diferente al de una empresa como Spotify o una empresa que tiene una gran aplicación web como Envision o ese tipo de cosas. Y sí, creo que van a abordar esto desde diferentes ángulos. La forma en que lo he visto es que hay un segmento... o al menos así es como percibo la comunidad de desarrollo web en general: hay un segmento de personas, de desarrolladores web que provienen del desarrollo de software no tradicional. antecedentes, ¿verdad? Y yo soy una de esas personas, estaba jugando con la web cuando era como un niño, ¿verdad?

Jeremy: Como en la escuela secundaria y haciendo estúpidas páginas de fans para todos, como los videojuegos en ese momento que realmente me gustaban. Y nunca tuve ese tipo de educación en informática. Hay conceptos de informática que he aprendido a lo largo del camino. Luego también hay un segmento de desarrolladores, especialmente creo que han surgido en los últimos cinco a 10 años que abordan esto de una manera más orientada a la informática. Y creo que eso va a... esas diferencias y experiencias van a llevar a cada uno de esos grupos a sacar sus propias conclusiones sobre la mejor manera de desarrollar para la web. Pero creo que la única forma en que realmente puede... Que puede desarrollar de forma sostenible para la web es evaluar críticamente lo que está creando y tratar de alinearse en torno a un enfoque que sirva mejor a los usuarios de esos productos. Y ahí es donde el sitio web y los modelos de aplicaciones web se sientan en mi cabeza cuando evalúo estas cosas.

Drew: Sí. Es interesante. Quiero decir, en el libro, en realidad cita algunos de mis trabajos. Muchas gracias. Y mi elección de tecnologías aburridas en notó básicamente PHP Apache y una pizca de JavaScript enrollado a mano puede crear una experiencia de usuario muy ágil de forma predeterminada, sin necesidad de realizar ninguna optimización en particular. Creo que eso lo convierte en una excelente experiencia de usuario para los visitantes de front-end que vienen y ven contenido en el sitio.

Drew: Pero en realidad, me siento como en ese entorno para crear contenido, una vez que inicias sesión y publicas cosas en el sitio. Creo que adolece un poco de estar construido con un enfoque de sitio web, en lugar de un enfoque de aplicación web más pesado de JavaScript, tanto que estoy pensando... o tal vez necesita ser ambos. Necesito continuar publicando el front-end en buen HTML y CSS estático y pequeños fragmentos de JavaScript. Pero el backend en el que quiero proporcionar una experiencia de creación de contenido tal vez sería mejor una elección de tecnología diferente. Es bastante interesante porque no siempre tiene que ser una cosa o la otra, ¿verdad? No es una opción binaria. Es más un espectro, ¿diría usted?

Jeremy: Sí, absolutamente. Y creo que estamos empezando a ver más discusión en la comunidad sobre el desarrollo web como un espectro como ese. Para ser directo con las personas que podrían estar interesadas en mi libro, definitivamente proviene del lado del sitio web del espectro. Y nuevamente, porque siento que eso siempre es como un buen valor predeterminado. Si no sabe cómo quiere construir algo, probablemente sea mejor intentar construirlo de una manera que minimice el uso de JavaScript y minimice la carga de más trabajo para el cliente. Dicho esto, creo que lo notado es una excelente experiencia. Creo que estas tecnologías gastadas y realmente "aburridas" realmente funcionan bien para la tarea en cuestión. Y lo hace de una manera abierta y habilitante para el desarrollador, ¿verdad?

Jeremy: No es necesario tener un conocimiento profundo de las tiendas de administración de estado o los marcos de administración de estado para lograr realmente este tipo de cosas. Y creo que eso está bien servido por ese enfoque particular. Pero para su punto, creo que hay oportunidades en cualquier sitio web para acercarse a la mitad del espectro sin involucrarse en todo el enrutamiento del lado del cliente como marcos pesados ​​​​que administran todo en el cliente y ese tipo de cosas. Creo que el enfoque de la isla está comenzando a explorar cómo se ve eso. Y lo admito, probablemente he hecho algo del tipo de las islas sin querer. Creo que lo hemos hecho durante bastante tiempo, simplemente no le hemos puesto un nombre. Pero creo que ahora que hemos identificado que tal vez sea un punto medio, podríamos comenzar a ver experiencias web que brindan una buena experiencia de usuario, pero que aún son más interactivas. Con suerte, eso no fue terriblemente serpenteante.

Drew: En cierto modo, se remonta un poco a los días en que incrustábamos una isla de Flash o...

Jeremy: Sí.

Drew: Algo en una página donde esta es nuestra pequeña sección interactiva, y el resto fluye.

Jeremy: Sí, como Flash, oh, Dios mío, tres iteraciones de mi cartera personal de la universidad fueron realmente malas para las imitaciones avanzadas de Flash y como efectos de desplazamiento. Y eso fue muy, muy divertido. Y a veces lo extraño como si hubiera una gran cantidad de contenido que va a desaparecer porque ya no usamos Flash. Y eso realmente apesta, pero en cierto modo fue una especie de precursor de este tipo de islas de las que estamos hablando. Es decir, podrías tener una página web estática y todo, pero luego tendrías esta experiencia ricamente interactiva simplemente como si estuviera justo en el medio.

Drew: Durante mucho tiempo, la mejora progresiva se ha considerado una forma de mejores prácticas para crear experiencias web. ¿Sigue siendo así, crees?

Jeremy: Admitiría que es probable... probablemente no. Admitiría que es más trabajo hacer una mejora progresiva porque, en cierto modo, estás bifurcando tu experiencia de desarrollo. Está tratando de ofrecer la funcionalidad mínima viable de un sitio web de manera que el servidor pueda manejar estas interacciones clave. Pero además de eso, estás diciendo: "Está bien, bueno, ahora quiero facilitar esta interacción para que sea un poco más fluida con JavaScript". Sigo pensando que es una forma viable de lograr sus objetivos con su sitio web o su aplicación o su producto.

Jeremy: Pero lo que diría es que nunca recomendaría que cada interacción en un sitio web tenga que ser facilitada por este tipo de patrón de navegación síncrona. Entonces, como un buen ejemplo, su página de pago para su sitio web económico definitivamente debería tener una ruta de servidor. Debería tener una ruta de servidor para agregar cosas al carrito, y luego debería poder rociar suficiente JavaScript para que sea un poco más agradable para que las cosas puedan ser un poco más rápidas y más asincrónicas.

Drew: Cuando se trata de medir el desempeño. Escuchamos mucho acerca de los principales elementos vitales de la web, principalmente de Google. ¿Son realmente los puntos de referencia contra los que deberíamos medirnos? ¿O es eso lo que Google quiere que pensemos? Ahora aprecio que esta podría ser una pregunta difícil que comenzaste a trabajar en Google.

jeremy: sí, sí. Ya sabes, así que estoy hablando por mí mismo aquí. Creo que los web vitals son... los web vitals básicos iniciales son un buen intento de definir qué partes de la experiencia del usuario son importantes. Creo que las métricas como el cambio de diseño acumulativo y la mayor pintura de contenido comienzan a pensar en la experiencia de maneras que realmente no habíamos comenzado a cuantificar. Antes de un cambio de diseño particularmente acumulativo, porque si alguna vez ha habido un momento en el que tocas con ira es porque a un botón le gusta moverse por la página o algo así. Quiero decir, creo que eso es algo útil para medirlo. es imperfecto Y creo que cualquiera que trabaje en web vitals central estaría de acuerdo en que se desea mejorar algunas de estas métricas. Hay otras métricas con las que no necesariamente estoy completamente de acuerdo. Al igual que el retraso de la primera entrada, es una métrica que es un poco difícil de identificar.

Jeremy: Creo que es realmente útil, ¿verdad? Porque lo que estás diciendo literalmente es que queremos medir la demora y la interactividad en esa primera interacción que hace el usuario, pero le falta un poco de contexto, ¿no? Porque algunas... muchas cosas pueden afectarlo porque no necesariamente siempre se relaciona con JavaScript. El primer retraso de entrada podría representar el retraso en el que se incurre al enfocar el campo del formulario, ¿verdad? Ese tipo de cosas, cosas en HTML. Creo que esas métricas... métricas como el retraso de la primera entrada pueden ser... pueden ser beneficiosas si puedes contextualizarlas con cosas como entradas de la API de tareas largas, tiempo de elementos y ese tipo de cosas. En última instancia, creo que el futuro de Core Web Vitals demostrará que será útil e instrumental para medir lo que hace que una buena experiencia de usuario. Esa es mi opinión personal.

Drew: Supongo que es, es una de esas cosas que siempre puedes medir contra ti mismo, medir tus propias mejoras o si tu experiencia ha empeorado si tu puntaje cambia, sin preocuparte tanto por los semáforos, pero preocupándote por lo que sabes. sobre el contexto de su sitio y cómo un cambio ha hecho una mejora.

Jeremy: Creo que las métricas como el cambio de diseño acumulativo son excelentes, pero también podrían beneficiarse de una pequeña mejora. Tal como está, el cambio de diseño acumulativo mide principalmente los cambios de diseño que ocurren durante la carga. Y como sabemos, cuando un usuario visita una página y aterriza en una página, los cambios de diseño pueden ocurrir en cualquier momento, ¿verdad? Así que definitivamente hay trabajo que creo que se puede hacer para mejorar la forma en que observamos ese tipo de fenómeno, seguro.

Drew: Creo que la estabilidad del diseño es una de las cosas que en realidad es un poco más difícil de lograr cuando se trabaja con la mejora progresiva. A veces, cuando carga una página procesada por el servidor y luego comienza a mejorarla en el cliente, puede existir el peligro de crear ese tipo de cambio de diseño, ¿no es así?

Jeremy: Absolutamente. Y ahí es donde la hidratación de los componentes se vuelve un poco complicada porque las dimensiones de ese componente pueden cambiar por varias razones. Como si pudiera haber contenido presente en el componente del lado del cliente que simplemente no se muestra en el servidor debido al estado que no se evalúa hasta que se ejecuta en el cliente. Es un problema extremadamente difícil. No me voy a sentar aquí y fingir que tengo la bala de plata para eso.

Drew: Quería hablar un poco sobre la dinámica de las importaciones y la división del código, ya que ambas son técnicas diferentes para el problema de descargar y ejecutar un gran paquete de JavaScript por adelantado al comienzo de la experiencia. ¿Existe el riesgo de optimizar en exceso al hacer muchas solicitudes pequeñas, particularmente en los proyectos más pequeños, o es algo en lo que no hay ningún daño en la implementación desde el principio, previniendo que vas a tener estos problemas? ¿O debería esperar hasta que realmente vea problemas de rendimiento antes de pensar en ese tipo de cosas?

Jeremy: Así que recomendaría que el final de lo que acabas de decir es una buena manera de comenzar con esto. No deberíamos intentar optimizar prematuramente a menos que, por supuesto, esas optimizaciones se puedan lograr muy rápida y fácilmente, pero si se necesita mucho esfuerzo para optimizar desde el principio, cuando en realidad no hay muchos problemas de rendimiento, diría que la división de código es probablemente algo que no tiene por qué suceder. Probablemente pueda simplemente cargar esa funcionalidad por adelantado.

Jeremy: Pero por ejemplo, hablo de esto en el libro. Si tiene una interacción de alto valor impulsada por una gran parte de JavaScript, y para mí, una gran parte de JavaScript podría significar 20 kilobytes porque a través del cable está comprimido y eso podría terminar siendo una parte de JavaScript de 60 kilobytes. Luego, si puede sacar eso en el paquete principal o en cualquiera de su miríada de paquetes, su sitio podría estar enviando, ayudará al rendimiento de inicio.

Jeremy: Pero en el libro, discuto una técnica sobre percibir cuándo... o al menos intentar percibir cuándo el usuario podría realizar una interacción de alto valor. Así que el ejemplo que uso es un trozo de JavaScript. Eso se usa para validar el contenido de un formulario porque la validación de formularios HTML es excelente, pero tampoco se le puede aplicar estilo y es bastante sencilla. No hay toneladas de flexibilidad para cosas como, escribir es igual a correo electrónico, ¿verdad? Lo evalúa de cierta manera. Sin embargo, esa validación del formulario en el cliente es realmente útil porque también podemos diseñarlo. Y podemos alinear la apariencia de esa validación para estar más cerca de cuál es la estética de la marca o cuál es la estética del sitio web. Y entonces, en este ejemplo, lo que hice fue, dije, si un usuario enfoca... aunque solo enfoca cualquiera de los campos en el formulario, ese es el punto en el que precargamos esa pieza de JavaScript.

Jeremy: Con suerte, para cuando llegue el momento, y espero porque lleva un poco de tiempo completar un formulario, que la red tenga tiempo suficiente para eliminarlo, de modo que cuando se llame a la importación dinámica, pueda obtener el efectivo para obtener lo que ya ha sido precargado. Es algo con lo que he estado trabajando un poco aquí y allá, y es difícil de hacer en todas las situaciones. Como, por ejemplo, no puede hacer esto de manera confiable todo el tiempo al pasar el mouse porque algunos dispositivos no tienen un puntero fino. Tienen... son... son entradas de toque, ¿verdad? Entonces, un desplazamiento se produce en un momento diferente que si tuviera un puntero fino, por ejemplo.

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy: Una especie de cosa en curso que he estado haciendo desde que salió es jugar con la API de pintura CSS. Me gusta mucho la API de pintura. Quiero decir, siempre ha existido por sí solo…. como a su manera, ya que al igual que el lienzo, el contexto 2D ha sido una cosa. Porque eso es... para aquellos que no lo saben, la API de dolor de CSS es una forma en la que puede incrustar un contexto de lienzo 2D y parametrizarlo y controlarlo con CSS, lo que abre muchas posibilidades realmente interesantes, como puede animar cosas que no podías animar previamente y ese tipo de cosas.

Jeremy: Y recientemente he estado actualizando el blog. Es decir... Soy un gran geek de Final Fantasy, como Final Fantasy II que acabo de reproducir y, por lo tanto, hay como 15 de ellos y 16 saldrán en algún momento, pero es una especie de campo retro. Así que he estado usando la API de pintura CSS para generar un mundo aleatorio usando diferentes mosaicos. Así que hay como ríos y cosas que corren y baldosas de hierba y árboles y ese tipo de cosas. Y parametrizando eso, como si el usuario visitara mi sitio web en modo oscuro... ese trabajo de pintura se representará como si fuera de noche. Tendrá como una especie de superposición y ese tipo de cosas.

Jeremy: Pero la API de pintura es increíble. Tengo que saludar a Tim Holman. Él, lo vi en JSConf Australia e hizo una charla sobre arte generativo. Eso fue realmente solo, realmente me interesó. Y luego Sam Richard, en eso en CSSConf el día anterior habló sobre la API de pintura CSS, cuando esas dos cosas se juntaron para mí, fue como, "Guau, esto es genial". ¡Así que hice algo llamado Paintlets! Es un Paintlets.Herokuapp.com si visita Chrome y tiene que hacerlo, desafortunadamente, porque aún no es muy compatible. Puedes ver un montón de obras de arte aleatorias diferentes generadas aleatoriamente y... sí, solo... eso es lo que me ha pasado, lo siento. Larga historia sobre eso.

Drew: Impresionante. Eso suena genial.

Jeremy: Sí. Si.

Drew: Si a usted, querido oyente, le gustaría saber más de Jeremy, puede encontrarlo en Twitter donde es @malchata y encontrar sus presentaciones escritas, videos y proyectos en su sitio web personal, jeremy.codes. JavaScript responsable está disponible ahora en A Reservar Aparte. Y puede encontrar más información al respecto en responsablejs.dev. Gracias por acompañarme hoy Jeremy, ¿tuviste algunas palabras de despedida?

Jeremy: Siga adelante y construya para la web de la mejor manera que pueda e intente tener en cuenta al usuario. Ese es mi mantra y espero que este libro haga que se mantenga un poco.