Aplicaciones Web Inmutables

Rate this content
Bookmark

Resolver las dependencias cuando están todas agrupadas es fácil. Resolver las dependencias cuando se cargan a través de etiquetas de script es mucho más desafiante. El objetivo de esta charla es explicar cómo Meltwater maneja la resolución de dependencias al construir aplicaciones nativas basadas en componentes web que dependen de paquetes publicados por muchos equipos diferentes.

20 min
20 Jun, 2022

Video Summary and Transcription

La charla de hoy discute las aplicaciones web inmutables y sus beneficios, como tiempos de carga más rápidos y un seguimiento de versiones fácil. El uso de la agrupación en estilo Universal Module Definition (UMD) permite una gestión flexible de dependencias y actualizaciones graduales. Herramientas como Webpack y Rollup proporcionan formas de referenciar UMD en paquetes y automatizar la configuración de dependencias. Los archivos Arborist y YAML ayudan a resolver árboles de dependencias y manejar conflictos, mientras que la herramienta Orchard CLI automatiza el ordenamiento de dependencias. Las dependencias internas y externas se pueden inicializar y gestionar de manera efectiva para un rendimiento óptimo.

Available in English

1. Introducción a las aplicaciones web inmutables

Short description:

Hoy vamos a hablar sobre aplicaciones web inmutables y dependencias. Tuvimos un problema con las dependencias en Meltwater, por lo que necesitábamos encontrar una forma de desagruparlas y compartirlas de manera efectiva. Las aplicaciones web inmutables nos permiten construir una vez y desplegar muchas veces, con variables de entorno fuera del paquete. Esto asegura que los activos se puedan almacenar en caché al máximo, lo que resulta en tiempos de carga más rápidos. También proporciona un seguimiento de versiones fácil y rollbacks.

¿Cómo les va, JS Nation? Hoy vamos a hablar sobre aplicaciones web inmutables y dependencias. Primero, soy Andy Damaris, pueden encontrarme en prácticamente todas las redes sociales como Teradox y mi sitio web es teradox.tech.

Lo que vamos a cubrir hoy es, vamos a comenzar con el problema. Hubo un problema que estábamos teniendo en Meltwater y luego pasaremos a las aplicaciones web inmutables, qué son y por qué las estamos usando, dependencias sin agruparlas, referenciando esas dependencias y finalmente hablaremos sobre cómo nosotros o esas dependencias con éxito.

Entonces, ¿cuál es el problema? Bueno, el problema eran las dependencias. Teníamos muchas y estaban siendo creadas por equipos internos para bibliotecas que podíamos usar regularmente para cosas como autenticación o búsquedas de empresas o búsquedas de usuarios y cada una de estas cosas estaba comenzando a acumular la cantidad de JavaScript duplicado que se estaba agrupando con todas las diferentes aplicaciones que estábamos enviando. Entonces, necesitábamos encontrar una forma de desagrupar estas dependencias y permitir que se compartieran de manera más efectiva entre las muchas aplicaciones que las estaban utilizando.

Entonces, las aplicaciones web inmutables fueron una parte importante de ese proceso, así que las vamos a cubrir primero. La filosofía básica de las aplicaciones web inmutables es que quieres construirlas una vez y desplegarlas muchas veces. Hay algunos fundamentos realmente específicos que necesitamos lograr para ser una aplicación web inmutable. El primero es que todas nuestras variables de entorno deben estar fuera del paquete. Esto permite que nuestros paquetes se construyan una vez por versión y sean inmutables para esa versión específica. Nunca cambiarán después de la primera vez que se construyan. También significa que necesitamos desplegarlos en una URL donde la versión que acabamos de construir esté incluida como parte de esa URL. Así que queremos que la URL completamente calificada tenga nuestro número de versión en algún lugar.

Ahora, ¿qué beneficios nos brinda esto realmente? Hay muchos. El primero es que cuando estamos probando en entorno de pruebas y estamos probando en producción, están utilizando los mismos activos exactos. La única diferencia será la configuración que ha cambiado entre los dos. Esto significa que todos nuestros activos también se pueden almacenar en caché al máximo. De hecho, se pueden almacenar en caché durante todo un año, que es el máximo actual del navegador. Esto es de gran beneficio para nuestros clientes. Solo necesitan hacer una solicitud para esa versión específica de ese activo específico una vez. Y después de eso, está en la caché de su disco local, lo que ahorra una gran cantidad de tiempo para las cargas secundarias y terciarias del sitio. Nunca tenemos que preocuparnos de que tengan que volver constantemente al origen por estos activos grandes en ocasiones. Otras cosas que se incluyen con esto son que siempre sabes qué versiones están desplegadas porque tu página de índice.html lo deja muy claro. Mira tu etiqueta de script. ¿Qué versión hay en la URL? Esa es la versión con la que estás tratando. También significa que los rollbacks ahora son realmente triviales. Solo estamos volviendo de una versión específica de un conjunto de activos a otra etiqueta de script. Otra versión específica de un conjunto de activos.

2. Aplicaciones web inmutables y dependencias

Short description:

Si eres un consumidor, es probable que ya tengas la versión anterior de los activos en tu caché de disco. La página de índice es el punto focal para los cambios inmediatos. Dividimos las cosas en tres procesos de pensamiento: alojamiento web estático, entrega de activos estáticos mediante etiquetas de script y APIs. Para acceder a la API, utilizamos un bloque de configuración en la etiqueta de script. Tenemos muchas dependencias, por lo que necesitamos herramientas para solucionar el problema. La primera herramienta son los UMDs, el estilo de agrupamiento de Universal Module Definition.

Y si ya eres un consumidor, es probable que ya tengas esa versión anterior de los activos en tu caché de disco listos para usar. Así que ni siquiera tendrás que pagar nuevamente los costos de descarga por ello.

Entonces, hemos hablado de todos nuestros activos, pero ¿qué pasa con la página de índice? Bueno, la página de índice es la única parte de una aplicación web inmutable que no se almacena en caché. Es nuestro punto focal donde todos nuestros cambios pueden aparecer de inmediato.

Así que nos gusta dividir las cosas en tres procesos de pensamiento diferentes. No es necesario hacerlo de esta manera, es solo un ejercicio para pensar en las cosas. La primera parte es nuestro alojamiento web estático. Aloja nuestra página HTML de índice. Esa página HTML de índice es bastante estática. No tiene mucha naturaleza dinámica. Y dicta las versiones de todos los activos estáticos que vamos a entregar. Luego, esos activos estáticos se entregan mediante etiquetas de script. Y esas etiquetas de script utilizan la URL completamente versionada de la que estábamos hablando. En este caso, la versión 1.2.3 para poder entregar esos activos.

Luego también tenemos nuestras APIs, y nuestras APIs pueden estar en un servidor diferente, pueden estar en el mismo servidor. Pero dictamos a qué API vamos a acceder mediante ese bloque de configuración que ves en la etiqueta de script. Ese bloque de configuración le dice a nuestra aplicación a dónde debemos ir para acceder a esa API y cuál debería ser la ruta, eliminando esa variable de entorno de nuestro código JavaScript.

Así que he pasado rápidamente por las aplicaciones web inmutables. Hay más matices, muchos más detalles en los que podrías profundizar. Y si eso es algo que te interesa, por favor visita immutablewebapps.org.

Así que ahora volvamos al meollo de lo que estamos hablando, que son las dependencias. Tenemos muchas de ellas. Son utilizadas por muchas aplicaciones diferentes. Entonces, ¿cómo solucionamos ese problema? Bueno, vamos a necesitar algunas herramientas para hacer esto con éxito. La primera herramienta que vamos a utilizar son los UMDs. Son un tipo específico de agrupamiento del estilo de Universal Module Definition.

3. Using UMDs and Bundling Tools

Short description:

Casi todos los agrupadores lo admiten y permiten que esos agrupadores den un nombre específico a un paquete de código que luego terminará en el ámbito global del disco en el navegador. El ejemplo con el que vamos a trabajar hoy es Meltwater Visualizations. Cuando tienes muchas dependencias entrelazadas, no todas podrán avanzar al mismo ritmo. Actualizar una dependencia, como visualizations, a la versión 14 cuando otras personas dependen de la versión 13 podría significar que todos tengan que actualizar al mismo tiempo y hacer una actualización muy grande. Pero si puedes cargar Meltwater Visualizations 13 y Meltwater Visualizations 14 al mismo tiempo, les das a esos otros equipos la oportunidad de actualizar a su propio ritmo, a un ritmo razonable que tenga sentido para la carga de trabajo que tienen. Y eso significa que las versiones pueden avanzar más lentamente. Y en lugar de tener que hacer una actualización muy grande, ahora puedes actualizar las versiones cuando tenga sentido hacerlo para el movimiento de tu equipo. Entonces, ¿cómo usamos los UMDs dentro de nuestro paquete? Hacer referencia a ellos se reduce a las herramientas de agrupamiento. Comenzaremos con Webpack. Webpack tiene una propiedad llamada externals. Los externals nos permiten cargar esos UMDs que se han colocado en el ámbito global del disco haciendo referencia a ellos mediante su nombre de módulo. Al usar su nombre de módulo, le decimos a Webpack que no queremos agrupar este módulo de nodo más. En su lugar, queremos hacer una referencia a ese módulo de nodo en este espacio de nombres global del disco correspondiente. El beneficio de hacerlo de esta manera es que cuando estamos probando con algo como Jest o VTest, aún podemos usar ese módulo de nodo para ejecutar nuestras pruebas. No es necesario que haga referencia al código específico del navegador si no queremos. Esto significa que nuestras pruebas y simulaciones son mucho más sencillas que si siempre dependiéramos del espacio de nombres global del disco. Ahora veamos cómo podría ser una configuración de rollup para esto. En rollup, esas dos cosas de las que hablamos que Webpack maneja en los externals se dividen en dos opciones de configuración separadas.

Casi todos los agrupadores lo admiten y permiten que esos agrupadores den un nombre específico a un paquete de código que luego terminará en el ámbito global del disco en el navegador. El beneficio de esto es que ahora podemos hacer referencia a ese módulo utilizando el espacio de nombres global del disco que ocupa para traerlo sin tener que agrupar esa dependencia en nuestro otro código.

El ejemplo con el que vamos a trabajar hoy es Meltwater Visualizations. Y notarás que cuando hablamos de hacer un nombre para este paquete UMD, incluimos ese sufijo de una versión principal. En este caso, la versión principal 14 de Meltwater Visualizations. La razón de esto es que cuando hacemos referencia a una versión principal, nos permite cargar múltiples versiones principales de la misma dependencia en la página al mismo tiempo. Ahora, es posible que pienses que eso parece una mala idea, y estoy de acuerdo contigo. Pero también hay beneficios al poder hacer eso. Cuando tienes muchas dependencias entrelazadas, no todas podrán avanzar al mismo ritmo.

Actualizar una dependencia, como visualizations, a la versión 14 cuando otras personas dependen de la versión 13 podría significar que todos tengan que actualizar al mismo tiempo y hacer una actualización muy grande. Pero si puedes cargar Meltwater Visualizations 13 y Meltwater Visualizations 14 al mismo tiempo, les das a esos otros equipos la oportunidad de actualizar a su propio ritmo, a un ritmo razonable que tenga sentido para la carga de trabajo que tienen. Y eso significa que las versiones pueden avanzar más lentamente. Y en lugar de tener que hacer una actualización muy grande, ahora puedes actualizar las versiones cuando tenga sentido hacerlo para el movimiento de tu equipo.

Ahora, esto no significa que no debas tener cuidado con mucha duplicación de código, eso es cómo llegamos aquí en primer lugar. Pero sí significa que hace que esa ruta de actualización sea mucho más fluida en muchos equipos diferentes. Entonces, ¿cómo usamos los UMDs dentro de nuestro paquete? Hacer referencia a ellos se reduce a las herramientas de agrupamiento. Comenzaremos con Webpack. Webpack tiene una propiedad llamada externals. Los externals nos permiten cargar esos UMDs que se han colocado en el ámbito global del disco haciendo referencia a ellos mediante su nombre de módulo. Al usar su nombre de módulo, le decimos a Webpack que no queremos agrupar este módulo de nodo más. En su lugar, queremos hacer una referencia a ese módulo de nodo en este espacio de nombres global del disco correspondiente.

Entonces, aquí están sucediendo un par de cosas. Uno, se le dice a Webpack que ignore la agrupación de ese nombre de módulo, y dos, ese nombre de módulo se configura para que corresponda a un objeto de espacio de nombres global del disco que debería existir. El beneficio de hacerlo de esta manera es que cuando estamos testing con algo como Jest o VTest, aún podemos usar ese módulo de nodo para ejecutar nuestras pruebas. No es necesario que haga referencia al código específico del navegador si no queremos. Esto significa que nuestras pruebas y simulaciones son mucho más sencillas que si siempre dependiéramos del espacio de nombres global del disco. El beneficio aquí son configuraciones de prueba más fáciles, más fáciles de debug, y tu código local se ejecuta de la manera que esperarías. Es maravilloso saber que podemos usar el módulo de NPM para testing local y saber que actuará de la misma manera que cuando está implementado.

Ahora veamos cómo podría ser una configuración de rollup para esto. En rollup, esas dos cosas de las que hablamos que Webpack maneja en los externals se dividen en dos opciones de configuración separadas.

4. Bundling Modules in Rollup

Short description:

La propiedad externa en rollup nos permite especificar qué módulos no deben ser agrupados. Podemos usar la opción global de salida para asignar nombres de módulos a espacios de nombres globales en el disco. Esto facilita hacer referencia a los UMDs desde el objeto window.

La primera es qué modules no se agruparán junto con nosotros. Para eso sirve la propiedad externa en rollup. Dice, aquí están los modules, simplemente no quiero que los cargues. No necesitas agruparlos en mi paquete. Y luego, en la opción global de salida, podemos usar el mismo tipo de mapeo que vimos en Webpack, donde el lado izquierdo es el nombre del módulo, y el lado derecho es el espacio de nombres global en el disco que queremos resolver para ese nombre de módulo mientras se está agrupando. Tiene una salida muy similar en la forma en que estamos haciendo referencia a estas cosas, y hace que sea muy sencillo hacer referencia a los UMDs desde el objeto window.

5. Automatizando la Configuración y el Ordenamiento de Dependencias

Short description:

Mantener la configuración de múltiples dependencias puede resultar agotador, especialmente cuando hay muchas que seguir. Sin embargo, el paquete HiMyNameIs ofrece una solución al automatizar el proceso de construcción del mapeo de módulos a espacios de nombres. Proporciona dos funciones: generateNamespaceFromPackage y getPackageNamespaceMapping. Estas funciones te permiten construir fácilmente el espacio de nombres global y resolver las dependencias en tu package.json. Además, la herramienta de línea de comandos Orchard automatiza el ordenamiento de las dependencias, asegurando que se carguen en el orden correcto para la resolución global.

Pero si empezamos a pensar en cuando llegamos a 20 o 30 o 50 de estas dependencias, mantener esa configuración es agotador. Hay tanto que mantener. Cada una de ellas tiene una versión principal que tenemos que tener en cuenta. Cuando actualizamos nuestro package.json, esa versión principal podría cambiar y tenemos que recordar actualizarla en la configuración. Quiero decir, se vuelve un poco caótico, pero afortunadamente podemos automatizar eso y podemos hacerlo a través de un paquete llamado HiMyNameIs. Este paquete se va a abrir al público, esperemos que en el próximo mes y podrás aprovecharlo.

HiMyNameIs es básicamente una biblioteca que nos permite construir ese mapeo de módulos a espacios de nombres del que estábamos hablando sin que tengas que mantenerlo tú mismo. Y lo hace con dos funciones muy sencillas. La primera función se llama generateNamespaceFromPackage. generateNamespaceFromPackage te permite construir ese espacio de nombres global del que estábamos hablando, incluyendo nuestra versión principal para que podamos agregarlo a una nueva propiedad de package.json. Esa propiedad de package.json se llama browserNamespace. Esta propiedad nos da la capacidad de resolver esa información más adelante en la construcción. Así que una vez que tienes una biblioteca que está utilizando esto y construyendo esa propiedad en package.json, significa que tus consumidores ahora están configurados para poder referenciarlos correctamente. Veamos cómo se ve eso.

La segunda función de HiMyNameIs es getPackageNamespaceMapping. Esta función va a tu package.json de tu proyecto y mira todas las dependencias. Ignora las dependencias de desarrollo y resuelve esas dependencias para mirar sus package.json. Si el package.json de esa dependencia tiene una propiedad browserNamespace, lo utiliza para construir el mapeo del nombre del módulo al espacio de nombres global. Así que ya no tienes que mantener eso. A medida que vas versionando, se versionará automáticamente para ti. Cada vez que construyes, esto se resolverá de manera adecuada y rápida y te dará ese mapeo que necesitas. Así que en rollup, es un poco más complicado, pero no mucho. Al igual que con webpack, la función getPackageNamespaceMapping te sigue dando ese objeto globals, pero también necesitas construir ese array externo, como mencionamos anteriormente. Afortunadamente, getPackageNamespaceMapping tiene toda la información que necesitas para poder hacerlo con éxito.

De acuerdo, pero aún no hemos abordado el ordenamiento, ¿verdad? Y ese es un problema mucho más difícil, porque las dependencias pueden tener dependencias pueden tener dependencias, y todas deben cargarse en el orden correcto para que esta resolución global funcione correctamente. Pero también podemos automatizar eso. Ahí es donde entra en juego la herramienta de línea de comandos Orchard. De manera muy similar a HiMyNameIs, lee tu package.json, solo mira tus dependencias, ignora las dependencias de desarrollo. Pero en lugar de detenerse en el nivel superficial esta vez. Utiliza un paquete directamente de NPM JS llamado Arborist para construir el árbol completo de dependencias.

6. Resolución del Árbol de Dependencias y Archivos YAML

Short description:

Arborist es una herramienta poderosa que maneja la resolución del árbol de dependencias para la instalación de NPM y ayuda a construir el archivo package-lock.json. Construye etiquetas de script basadas en la resolución del árbol de dependencias y las limita utilizando un conjunto seleccionado de archivos YAML. Estos archivos contienen información de propiedad, detalles técnicos y permiten la creación de dependencias ordenadas. El Orchard lleva un registro de quién es responsable de cada dependencia, y los archivos YAML especifican la ruta y la versión de cada dependencia. El sistema también maneja conflictos con otras versiones principales y requiere inicialización.

Arborist es básicamente el responsable de la resolución del árbol de dependencias para cosas como la instalación de NPM. Permite que la instalación de NPM construya ese árbol de dependencias completo para comprender qué nuevos paquetes deben colocarse en qué lugar en ese árbol de dependencias. También ayuda a construir el archivo package-lock.json. Es una herramienta muy poderosa que no construimos para que este sistema funcione.

Utilizando ese árbol de dependencias, luego construye un conjunto de etiquetas de script basadas en esa resolución del árbol de dependencias. Y luego limitamos eso utilizando un conjunto seleccionado de archivos YAML. ¿Por qué una lista seleccionada de dependencias? Bueno, hay un par de razones. La primera principalmente es la seguridad. No queremos que se cargue cualquier paquete de node o de NPM. Realmente queremos limitarlo a solo las cosas que realmente queremos que se carguen en el navegador. Al limitarlo, estamos limitando la cantidad de cosas que pueden cargarse a un subconjunto muy específico que realmente nos importa. También ayuda a limitar esa resolución del árbol de dependencias a un tiempo mucho más corto al recortar ramas que ya no son relevantes.

Entonces, con estas herramientas en su lugar, ahora tenemos este archivo YAML con el que debemos preocuparnos en el Orchard. Afortunadamente, es un archivo YAML bastante sencillo. Esto es lo que parece para una dependencia interna. En la parte superior, tenemos información de propiedad. Es maravilloso dentro de una gran organización poder saber exactamente quién es responsable de la dependencia en la que confías en producción. Eso es parte de lo que nos permite controlar el Orchard. Cada uno de estos archivos YAML tiene una propiedad `owned by`, un repositorio y una propiedad de contacto que nos permite realizar un seguimiento muy cercano de quién está realmente a cargo de estas diferentes dependencias. Luego, en los detalles técnicos, aquí es donde realmente estamos construyendo la ruta para cada una de las dependencias que estamos cargando, ya sea mediante una etiqueta de script o una etiqueta de enlace. Lo dividimos en estas tres partes por una razón muy específica. Queríamos un sufijo que sea la ruta base desde la que se cargarán estas cosas. Luego queríamos una ruta de versión que permita que esa ruta de versión se prefije con una `v` o un símbolo `@` dependiendo de dónde se esté cargando. Luego, el sufijo son los archivos específicos que deben cargarse. En el caso de lo que estamos viendo, esto cargaría una etiqueta de script con el tipo `module` y luego resolvería esa ruta base más la versión más la ruta ESM como origen de esa etiqueta de script. También crearía una etiqueta de enlace basada en eso, una vez más, esa ruta base, la versión y la ruta CSS para construir esa etiqueta de enlace que nos permite crear un conjunto de dependencias ordenadas. Hay otras dos propiedades aquí que vale la pena mencionar. Una es `conflicts with other major versions`, que es esa advertencia anterior de que intentamos asegurarnos de que nuestras bibliotecas internas puedan ejecutarse con múltiples versiones principales al mismo tiempo. Y este sería el lugar donde detendríamos una compilación si se intentaran cargar dos versiones diferentes de la misma biblioteca que no pueden interoperar correctamente.

7. Inicialización de Dependencias Internas y Externas

Short description:

Existen bibliotecas internas que requieren código de inicialización para un estado adecuado. Las dependencias externas, como moment.js, tienen propiedades de propiedad y detalles técnicos similares. Se utiliza ES5 en lugar de ESM, con una etiqueta de script y el atributo defer. No se permiten conflictos con otras versiones principales.

Y el último aquí requiere inicialización. Hay algunas bibliotecas internas que requieren que se ejecute algún código de inicialización para que estén en un estado adecuado. Y nos gusta destacarlo para nuestros consumidores para que sepan exactamente lo que necesitan inicializar. Al mirar un ejemplo de una dependencia externa, se ve muy, muy similar a una dependencia interna. En este caso, moment.js. Podemos ver que las propiedades de propiedad han cambiado un poco. Ya no es una preocupación interna, por lo que no tenemos cosas como el nombre del equipo. Pero sí tenemos cosas como el repositorio del que proviene y dónde puedo contactarlos en caso de algún problema. Los detalles técnicos también son muy similares. En este caso, se utiliza ES5 en lugar de ESM porque no hay una versión ESM de moment.js. Así que todo eso significa que en lugar de ser una etiqueta de script con type=module, ahora obtendremos una etiqueta de script con el atributo defer, lo que básicamente permite que esa etiqueta de script se diferida hasta que se haya analizado todo el HTML y seguirá el mismo proceso de ordenamiento que una etiqueta de script con type=module cuando estamos haciendo esa resolución. Aquí podemos ver que tenemos conflictos con otras versiones principales establecido en true. No se pueden cargar múltiples versiones principales de moment. Simplemente no está permitido. Ocupan el mismo espacio de nombres this global y se sobrescribirían entre sí. Así que esos son un par de ejemplos de archivos YAML que se utilizan para configurar el orchard. Quiero tomar un segundo para hablar sobre algunos de los resultados de este trabajo, los beneficios que nos ha proporcionado en Meltwater. Y la gran cosa aquí es que es algo bueno. Realmente nos ha ayudado a reducir los problemas de los clientes que estábamos experimentando al tener el entorno de pruebas y producción que dependían de las mismas versiones exactas del código. Ya no nos preocupamos por los cambios de lógica que podrían colarse entre el entorno de pruebas y producción. También hemos reducido el tamaño general de nuestros paquetes para nuestras aplicaciones al hacer que esas dependencias sean externas. Esas dependencias pueden ser utilizadas por muchas aplicaciones diferentes en nuestra suite de aplicaciones ya que todas se cargan en el mismo dominio. También hemos visto que las cachés se están utilizando mucho más. Estamos viendo muchas menos solicitudes de archivos remotos ya que pueden almacenarse en caché en el navegador. Realmente ha ayudado mucho con los tiempos de carga para los usuarios. Así que un resumen rápido de todo lo que hemos hablado hoy es que teníamos un problema con muchas bibliotecas que se cargaban en muchas aplicaciones diferentes y esa duplicación de descarga de JavaScript. Así que adoptamos un enfoque de aplicaciones web inmutables para asegurarnos de que todos nuestros activos estuvieran completamente versionados y en caché al máximo. Los construimos utilizando UMDs, lo que permite crear ese espacio de nombres this global. Y también se pueden cargar a través de los empaquetadores que ya estamos utilizando. Y luego un poco de herramientas para DevAx es HiMyNameIs para permitir que esas dependencias se resuelvan más rápidamente y más fácilmente y también el orchard. El orchard es responsable de cargar esas cosas en un orden específico. Así que he cubierto mucho durante esta charla y sé que hay muchos temas aquí, así que gracias por su tiempo. Gracias por escuchar. Y si tienen alguna pregunta sobre alguno de estos temas, definitivamente contáctenme en las redes sociales. Haré todo lo posible para responder lo más rápido posible y responder cualquier pregunta que tengan. Muchas gracias de nuevo por su tiempo. Fue genial estar aquí para hablar.

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

DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.A brief history of JavaScript package managersThe isolated node_modules structure created pnpmWhat makes pnpm so fastWhat makes pnpm disk space efficientMonorepo supportManaging Node.js versions with pnpm
JSNation 2022JSNation 2022
28 min
Yarn 4 - Modern Package Management
Top Content
Yarn 4 is the next major release of your favourite JavaScript package manager, with a focus on performance, security, and developer experience. All through this talk we'll go over its new features, major changes, and share our long-term plans for the project.If you only heard about Yarn without trying it yet, if you're not sure why people make such a fuss over package managers, if you wonder how your package manager can make your work simpler and safer, this is the perfect talk for you!
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 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 🎅
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.

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.