Las Dilemas que Enfrenté al Construir una Biblioteca de Componentes

♪♪♪ Soy Indrico, y esta es mi charla, Los dilemas que enfrenté al construir mis bibliotecas de componentes, o también conocido como El sándwich perfecto no existe A menos que estés comiendo un sándwich hecho por JakeTheDog. Entonces, tienes hambre y quieres hacer un bocadillo. Así que tal vez quieras hacer un sándwich. Entonces comienzas tomando un poco de pan blanco Hovis, o tal vez sea Wonder Bread para aquellos en América. Para esto, vas a Sainsbury's y obtienes un poco de mayonesa de huevo prehecha. Luego cortas algunas deliciosas cebollas blancas crudas, las pones encima del sándwich y luego le echas montones de ketchup. Y felicidades, tienes un delicioso manjar.

Ahora, si has jugado Legend of Zelda, Tears of the Kingdom, y arrojaste esos ingredientes en una sartén, probablemente verías aparecer esta pequeña pantalla. Es comida dudosa. Es demasiado asqueroso para siquiera mirarlo. Un olor extraño emana de este montón. Comerlo no te hará daño, probablemente.

Entonces, digamos que trabajas para un restaurante de alta gama, y quieres hacer un sándwich elegante. Bueno, no puedes simplemente servir a tus clientes el sándwich que acabamos de hacer. Tienes que hacer algo un poco más agradable. En lugar de solo tu pan blanco simple, tal vez vayas a un montón de diferentes panaderías, pruebes sus panes, tal vez vayas por la sensación en la boca y la textura, y decidas sobre el perfecto pan de masa madre. No puedes simplemente echar cualquier ketchup viejo en ese pan de masa madre. En su lugar, haces tu famoso relish casero especial. Nuevamente, cebollas blancas crudas, sí, toman un segundo para cortar, pero si realmente quieres tomarte el tiempo y hacer algo delicioso, vas a caramelizarlas. Eso lleva mucho más tiempo, pero tus usuarios, lo siento, quiero decir tus clientes, apreciarán el tiempo y esfuerzo que pones en hacer esas cebollas caramelizadas.

Pero eso no es lo único que necesitas considerar cuando estás haciendo tu sándwich gourmet. Tienes que considerar cosas como el costo monetario para hacer el sándwich, los requisitos dietéticos de tus clientes, tal vez quieras atender a celíacos, o tal vez a personas sin lácteos, pero eso es algo que necesitas decidir lo mejor para ti. Pero luego también necesitas las habilidades y el equipo para hacer ese maldito sándwich. Y un hombre sabio una vez dijo, algo rápido y sucio podría funcionar para ti ahora, pero no será adecuado en cada situación. Y lo mismo ocurre al construir una biblioteca de componentes. Encuentro que construir una biblioteca de componentes es una parte realmente gratificante de ser un desarrollador web, pero no puedes simplemente juntar cualquier código antiguo y esperar que resuelva los problemas de todos. Hay mucho más que eso. Así que esta charla es una culminación de todas esas pequeñas decisiones que he tenido que tomar al construir mis bibliotecas de componentes. Así que aquí estamos, los dilemas que enfrentarás al construir una biblioteca de componentes. Así que me di cuenta de que al construir un componente para un equipo, o una empresa, o para la comunidad de código abierto, enfrentarás un montón de dilemas.

Ahora, estas son pequeñas decisiones como, bueno, tal vez no pequeñas, en realidad decisiones bastante grandes, si usar un framework de JavaScript, puede que no lo necesites, cómo considerar la accesibilidad dentro de tu estrategia de pruebas, que es algo que ciertamente querrás hacer, y si usar un monorepo para gestionar tu biblioteca de tres componentes, y spoilers, no lo hagas. Y tomar la decisión equivocada desde el principio puede causar dolores de cabeza duraderos para ti, tus compañeros de equipo y tus usuarios finales. Así que es importante considerar estas cosas. Y algunas de estas decisiones que se toman pueden ser cosas que puedes cambiar un poco más adelante. Tal vez te des cuenta después de investigar un poco que una alternativa es mejor que otras son más como puertas de un solo sentido, donde si cometes un error o eliges la opción incorrecta desde el principio, puede tener consecuencias duraderas mucho más adelante.

Para esto, antes de continuar, permíteme presentarme. Soy Andriuko Kirula, y soy un desarrollador full-stack, y he estado en el juego por casi una década ahora. Y me especializo en el front-end, y he construido algunas bibliotecas de componentes, principalmente para empresas, pero también algunas por diversión.

Actualmente estoy en busca de mi próximo rol de contrato. Así que si necesitas un desarrollador front-end o un desarrollador full-stack, entonces podría ser tu persona. Así que déjame hablar sobre algunas de las bibliotecas de componentes que he construido para empresas.

En mi último rol en Anima, teníamos un montón de diferentes front-ends que estaban construidos en React. Y por eso tenía sentido que creáramos una biblioteca de componentes en React que luego usamos en esos diferentes front-ends. Eso significaba que todos nuestros front-ends se veían y sentían de la misma manera. Y lo mismo ocurre con las bibliotecas de componentes que se construyen en Trin o a las que contribuí en Health Hero.

Y en cuanto a las que son por diversión, tomo un enfoque ligeramente diferente. Muchas veces lo hago para satisfacer una inquietud creativa o para aprender una tecnología a un nivel más profundo. Y puedes ver mi favorita que hice es A2K, que es una biblioteca de componentes inspirada en Windows 2000. Y puedes ver aquí que los diferentes componentes que exporta le dan a tus interfaces este genial toque retro. Y he construido un par de bibliotecas de componentes independientes. Y también he construido una biblioteca de componentes React llamada BeautifulSkillTree. No la he actualizado en un tiempo, pero parece tener un poco de seguimiento de culto.

Genial. Entonces, ¿por qué construyo bibliotecas de componentes? ¿O por qué deberías construir bibliotecas de componentes? La respuesta empresarial es que construir una biblioteca de componentes te permite construir tus interfaces más rápido usando componentes reutilizables. Y luego eso te permite tener un lenguaje visual consistente a través de tus diferentes interfaces. Pero luego, a un nivel más personal, prefiero escribir... Bueno, me gusta escribir bibliotecas de componentes porque te permite entender mejor un ecosistema dado. Si quieres mejorar escribiendo en React o Svelte, entonces una muy buena manera de hacerlo es escribiendo algunos componentes complejos en ese framework.

Lo mismo ocurre si quieres aprender componentes web. Una gran manera de hacerlo es construyendo componentes. También te ayuda a mejorar tu comprensión de patrones comunes de UI. Si has intentado construir un menú select o has intentado construir un acordeón desde cero, probablemente pronto te darás cuenta de que no es tan simple como podría parecer. Tienes muchos subcomponentes que podrías necesitar construir, muchas interacciones complicadas y casos especiales que también necesitas acomodar. Y a un nivel meta, si quieres mejorar en desarrollar y publicar una biblioteca, la mejor manera de hacerlo es desarrollando y publicando una biblioteca. Así que genial, hemos hablado sobre los beneficios de construir una biblioteca de componentes.

Pero no es tan sencillo porque, como mencioné antes, hay un montón de decisiones diferentes que necesitas tomar si quieres hacer una biblioteca de componentes que sea adecuada para tus usuarios.

Para esto, y estas son solo algunas de las preguntas con las que me he encontrado al construir mis propias bibliotecas de componentes. Y de hecho, saqué esta lista de un artículo de GitHub que escribí, que detalla todas mis experiencias a través de estas diferentes preguntas. Así que si eso suena como algo que te interesa, entonces genial, porque esta charla tomará un puñado de estas preguntas y profundizará en ellas. Pero si quieres revisar ese artículo de GitHub y contribuir con tus propias experiencias, entonces eso es genial. Así que por favor, adelante y hazlo.

Así que la primera que veremos es si deberías escribir tus componentes desde cero o construir los tuyos propios. Así que la primera pregunta es si quieres construir tu componente, usando una biblioteca. Y una buena manera de entender si eso es una buena idea o no es mirar todos los diferentes frontends con los que planeas usar tu biblioteca de componentes. Si todos usan el mismo framework, entonces tal vez sea una buena idea escribir tu biblioteca de componentes en ese framework. Si tienes un frontend de Vue, un frontend de Svelte y un frontend de React, entonces tal vez considera usar Web Components, porque puedes usarlos en muchos frameworks diferentes. Así que ya hemos llegado a una bifurcación en el camino aquí. Tenemos como si usar Web Components para una biblioteca de componentes, si usar un framework específico, y también hay otras opciones. Y esto es algo que verás mucho cuando construyas la tuya propia, es que responder una pregunta a menudo lleva a muchas otras preguntas.

Así que tomemos como la bifurcación izquierda, donde usas Web Components. Bien, genial, pero ahora hay toda una serie de preguntas que necesitas responder. ¿Quieres escribir Vanilla Web Components, que es una API de nivel más bajo, un poco más compleja, pero obtienes control total sobre cómo se comportan? ¿O quieres usar una biblioteca auxiliar como Lit o Atomico que suavizan algunos de los bordes más complicados y te dan cosas como reactividad de inmediato? ¿O quieres usar una biblioteca existente como SheLace o WebAwesome, o en realidad lo mismo, pero donde te ofrecen una suite de componentes completamente funcionales que puedes instalar para satisfacer tus necesidades? Y luego encuentras que si elegiste construir en un framework, tienes un conjunto similar de preguntas también, si escribir tus componentes en Vanilla React, si quieres usar una biblioteca como Radix o React ARIA que te dan componentes sin estilo, pero manejan muchas de las interacciones más complejas para patrones de UI complejos. O tal vez usar una biblioteca como Mui o Shadtian, donde obtienes componentes completamente funcionales, y luego tienes la opción de personalizarlos.

Y así, estos son más detalles de implementación. Pero si damos un paso atrás, notarás algunos paralelismos entre esas dos preguntas, a saber, con qué nivel de abstracción te sientes cómodo tratando. Así que diferentes niveles de abstracción tratan con... Diferentes niveles de abstracción ofrecen soluciones a diferentes problemas. Como soluciones a diferentes problemas. Así que yendo desde el nivel más alto de abstracción, podrías usar una biblioteca de componentes con componentes funcionales que ya se ven geniales. Y así, para ti como desarrollador, tienes que lidiar con mucha menos complejidad, y luego también puedes construir algo o entregar algo mucho más rápidamente. Y luego nuevamente, si usas componentes funcionales que no tienen estilo, no tienes que lidiar demasiado con el funcionamiento interno de los componentes y cómo se comportan. Solo necesitas asegurarte de que se vean exactamente como los necesitas. Luego das otro paso, como bajar un nivel, y tal vez estás usando una biblioteca para ayudarte a escribir componentes, pero aún necesitas implementar toda la funcionalidad del componente tú mismo, o escribes componentes desde cero sin una biblioteca. Y nuevamente, eso es lo más complejo de todos porque estás lidiando con cosas como el estilo y la interactividad, y tal vez las APIs de nivel más bajo que ofrece el navegador. Así que he tomado la decisión equivocada en varias ocasiones, y probablemente voy a tomar la decisión equivocada en el futuro también.

Ha habido ocasiones en las que he hecho componentes desde cero, y el desafío con eso es que ahora soy dueño de la complejidad de las interacciones. Y así se hace más difícil si estás trabajando en un equipo y estás construyendo todo desde cero porque ahora tienes muchas personas diferentes entrando y ajustando cosas, y tal vez la visión original se ha enturbiado, así que ahora tienes este componente Hero donde tienes un botón, un botón de enlace y un enlace todo en el mismo componente haciendo muchas cosas diferentes. Y así ahora tengo estas implementaciones complejas con preocupaciones mezcladas, y habrá montones de casos límite. Y así a veces podría tener más sentido delegar toda esa complejidad a una biblioteca de código abierto, y tal vez esa biblioteca tenga un equipo que esté dedicado a resolver un solo problema, y ese único problema es construir una biblioteca de componentes. Y esa biblioteca de componentes puede haber sido utilizada en decenas de miles de proyectos diferentes, así que ahora tienes todas las estadísticas de uso para informar cómo se comporta esa biblioteca de componentes. Y así no tienes esa carga de mantenimiento que podrías tener si construyeras todo tú mismo. Pero no es necesariamente lo mejor delegar siempre la complejidad a otra persona. Hay diferentes razones para elegir esos niveles de abstracción. Así que tal vez quieras aprender un framework a un nivel más profundo. Bueno, entonces tal vez sea bueno intentar construir todo desde cero. También necesitas considerar quién va a contribuir a tu biblioteca de componentes. Si eres solo tú, entonces adelante, y tal vez las cosas sean un poco más desordenadas, no te importa eso un poco, pero si estás trabajando con un equipo o esperas contribuciones de código abierto, entonces necesitas ser un poco más metódico sobre cómo escribes las cosas y si hacer que sea lo más fácil posible para que otros contribuyan.

Genial, así que esa es la primera pregunta que cubrimos, y prácticamente llevó a otra docena de preguntas, pero espero que tengas una mejor comprensión sobre el tipo de introspección que necesitas hacer si quieres comenzar a construir tu primera biblioteca de componentes.

Así que la siguiente pregunta que vamos a analizar es si exportar tu biblioteca como un paquete único o como paquetes con ámbito. ¿Y a qué me refiero con esto?

Bueno, si has usado bibliotecas de componentes en el pasado, tal vez Material Web, sabrás que si ejecutas npm install Material Web o cualquier biblioteca de componentes, tendrás acceso a toda la suite de componentes, y esto es realmente útil como consumidor porque si estás consumiendo este tipo de biblioteca de componentes, entonces solo necesitas ejecutar el script de actualización contra un paquete para obtener la última versión de todos los componentes. Puedes mirar fácilmente los registros de cambios.

Y si estás gestionando la biblioteca de componentes tú mismo, es mucho más fácil gestionar una sola versión y luego publicar una sola versión. Para esto, y lo contrastaré con los paquetes con ámbito, y esto podría, bueno, esto es como un Radix UI donde podrías querer usar, digamos, su menú select y tal vez sus componentes de menú popover, y entonces necesitarías ejecutar npm install Radix UI, select menu, y luego npm install Radix UI popover. Así que instalar un solo paquete te da acceso a un solo componente. Y esto es útil si solo planeas usar, digamos, uno o dos, o un número muy, muy pequeño de componentes de una biblioteca dada.

Y tengo un asterisco aquí sobre la reducción de tamaños de paquete, lo cual tal vez no sea estrictamente cierto, lo cual toco un poco más adelante, pero como autor de componentes o autor de biblioteca, tienes mucha flexibilidad en cuanto a cómo los versionas y publicas. Puedes publicarlos, versionarlos independientemente para que cada componente tenga su propia versión, o puedes versionarlos juntos para que cada vez que lances, aumentes la versión para todos ellos y tal vez solo algunos de los cambios, solo se realicen cambios en algunos de esos componentes. Y hablaremos un poco sobre esa última opción en un segundo, porque encuentro eso realmente molesto como consumidor. He trabajado con paquetes independientes que fueron versionados juntos.

Y aunque el sistema de plugins de Gatsby no era necesariamente como una biblioteca de componentes, lo que harías, si has construido con Gatsby en el pasado, probablemente usarías una docena o más de estos diferentes plugins de primera parte, y todos estaban versionados juntos contra la misma versión. Y así lo que sucedería es que si te alejabas de tu computadora por un par de semanas, volvías e intentabas actualizar tus dependencias, verías una lista completa de plugins de Gatsby que necesitaban ser actualizados, y así cuando revisas cada registro de cambios, porque no me gusta simplemente actualizar todo y esperar lo mejor, a menudo verías esto, como aumento de versión, aumento de versión, aumento de versión, aumento de versión, oh, pequeño cambio en el readme, aumento de versión, aumento de versión. Y tendrías que hacer eso a través de una docena o más, si no más, paquetes. Así que eso es un poco molesto. Pero no es tan malo si estás usando un pequeño número de componentes y están versionados independientemente.

De esa manera, tal vez te hayas alejado de tu computadora por dos semanas y solo uno de esos componentes ha cambiado. Así que no necesitas actualizar todos ellos. Ahora, como editor, de hecho he lidiado con la publicación de paquetes con ámbito. Y hablé sobre mi biblioteca de componentes A2K un poco antes. Y para ser totalmente honesto, fue un error y lo lamento enormemente. Así que el propósito de A2K era permitir a las personas construir una interfaz completa usando una suite de componentes de estilo retro. Entonces, ¿por qué haría que mis desarrolladores o mis consumidores instalen cada componente individualmente? Simplemente no tiene sentido. Si planean usar A2K para construir una interfaz, probablemente usarán todos los componentes. Así que hacer que alguien instale 12 componentes mata absolutamente la experiencia de usuario y aumenta la fricción. Y probablemente diría que la adopción habría sido un poco más alta si hubiera publicado todo como un solo componente. Además de eso, gestionar versiones independientes es un poco más complejo.

Así que necesitas configurar tu repositorio como un repositorio modelo. Necesitan tener un flujo de trabajo específico para que puedas publicar componentes a medida que cambian y asegurarte de que las versiones se incrementen según el cambio. Y me gusta, uso change sets para esto. Y me gusta como herramienta, pero hace que, o tener todas estas herramientas en tu repositorio simplemente lo hace mucho más difícil de manejar. Así que intenta optar por la opción más simple si puedes. Y hablé sobre problemas de puerta de un solo sentido anteriormente. Y creo que este es un buen ejemplo. Si quisiera cambiar A2K ahora para ser una sola biblioteca o un solo paquete con todos los componentes, tendría que pedirle a todos los que lo usan que cambien completamente la forma en que están usando la biblioteca de componentes. Y no muchas personas lo usan ahora, pero si estás construyendo una biblioteca de componentes que es utilizada por miles de diferentes desarrolladores, les estás pidiendo mucho. Así que es mejor asegurarse de que has resuelto este problema o al menos tomar lo que sientes que es el mejor enfoque en ese momento. Así que definitivamente vale la pena considerarlo.

Entonces, ¿qué haría ahora? Para empezar, ofrecería un solo paquete por las razones que mencioné, también escribiría el paquete solo en ESM. Una cosa que no mencioné, porque es parte de un dilema diferente es que publiqué A2K como ESM, CommonJS y UMD. Y esto es, nuevamente, porque quería hacerlo lo más disponible posible para que cualquiera pudiera usarlo. Pero, en retrospectiva, es un componente web. Probablemente se usarán en la web. ESM es amigable con la web. Así que tiene sentido que solo publique como ESM a menos que realmente, realmente necesite usar CommonJS por cualquier razón. Para esto, además, porque ESM, como los módulos ES son analizables estáticamente, si un consumidor solo quiere usar un solo componente, entonces su empaquetador debería poder eliminar cualquiera de los componentes no utilizados. Así que no necesitas preocuparte demasiado por los tamaños de los paquetes. Y de lo que hablé un poco, por qué usaría un solo paquete, porque A2K tiene un lenguaje de diseño consistente. Así que no tenía sentido que estuviera todo separado. Así que cada vez que empiezo una nueva biblioteca de componentes, me hago estas cuatro preguntas. Y ya he tocado algunas de ellas hasta cierto punto. Pero si dices que sí a todas ellas, nuevamente, lenguaje de diseño con opinión, evitando la complejidad, esperando que los usuarios utilicen múltiples componentes y feliz de versionar todo junto, entonces probablemente sea mejor simplemente poner todo en un solo paquete. Pero si dices que no a una o más de estas, entonces podría ser mejor intentar y publicarlos de manera independiente.

Genial. Así que este es el último elemento que vamos a revisar en esta charla. ¿Debería usar herramientas para construir y/o empaquetar mi biblioteca de componentes? Así que estamos en dos lados de esto. Está la construcción y está el empaquetado. Y cuando digo empaquetar, me refiero a ejecutar cosas como, ya sabes, combinando todo en un solo paquete en el que tal vez estés concatenando, minificando, transpiliendo. Mientras que construir es simplemente convertir algo, como ejecutar algunos pasos para hacer tu código amigable para el navegador código amigable para el navegador.

Así que veamos primero el empaquetado. ¿Debería empaquetar mi biblioteca? Y voy a decir que no porque es muy molesto. He estado en el extremo receptor de lidiar con una biblioteca empaquetada. Y la razón por la que fue un dolor para mí es porque las optimizaciones que esa biblioteca hizo no estaban en línea con lo que necesitaba para dar a mis usuarios finales. Así que esta biblioteca que he usado en el pasado, y realmente me gustó. Y pienso muy bien del equipo por esto. Ellos, bueno, la usamos bastante. Encontramos algunos errores aquí y allá, lo cual es de esperar. Pero lo que haríamos es depurar los módulos de nodo y luego tal vez ejecutar un paquete de parches si necesitábamos hacer algunos pequeños cambios mientras esperábamos que nuestras correcciones de errores de solicitud de extracción se integraran. Y todo eso estaba bien porque el código era básicamente solo módulos ES estándar como los desarrolladores lo habían escrito. Pero luego lo actualizamos un día y decidieron empaquetar su código. Así que en lugar de ser como muchos y muchos archivos diferentes, había solo como este archivo común JS que tenía todo el código empaquetado. Y fue un absoluto dolor depurarlo. Y les pedí que no hicieran eso, que revirtieran sus cambios. Y después de unas semanas lo hicieron. Y fue una experiencia de desarrollo mucho más agradable como consumidor.

Así que solo para reiterar, no asumas las necesidades de optimización de tus consumidores. Solo publica como códigos amigables para el navegador que si quieren ejecutar como una configuración de lista de compilación, entonces no necesitarán hacer ningún cambio a tu código. Los pasos de construcción son un poco diferentes. Para esto... Podrías querer usar diferentes herramientas para hacer tu experiencia de desarrollo un poco mejor como autor de la biblioteca. Podrías usar TypeScript porque te gusta el análisis estático que te da. Podrías querer agregar tipos a tu código también. SAS te da cosas como tal vez funciones que no están disponibles en CSS.

Y Stencil te permite escribir componentes en su sintaxis dada, que luego se compila a componentes web de vanilla. Pero el desafío con estos es que no son tecnologías amigables para el navegador. Y voy a decir algo bastante impactante aquí, y es que el código que no es compatible con el navegador no funcionará en el navegador. Y lo que eso significa es que si quieres usar TypeScript, tendrás que agregar un compilador a tu repositorio para asegurar que el código que escribes realmente se convierta en código amigable para el navegador. Y así, si estás escribiendo un componente en TypeScript, antes de que ese código se renderice en el navegador, necesita pasar por ese paso de compilación. Y así, hay este nivel de fricción entre escribir el código y realmente verlo funcionar. Y eso puede estar bien para ti. Tal vez esa compensación no sea un problema. Si estás trabajando solo y realmente te gusta TypeScript, esa podría ser una buena opción. Pero si estás trabajando en un equipo o estás trabajando en un proyecto de código abierto, entonces podrías darte cuenta de que cualquiera que quiera contribuir tiene que entender cómo funciona todo. Y eso podría simplemente hacer las cosas un poco más complejas. Lo mismo ocurre con tener un compilador, incluso si es TypeScript, Stencil, lo que sea, es que ahora hay esta caja negra, que podría ser un punto único de fallo. Y así podrías terminar luchando con esta herramienta si no está funcionando de la manera que esperas. Y recuerdo haber leído un artículo de los desarrolladores de Shoelace. Y él dijo que usó Stencil inicialmente para construir los componentes web de Shoelace. Pero luego de un tiempo, simplemente seguía chocando contra el compilador y terminó cambiándose a Lit porque era una herramienta mucho más simple que le permitía escribir sus componentes web. Y otro ejemplo es el equipo de Svelte. Inicialmente escribieron la biblioteca en TypeScript, pero optaron por eliminar TypeScript, volver a JavaScript vanilla, y escribir sus tipos en JSDoc. Y esto fue útil porque hizo mucho más fácil que la gente contribuyera.

Y ahora, lo que podrías querer ser, podrías querer considerar es no sobrecorregir. Es fácil pasar de tener montones y montones de diferentes, herramientas de construcción allí para luego eliminar todo y solo asegurarte de que escribes tu código como un navegador lo leerá y evitar cualquier otra cosa como pruebas y tipos o lo que sea. Pero lo bueno es que no necesitas evitar todas esas cosas geniales. En lugar de escribir TypeScript y ejecutar el empaquetador antes de ejecutar tu código en el navegador, puedes en lugar de escribir tus tipos JSDoc y tener un paso de TypeScript literalmente justo antes de publicar para generar tipos desde tu JSDoc, y de esa manera puedes publicar tus tipos para que tus consumidores los usen. Así que no necesitas eliminar completamente todo o prescindir de todas estas herramientas útiles. Puedes simplemente hacer que sea lo más fácil posible para que otros contribuyan.

Así que mi enfoque, probablemente adivinaste que me gusta mantener las cosas bastante simples ahora. He pasado de un extremo de hacer las cosas lo más complejas posible, y ahora estoy como balanceándome en la otra dirección. Me gusta apoyarme en las capacidades del navegador, pero no estoy completamente en el campo de como nada más en absoluto. Un buen ejemplo es que te familiarizas mucho más con las herramientas en el navegador. Como creo que CSS es genial, y es súper capaz, particularmente en los últimos años. Así que ni siquiera he necesitado usar SAS o módulos CSS. Y tal vez en el pasado, solía simplemente usar SAS porque era a lo que estaba acostumbrado. Pero apoyarse, familiarizarse más con las herramientas fundamentales podría abrirte los ojos a que son mejores de lo que tal vez les das crédito. Lo mismo ocurre con TypeScript. Me gusta usarlo en mis aplicaciones, pero prefiero usar JS Dock al escribir mis bibliotecas.

Genial. Así que he cubierto unos tres dilemas diferentes, pero en el artículo de GitHub que mencioné antes, cubro mucho más. Así que si te gustaría aprender un poco más, entonces por favor échale un vistazo y tal vez incluso contribuye con tus propias historias. Eso es todo de mi parte, y agradezco que hayas visto, y que tengas un buen día. Adiós.