Autoría de HTML en un Mundo JavaScript

Rate this content
Bookmark

En esta charla, Tony muestra cómo un enfoque de autoría y HTML semántico primero para el trabajo de plantillas JSX conduce a componentes de interfaz de usuario más legibles, mantenibles y accesibles. Demuestra cómo pensar en implementar un prototipo de interfaz de usuario de una manera semántica, autoría de HTML antes de los visuales. Muestra cómo el marcado accesible mejora el rendimiento, reduce el tamaño del DOM, minimiza el tiempo dedicado a CSS y reduce la carga cognitiva no solo para los desarrolladores, sino también para todos nuestros usuarios, sin importar cómo consuman nuestros sitios y aplicaciones.

21 min
15 Nov, 2023

AI Generated Video Summary

Esta charla de Tony Alicia se centra en la autoría de HTML en un mundo JavaScript. El orador desafía a los desarrolladores a cambiar su enfoque para construir componentes React comenzando con HTML primero. Al autorizar HTML de una manera semántica, se puede mejorar la legibilidad y el mantenimiento. Un HTML bien autorizado proporciona una mejor comprensión del contenido y mejora la accesibilidad. También tiene beneficios de rendimiento al reducir el tamaño del DOM. Invertir tiempo en HTML puede ahorrar tiempo y hacer que las aplicaciones sean más a prueba de futuro.

1. Introducción y Antecedentes

Short description:

Hola, soy Tony Alicia. Esto es Autoría de HTML en un Mundo de JavaScript. Enseño en Udemy, Pluralsight, Teachable y YouTube. Conéctate conmigo en mi sitio web en TonyAlicia.dev o encuéntrame en YouTube, Twitter. Aprende sobre The Smythe Group en TheSmytheGroup.com.

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.

2. Autoría de HTML en un Mundo de JavaScript

Short description:

Pero esta masterclass es Autoría de HTML en un Mundo de JavaScript. Me gustaría desafiarte a cambiar tu forma de pensar, a cambiar tu enfoque de cómo construyes tus componentes de React. Digamos que obtienes un prototipo. ¿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? Comencemos pensando 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? El punto principal de autorizar nuestro HTML es elegir nuestros elementos HTML de acuerdo a la información y las cosas que están sucediendo en la página. Ahora hablemos de los beneficios de autorizar nuestro HTML de una manera semántica y cómo realmente se ve. La autoría de HTML es una habilidad. Y es una habilidad muy aprendible.

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.

3. Especificación de HTML y Marcado Semántico

Short description:

Vamos a la Especificación de HTML, donde se definen los significados de cada elemento HTML. Por ejemplo, el elemento address representa la información de contacto para el ancestro del artículo o elemento body más cercano. Al autorizar HTML de manera semántica, podemos mejorar la legibilidad y mantenibilidad. En lugar de centrarnos primero en CSS y JavaScript, deberíamos considerar el contenido y su significado. Marcar semánticamente nuestro documento lo hace más legible y fácil de mantener. Comparando las versiones no semánticas y semánticas, esta última es más comprensible y tiene beneficios a largo plazo.

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.

4. Beneficios del HTML bien autorizado

Short description:

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.

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.

5. Beneficios del HTML Semántico y Rendimiento

Short description:

Si tengo buenos elementos semánticos en mis componentes React, proporciona una mejor comprensión del propósito del componente. La accesibilidad es importante, y un buen HTML permite a los navegadores y lectores de pantalla interpretar correctamente el contenido. Al autorizar bien el HTML, hacemos que nuestros componentes React sean más accesibles. El HTML transmite significado, no presentación. El rendimiento puede mejorarse autorizando bien el HTML, ya que cada elemento en el componente afecta al DOM y al recorrido del CSS.

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.

6. Tamaño del DOM y Rendimiento

Short description:

En la puntuación de Google Lighthouse, un tamaño excesivo del DOM puede llevar a problemas de rendimiento. A medida que se añaden más nodos al DOM, el rendimiento disminuye. Un HTML mal autorizado puede resultar en un gran número de nodos del DOM, impactando negativamente en el rendimiento. Al autorizar correctamente y reducir el tamaño del DOM, podemos mejorar el rendimiento y tener una mejor comprensión de los límites de los componentes y la colocación del CSS.

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.

7. Beneficios de la Preparación Futura de HTML

Short description:

Invierte tiempo ahora en tu HTML para ahorrar tiempo más tarde y hacer tu aplicación más a prueba de futuro. Comienza pensando en elementos que no tienen CSS por defecto. Considera el uso de elementos adecuados como article, header y aside en lugar de div. Diviértete discutiendo con tu equipo y observa los beneficios en mantenibilidad y legibilidad. Prueba un enfoque diferente al autorizar primero el HTML y luego hacer que funcione y se parezca al prototipo.

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.

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
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 2023JSNation 2023
29 min
The Good, The Bad, and The Web Components
There has been no shortage of both fair and unfair criticism toward Web Components from a wide range of folks that build for the web, including but not limited to JavaScript Framework authors in supposed competition with the platform. In this talk I'll show you how to navigate and simplify the multifaceted landscape of web components, satisfying common criticisms and showing how you can Use the Platform most effectively today.
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 🎅
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.