El Bueno, el Malo y los Componentes Web

Spanish audio is available in the player settings
Rate this content
Bookmark

No ha faltado críticas justas e injustas hacia los Componentes Web por parte de una amplia gama de personas que construyen para la web, incluidos, pero no limitados a, los autores de Frameworks de JavaScript en supuesta competencia con la plataforma. En esta charla te mostraré cómo navegar y simplificar el paisaje multifacético de los componentes web, satisfaciendo las críticas comunes y mostrando cómo puedes utilizar la plataforma de manera más efectiva hoy en día.

29 min
01 Jun, 2023

Video Summary and Transcription

Los Componentes Web son una pieza de UI reutilizable habilitada por estándares web e integrada en la plataforma web. Ofrecen el potencial de una inicialización más rápida de los componentes y menos sobrecarga de bibliotecas. Los Componentes Web se pueden crear desde cero y utilizar con bibliotecas de componentes existentes. Shadow DOM y Declarative Shadow DOM proporcionan beneficios como CSS con alcance y componentes renderizados en el servidor. Se discute el compromiso entre no repetirse a uno mismo y lograr el soporte completo de renderizado en el lado del servidor. La experiencia del usuario se considera más importante que la experiencia del desarrollador.

Available in English

1. Introducción a los Componentes Web

Short description:

Hoy vamos a hablar sobre los componentes web. Son buenos. Son malos. Esperemos que no sean feos. Aquí hay un ejemplo de un componente. Mira eso. Es un botón. Tenemos nuestro bonito JavaScript arriba. Tenemos nuestro JSX abajo. Algunos de ustedes pueden estar familiarizados con de dónde viene este ejemplo. Es de Vercell.js. Hay un montón de abstracciones de componentes que existen en el espacio. Pero hoy quiero hablarles sobre los Componentes Web.

¿Cómo están todos? ¿Tomaron un poco de café? Bruce, supongo que somos viejos amigos. Genial. Es genial escuchar eso. Bueno, realmente no podrías decirlo por esa introducción, pero está bien. Bruce y yo nos llevamos muy bien.

Muy bien. Hoy vamos a hablar sobre los componentes web. Son buenos. Son malos. Esperemos que no sean feos. Así que sí. Componentes web. Animaciones. Me encanta. Componentes web, ¿verdad? No tengo que convencerlos de que los componentes son buenos, ¿verdad? Componentes. ¡Hurra!

Muy bien. Aquí hay un ejemplo de un componente. Mira eso. Es un botón. ¡Woo-hoo! Gracias. Eso ha sido todo por mi parte. Sí. Tenemos nuestro bonito JavaScript arriba. Tenemos nuestro JSX abajo. Esto es genial. Y algunos de ustedes pueden estar familiarizados con de dónde viene este ejemplo. Es de Vercell.js.

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

2. Componentes Web y Sistemas de Diseño

Short description:

Los Componentes Web son una pieza de UI reutilizable habilitada por los estándares web e integrada en la plataforma web. Ofrecen el potencial de una inicialización más rápida de los componentes y menos sobrecarga de bibliotecas. Ejemplos de Componentes Web en uso incluyen MSN, material design y Adobe Photoshop en la web. Según las estadísticas web de Google Chrome, casi el 19 por ciento de las cargas de páginas en el navegador utilizan Componentes Web.

Entonces, un Componente Web es una pieza de UI reutilizable, habilitada por los estándares web. Está integrada en la plataforma web. Es proporcionada de forma gratuita por los navegadores web. Y realmente, el beneficio aquí es que tienes el potencial de inicializar tus componentes más rápido y ejecutarlos con menos sobrecarga de bibliotecas, lo cual es genial.

Entonces, como Bruce presentó, mi nombre es Zach. Escribo en zackleet.com. He construido Eleventy, que es un generador de sitios estáticos. Y trabajo en Netlify. Y solo para convencerte de que los Componentes Web son algo en lo que deberías estar interesado, voy a mostrarte algunos ejemplos. ¡Hurra! Esto es presión de grupo. Esto es prueba social. Y después de estas cuatro o cinco diapositivas, todos ustedes estarán convencidos de que los Componentes Web son increíbles. Así que empecemos.

Los Componentes Web, realmente el pan y la mantequilla de los Componentes Web en este momento son los sistemas de diseño. A la gente le encanta la portabilidad de los Componentes Web. Les encanta que estén integrados en la plataforma. Y ahí es donde encontrarás la mayoría de los ejemplos de ellos en la naturaleza. Microsoft construyó MSN con Componentes Web. VMware tiene un buen sistema de diseño. Google tiene material design que exporta a Componentes Web. IBM tiene uno, Salesforce. Mi favorito personal, Nord Health construido con 11-D, es un muy buen ejemplo de eso. GitHub utiliza Componentes Web. Adobe incluso llevó Photoshop a la web con Componentes Web utilizando Lit, lo cual me parece genial. Y eso utiliza Spectrum Componentes Web, que es un envoltorio alrededor de Lit. Entonces, ¿los Componentes Web son una cosa? Mira todos estos logotipos, logotipos, logotipos, logotipos. Nos encantan los logotipos. ¿Eso realmente nos convence de que las cosas son buenas? Sí, creo que sí. Si vas a las estadísticas web de Google Chrome, han medido que, a partir de abril de este año, casi el 19 por ciento de las cargas de páginas en el navegador web de Google Chrome utilizan Componentes Web.

3. Introducción a la Creación de Componentes Web

Short description:

Hoy aprenderemos cómo crear Componentes Web desde cero y aprovechar su poder único. Las bibliotecas de componentes se están adaptando a los Componentes Web, lo que nos permite exportar a ellos y reutilizar patrones existentes.

Muy populares, increíbles. Eso los convence 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 Componentes Web. Pero hoy vamos a aprender cómo crear un Componente Web desde cero para que sepas cómo funciona, puedas construirlo y aprovechar su poder único. Pero estas bibliotecas de componentes, animaciones, algunas de ellas también incluyen opciones para exportar directamente a Componentes Web. Y creo que eso también es genial porque podemos reutilizar los patrones existentes que tenemos en nuestro código de biblioteca y framework y exportar a Componentes Web para usar en la práctica.

4. Understanding Web Components

Short description:

Los Componentes Web son elementos personalizados que se pueden agregar a una página web. Permiten la creación de componentes de interfaz de usuario reutilizables. Al utilizar un registro de elementos personalizados, el navegador mejora o hidrata los elementos utilizando estándares web. Las limitaciones incluyen el requisito de que los nombres de los elementos incluyan un guion para evitar la superposición con elementos HTML existentes. La evaluación del rendimiento de carga de los componentes implica minimizar el cambio de diseño y maximizar el contenido HTML antes de la inicialización de JavaScript.

¿Qué son? Aquí tienes un Componente Web. ¡Guau! Tan bueno como ese ejemplo de botón que mostré antes. Tenemos una especie de componente de contador ubicuo 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 hermoso contador que cuenta hacia arriba cuando haces clic en el botón. Código increíble. Nos encanta.

Y así es como se ve cuando agregas un botón al ejemplo. Este es el slot predeterminado, el componente hijo de un elemento personalizado y simplemente agregamos un botón aquí. Esto se llama DOM ligero, pero yo simplemente lo llamo HTML plano porque no necesitamos palabras sofisticadas para cosas que ya existen. Y así es como se ve el JavaScript para un elemento personalizado. Entonces, cuando usamos nuestro registro de elementos personalizados, definimos qué nombre de etiqueta queremos asociar con eso y luego pasamos una clase. Lo que sucede con el registro de elementos personalizados es que cada vez que el navegador encuentra un elemento myCounter en la página, no es necesario que exista en la carga inicial de la página, puedes buscarlo más adelante. Esos se mejorarán o hidratarán utilizando estándares web. Y todo esto te lo proporciona el navegador web de forma gratuita. Aquí hay algunas limitaciones menores con los registros de elementos personalizados. No puedes definir un nombre de elemento que no tenga un guion. Entonces, si tienes un elemento como este, necesitas agregar un guion. Increíble. Y la razón por la que existe esa limitación es porque no quieres superponerte con los elementos HTML existentes que forman parte del estándar web.

Para hacer este ejemplo un poco más completo, agreguemos un poco de JavaScript adicional para incrementar nuestro número de botón. El número que se muestra en nuestro botón. Esto es lo que parece. Así que podemos tener cualquier número de elementos myCounter en la página y todos se mejorarán utilizando este mecanismo. Haces clic en el botón y aumentas el número dentro de él. Increíble. La forma en que me gusta evaluar cómo se cargan los componentes, y esto realmente se relaciona con la charla de Barry anterior, es que realmente queremos poner tanto como sea posible en HTML. Entonces, lo que me gusta hacer cuando estoy evaluando las características de rendimiento de una biblioteca o un framework, es ver cómo puede verse antes de que se haya inicializado JavaScript y cómo se ve después de que se haya inicializado JavaScript. Y queremos minimizar la cantidad de cambio de diseño que ocurre allí. Y así, con este ejemplo en particular, no hay cambio de diseño antes y después porque no hicimos ninguna modificación en el DOM. Todo el HTML que se renderiza es el mismo que estamos usando en nuestra página.

5. Patrones de Componentes Web y ShadowDOM

Short description:

Este patrón permite el renderizado en el servidor sin sobrecarga de bibliotecas y habilita la mejora progresiva. Ejemplos de componentes web que reutilizan este patrón incluyen un componente de utilidades de detalles y un componente de video de radio estrella. Otro ejemplo es el componente de isla, que inicializa componentes web anidados cuando son visibles para el usuario. Sin embargo, este patrón conduce a contenido repetido dentro del componente web, lo cual puede ser problemático para la experiencia de autoría. Para resolver esto, podemos usar ShadowDOM, que proporciona una plantilla reutilizable inyectada a través de JavaScript.

Entonces, de alguna manera, este patrón es exclusivamente renderizado en el servidor. No hicimos nada más que agregar algunos event listeners aquí. No estamos utilizando ninguna biblioteca JavaScript, no hay sobrecarga de biblioteca y podemos tener una mejora progresiva agradable sin ningún cambio de diseño, lo cual es genial para las core web vitals también.

Entonces, hay algunos componentes web que construí en la naturaleza que reutilizan este patrón. Hay un componente de utilidades de detalles que construí para agregar comportamientos adicionales a los elementos de resumen detallados en tu página. Puedes ir y revisar ese componente si estás interesado en él. Este simplemente agrega un comportamiento para cerrar el elemento de detalles cuando haces clic fuera de él.

En este ejemplo, tengo un componente de video de radio estrella 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 reproducirlo por completo antes de que el usuario lo haya encontrado en la página. Entonces queremos reproducción automática, pero solo cuando el usuario se desplaza hasta él. De esta manera, estamos mejorando el HTML existente que es el hijo de nuestro componente web.

Otro ejemplo que tengo aquí en mi Github es un componente de isla. Y ahora Astro es un framework de componentes muy popular, o un framework popular que realmente depende mucho de la arquitectura de islas, que es solo un poco picante, una carga diferida elegante, lo cual sé que tal vez es algo controvertido de decir, pero lo diré de todos modos. Sí, hay un componente web de isla que hace algo muy similar. Entonces, cualquier componente web que esté anidado dentro de este componente de isla solo se inicializa cuando son visibles para el usuario final, lo cual me parece genial. Y hay varios mecanismos diferentes para eso también. Puedes hacerlo solo cuando está inactivo, puedes hacerlo cuando se habilita el guardado de datos, puedes hacerlo 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 componente web se repite. La experiencia de autoría no es buena, porque realmente no queremos tener que anidar todo este HTML repetido en todo nuestro contenido. Entonces, mi principal queja probablemente con este patrón es que tengo que duplicar este HTML yo mismo, a menos que tenga una biblioteca o un framework existente para hacerlo por mí. Y no me gusta repetirme. Y no me gusta repetirme. Entonces, cuando tenemos tres instancias de contador en la página, esto es más o menos lo que esperaría o lo que querría hacer. Quiero las cosas únicas dentro de las instancias del componente. No quiero cosas repetidas que tenga que gestionar yo mismo.

Entonces, para hacer eso, tenemos que pasar al nivel dos de los Componentes Web y usar ShadowDOM. ShadowDOM es una forma de tener una plantilla reutilizable que puedes inyectar tú mismo en JavaScript. Y esto es cómo podría verse. Tenemos un elemento de plantilla en nuestra página. Tenemos nuestro botón dentro de él. Tenemos nuestro slot.

6. ShadowDOM y Declarative Shadow DOM

Short description:

La ranura predeterminada, o el DOM ligero, se inserta en el contenido de nuestras instancias de componente. Al inyectar la plantilla ShadowDOM, evitamos repetir el elemento de botón y logramos la inserción automática en la ranura. Sin embargo, existe un mayor riesgo de cambio de diseño. Podemos usar ganchos CSS para controlar los estilos antes y después de la inicialización del componente. Algunas bibliotecas de componentes ocultan el componente utilizando este mecanismo, pero crea una dependencia adicional de JavaScript. Declarative Shadow DOM, una nueva especificación, nos permite usar la plantilla e inyectarla en el Shadow DOM, eliminando la dependencia de JavaScript y brindando todos los beneficios de Shadow DOM.

Y luego la ranura predeterminada, o el DOM ligero o el HTML plano, que está anidado dentro de nuestras instancias de componente, se inserta en ese contenido. Y así he sombreado el código del ejemplo anterior. Y puedes ver el nuevo código que hemos agregado solo para inyectar la plantilla ShadowDOM. Así que son solo un par de líneas. Encontramos el elemento de plantilla, lo adjuntamos y eso es todo.

Entonces, de esa 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 en la ranura para nosotros. Pero, volviendo a nuestra experiencia pre-JavaScript y post-JavaScript, dependiendo de dónde ejecutemos ese código de registro de elementos personalizados, esto podría interrumpir un cambio de diseño porque el contenido que estaba disponible para el componente antes de que se inicializara JavaScript 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. Entonces, de esa manera tenemos un componente renderizado por cliente en JavaScript. El beneficio aquí es que ninguno del contenido se repite. Y nuevamente, no tenemos ninguna biblioteca de JavaScript, eso es genial. No nos estamos repitiendo en nuestras instancias de componente, pero tenemos un mayor riesgo de cambio de diseño.

Entonces, en CSS, en realidad tenemos un gancho para controlar los estilos antes de que esté disponible el registro de componentes o antes de que se inicialice un componente en nuestro registro, y después. 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 tener ningún JavaScript en mi ruta de representación crítica, quiero que mi página sea lo más rápida posible. Y algunas bibliotecas de componentes existentes a las que hice referencia anteriormente en esta demostración, y no voy a mencionar nombres a menos que encuentres mis notas del presentador aquí, utilizan este mecanismo para ocultar por completo el componente. Entonces, esto todavía tiene algún cambio de diseño cuando estás haciendo manipulación de contenido o JavaScript del DOM, perdón. Entonces, no recomendaría hacer esto, si podemos evitarlo, porque, nuevamente, crea una dependencia adicional de JavaScript en tus estilos. Si JavaScript falla o tu JavaScript no se ejecuta o tienes un error en tu página debido a tal vez una extensión del navegador, tu página será invisible, lo cual no es genial. Aquí hay otro ejemplo de otra biblioteca de componentes sin nombre en la naturaleza con Componentes Web. Aquí están alternando la opacidad. Así que supongo que esto es tal vez parte de mi marca, si las personas están familiarizadas con mi extenso trabajo en las redes sociales, también muy relevante. Aquí solo hay una queja sobre JavaScript. No necesariamente queremos requerir JavaScript para tener una representación completa de nuestro Componente Web. Y con Shadow DOM eso es un requisito. Entonces, ¿cómo lo solucionamos? 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 por nosotros. Esto elimina por completo la dependencia de JavaScript que necesitábamos en el ejemplo anterior y obtenemos todos los beneficios de Shadow DOM. Así es como podría verse tu instancia de componente.

7. Repetición de plantillas con Declarative Shadow DOM

Short description:

Nuestra experiencia antes y después de JavaScript aquí es muy similar al primer nivel cuando simplemente creamos un elemento personalizado y repetimos nuestro HTML en todas las instancias de nuestro componente. En este caso, solo estamos repitiendo nuestra plantilla. Pero hablaré de eso más adelante. Con Componentes Web, con Declarative Shadow DOM, obtenemos componentes renderizados en el servidor. No estamos utilizando ninguna biblioteca de JavaScript aquí. Obtenemos una encapsulación completa de nuestros componentes. Obtenemos una mejora progresiva sin cambios en el diseño. Pero el único problema aquí es que nos estamos repitiendo bastante. Es casi peor que el primer ejemplo.

Y así, nuestra experiencia antes y después de JavaScript aquí es muy similar al primer nivel cuando simplemente creamos un elemento personalizado y repetimos nuestro HTML en todas las instancias de nuestro componente. En este caso, solo estamos repitiendo nuestra plantilla. Pero hablaré de eso más adelante. Y esto es para los navegadores existentes que no tienen Declarative Shadow DOM, que actualmente solo es Firefox. Así es como se ve el polyfill para agregar soporte para eso. Ahora, por supuesto, un polyfill es otra dependencia de JavaScript aquí, que 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 Componentes Web, con Declarative Shadow DOM, obtenemos componentes renderizados en el servidor. No estamos utilizando ninguna biblioteca de JavaScript aquí. El polyfill es solo un par de líneas, como puedes ver. Entonces, incluso en Firefox, sigue siendo bastante pequeño, aunque está renderizado en JavaScript en Firefox hasta que agreguen soporte allí. Obtenemos una encapsulación completa de nuestros componentes. Obtenemos una mejora progresiva sin cambios en el diseño. Pero el único problema aquí es que nos estamos repitiendo bastante. Es casi peor que el primer ejemplo. Entonces, cuando tienes tres instancias diferentes de nuestro componente contador con Declarative Shadow DOM, todo esto se repite. Debes repetir las plantillas en cada instancia, y eso es para habilitar el comportamiento de transmisión, porque no querrías que la plantilla no esté disponible cuando se instancia el componente.

8. Beneficios de usar Shadow DOM y Componentes Web

Short description:

Uno de los beneficios más fáciles y comunicados de usar Shadow DOM es el CSS con alcance. El CSS con alcance te permite anidar un elemento de estilo dentro de tu plantilla Shadow DOM, asegurando que los estilos del componente estén limitados solo al componente. Sin embargo, hay un compromiso entre no repetirte y lograr el soporte completo de renderizado en el servidor. Los frameworks de JavaScript y las bibliotecas de componentes aún no han resuelto completamente el problema del SSR. Los componentes web ofrecen beneficios únicos, como el registro de elementos personalizados, que pueden ser aprovechados por los frameworks de JavaScript. Algunos frameworks de componentes tienen objetivos de compilación para componentes web, y también hay componentes web de primera parte disponibles.

Ahora, el beneficio... Uno de los beneficios más fáciles y comunicados 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 esos estilos del componente están limitados solo al componente, lo cual es increíble. Y esta asignación de color azul solo se aplicará al ejemplo de nuestro contador. Y tienes algunas otras propiedades CSS... O, perdón, pseudo clases CSS que también te permiten acceder a esas cosas. Puedes decir, quiero colon host, lo cual te da acceso al nombre de la etiqueta. Puedes poner un selector adicional en host, y puedes agregar contexto de host, que es casi como un selector padre. Volvemos a repetirnos una y otra vez en estas plantillas. No queremos tener que anidar nuestro CSS con alcance en cada instancia del componente también. Eso es mucho peor. Entonces, de alguna manera, hay casi un enfrentamiento entre no repetirte y obtener un soporte completo de renderizado en el servidor. Y el elefante en la habitación aquí, en este ejemplo, es JavaScript. Tenemos una dependencia de JavaScript que nos permite no repetirnos en todas las instancias de nuestro componente, 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 del componente. Así que vamos a pasar al nivel 4, que es cómo agregar el renderizado en el servidor sin repetirnos. Si observas este ejemplo anterior donde teníamos nuestro Shadow DOM declarativo anidado en todas las instancias de nuestro componente, puedes ver que queremos que exista así. Queremos una plantilla reutilizable que podamos asignar a una definición de componente, y que el navegador web se encargue de eso por nosotros. Ahora hay algunos problemas que resolver con la transmisión, pero creo que eso es algo que está llegando a la plataforma web y he vinculado con un texto muy pequeño allí, una URL si quieres ver la discusión en curso sobre eso. Pero la esencia de la situación es que el SSR no está realmente resuelto de manera suficiente por la plataforma todavía. Creo que está llegando, creo que llegaremos allí, pero los frameworks de componentes no han resuelto este problema tan bien. Están sujetos a las mismas limitaciones que la plataforma. Creo que lo importante que me gustaría comunicar aquí es que no debemos tener a los componentes web necesariamente a un estándar más alto que nuestros frameworks y bibliotecas de JavaScript existentes que usamos hoy en día. Históricamente, ha sido muy adversarial, ¿verdad? Los frameworks de JavaScript han estado en contra de los componentes web y tal vez los críticos más vocales de los componentes web. Pero creo que hay algunos beneficios muy únicos que podemos obtener de los componentes web, específicamente el registro de elementos personalizados que pueden ser aprovechados muy bien por los frameworks de JavaScript. Y así, pasando por las bibliotecas de frameworks que hemos hablado, los logotipos que hemos visto antes y en la parte inferior izquierda puedes ver que algunos de estos frameworks de componentes tienen objetivos de SSR o, perdón, tienen objetivos de compilación para componentes web. Y luego, en la parte superior derecha, hay componentes web de primera parte. Así que creas cosas y los componentes web se integran y luego el SSR es una característica adicional sobre eso. Y luego, en la parte inferior derecha, hay un WebCE y enhanced.dev, que son dos frameworks existentes.

9. Web Components SSR and WebC

Short description:

Trabajo en WebCE, enhanced.dev es otro en el que realmente he intentado hacer que la historia de SSR y los componentes web sean primero en lugar de una característica añadida más tarde. SSR está bastante soportado para los componentes web con estos frameworks de componentes que tienen los componentes web primero, tu autoría y componentes web, 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. Voy a mostrar un ejemplo muy rápido de un componente WebC. Al utilizar bibliotecas de componentes ssrfirst, obtenemos el beneficio de un HTML renderizado en el servidor y compatible con la transmisión. No tenemos ninguna biblioteca de JavaScript adicional. No hay sobrecarga de biblioteca JavaScript. Podemos encapsular, no repetirnos y obtener una mejora de progreso. 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 ha destacado hoy es que si puedes hacerlo en HTML, será más rápido que JavaScript. Y creo que eso se ha demostrado realmente cierto si has intentado usar bibliotecas de CSS y JavaScript en los últimos años.

Trabajo en WebCE, enhanced.dev es otro en el que realmente he intentado hacer que la historia de SSR y los componentes web sean 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 visitar customelements-everywhere.com con guiones entre los nombres. La sorpresa es que React es el único que se mantiene activamente y tiene fallos en estas pruebas, lo cual es lamentable. Esperemos que se solucione en React 19, pero no tengo muchas esperanzas.

Entonces, nuevamente, SSR está bastante soportado para los componentes web con estos frameworks de componentes que tienen los componentes web primero, tu autoría y componentes web, 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. Voy a mostrar un ejemplo muy rápido de un componente WebC. Así es como se ve la experiencia de autoría en tu plantilla. Y luego tienes una definición de componente a la derecha. Así que no tenemos que repetirnos, pero aún obtenemos todos los beneficios del declarative shadow DOM y se renderizará la salida para ti. Lo repetiremos de esta manera, pero no necesariamente tienes que hacerlo en tu experiencia de autoría. Aún obtienes una buena experiencia de autoría. Y también hay otra forma de hacerlo en WebC. Puedes compilar a HTML regular. Así que puedes compilar al nivel uno de los ejemplos que mostramos hoy. Y este es el resultado que obtendrás de ese ejemplo. En esta demostración, se parece mucho a Svelte en la salida del compilador. Al utilizar bibliotecas de componentes ssrfirst, obtenemos el beneficio de un HTML renderizado en el servidor y compatible con la transmisión. No tenemos ninguna biblioteca de JavaScript. No hay sobrecarga de biblioteca de JavaScript. Podemos encapsular, no repetirnos y obtener una mejora de progreso. 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 ha destacado hoy es que si puedes hacerlo en HTML, será más rápido que JavaScript. Y creo que eso se ha demostrado realmente cierto si has intentado usar bibliotecas de CSS y JavaScript en los últimos años. Así que gracias por escuchar.

En primer lugar, porque dijiste que te sentías mal porque nadie en esta conferencia tiene una fotografía enmarcada tuya, alguien anónimo dijo: no hay pregunta, solo quería decir que la presentación es de primera categoría. Gracias, Zach. Wow, okay.

QnA

Handling Collisions and Naming Conventions

Short description:

Entonces, sí. Diez de diez. Haremos negocios de nuevo. Sí. Un aplauso para la Sra. Leatherman por enviar eso. Dip preguntó, ¿cómo lidias con las colisiones al manejar múltiples versiones de un componente web en la misma página? ¿Los registros de elementos con ámbito era su nombre? Sí, creo que sí. Hablando de nombres de componentes, cuéntanos brevemente sobre el guion en los nombres. ¿De qué se trata eso? Básicamente, el guion en el nombre es porque el W3C y el WOTWG han dicho que nunca inventarán una etiqueta HTML básica con un guion en su nombre y, por lo tanto, no chocará. ¿Y los atributos? ¿Qué pasa con ellos? Oh no. Puedes nombrarlos como quieras. Hay una pregunta interesante que podría haber desaparecido. Pero era simplemente, ¿por qué los desarrolladores dedican tanto tiempo a preocuparse por cosas que no son importantes? Realmente no tengo el contexto de esto. ¿Ahora qué? Hay dos formas diferentes en las que puedo interpretar esa pregunta. La primera forma es que toda la charla que acabo de dar no es importante y no deberíamos preocuparnos por eso. Así que voy a ignorar esa pregunta. Y asumir que los desarrolladores se preocupan mucho por cosas fuera del alcance de mi charla que no son relevantes.

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

Dip preguntó, ¿cómo lidias con 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 llamada registros de elementos con ámbito y eso será una especie de forma de manejar el mismo nombre de componente registrado varias veces en tu página, así que eso está por venir. Esos nombres de etiqueta de componente son globales en este momento, pero ese es un problema que se resolverá en el futuro. ¿Los registros de elementos con ámbito era su nombre? Sí, creo que sí. Vaya. Sospecho que no he oído hablar de esto en cantidades crecientes ahora.

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

¿Y los atributos? ¿Qué pasa con ellos? Oh no. Puedes nombrarlos como quieras. Sí. Y ni siquiera creo que necesiten, si están en un elemento personalizado, ni siquiera necesitan tener el prefijo de datos que es común en los patrones HTML existentes. Así que sé creativo con los nombres de atributos, ¡woohoo! Sé creativo con los nombres de atributos, lo escuchaste aquí primero, gente de fiesta.

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

Developer Experience vs User Experience

Short description:

Los desarrolladores se suben fácilmente a los trenes de moda, tomando referencias de otros. Esta conferencia destaca la importancia del rendimiento web y la accesibilidad. En nuestra industria, la gente se preocupa por no repetirse, pero aún así utiliza JavaScript en exceso. Surge la pregunta de la experiencia del desarrollador frente a la experiencia del usuario. Según Zach Leatherman, la experiencia del usuario es más importante que la experiencia del desarrollador.

No lo sé. Creo que esa es una pregunta difícil de responder. Siento que los desarrolladores se suben fácilmente a los trenes de moda. Somos criaturas sociales y tendemos a seguir las tendencias de lo que hacen los demás. Y si alguien a quien admiras y sigues te dice que te preocupes por algo en particular, entonces también empiezas a preocuparte por eso. Así que creo que esta conferencia es genial porque necesitamos que más personas hablen sobre temas como el rendimiento web y la accesibilidad, y sí, cosas que tal vez hayan sido marginadas un poco, pero que son muy importantes de todos modos.

Aunque no había contexto para esa pregunta, la incluí porque era una pregunta genuina de un miembro del público, pero se relaciona con algo en lo que estaba pensando. Como mencionaste a menudo, no repetirse a uno mismo. Entiendo eso, pero trabajamos en una industria en la que la gente se preocupa por no repetirse y, sin embargo, están más que dispuestos a enviar 48 kilotones de JavaScript en lugar de simplemente escribir un poco de HTML, ¿de qué se trata eso? Eso nos lleva a la pregunta de la experiencia del desarrollador frente a la experiencia del usuario.

De acuerdo, haré la pregunta. No sé si tenemos tiempo para eso, ya que nos quedan treinta segundos, pero eso podría ser una hora entera. Haré la pregunta y tú 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 del desarrollador. Sí. Cien por ciento.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Day Berlin 2022React Day Berlin 2022
34 min
It's Time to De-Fragment the Web
Top Content
Over the past few years, the number of web frameworks available to us has exploded. In some ways, the breadth of choice is a clear win for our ecosystem. However, for many of us, it also comes with harsh drawbacks: - Have you ever used a popular open-sourced component built for framework A, and wished it existed in framework B? What about a design system library? - Does your company have frontends built in different frameworks, and your web teams are frustrated about the wasted hours needed to achieve a consistent design system? - Does your team build SDKs for web frameworks, and must manually re-write them for each framework? The solution to all 3 of these problems exists today. To fully understand it, we must first examine today’s web frameworks, re-think what a component should look like, and introduce a new Intermediate Representation of our components. This is what we have done at Builder.io when we created Mitosis, and we’re excited to share it with everyone.
JSNation Live 2021JSNation Live 2021
28 min
Web Components, Lit and Santa 🎅
Get started with Web Components – enabling you to define new HTML elements that work everywhere regular HTML does. This talk will focus on Lit, a suite from Google that helps you create WCs with features you'd expect like data-binding and declarative definitions. It'll also cover how we've used them to build one of the web's jolliest sites, Google's Santa Tracker 🎅
React Summit US 2023React Summit US 2023
21 min
Authoring HTML in a JavaScript World
 In this talk, Tony shows how an authoring and semantic HTML-first approach to JSX template work leads to more readable, maintainable, and accessible UI components. He demonstrates how to think through implementing a UI prototype in a semantic way, authoring HTML before visuals. He shows how accessible markup improves performance, reduces DOM size, minimizes time spent on CSS, and reduces cognitive load not only for developers, but also for all our users, no matter how they consume our sites and applications.
JSNation 2022JSNation 2022
20 min
Immutable Web Apps
Resolving dependencies when they are all bundled together is easy. Resolving dependencies when they are in being loaded via script tags is much more challenging. The goal of this talk is to explain how Meltwater handles dependency resolution when building native Web Component based applications that rely on packages published by many different teams.
JSNation 2022JSNation 2022
10 min
Web Components are awesome!
Ever wondered how by placing "video" or "audio" into your HTML, you get a media player with controls included? Or how, depending on the type attribute, "input" can be a button, a place to enter text, select a date or file, color picker and more? What if you could create your own element? The answer: Web Components! 🤯 In this talk, we’ll take a look at what Web Components are, how to make one and include it into an application.
React Advanced Conference 2021React Advanced Conference 2021
32 min
Let's talk about Web Components
Before the dawn of some of the most popular frameworks (read: React and Vue), there was Web components. Web Components take one of the best parts of these frameworks (reusable components) and combine it with the best parts of web development (native browser support and not needing to set up a build process). As if that's not enough, web components allow you use the same functions across any framework.If at this point, you're wondering "If web components are so awesome, why haven't I heard about them before?", then you're in luck because that's exactly what this talk is about.In this presentation, we'll take a look at what web components are, why web components are awesome, why web components can be a pain and how we can use web components both as a standalone tool and together with frameworks.

Workshops on related topic

JSNation Live 2021JSNation Live 2021
184 min
Web Components in Action
Workshop
The workshop extends JavaScript programming language knowledge, overviews general software design patterns. It is focused on Web Components standards and technologies built on top of them, like Lit-HTML and Lit-Element. We also practice writing Web Components both with native JavaScript and using Lit-Element. In the end we overview key tooling to develop an application - open-wc.