Autoría de HTML en un Mundo JavaScript

Hola, soy Tony Alicia. Esto es Autoría de HTML en un Mundo de JavaScript. Primero, un poco sobre mí. Puedes encontrarme enseñando en Udemy, Pluralsight, Teachable y YouTube y trabajo con una empresa llamada The Smythe Group. Ahora, si te gustaría conectar, no dudes en ponerte en contacto. Puedes encontrarme y mis cursos en mi sitio web en TonyAlicia.dev. Envíame un correo electrónico, encuéntrame en YouTube, Twitter. Puedes ir a TheSmytheGroup.com para descubrir cómo ayudamos a los equipos de desarrollo a convertirse en lo mejor que pueden ser y hacer su mejor trabajo.

Pero esta masterclass es Autoría de HTML en un Mundo de JavaScript. Y todos nosotros, todos ustedes que están escuchando, todos ustedes pasan su tiempo en JavaScript. Ya sea que estemos escribiendo TypeScript, ya sea que estemos lidiando con bases de datos, ya sea que estemos en el servidor, ya sea que estemos escribiendo pruebas, nuestra vida gira en torno a JavaScript. Es un mundo de JavaScript. Y sin embargo, hay tres patas del taburete cuando se trata de tecnologías web fundamentales, HTML, CSS, y JavaScript.

Entonces, en esta masterclass, me gustaría desafiarte a cambiar tu forma de pensar, a cambiar tu enfoque de cómo construyes tus componentes de React. Lo que quiero decir con eso es esto. Digamos que obtienes un prototipo. Este es un ejemplo muy simplista. Pero obtienes un prototipo, quizás de un diseñador, y ahora tienes que implementarlo. ¿Cuál es la primera cosa que pasa por tu cabeza? ¿Cuáles son los primeros pasos en tu mente mientras imaginas implementar el prototipo en React? Bueno, puede ser que empieces a pensar en cuáles serán los componentes, cómo será la estructura del componente, cuál será el CSS para hacer que el sitio web o la aplicación web se parezcan a un prototipo. Entonces, realmente, mentalmente, comenzamos en el mundo del CSS. ¿Cómo puedo hacer que se parezca al prototipo? Y comenzamos en el mundo de JS. ¿Cómo puedo hacer que funcione? ¿Cómo puedo hacer que la aplicación real haga lo que el prototipo dice que debería hacer? Y luego, en el camino, en algún lugar del camino, metemos algo de HTML. Realmente es una especie de estructura, un andamio, un esqueleto en el que colgar un código de JavaScript y CSS. Y si estamos escribiendo JSX, podrías decir, bueno, no estoy escribiendo HTML. Pero realmente, lo estamos, porque ambos se están convirtiendo en el DOM. Y así, en última instancia para el usuario, es lo mismo que si estuviéramos escribiendo HTML. Así que elegir nuestros elementos es algo que sucede en el camino. Me gustaría desafiarte a cambiar tu mentalidad y en su lugar pensar en HTML primero. ¿Qué pasaría si pensáramos en nuestro HTML primero y luego comenzáramos a pensar en cómo hacer que la aplicación funcione y el CSS viene de la mano mientras lo hacemos parecer al prototipo? De nuevo, si solo estamos mirando el prototipo y estamos pensando en el HTML, lo que estamos realmente pensando es cuál es el significado de cada una de estas piezas de información que vemos en el prototipo. Si estamos pensando en HTML, estamos pensando en semántica y la palabra semántica significa tener que ver con el significado. El punto principal de autorizar nuestro HTML, y vamos a introducir esa frase cuando autorizamos nuestro HTML, cuando nos comportamos como autores de HTML, es decir, estamos eligiendo nuestros elementos de HTML de acuerdo a la información y las cosas que están sucediendo en la página en la pantalla, entonces estamos lidiando con semántica. Estamos autorizando de una manera semántica.

Ahora me gustaría hablar sobre los beneficios de autorizar nuestro HTML de una manera semántica y qué realmente parece. Para empezar, hablemos de la capacidad de aprendizaje. Todos estamos tratando de mantenernos al día con las últimas cosas que suceden en el mundo de JavaScript. Pero HTML es una habilidad. La autoría de HTML es una habilidad. Y es una habilidad muy aprendible.

Vamos, por ejemplo, a un sitio web que muchos desarrolladores web de front-end nunca han visitado. La Especificación de HTML. En esa especificación tenemos lo que es esencialmente nuestro diccionario. El significado de cada uno de los elementos de HTML. Creo que todos los desarrolladores de front-end deberían al menos estar familiarizados con la sección 4 de la Especificación de HTML, donde especifica lo que significan todos los elementos, lo que hacen.

Por ejemplo, el elemento address. Puedo hacer clic en él, y si uso ese elemento, representa, de nuevo semántica, representa la información de contacto para el ancestro del artículo o elemento body más cercano. Entonces, en otras palabras, si tengo información de contacto para la página, o para algo que está en un elemento de artículo, puedo usar address. Esa sería la elección más semántica. Estaría expresando significado, en lugar de simplemente envolverlo en un div, y hablaremos de eso en un momento.

Entonces, la idea es que HTML es aprendible. Puedes familiarizarte con los significados de cada uno de los elementos. Y eso puede ayudarte en tu trabajo. Ahora, más allá de eso, podemos hablar de legibilidad y mantenibilidad. Ese es otro beneficio importante de pensar en tu HTML, de autorizar tu HTML y tus componentes, en lugar de pensar primero en el CSS y JavaScript.

Entonces, ¿qué queremos decir con esto? Bueno, si no autorizo mi HTML, si pienso primero en el CSS y JS y solo intento hacer que se parezca al prototipo y funcione como el prototipo, entonces probablemente podría terminar con algo que se vea así. Podría tener muchos divs y spans, span div div div span, span div span div div span, porque realmente solo estoy usando el HTML como una forma de tener declaraciones if y cosas para devolver de mis componentes funcionales y cosas para colgar mis clases de CSS. Pero no estoy pensando en el contenido. ¿Qué significa el contenido?

Otra forma de pensar en ello es que, si miro el prototipo, puedo pensar primero en el contenido sin ninguna de las visuales. ¿Qué son estas cosas? ¿Es un encabezado? ¿Es un par de nombre y valor con un nombre y luego su valor real, como un título, como modelo Corolla año 2010, es una lista? ¿Es una lista donde el orden importa o no importa? ¿Es información de dirección? ¿Es información de contacto? Y luego comenzamos a marcar semánticamente nuestro documento. Y podría terminar pareciéndose a algo como esto. Por ejemplo, el DL, DT y DD. Bueno, si voy a la sección cuatro, y lo busco, puedo ver que el DL, DT, DD, representan listas de asociación de pares de nombre y valor. Entonces, ¿cómo puedo marcar un par de nombre y valor que es una pieza de data con su etiqueta que no es un elemento de formulario? Bueno, esta sería una forma. En lugar de span y div, puedo hacerlo de manera semántica.

Ahora, cuando pensamos en esto, cuando comparamos lo no semántico con lo semántico, ¿cuáles son los beneficios? Los beneficios son inmediatamente, la versión semántica es más legible. Puedo mirar el contenido y entender lo que es. Y por lo tanto, un año a partir de ahora, cuando alguien más en mi equipo o yo, cuando vuelva a mirar estos componentes, bueno, ahora es más mantenible. Es más fácil para mí entender lo que son, lo que hacen, cuál era su intención. Y cuando piensas en volver a mirar tus componentes, a menudo estas piezas de data no están escritas explícitamente.

A menudo son variables. Entonces, si tienes div, div, span, div, span con muchas variables, puede ser muy difícil entender lo que estás viendo. Por otro lado, si estás bien marcado, si has autorizado tu HTML, el HTML en sí te está proporcionando información sobre lo que es ese contenido. Además, también, si estás en el navegador y estás en las herramientas del navegador y abres los elementos, ahora en lugar de tener que buscar entre un montón de div, span, div, span, span, div, span, vas a tener elementos disponibles que pueden ayudarte a encontrar tu camino mientras estás depurando, editando, etc. Algunos de estos son beneficios para la legibilidad y mantenibilidad de tus componentes.

Entonces, si tengo, en el futuro, un componente React y estoy usando mi JSX y estoy eligiendo los elementos que finalmente terminarán estando en el DOM, incluso solo tener buenos elementos semánticos que se devuelven de mis React componentes y dentro de mis React componentes, voy a ver ese beneficio. Abren el componente y de inmediato tienen una mejor imagen de lo que es esta cosa y qué hace.

Bien, ahora, ¿cuál es otro beneficio? Otro beneficio es la accessibilidad. Ahora, cuando piensas en accessibilidad podrías pensar en ARIA, ¿verdad? Pero, sabes, puedes agregar demasiado ARIA. Puedes empeorar las cosas. El primer paso de la accessibilidad, y ARIA es importante, pero el primer paso es un buen HTML que permite al navegador o a los lectores de pantalla usar los elementos como se anticipó porque las personas que hacen navegadores y lectores de pantalla, ¿en qué están mirando para decidir cómo funcionan las cosas? ¿Cómo interpretan el HTML? Están mirando la especificación, la especificación de HTML. Entonces, si digo que esta pieza de información, esta pieza de data, esta pieza interactiva de mi página web o aplicación web, si la marco correctamente, si autorizo mi HTML, ahora el agente del usuario puede hacer su trabajo correctamente. Y por agente del usuario, lo que queremos decir es un programa de software que traduce el contenido al formato que un usuario quiere consumir. Verás, nuestro HTML no se trata de construir páginas web visuales. Se trata de marcar información para que los agentes del usuario, programas, como nuestro navegador, como un lector de pantalla, puedan decidir qué hacer. Ahora, si marco un pedazo de texto como fuerte, entonces tal vez un navegador visual lo hará en negrita y un lector de pantalla lo dirá en un tono de voz diferente. Todo se trata de cómo el usuario quiere consumir la información. Por eso se llama agente del usuario. Está trabajando en nombre del usuario, y al autorizar nuestro HTML, también estamos trabajando en nombre del usuario. Estamos haciendo que nuestros React componentes sean más accesibles. Y esto vuelve a los fundamentos del HTML. Aquí hay una cita y solo me centraré en un par de aspectos de la especificación de HTML en sí. HTML transmite significado, no presentación. Entonces, no tienes que cambiar la página para tener diferentes presentaciones, y eso incluye presentaciones a través de varios lectores de pantalla. Por ejemplo, un usuario ciego que usa un navegador, usando síntesis de voz, podría obtener diferentes tonos vocales dependiendo de cómo hayamos marcado nuestras aplicaciones, nuestras páginas web. Entonces, accessibilidad.

Ahora aquí hay otro. Rendimiento. ¿Piensas en HTML cuando piensas en rendimiento? Probablemente estás pensando en tu JavaScript, probablemente estás pensando en tu base de datos, probablemente estás pensando en la red y en las funciones de borde, lo que sea que venga a la mente, pero sabes que puedes mejorar enormemente el rendimiento de tus aplicaciones React al autorizar bien tu HTML. ¿Cómo? Bueno, cada elemento que colocas en tu componente, cada nivel de elementos que agregas, ¿qué se convierte finalmente? Se convierte en un nodo en el DOM. Se convierte en una pieza de información en la memoria del dispositivo del usuario. Se convierte en algo que el CSS tiene que atravesar. Porque cuando haces un selector de CSS, le estás pidiendo que mire a través del DOM y encuentre ciertos nodos. Cuanto más grande, más ancho, más profundo sea tu DOM, más lento será el rendimiento de tu aplicación. Y esa no es una idea nueva.

Por ejemplo, en la puntuación de Google Lighthouse, existe la idea de evitar un tamaño excesivo del DOM. Y eso dice que por encima de cierta cantidad de nodos, 800 nodos, 1400 nodos, vas a tener problemas de performance que serán señalados por la puntuación de Lighthouse. Pero eso no quiere decir que de repente, tan pronto como alcances ese número de nodos, tengas un mal performance. A medida que añades más nodos a tu DOM, tu performance disminuye. Es la cantidad de tiempo que tarda el JavaScript en generar plantillas, o si está pregenerado en el servidor, son cantidades más grandes de información siendo descargadas. Hace que tu CSS sea más lento. Y el navegador, el motor del navegador tiene que pintar todas estas cosas en la pantalla, tiene que decidir qué hacer. Así que mientras estás desplazándote o estás abriendo y cerrando un acordeón, cuantos más elementos del DOM tengas, menos rendimiento tendrán esas interacciones porque más tiene que hacer el navegador.

De hecho, he trabajado con equipos que tenían un problema de performance en algún tablero complejo o página y aplicación, y estaban mirando el JavaScript y la database y la red. Y en realidad, tomamos un par de horas para autorizar su HTML. Tenían divs dentro de divs dentro de divs. Grandes cantidades de nodos anidados. Y el problema es que con algo como React, bueno, si autorizo mal en un componente, y luego pongo ese componente en un bucle dentro de un componente mal autorizado, y pongo ese componente en un bucle dentro de otro componente mal autorizado en HTML, mi DOM final puede ser mucho más grande de lo que parece ser en mi JSX de componente. Así que terminaron con tantos nodos del DOM. Pero ese era el problema de performance. Un par de horas de trabajo, y vimos un enorme aumento de performance. Al autorizar correctamente, reduciendo el tamaño del DOM. Porque cuando piensas en el HTML, tiendes a escribir menos HTML. Y también tiendes a tener ya los marcadores que necesitas para tu CSS. Por ejemplo, si pienso en este código semántico. Inmediatamente empiezo a ver también dónde podrían estar los límites de los componentes. Inmediatamente empiezo a ver dónde podría necesitar colgar mi CSS. Podría necesitar estar adjunto a estos nodos del DOM para coincidir con el prototipo. Pero si sólo estoy pensando en hacer que se vea bien. No sólo termino con HTML no semántico. Tiendo a terminar con HTML que se ve así. Anidado, anidado, anidado. Porque todo lo que estoy pensando es, Oh, necesito CSS para eso, déjame añadir un elemento. Oh, necesito CSS para eso, déjame añadir un elemento. Y terminamos reduciendo, impactando negativamente, el performance de nuestra aplicación simplemente por no autorizar nuestro HTML.

Ahora hay otro beneficio. Y ese beneficio es la preparación para el futuro. Recuerda que dijimos que la idea es que estás diciéndole al agente de usuario qué es esto, qué son estas piezas de información. Y eso significa que si un futuro agente de usuario consume el DOM, consume los resultados de tu JSX, consume tu HTML, entonces será capaz de determinar cómo presentar a sus usuarios tu información.

Por ejemplo, aquí está un nuevo agente de usuario, Safari para Vision OS. Y cuando se habló de Vision OS y Safari y Vision OS, en una de las diapositivas, se habló de regiones interactivas, es decir, que estás mirando una página web. ¿Cómo sabemos que esto es algo en lo que puedo enfocarme, interactuar con, que puedo copiar y pegar, sea cual sea el caso? Bueno, miraron el HTML, comenzando con cosas como botones, enlaces y menús. Así que, en el futuro, si uso una etiqueta p, un párrafo, en lugar de un div, entonces un futuro OS como Vision OS podría decir, ah, bueno, la etiqueta p es algo que puedo copiar y pegar. Pero si todo son divs, realmente no lo sabemos, ¿verdad? Así que, si inviertes el tiempo ahora en tu HTML, entonces puedes ahorrar tiempo más tarde, y haces que tu aplicación sea más a prueba de futuro, durará más tiempo a medida que los agentes de usuario cambien en el futuro.

Así que a menudo la pregunta es, ¿por dónde empezar? Ya tengo muchos divs y spans en mis componentes de React. Bueno, algunos lugares fáciles para empezar. Para empezar a poner tu mentalidad en el lugar de autorizar tu HTML, piensa en elementos que no tienen CSS por defecto, porque a menudo la gente recurre a los divs porque no tienen CSS por defecto. Pero hay otros elementos que no tienen CSS por defecto, y podrías empezar por ahí. Quiero mostrarte una cosa en la especificación de HTML. Podemos ver que el elemento div es en realidad llamado en la especificación el elemento de último recurso, cuando ningún otro elemento es adecuado. Pero hay muchos otros elementos adecuados donde a menudo usamos div. Por ejemplo, un artículo que es una pieza de información autocontenida, una tarjeta podría ser un artículo, una sección de tu documento donde hay encabezados, eso podría ser un reemplazo para un div. Un reemplazo para un div, el elemento de encabezado, a menudo estamos envolviendo piezas. Tal vez tienes un encabezado y un subencabezado y algunos iconos. Así que los envolvemos en divs. El elemento de encabezado podría ser perfecto para eso. Un aside para algo que no tiene que ver directamente con lo que está en la página, como aquí hay algunos otros enlaces, aquí hay algunas otras actividades que puedes realizar en esta aplicación en particular que no está relacionada con la página que estoy viendo en la aplicación. Todos esos pueden ser intercambios directos por un div. Y puedes empezar a mirar tu contenido y empezar a pensar, bueno, ¿es esto un artículo? ¿Es esta una sección? ¿Es este un encabezado? ¿Es esto un lado? Y tu equipo puede divertirse teniendo esas conversaciones porque puede que no haya una respuesta correcta, una respuesta perfecta, pero al menos estás pensando en ello y has decidido como equipo, sabes qué, creemos que esto es un aside. Y, verás inmediatamente los beneficios en mantenibilidad, legibilidad, cuando vuelvas a editar estos componentes.

Así que de nuevo, te reto, prueba un enfoque diferente. En lugar de CSS primero, sigue añadiendo elementos de HTML según lo necesites, haz que todo funcione, haz que se parezca a un prototipo. Considera cambiarlo, empieza mirando tu contenido, autorizando tu HTML, y luego empieza a hacer que funcione, empieza a hacer que se parezca al prototipo. Estarás pensando de una manera que no sólo será aprendible como desarrollador, te acostumbrarás a lo que son los elementos y lo que está disponible, sino también de una manera que te ayudará a tener aplicaciones de React más legibles, mantenibles, accesibles y a prueba de futuro. Y eso es todo, así que gracias de nuevo, y espero verte en línea. Disfruta de la masterclass.