Lo Bueno, Lo Malo, y Los Componentes Web

¿Cómo está todo el mundo? ¿Tienen café? Bruce, supongo que somos viejos amigos. Genial. Es estupendo escuchar eso. Bueno, realmente no se podía decir por esa introducción, pero está bien. Bruce y yo nos llevamos muy bien.

Muy bien. Así que hoy vamos a hablar sobre web components. Son buenos. Son malos. Esperemos que no sean feos. Entonces, sí. Web components. Animations. Hay que amarlo. Web components, ¿verdad? No tengo que convencerlos a todos de que los componentes son buenos, ¿verdad? Componentes. Yay.

Muy bien. Aquí hay un ejemplo de un componente. Mira eso. Es un botón. ¡Woo-hoo! Gracias. Ese ha sido mi tiempo. Sí. Así que tenemos nuestro agradable JavaScript en la parte superior. Tenemos nuestro JSX en la parte inferior. Esto es genial. Y algunos de ustedes podrían estar familiarizados con el ejemplo de donde proviene. Es de Vercell.js.

Entonces, si miramos algunas de las otras bibliotecas de componentes que existen ahora, hay un montón de ellas, ¿verdad? Hay un montón de abstracciones de componentes que existen en este espacio. Pero hoy quiero hablarles sobre Web Components.

Entonces, un Web Component es una pieza de UI reutilizable, está habilitado por los web standards. Está incorporado en la plataforma web. Te lo proporcionan gratis los navegadores web. Y realmente el beneficio aquí es que tienes la posibilidad de inicializar tus componentes más rápido y funcionar con menos sobrecarga de biblioteca, lo cual es genial.

Como Bruce presentó, mi nombre es Zach. Blogueo en zackleet.com. Construí Eleventy, que es un generador de sitios estáticos. Y trabajo en Netlify. Y solo para convencerte de que los Web Components son algo que deberías tener en cuenta, te voy a mostrar algunos ejemplos. Hurra. Esto es presión de grupo. Esto es prueba social. Y después de estas cuatro o cinco diapositivas, todos estarán convencidos de que los Web Components son asombrosos. Así que vamos a ello.

Los Web Components, realmente el pan y la mantequilla de los Web Components en este momento son los sistemas de diseño. A la gente le encanta la portabilidad de los Web Components. Les encanta que estén incorporados en la plataforma. Y eso es realmente donde verás la mayoría de los ejemplos de ellos en la naturaleza. Microsoft construyó MSN con Web Components. VMware tiene un bonito sistema de diseño. Google tiene diseño material que se exporta a Web Components. IBM tiene uno, Salesforce. Mi favorito personal, Nord Health construido con 11-D es un muy buen ejemplo de eso. GitHub usa Web Components. Adobe realmente trajo Photoshop a la Web con Web Components usando Lit, lo cual creo que es genial. Y eso está usando Spectrum Web Components que es un envoltorio alrededor de Lit. ¿Son los Web Components una cosa? Mira todos estos logos, logos, logos, logos. Nos encantan los logos. ¿Eso realmente nos convence de que las cosas son buenas? Sí, creo que sí. Si vas a las estadísticas web de Google Chrome, tienen hasta abril de este año, medido que el 18, casi el 19 por ciento de las cargas de páginas en el navegador web de Google Chrome son propiedades que utilizan Web Components.

Así que bastante popular, increíble. Eso os ha convencido a todos de que son buenos y deberían ser utilizados porque son populares, ¿verdad? Las bibliotecas de componentes también se están adaptando a los Web Components. Pero hoy vamos a ver cómo crear un Web Component desde cero para que sepas cómo funciona, puedas construirlo, puedas utilizar su poder único. Pero estas bibliotecas de componentes, animations, algunas de ellas también incluyen opciones para exportar directamente a Web Components. Y creo que eso también es genial porque podemos reutilizar los patterns existentes que tenemos para nuestra biblioteca y framework code y exportar a Web Components para usar en la naturaleza.

Entonces, ¿qué son los Web Components? ¿Qué son? Aquí tienes un Web Component. ¡Woo! Tan bueno como ese ejemplo de botón que mostré antes. Tenemos el tipo de componente contador omnipresente que a la gente le encanta demostrar. Esto se llama un elemento personalizado y así es como se ve cuando lo demuestras, ¿verdad? Tienes este encantador contador que cuenta hacia arriba cuando haces clic en el botón. Increíble code. Nos encanta.

Y así es como se ve cuando añades un botón al ejemplo. Esta es la ranura por defecto, el componente hijo de un elemento personalizado y acabamos de añadir un botón aquí. Esto se llama light DOM pero yo simplemente lo llamo HTML plano porque no necesitamos palabras elegantes para cosas que ya existen. Y así es como se ve el JavaScript para un elemento personalizado. Así que tenemos, cuando usas nuestro registro de elementos personalizados, definimos qué nombre de etiqueta queremos asociar con eso y luego pasamos una clase. Así que lo que pasa con el registro de elementos personalizados es que cada vez que el navegador encuentra un elemento my counter en la página, no necesita existir en la carga inicial de la página, puedes traerlo más tarde. Estos serán mejorados o hidratados usando estándares web. Y todo esto te lo proporciona gratis el navegador web. Hay algunas limitaciones menores aquí con los registros de elementos personalizados. No puedes definir un nombre de elemento que no tenga un guión en él. Así que si tienes un elemento como este, necesitas añadir un guión. Asombroso. Y la razón de que exista esta limitación es porque no quieres superponerte con los elementos HTML existentes que forman parte del estándar web.

Así que para hacer este ejemplo un poco más completo, vamos a añadir algo más de JavaScript para incrementar realmente nuestro número de botón. El número que se muestra en nuestro botón. Así es como se ve. Así que podemos tener cualquier número de elementos myCounter en la página, y todos serán mejorados usando este mecanismo. Así que haces clic en el botón, y aumentas el número dentro de él. Asombroso. Así que la forma en que me gusta evaluar cómo se cargan los componentes, y esto realmente se une con la charla de Barry de antes, realmente queremos poner tanto en HTML como podamos. Así que lo que me gusta hacer cuando estoy evaluando las características de rendimiento de una biblioteca o un framework, me gusta ver cómo puede verse antes de que se inicialice JavaScript y cómo se ve después de que se ha inicializado JavaScript. Y queremos minimizar la cantidad de desplazamiento del diseño que ocurre allí. Y así con este ejemplo específicamente, no hay desplazamiento del diseño antes y después porque no hicimos ninguna modificación del DOM. Todo el HTML que se renderiza es el mismo que el HTML que estamos usando en nuestra página.

De cierta manera, este patrón es exclusivamente renderizado por el servidor. No hicimos nada más que añadir algunos oyentes de eventos aquí. No estamos usando ninguna biblioteca JavaScript, no hay sobrecarga de la biblioteca, y podemos tener una bonita mejora progresiva sin ningún cambio de diseño, lo cual es genial para un core web vitals también.

Hay algunos web components que construí en la naturaleza que reutilizan este patrón de alguna manera. Hay un componente de detalles utils que construí para añadir comportamientos adicionales a tus elementos de resumen detallados en tu página. Y puedes ir y revisar ese componente si estás interesado en él. Este solo añade un comportamiento para cerrar el elemento de detalles cuando haces clic fuera de él.

En este ejemplo, tengo un componente de video radio star que solo reproduce un elemento de video en la página cuando es visible, lo cual creo que es un buen patrón, especialmente cuando no necesariamente quieres reproducir todo el camino antes de que el usuario incluso se encuentre con ellos en la página. Así que queremos autoplay, pero solo cuando el usuario se desplaza hasta él. De esta manera, estamos mejorando el HTML existente que es el hijo de nuestro web component.

Y otro ejemplo que tengo aquí en mi Github es un componente is lan. Y ahora Astro es un componente muy popular framework, o un framework popular que realmente depende mucho de las islas architecture, que es solo una especie de carga perezosa picante, elegante, lo cual sé que es quizás una cosa controversial que decir, pero lo diré de todos modos. Así que sí, hay un componente web is land que hace algo muy similar. Así que cualquier web components que estén anidados dentro de este componente is land solo se inicializan cuando son visibles para el usuario final, lo cual creo que es genial. Y hay un montón de diferentes mecanismos para eso también. Puedes hacerlo solo cuando está inactivo, puedes hacerlo cuando se habilita el ahorro de data, puedes hacer bajo consultas de medios, o solo cuando el usuario ha interactuado con él.

Ahora, el problema con este patrón aquí es que todo el contenido dentro de nuestro web componente se repite de alguna manera. Así que la experiencia de autoría no es genial, porque realmente no queremos tener que anidar todo este HTML repetido a lo largo de todo nuestro contenido. Así que mi queja número uno probablemente con este patrón es que tengo que duplicar este HTML yo mismo, a menos que tenga una biblioteca o framework existente en la parte superior para hacerlo por mí. Y no me gusta repetirme. Y no me gusta repetirme. Así que cuando tenemos tres instancias de contador en la página, esta es la clase de experiencia de autoría de lo que esperaría o lo que querría hacer. Quiero las cosas únicas dentro de las instancias del componente. No quiero ninguna cosa repetida que tenga que gestionar yo mismo.

Así que para hacer eso, tenemos que graduarnos a un nivel dos de Web Components y empezar a usar ShadowDOM. Así que ShadowDOM es una forma de tener una plantilla reutilizable que puedes inyectarte en JavaScript. Y esto es lo que podría parecer. Así que tenemos un elemento de plantilla en nuestra página. Tenemos nuestro botón dentro de él. Tenemos nuestra ranura.

Y luego la ranura predeterminada, o el light DOM o el simple HTML, que está anidado dentro de nuestras instancias de componentes, se inserta en ese contenido. Y he atenuado un poco el code del ejemplo anterior. Y puedes ver el nuevo code que hemos añadido solo para inyectar la plantilla ShadowDOM. Así que son solo un par de líneas. Encontramos el elemento de la plantilla, lo adjuntamos, y eso es todo.

De esta manera, obtenemos los beneficios de no tener que repetir nuestro elemento de botón en cada instancia de nuestro componente. Y el contenido se inserta automáticamente para nosotros. Pero, volviendo a nuestra experiencia pre-JavaScript y post-JavaScript, dependiendo de dónde ejecutemos ese registro de elementos personalizados code, esto podría interponer algún cambio de diseño porque el contenido que estaba disponible para el componente antes de que JavaScript se inicializara era solo un número. Y después de que el componente se renderiza usando ShadowDOM, es un botón y un número dentro de él. Así que de esta manera tenemos un componente renderizado por JavaScript del cliente. La ventaja aquí es que ninguno de los contenidos se repite. Y de nuevo, no tenemos ninguna biblioteca JavaScript, eso es genial. No nos estamos repitiendo en nuestras instancias de componentes, pero tenemos un mayor riesgo de cambio de diseño.

Así que en CSS, en realidad tenemos un gancho para controlar los estilos antes de que un registro de componentes esté disponible o antes de que un componente se inicialice en nuestro registro, y después. Así que este es un gran gancho para decir que quiero renderizar mi componente de cierta manera antes y después de que se inicialice. Porque realmente, no quiero ningún JavaScript en mi camino crítico de renderización, quiero que mi página sea lo más rápida posible. Y algunas bibliotecas de componentes existentes a las que enlacé anteriormente en esta demostración, y no voy a nombrar necesariamente nombres a menos que encuentres mis notas de orador aquí, usan este mecanismo para ocultar el componente por completo. Así que esto todavía tiene algún cambio de diseño cuando estás haciendo manipulación de contenido o JavaScript del DOM, discúlpame. Así que no recomendaría hacer esto, si podemos evitarlo, porque, de nuevo, crea una dependencia adicional de JavaScript en tus estilos. Si JavaScript falla o tu JavaScript no se ejecuta o obtienes un error en tu página de quizás una extensión de navegador, tu página va a ser invisible, lo cual no es genial. Aquí hay otro ejemplo de otra biblioteca de componentes sin nombre en la naturaleza con Web Components. Solo están alternando la opacidad aquí. Así que supongo que esto es quizás parte de mi marca, si la gente está familiarizada con mi extenso trabajo en las redes sociales, trabajo muy relevante también. Solo JavaScript es una queja aquí. No necesariamente queremos requerir JavaScript para tener una renderización completa de nuestro Web Component. Y con Shadow DOM eso es un requisito. Entonces, ¿cómo trabajamos alrededor de esto? Hey, hay una nueva especificación, nivel tres, Declarative Shadow DOM. En realidad podemos usar la plantilla y el navegador inyectará esa plantilla en el Shadow DOM para nosotros. Así que esto alivia completamente la dependencia de JavaScript que necesitábamos del ejemplo anterior y obtenemos todos los beneficios de Shadow DOM. Así es como podría verse tu instancia de componente.

Y entonces, nuestra experiencia antes y después de JavaScript aquí es muy similar al primer nivel cuando solo hicimos un elemento personalizado y repetimos nuestro HTML en todas nuestras instancias de componentes. En este caso, solo estamos repitiendo nuestra plantilla. Pero hablaré de eso más tarde. Y esto es para lo que sirve el polyfill para los navegadores existentes que no tienen Declarative Shadow DOM, que actualmente es solo Firefox. Así es como se ve el polyfill para agregar soporte para eso. Ahora, por supuesto, un polyfill es solo otra dependencia de JavaScript aquí, lo cual no necesariamente queremos. Pero esto desaparecerá con el tiempo, lo cual es genial. Pero cuanto antes Firefox pueda agregar soporte para Declarative Shadow DOM, mejor estaremos. Entonces, con Web Components, con Declarative Shadow DOM, obtenemos componentes renderizados por el servidor. No estamos utilizando ninguna biblioteca de JavaScript aquí. El polyfill es solo un par de líneas, como puedes ver. Así que incluso en Firefox, todavía es bastante pequeño, aunque es JavaScript renderizado en Firefox hasta que agreguen soporte allí. Obtenemos una encapsulación completa de nuestros componentes. Obtenemos un mejoramiento progresivo sin desplazamiento de diseño. Pero el único problema aquí es que nos estamos repitiendo bastante mal. Es casi peor que el primer ejemplo. Entonces, cuando tienes tres instancias diferentes de nuestro componente de contador con Declarative Shadow DOM, todo esto se repite. Tienes que repetir las plantillas en cada instancia, y eso es para habilitar el comportamiento de transmisión, porque no necesariamente querrías que la plantilla no estuviera disponible cuando la instancia del componente lo esté.

Ahora, el beneficio... Uno de los más fáciles y más... El beneficio más fácilmente comunicado de usar Shadow DOM, ya sea con una dependencia de JavaScript o de manera declarativa, es que tienes CSS con alcance. Así que puedes anidar un elemento de estilo dentro de tu plantilla Shadow DOM, ya sea que lo hagas de manera declarativa o no. Y todos los estilos del componente están limitados solo al componente, lo cual es increíble. Y esta asignación de color azul solo estará limitada a nuestra instancia de contador. Y tienes algunas otras propiedades de CSS... O, discúlpame, pseudo clases de CSS que te permiten acceder a esas cosas también. Puedes decir, quiero colon host, que te da acceso al nombre de la etiqueta. Puedes poner un selector adicional en host, y puedes agregar host context, que es casi como un selector de padre. Volvemos a repetirnos una y otra vez en estas plantillas. No queremos tener que anidar nuestro CSS con alcance en cada instancia de componente también. Eso es mucho peor. Así que de alguna manera, casi hay un enfrentamiento entre no repetirse y obtener soporte completo de renderizado en el lado del servidor. Y el elefante en la habitación aquí, en este ejemplo, es JavaScript. Tenemos una dependencia de JavaScript que nos da la capacidad de no repetirnos en todas nuestras instancias de componentes, pero si queremos eliminar esa dependencia de JavaScript para obtener una experiencia de carga lo más rápida posible, tenemos que repetirnos y repetir esos estilos y plantillas en cada instancia de componente. Así que vamos a pasar al nivel 4, que es cómo añadir renderizado en el lado del servidor sin repetirnos. Y así, si miras este ejemplo anterior donde teníamos nuestro Shadow DOM declarativo anidado en todas nuestras instancias de componentes, puedes ver que queremos que exista así. Queremos una plantilla reutilizable que podamos reasignar a una definición de componente, y que eso sea manejado por el navegador web. Ahora hay algunos problemas que resolver con la transmisión allí, pero creo que eso es algo que está llegando a la plataforma web y he enlazado con un texto super pequeño allí, una URL si quieres ver la discusión en curso de eso. Pero el meollo de la cuestión es que el SSR no está realmente suficientemente resuelto por la plataforma aún. Creo que está llegando, creo que llegaremos allí, pero los frameworks de componentes no han resuelto este problema tampoco. Están sujetos a las mismas limitaciones que la plataforma. Así que creo que lo importante que me gustaría comunicar aquí es que no deberíamos mantener necesariamente a los web components a un estándar más alto que nuestros frameworks de JavaScript existentes y las bibliotecas de componentes que usamos hoy. Y históricamente, ha sido muy adversarial, ¿verdad? Los frameworks de JavaScript han estado en contra de los web components y quizás los críticos más vocales de los web components. Pero creo que hay algunos beneficios muy únicos que podemos obtener de los web components, específicamente solo el registro de elementos personalizados que puede ser aprovechado muy bien por los frameworks de JavaScript. Y así, solo repasando las bibliotecas de framework de las que hablamos, los logotipos que miramos antes y en la parte inferior izquierda puedes ver que algunos de estos frameworks de componentes tienen objetivos de compilación para web components. Y luego en la parte superior derecha, hay web components de primera parte. Así que creas cosas en el mundo de los web components y luego el SSR es una característica añadida encima de eso. Y luego en la parte inferior derecha, hay WebCE y enhanced.dev, esos son dos frameworks existentes.

Trabajo en WebCE, enhanced.dev es otro en el que realmente he intentado hacer que la historia de SSR y los web components sean SSR primero en lugar de una característica añadida más tarde. Y si quieres comprobar la compatibilidad con los frameworks de componentes existentes y los estándares web, puedes comprobar customelements everywhere.com con guiones entre los nombres. La alerta de spoiler, React es el único que está siendo mantenido activamente que tiene fallos en estas pruebas, lo cual es desafortunado. Esperemos que llegue en React 19 pero no estoy conteniendo la respiración.

Vale. Entonces, de nuevo, SSR está algo soportado para los web components con estos frameworks de componentes que tienen web components primero, estás creando en web components, Lit y Stencil son dos ejemplos de eso. Y Enhance y WebC están tomando un enfoque diferente. Queremos que la experiencia de SSR ocurra primero. Así que solo voy a pasar por un ejemplo super rápido de un componente WebC. Así es como se ve la experiencia de creación en tu plantilla. Y luego tienes una definición de componente a la derecha. Y así no tenemos que repetirnos pero aún obtenemos el beneficio completo del shadow DOM declarativo y renderizará la salida para ti. Lo repetiremos de esta manera, pero no necesariamente tienes que hacerlo en tu experiencia de creación. Aún obtienes una buena experiencia de creación. Y hay otra manera de hacerlo en WebC también. Puedes compilar a HTML regular. Así que puedes compilar al nivel uno de los ejemplos que mostramos hoy. Y esta es la salida que obtendrás de ese ejemplo. Así que en esta demo es muy svelte-esque en la salida del compilador. Así que usando bibliotecas de componentes ssrfirst, obtenemos el beneficio de HTML amigable para la transmisión y renderizado en el servidor. No tenemos ninguna biblioteca de JavaScript. No hay ningún tipo de sobrecarga adicional de la biblioteca de JavaScript allí. Podemos encapsular, no nos repetimos, y obtenemos una buena mejora progresiva. Si quieres probar WebC, hay un buen proyecto de inicio en mi GitHub, en el GitHub 11 para hacer eso. Pero realmente, lo principal que creo que Barry realmente enfatizó hoy es que si puedes hacerlo en HTML, será más rápido que JavaScript. Y creo que eso realmente se ha demostrado cierto si has intentado usar CSS y JavaScript bibliotecas en los últimos años. Así que gracias por escuchar.

En primer lugar, porque dijiste que te sientes mal porque nadie en esta conferencia tiene una fotografía tuya enmarcada, anónimo dijo, sin preguntas, solo quería decir que la presentación es de primera. Gracias, Zach. Vaya, vale.

Entonces, sí. Diez de diez. Haremos negocios de nuevo. Sí. Un aplauso para la Sra. Leatherman por enviar eso.

Dip preguntó, ¿cómo manejas las colisiones al manejar múltiples versiones de un componente web en la misma página? Sí, quiero decir, hay una especificación que viene que son los Registros de Elementos con Alcance y eso será una especie de manera de manejar el mismo nombre de componente en tu página registrado varias veces, así que eso viene. Los nombres de las etiquetas de los componentes son algo globales ahora, pero ese es un problema que se resolverá en el futuro. ¿El nombre era Registros de Elementos con Alcance? Sí, creo que sí. Vaya. Sospecho que no he oído hablar de esto cada vez más ahora.

Hablando de nombres de componentes, cuéntanos brevemente sobre el guion en los nombres. ¿De qué se trata eso? Sí, necesitas agregar un guion en tus nombres de etiquetas para que no entre en conflicto con las adiciones actuales y futuras a la especificación HTML. Creo que esa es una limitación importante porque no necesariamente queremos que nuestros elementos personalizados colisionen con los elementos HTML que agreguen más tarde. Pero quiero decir, las adiciones a HTML parecen estar ocurriendo bastante lentamente. Creo que CSS ahora mismo es increíble cómo las cosas se han acelerado y cómo están enviando cosas muy rápidamente en el mundo de CSS. Así que esperemos que más cosas lleguen a HTML también. Así que básicamente el guion en el nombre es porque el W3C y WOTWG han dicho que nunca inventarán una etiqueta HTML central con un guion en su nombre y por lo tanto, no colisionará.

¿Qué pasa con los atributos? ¿Qué pasa con ellos? ¿Tienen guiones en ellos? Oh no. Puedes nombrarlos como quieras. Sí. Y ni siquiera creo que necesiten, si están en un elemento personalizado, ni siquiera creo que necesiten tener el prefijo data que es común en los patterns HTML existentes. Así que desata tu imaginación con los nombres de los atributos, woohoo. Desata tu imaginación con los nombres de los atributos, lo escuchaste aquí primero, gente de fiesta.

Hay una pregunta interesante que podría haber desaparecido. Pero era simplemente, ¿por qué los desarrolladores pasan tanto tiempo preocupándose por cosas que no son importantes? Realmente no tengo el contexto de esto. Ahora, ¿qué? Hay dos formas diferentes en las que puedo tomar esa pregunta. La primera forma es que toda la charla que acabo de dar es algo que no es importante y no deberíamos preocuparnos por ello. Así que voy a ignorar esa. Y supongo que los desarrolladores se preocupan mucho por cosas fuera del alcance de mi charla que no son relevantes.

No lo sé. Creo que esa es una pregunta difícil de responder. Siento que los desarrolladores realmente se suben muy fácilmente a los trenes de moda. Somos criaturas sociales y tomamos señales de lo que otras personas están haciendo. Y entonces, si alguien a quien admiras y sigues te dice que te preocupes por algo, entonces empiezas a preocuparte por ello también. Y entonces creo que, sí, creo que esta masterclass es genial porque necesitamos que más personas estén frente a personas hablando de cosas como el rendimiento web y la accesibilidad, y, sí, las cosas que quizás han sido un poco marginadas, pero cosas que son muy importantes no obstante.

Aunque no había contexto para esa pregunta, la incluí porque era una pregunta genuina de un miembro de la audiencia, pero sí, se ajusta a algo en lo que estaba pensando. Como mencionaste a menudo acerca de, no te repitas. Lo entiendo, pero trabajamos en una industria en la que la gente se preocupa por no repetirse y sin embargo están más que felices de lanzar 48 kilotones de JavaScript por el cable en lugar de simplemente escribir algo de HTML, ¿qué pasa con eso? Eso entra en toda la cuestión de la experiencia del desarrollador versus la experiencia del usuario.

OK, haré la pregunta. No sé si tenemos tiempo para eso, ya que nos quedan treinta segundos, pero eso es quizás una hora entera. Haré la pregunta a la que puedes responder en veintiséis segundos. ¿Qué es más importante, la experiencia del desarrollador o la experiencia del usuario final? Creo que la experiencia del usuario es mucho más importante que la experiencia del desarrollador. Y lo escuchaste aquí, gente. El líder de pensamiento, Zach Leatherman dijo que la experiencia del usuario es más importante que la experiencia del desarrollador. Sí. Cien por ciento.