Optimizing Front-End Frameworks

Es hora de comenzar. Vamos a empezar. Muy bien, todos. Bienvenidos, bienvenidos, y como dijimos, bienvenidos a 1,000 maneras de autocompletar. Así que probablemente hayas visto una interfaz de usuario como esta antes donde vas a ver mucho JavaScript. Esto es mucho JavaScript. Hay muchas preguntas enumeradas debajo de ella, y podrías haber implementado una interfaz de usuario como esta tú mismo, y en esta charla, vamos a mostrar cómo esto se puede implementar de muchas maneras diferentes.

Así que, y todas esas cosas que podrías considerar son cosas como eliminación de rebotes de entrada. Así que mientras el usuario está escribiendo, no quieres enviar una solicitud API por cada pulsación de tecla. Quieres enviar una solicitud por cada pulsación de tecla. Y si algo está sucediendo detrás de escena, queremos dar alguna indicación al usuario. Además, queremos cancelar solicitudes en curso. Así que si enviamos una solicitud y luego necesitamos enviar una nueva solicitud, necesitamos cancelar esa solicitud anterior, de lo contrario, la interfaz de usuario podría desincronizarse. Y también necesitamos preocuparnos por los estados de error. A nadie le gusta cuando la pantalla simplemente se vuelve blanca, así que deberíamos manejar eso también.

Así que esta es una gran manera de implementar un framework de front-end. Así que voy a mostrarte un gran ejemplo de esta pregunta de entrevista de front-end donde ella implementó autocompletar con React y habló sobre cómo es una buena pregunta de entrevista. De hecho, me han hecho una pregunta similar en una entrevista, y es una gran manera de practicar trabajando con un framework de front-end y también practicar con React. Así que después de ver este video, lo implementé yo mismo con React, pero realmente me hizo pensar, porque de alguna manera, es una buena manera de evaluar todos estos frameworks y todas estas cosas. Así que voy a hablar sobre cómo estamos haciendo con interfaces de usuario condicionales y renderizado de listas y actualizaciones de estado y efectos y actualizaciones de estado dependientes y gestión de estado asíncrono y todas estas cosas que realmente muestran cómo se hacen todas estas cosas a través de todos estos frameworks y bibliotecas. Así que en esta charla, voy a mostrarte cómo lo hice en Vanilla Js y React y Vue y Angular, preact, Svelte, solid y en HTMX.

Así que hola, mi nombre es CJ, como se dijo, actualmente soy un desarrollador web, he estado trabajando con Vue y Angular, y estoy trabajando con Vue y Angular, y estoy trabajando con Vue. ¿Quién aquí escucha el podcast Syntax? Sí, sí. Esperamos ver más manos más tarde. Y cada episodio del podcast Syntax es traído a ustedes por Sentry, así como cada video, así que de hecho hago videos para el canal de YouTube Syntax y Sentry es una plataforma de monitoreo de errores. Puedes agregarlo a tu aplicación en producción, y cualquier error que ocurra se envía de vuelta al panel de control, y luego puedes volver al panel de control, y luego puedes volver al panel de control, y luego puedes volver al panel de control. Así que puedes volver al panel de control en sentry.io. Ese era yo. Vamos a aprender quiénes son todos ustedes. ¿Quién aquí escribe JavaScript puro a diario? Vamos a ver una mano.

Probablemente la mayoría de ustedes. Quizás no exclusivamente Vanilla Js, pero creo que muchos de nosotros lo hacemos. ¿Quién aquí escribe React a diario? Esto es como el 80, 90% de la audiencia. Eso es increíble. ¿Quién aquí escribe Vue? ¡Sí! Bien. Como tres o cuatro manos. Increíble. Bien. Entonces, ¿qué hay de Angular? ¿Alguien de Angular? Uno. ¿Alguien más? Bien. ¿Dos? Bien. Genial. Um, ¿alguien escribe Preact? Sí, bien. ¿Qué hay de Svelte? ¿Ninguna mano para Svelte? Bien, bien. Te veo. Es difícil de ver. Hay luces brillantes. ¿Qué hay de solid? ¿Alguien escribe solid? Bien. Somos una comunidad de React. Tenemos mucho que aprender. Honestamente, esta charla es realmente para desarrolladores de React para ver todas las formas en que se hacen las cosas en todos estos frameworks.

Muy bien. Vamos también a establecer algunas expectativas porque para todos estos ejemplos que voy a mostrarles siempre estoy usando la última y actual versión de cada uno de los frameworks. Porque hay muchas maneras de hacer las cosas en cada uno de estos. Yo elegí la última versión y luego hice mi mejor esfuerzo para mostrar la forma preferida de hacerlo consultando la documentación, leyendo guías de la comunidad, excepto en Angular, por lo cual estoy eternamente apenado. Si escribes Angular, ven a verme después. Tengo brillantes stickers de Angular para ti. Hice mi mejor esfuerzo. Pero hay algunas áreas donde señalaré que probablemente podríamos haber usado RxJS o algo así.

Pero no tuve el tiempo. Tuve que hacer todas las otras cosas. Y todos estos ejemplos realmente se van a centrar en el código. ¿Cómo hacemos realmente estas cosas? Cómo funciona. ¿Cómo hacen estos frameworks el renderizado? ¿Está compilado? ¿Hay un virtual DOM? Eso es para una charla diferente. Esto se trata de todo el código. Qué escribimos como desarrolladores para hacer estas cosas.

Y también mostraré estos ejemplos de forma aislada. Tienes que usar tu imaginación para combinar todo lo que te mostré para poder demostrar todos estos aspectos. Muy bien. Y última advertencia, aquí hay código. Va a haber un montón de código. Pero te animo, si empiezas a sentirte abrumado, intenta estar atento a tu framework favorito como React. O tal vez cuando empieces a ver que aparece tu framework favorito, espera a verlo aparecer. Porque como dije, vas a ver mucho código.

Muy bien. Vamos a entrar en ello. Vamos a hablar primero de cómo estamos manejando el estado de entrada de formularios. Cuando estás construyendo esta UI, queremos hacer un seguimiento de lo que el usuario está escribiendo en este cuadro de entrada aquí. Y típicamente almacenamos eso en el estado. Así que podemos usarlo más tarde cuando estemos haciendo esa solicitud de API. Ahora, dentro de vanilla JS, podemos obtener el elemento del DOM con query selector. Imagina que tenemos algo de HTML. Y hay un elemento en la página con ID search. Podemos obtenerlo. Y luego podemos agregar un event listener para la entrada. Así que cada vez que hay una pulsación de tecla dentro de allí, se llamará a este callback y podemos usar ese valor. Así que en vanilla JS, el estado está realmente como dentro del DOM. Técnicamente, podrías sacarlo. Hay muchas maneras de implementar esto.

Pero en este caso, cada vez que se ejecuta input.value, va a tener el último valor. Así que el estado está como almacenado dentro del DOM.

Dentro de React, tenemos nuestro hook useState. Pasamos ese valor inicial como una cadena vacía. Y esto nos devuelve el valor actual de search. Y luego una función que podemos llamar para actualizarlo. Así que cada vez que se llama a setSearch, eso establece el último valor, vuelve a renderizar, search tendrá el último valor.

Ahora, Preact es en realidad como una versión compatible con la API de React pero más ligera. Como este código que estás viendo ahí funcionará directamente dentro de Preact. Pero Preact en realidad introdujo signals. Así que todos los ejemplos que voy a mostrar hoy con Preact serán con signals. Tienen este hook llamado use signal donde puedes pasar el valor inicial y luego usar el mismo hook para actualizarlo. Así que el primer ejemplo que voy a mostrar es un useSignal donde puedes pasar el valor inicial y luego obtienes esa signal. Y este es un objeto que tiene una propiedad dot value que siempre tendrá el último valor encima. Y luego podemos cambiar eso o sobrescribirlo para actualizarlo a un valor más nuevo.

Y en Solid, también tenemos signals. Pero es como una combinación de Preact y React. Así que tenemos este createSignal. Pasamos el valor inicial. Esto nos va a devolver un getter y un setter. Esa es una de las principales diferencias aquí. Este search es una función que necesitamos invocar en nuestro render para obtener el último valor. Pero eso es una señal para el compilador de que ese único lugar que llamó a ese getter realmente necesita ser actualizado cada vez que el valor cambia. Y luego setSearch, muy similar, lo llamamos para actualizar el estado.

Ahora dentro de Vue, tenemos esta función de composición llamada ref. Ahora, si estás familiarizado con React, podrías pensar, oh, eso es como useRef. Técnicamente se puede usar para eso. Pero siempre usamos esto para declarar valores reactivos. Esto es básicamente declarar un valor. Así que si queremos declarar un valor, podemos usar esta función.

Y luego si queremos acceder a él en nuestros códigos de JavaScript, podemos usar search.value. Así que se parece un poco a una signal. Y la forma en que lo usas es como una signal. Pero eso existía antes de que el término signal se volviera súper popular en el panorama actual de las cosas.

Y dentro de Svelte, aquí en este ejemplo de Svelte 5, estamos usando el estado del signo de dólar. Y así en el servicio, esto se ve como todos los demás. Todos los demás. Pero esto es en realidad una directiva del compilador. Es en realidad un indicador para el compilador para decir, oye, search es una variable que necesitamos rastrear. Si alguna vez cambia, actualiza la vista. Así que en realidad no es una llamada a función. Pero se parece un poco a eso.

Y luego en Angular, falta un montón de código aquí. Porque tenemos todas estas importaciones y decoradores. Pero en última instancia, vamos a estar usando el form control, que se introdujo en Angular 18. Y tus componentes de Angular son en realidad una clase. En este caso, tendremos una propiedad search, igualada a una instancia de form control. Así es como definimos el estado. Ahora, ¿cómo actualizamos realmente el estado? Oh, lo siento. HTML es solo un input. Porque es HTML y el estado se almacena en el DOM. Nada demasiado loco allí. Pero ahora, ¿cómo actualizamos realmente ese estado?

Dentro de React, necesitamos pasar un callback al método on change allí. Así que cuando este valor de input cambia, esta función se llama. Llamamos a nuestro setter, actualizamos el valor. Y luego podemos establecer el atributo de valor para que sea el último valor de search allí. Pero esto es como una pequeña mentira blanca. Porque bajo el capó en realidad es el valor de on input. Así que si decimos on input, obtendremos el evento on input. Pero solo nos dejan usar el evento on change.

Y dentro de Preact, realmente usas el evento on input. Así que esto es muy similar. Pero como mencioné, esa signal, podemos sobrescribirla directamente. Así que no tenemos que hacer nada especial. No tenemos que llamar a un setter. Podemos simplemente establecer el valor de la signal para que sea el último valor. Y luego para pasar el valor como la prop allí, simplemente pasamos search.value.

Ahora, Solid, de nuevo, es un poco como una combinación de React y Preact. Así que tenemos que usar ese on input. Y luego tenemos que llamar a nuestro setter para realmente actualizar el valor. Pero notarás que necesitamos invocar search. Así que ese es nuestro getter. Pero esa invocación es un indicador para el compilador de Solid de que este es un lugar que realmente necesita ser actualizado si search alguna vez cambia.

Ahora, Vue en realidad tiene una directiva incorporada. Se llama V model. Así que pasamos una variable de estado a ella. Y si eso alguna vez cambia, este input realmente será cambiado. Y luego podemos actualizar eso detrás de las escenas. Ahora, V dash model es solo azúcar sintáctica. Bajo el capó, está agregando un listener de cambio. Está enlazando el valor. Pero es bueno que esto esté incorporado. Y técnicamente, podrías hacerlo manualmente si quisieras. Pero lo hacemos tan a menudo, nos dan una pequeña directiva agradable para ello.

Y en Svelte, también hay una manera de enlazar al valor. Así que podemos usar el bind colon, especificar cualquier atributo, y luego poner un accesor de variable de estado con el signo de dólar dentro de allí. Y luego podemos hacerlo en el control de formulario. Pero, de nuevo, esto es realmente solo azúcar sintáctica. Todavía está agregando un listener de cambio. Todavía está actualizando el valor allí.

Dentro de Angular, ahora que estamos usando este control de formulario, podemos usar el control de formulario con corchetes y especificar el último valor dentro de allí. Y en HTML, sigue siendo solo el input porque el estado se almacena en el DOM. Muy bien. Podemos de alguna manera, mirando todos estos ejemplos, podemos categorizarlos de diferentes maneras. Estado manual, estoy llamando a React, Svelte, y luego todos los demás tienen algo de magia añadida. Tenemos directivas personalizadas, cosas personalizadas que podemos usar. Hay un poco de magia. Y luego, la otra forma en que puedes ver estos ejemplos es que algunos de ellos se categorizan como inmutables, algunos de ellos son mutables. En tanto React como Solid, básicamente sobrescribimos el último valor del estado cada vez que queremos cambiarlo. Pero para todos los otros ejemplos, podemos simplemente mutar directamente el estado.

ejemplos, podemos simplemente mutar directamente el estado. Muy bien. Estoy quedándome un poco sin tiempo, así que vamos a omitir el renderizado condicional y luego saltar directamente a async y efectos.

Pero si quieres ver esto, definitivamente ven a verme después, y hablaremos sobre ello. Bien. Así que estamos haciendo un seguimiento del estado, lo estamos actualizando. Cuando el estado cambia, digamos que queremos llamar a una API para obtener esos datos basados en cuál es el valor actual del estado. Para esto, vamos a usar el estado. Ahora, en JavaScript puro, literalmente podemos llamar a nuestra API dentro de nuestro listener de eventos allí. Y así, imagina que git results es una función que tiene fetch dentro de ella. Hace el trabajo duro de llamar a la API y obtener los resultados.

Pero debido a que este callback se va a llamar, cada vez que el valor del input cambia, git results va a llamar a la API en cada cambio allí. Dentro de React, usamos el usuario. Y así vamos a usar el usuario. Y vamos a llamar a la API. Y así dentro de React, vamos a hacer el hook use effect. Y notarás aquí, estamos pasando ese array como el último argumento, y ese es nuestro array de dependencias. Así que cada vez que el valor de búsqueda cambia, este use effect se va a volver a ejecutar. Y así, esencialmente, si estamos actualizando ese valor de búsqueda en el input, cada vez que cambia, este código se volverá a ejecutar, llamará a la API. Todos los otros frameworks son muy similares. Cada vez que estamos accediendo a signal.value, es capaz de hacer un seguimiento de eso, y saber que necesita volver a llamar a esto si cambia. Similar dentro de Solid, tienen create effect, y esto simplemente se volverá a ejecutar cada vez que sus dependencias cambien. Y nuevamente, estás viendo esa invocación justo allí. Así que estamos llamando, estamos invocando el getter, que es una señal para decir, hey, si esto cambia, ese código necesita volver a ejecutarse. Dentro de Svelte, ellos introdujeron la runa de efecto del signo de dólar aquí en Svelte 5, y podemos hacer algo similar, así que cada vez que cambia, simplemente llama a la API. Vue tiene una función de efecto de observación incorporada, muy similar, cada vez que search.value cambia, va a volver a ejecutar esta función. Angular, es un poco diferente, y aquí es donde empiezo a disculparme por el ejemplo. Así que en este caso, estamos suscribiéndonos a los cambios de búsqueda, que era esa propiedad de control de formulario, y luego si alguna vez cambia, estamos llamando a nuestra API. Este es un lugar donde potencialmente usarías algo como RxJS. Hay otras formas de hacerlo.

Esto es lo que obtienes por ahora, y también que ng on init es una especie de como nuestro component did mount. Cuando el componente se monta, ese código se ejecutará para configurar esa suscripción. Y luego en HTMX, podemos agregar este atributo hx-get. Así que cada vez que el input cambia, eso va a disparar una solicitud a slash search. Así que estoy categorizando estos de dos maneras. Tienes seguimiento manual, que es React, y luego todo lo demás es seguimiento automático. Así que en React, tienes que especificar el array de dependencias. Muchas veces tenemos reglas de ESLint que nos recordarán si olvidamos una dependencia o algo así, pero todos los demás, porque están basados en señales, pueden automáticamente recordar nuestros efectos y no tenemos que especificar manualmente ese array de dependencias.

Ahora hablemos de debouncing. Así que en este ejemplo, mientras el usuario escribe, estamos enviando una solicitud en cada pulsación de tecla, y esto es lo que queremos evitar, porque básicamente está saturando nuestra API, y realmente puede ralentizar las cosas. Lo que queremos es esperar a que el usuario termine de escribir, y luego llamar a la API. Así que el usuario escribe, y luego, una vez que ha terminado durante 200 milisegundos, llamamos a la API. Esto es debouncing.

Y la forma en que lo implementamos es simplemente con un set timeout. Así que te mostraré el ejemplo en JS vanilla primero, donde esencialmente tenemos un ID de timeout, y comienza vacío, pero luego cada vez que el input cambia, limpiamos el ID de timeout actual. Y así, clear timeout está integrado en el navegador web, y también vamos a usar el ID de timeout para realmente establecer un timeout para el usuario. Así que básicamente, comenzamos limpiando este timeout, y luego está bien si realmente pasas undefined. No va a dar error. Pero luego establecemos un timeout. Así que decimos, está bien, en 200 milisegundos, entonces llamaremos a la API. Pero si el callback de entrada se llama de nuevo, vamos a limpiar el anterior. Así que básicamente, mientras el usuario escribe, establecemos un timeout, y luego inmediatamente lo limpiamos, porque escribieron otro carácter. Así que lo establecemos, lo limpiamos, lo establecemos, lo limpiamos, y luego finalmente, si no escriben, lo limpiamos. Así que estamos alquilando esta misma cosa, pero en combinación con nuestro use effect.

Así que para React, la forma en que podemos limpiarlo es devolviendo una función desde nuestro use effect. Y así, esto se conoce como nuestra función de limpieza, ¿verdad? Establecemos el timeout almacenado dentro de ese ID de timeout, pero si el término de búsqueda cambia alguna vez, necesitamos limpiar ese timeout, y así la función que devolvemos desde el use effect se va a invocar, limpiar el timeout, y básicamente, lo limpiará, lo limpiará, lo limpiará, hasta que el usuario termine de escribir, y luego haga esa solicitud para obtener resultados. Todos los demás frameworks, muy similares. Así que en Preact, podemos devolver un callback desde nuestro use signal effect. En Svelte, también podemos devolver un callback desde nuestro efecto de signo de dólar. La única cosa a tener en cuenta aquí, sin embargo, es que Svelte 5 no rastrea automáticamente el acceso a dependencias dentro de callbacks anidados.

Así que aquí es donde estamos accediendo a la búsqueda, pero porque eso está en un callback anidado, Svelte no lo rastrea automáticamente. Así que el truco aquí es simplemente deshacerse de eso y luego simplemente acceder a él, y básicamente, como un no-op, simplemente, oye, necesito búsqueda, y luego el compilador de Svelte sabrá que necesita volver a ejecutar esta función cada vez que la búsqueda cambie, y nuevamente, estamos devolviendo esa función de limpieza. Por supuesto, esto es un truco. Probablemente hay mejores maneras de hacerlo, pero sí, y luego en Solid, muy similar, pero tienen esta función on cleanup que simplemente importas de la biblioteca de Solid. Así que no hay necesidad de devolver un callback, y lo bueno de eso es que realmente puedes llamarlo en cualquier lugar. Así que si tu función de limpieza por alguna razón necesita estar anidada en un callback o algo así, puedes hacerlo con ese on cleanup. Dentro de Angular, esto es un poco de nuevo, me disculpo, pero esto es como el ejemplo vanilla combinado con nuestra suscripción.

Así que si el timeout cambia, lo limpiamos y luego lo llamamos de nuevo si el valor de búsqueda cambia, y luego con Vue.js, bastante similar, pero ellos te dan la función on cleanup como argumento de callback. Así que podemos esencialmente establecer el timeout y luego pasar nuestro callback a on cleanup, pero esto es similar a Solid en que técnicamente podríamos llamarlo en cualquier lugar que quisiéramos. No tenemos que devolver una función, y luego con HTMX, tienen este atributo incorporado llamado HX trigger, y básicamente estamos diciendo que estamos escuchando key up y changed, pero con el retraso de 200 milisegundos. Así que esto no hará una solicitud a slash search a menos que el evento haya ocurrido hace 200 milisegundos y no se haya disparado uno nuevo. Así que ellos tienen una especie de forma incorporada de hacer ese set timeout. Y así realmente todos estos, excepto HTMX, es básicamente establecer tu timeout y luego limpiarlo y asignar algún tipo de callback. La forma en que haces el callback varía, pero básicamente tienes, como, una función de limpieza.

Bien. Hablaremos sobre el renderizado de listas. Vamos a pasar rápidamente por esto, porque tengo más cosas que mostrarte, pero básicamente en vanilla JS, tomamos ese elemento de resultados de la página y luego lo añadimos. Así que este es un elemento de lista que vamos a crear. Así que vamos a crear un elemento de lista para cada resultado que obtuvimos de la API y luego añadir todos esos. También podrías establecer innerHTML. Podríamos construir una cadena HTML o algo así, hay muchas maneras de hacerlo, pero en este caso, estamos creando manualmente cada elemento.

Y en React, por supuesto, podemos simplemente usar map. Lo que hay que tener en cuenta aquí es que necesitamos una key, porque necesitamos hacer un seguimiento de cada elemento en caso de que este array cambie. Así que esa key permite al mecanismo del DOM virtual asegurarse de que si algo en el array cambia, todavía estamos bien. Preact, muy similar, pero simplemente estamos accediendo al valor de la señal. Solid, un poco diferente. Tienen este componente incorporado llamado four, y luego tiene en cada propiedad donde puedes pasar una expresión. En este caso, estamos accediendo a resultados, que es una señal. Y esto básicamente necesita existir, porque los componentes solid no se vuelven a renderizar una y otra vez. Así que necesitamos asegurarnos de que estamos accediendo a todas las señales en el array. Y así, si solo hicieras un map simple, no sabría que necesita actualizarse. Por eso te dan ese método. Y luego pasas un callback y obtienes tu renderizado.

Vue tiene una directiva incorporada llamada V4 que te permite hacer item en items. Luego puedes pasar la key, porque Vue también se basa en el DOM virtual. Y también tienen esta sintaxis de handlebar. Y dentro de Angular, tienen su propio pequeño lenguaje aquí. Así que at four, item en items. También te permiten hacer un seguimiento de una key específica y están usando handlebars dentro. Y luego Svelte tiene su propia sintaxis personalizada también. Así que esto es hash each array as item. Y luego podemos realmente renderizarlo usando solo llaves simples allí y luego cerramos el bloque con slash each. Y en HTMX, realmente depende de tu empaquetado. Así que este es como el ejemplo completo con HTMX, donde no pude mostrar esto con renderizado condicional, pero si hay una solicitud a slash search, va a mostrar progreso, porque ese es el indicador de que algo está sucediendo.

Y luego, cuando volvemos a los resultados, el objetivo es este elemento de resultados aquí. Y así, lo principal a tener en cuenta es que nos falta la implementación del servidor, porque el servidor realmente necesita devolver esa lista de HTML que realmente añadimos a la página. Y así, todos estos tienen un lenguaje específico de dominio. Creo que incluso React y Preact, aunque es solo un map, sigue siendo un extraño JSX. Así que estoy llamando a todo esto lenguaje específico de dominio.

Así que ahí estaba el código. Vamos a llegar a algunas conclusiones y a dónde ir desde aquí. Las cosas que no pude cubrir son el manejo de errores, la cancelación de solicitudes, la accesibilidad y muchas otras cosas, pero en última instancia, la conclusión aquí es simplemente usar HTMX. Estoy bromeando. Vamos a sentir la sala. Así que sé que esto fue un recorrido vertiginoso y no pudimos ver todas las piezas, pero ¿quién aquí va a ir a casa y simplemente escribirse un poco de vanilla JS? ¿Nadie? Bien. ¿Quién va a ir a casa y seguir escribiendo React? Sí, creo que muchos de nosotros tenemos que hacerlo, porque es nuestro trabajo. ¿Quién va a ir a casa y escribir un poco de Vue? Vue fue genial, ¿verdad? Vif, V4, Vmodel, tiene muchas cosas buenas. ¿Quién va a ir a casa y probar Angular? Me disculpo. Sí, tenemos dos conversos, tal vez no estabas aquí antes, pero, sí, Angular es el camino a seguir. ¿Quién va a probar Preact? Preact es bastante dulce, y lo bueno de su biblioteca de señales es que realmente puedes usar eso en tu aplicación React, y puedes simplemente mostrarme tu aplicación React, y está allí, y puedes simplemente mirarlo. Tienen un Preact React signals, y puedes seguir usando tu mismo viejo React y añadir señales dentro de él. ¿Quién va a probar Svelte? Unos pocos, ¿sí? También es realmente genial. ¿Quién va a probar Solid? Ninguna mano. Personalmente, creo que si nos estamos inclinando hacia nuevos frameworks que hacen cosas de nuevas maneras, creo que Solid es probablemente la rampa de acceso más fácil para cualquier desarrollador de React, porque la sintaxis se ve realmente bien para ello. ¿Quién va a probar Svelte? Bien. De acuerdo. Tenemos al menos tres o cuatro conversos. Eso es increíble. Bien. Y luego, sí, hablemos sobre los próximos pasos. Así que, de nuevo, solo te mostré el código. No hablé sobre todas las otras cosas que necesitas considerar cuando estás eligiendo un framework de front-end. El ecosistema, ¿verdad? ¿Hay bibliotecas para mapas y gráficos y todo lo demás? ¿Hay bibliotecas para trabajar con componentes de UI, y cuáles son los recursos disponibles, verdad? ¿Hay muchos ejemplos por ahí? ¿Hay respuestas en stack overflow? ¿Fue la IA entrenada en Stack Overflow? ¿Hay una comunidad? ¿Tienen un servidor de Discord activo? ¿Hay problemas activos en GitHub o discusiones? ¿Y hay conferencias y encuentros? Así que, todo esto también importa, creo, cuando estás eligiendo tu framework de front-end. No se trata solo del código.

tu framework de front-end. No se trata solo del código. Estas son las cosas a considerar también, y potencialmente un tema para una futura charla. La otra cosa es sobre el rendimiento y cómo estas cosas realmente funcionan, ¿verdad? Así que, algunos de estos frameworks son compilados en lugar de tener código en tiempo de ejecución, y algunos de ellos usan un DOM virtual. Algunos de ellos no.

Algunos de ellos tienen, como, un ciclo de renderizado que funciona de cierta manera. Algunos de ellos tienen actualizaciones de grano fino, y todo eso es algo que podrías tener en cuenta también. Y, por supuesto, no va a haber una respuesta correcta. Creo que se reduce a la preferencia, tu experiencia pasada. Personalmente, uno de los primeros frameworks de front-end que usé fue Vue.js, como, la versión 1.4 o lo que sea, y así, para mí, tiendo a gravitar hacia Vue porque se parece a esas cosas más antiguas. Algunos de ustedes podrían haber escrito solo React en su vida, así que podrían no haber escrito React en su vida, así que definitivamente tu experiencia pasada entra en juego. La otra cosa es, como, ¿qué es correcto en el momento? Como, si trabajas en una empresa y estás construyendo una nueva aplicación, como, ¿qué es popular ahora mismo, o qué saben mis desarrolladores? Y tal vez tomes la decisión entonces. Y también, como dije, lo que usas en tu trabajo. Muchos de nosotros no tenemos elección. Simplemente tienes que usar lo que usas. Y en última instancia, creo que también se reduce a las vibraciones.

Como, ¿con qué vibra más? Y en última instancia, como, la razón por la que incluso di esta charla es que quiero animarte, como, a explorar, experimentar, salir de tu burbuja de confort de, como, escribir todo con React y ver que hay formas geniales de hacer las cosas del otro lado. Y la última pregunta que te dejaré es tal vez dejar de pensar en ti mismo como un desarrollador de React. Como, ¿cómo respondes a esta pregunta? Como, ¿eres un desarrollador de React? ¿Eres un desarrollador de Vue, un desarrollador de preact, un desarrollador de solid HTML, un desarrollador de insertar framework de la semana? ¿O eres un desarrollador de JavaScript? Muy bien. Muchas gracias. Tenía una pregunta para empezar. Así que, sé que pusiste la cosa de HTML ahí, pero ¿cuál es tu, como, si tuvieras que elegir uno, qué método elegirías? Ahora mismo me inclino hacia Svelte y también Vue. Como dije, tengo un largo amor por Vue. Lo he estado usando durante mucho tiempo. Y cuando Svelte salió fue muy, se sintió como la mejor versión de Vue. Y luego, cuando salió Svelte 5, fue como la segunda mejor versión de Vue. Y luego, cuando empecé a usarlo, estaba tan emocionado. Estaba como, oh, voy a usar esto. Y luego, cuando salió Svelte 5, inicialmente lo rechacé en Runes. Estaba como, oh, no, se está volviendo más complejo, pero me he acostumbrado a ello.

Y luego con Solid, también tienen este componente switch. Así que hay otras formas de escribir esto que no son solo lo que mostré aquí. Pero Svelte o Vue serían mi respuesta allí.

Bien. Bien. Y tengo una pregunta aquí de un anónimo. ¿No preferiríamos adjuntar la solicitud al callback adjunto al callback de debounce de entrada en lugar de escribir en effect para reaccionar a un cambio de estado? Depende, sí. Así que de nuevo, hay muchas maneras de implementarlo. También están, como, si eres un desarrollador de React, hay una biblioteca, como, use debounce value, ¿verdad? Y así, en lugar de combinar la actualización de estado con la actualización de estado, también hay una biblioteca que se llama use debounce. Y así, en lugar de combinar la actualización de estado con la solicitud, podrías realmente tener una variable de estado separada que solo se actualiza en debounce y luego tener un use effect separado que dependa de eso. Creo que eso es un poco a lo que se refieren. Definitivamente un enfoque válido. Simplemente no uno que mostré.

Y a continuación, otra pregunta anónima. ¿Por qué no simplemente usar el hook use debounce? Oh, bien. Porque quería mostrarte cómo hacerlo tú mismo. Te voy a mostrar cómo hacerlo. Así que, como, tengo una biblioteca que estoy usando. Esa es la razón principal. Y un poco ya hablé de ello. Por supuesto, si tienes una base de código más grande, no querrás estar escribiendo esto desde cero en cada lugar. Podrías recurrir a una biblioteca que implemente use debounce value. Sí. Pero es un gran punto. Creo que para muchas de estas cosas, hay realmente bibliotecas que implementarán todo esto por ti. No tienes que escribir nada del código. Creo que como un ejercicio en solo ver cómo funcionan las cosas en estos frameworks es una buena oportunidad para hacerlo. Hay una pequeña versión de esto donde puedes usar las teclas de flecha hacia abajo para seleccionar los elementos. Creo que es una buena pregunta de entrevista porque no es solo código de fuga. Es como, ¿conoces los fundamentos de cualquier framework de front-end? ¿Puedes realmente, como, implementar estas cosas? Bien.

Otra más. Solo tenemos un par de preguntas más aquí. ¿Cuáles son tus pensamientos sobre lit y o web components? Sí. No he pasado mucho tiempo con ellos. Creo que se reduce a, como, cuando estás incluso con lit, que de alguna manera te ayuda a reducir el boilerplate cuando estás construyendo web components, todavía hay mucho código extra que tienes que escribir potencialmente para, como, la gestión de estado. Tal vez recurras a otra biblioteca. Y podría terminar pareciendo un poco como el ejemplo de vanilla. Pero honestamente, no he pasado mucho tiempo con ellos. Probablemente debería.

Bien. Tenemos una última pregunta. Sé que has estado escribiendo durante mucho tiempo. ¿Cómo conoces todos estos lenguajes? Tengo mucho tiempo libre. Y así hago videos en YouTube para syntax. Y creo que parte de mi trabajo y supongo que también lo que estaba haciendo para Coding Garden antes de que me contrataran en syntax es muchas comparaciones. Mucha gente está ocupada, ¿verdad? No tienen tiempo para hacer todo esto. Así que si puedo ser el tipo que lo hace y lo resume para ti, con gusto lo haría. Y lo disfruto. Como dije en mis conclusiones, hay formas más interesantes y mejores de hacer las cosas. No todo tiene que ser React. Y creo que ver eso y también inspirarse, tal vez te inspiró a escribir tu React de manera ligeramente diferente también. Eso es algo que me gustaría hacer.

Así que, sí. Genial. Bueno, gracias. Esas son todas las preguntas para las que tenemos tiempo. Pero aún pueden hacer preguntas después. CJ estará por aquí si tienen más preguntas. Así que asegúrense de calificar la charla en Slido. Y vamos a tener un breve descanso para que puedan cambiar de pista. Así que solo revisen el horario del sitio web para averiguar qué quieren hacer a continuación. Así que gracias, CJ.