Opcional Javascript: Aplicaciones React modernas que funcionan sin JS

Es genial ver tantas caras aquí. Y supongo que vamos a empezar de inmediato. Así que la idea para esta charla proviene del proyecto en el que trabajamos, que fue un experimento para obtener una respuesta a la siguiente pregunta. ¿Podemos construir aplicaciones de react que también puedan funcionar sin JavaScript? Y por falta de un nombre mejor, comencé a llamar a tales aplicaciones opcionales de JavaScript. Y hoy voy a compartir con ustedes mis hallazgos.

Pero primero, hablemos de la web sin JavaScript. Algunos de ustedes pueden haber intentado hacer esto en un navegador, por lo que saben lo que estoy a punto de mostrar. Pero para aquellos de ustedes que no lo han hecho, puedo resumir la experiencia de navegar por la web sin JavaScript en una diapositiva. Básicamente, se ve así. Hay un pequeño número de aplicaciones que conservan cierto grado de funcionalidad. Pero en la mayoría de los casos, obtendrás un esqueleto de aplicación que parece que está cargando pero nunca lo hará, o un simple mensaje pidiéndote que vuelvas a activar el JavaScript. Y eso tiene sentido, ¿verdad? Porque sabemos que las aplicaciones altamente interactivas van de la mano con JavaScript. Entonces, sin JavaScript, simplemente se rompen.

Pero no todos los sitios web son creados iguales. Y mientras tenemos un gran número de sitios web que tienen JavaScript como una parte intrínseca para proporcionar sus características principales, hay un número aún mayor de aplicaciones que utilizan JavaScript para mejorar la experiencia del usuario, ¿verdad? Para mostrar campos de entrada más amigables para el usuario, agregar algunas micro interacciones, cosas así. Pero esencialmente, tal JavaScript sirve para un propósito cosmético. Y por lo tanto, no debería ser difícil imaginar que tales aplicaciones aún podrían funcionar incluso cuando JavaScript está apagado, al menos en teoría. En la práctica, sin embargo, casi nunca sucede porque la construcción de aplicaciones para el enfoque opcional de JavaScript requiere una intención. Pero lo mejor que solemos hacer es poner una etiqueta de no-script con un mensaje y dar por terminado el día.

Ahora, todo eso puede parecer irrelevante, pero comencé a notar que las herramientas y frameworks que estamos utilizando están comenzando a abordar eso. Y no solo hablan de este problema, sino que también nos dan herramientas que facilitan el desarrollo de aplicaciones opcionales de JavaScript. Así que comenzando con el último React y Next.js que lo utiliza. Nos dan React componentes de servidor y acciones de servidor que nos permiten mover la obtención de datos y la mutación de datos al servidor. Ahora, esto es muy importante porque esa habilidad se convertirá en clave para desbloquear experiencias sin JavaScript. Luego también está remix y las aplicaciones construidas sobre React Router que utilizan el último enrutador de datos. Tienen abstracciones ligeramente diferentes, ¿verdad? Utilizan cargadores y acciones, pero esencialmente logran el mismo objetivo, obtener y mutar datos en un servidor. Y luego, incluso si miramos fuera del ecosistema de React, descubriremos herramientas como Astro, SolidStarts, Weld, tal vez incluso más que comienzan a abordar este problema de experiencias sin JavaScript de una forma u otra. Entonces eso plantea una pregunta, ¿verdad? ¿Por qué todo el mundo está hablando de esto de repente? Y si miramos las estadísticas de los usuarios que desactivan activamente JavaScript en su navegador, vamos a descubrir que el número es bastante pequeño, ¿verdad? Es aproximadamente el 0.2% de todo el tráfico web. Pero lo que importa mucho más es cómo este enfoque opcional de JavaScript afecta el rendimiento de la aplicación performance y una métrica llamada TTI en particular, ¿verdad? TTI, o tiempo hasta la interactividad en términos laicos, es la cantidad de tiempo que se necesita desde ver un botón hasta poder hacer clic en él, porque, ya sabes, en React no sucede instantáneamente. Primero necesitamos descargar, analizar y ejecutar el paquete de JavaScript.

Y si tenemos un gran paquete de JavaScript y una red lenta, entonces tenemos un problema, porque este retraso puede extenderse a varios segundos, y vemos a los usuarios abandonar el sitio web. Pero si construimos nuestras aplicaciones de manera que sean utilizables incluso antes de que cualquier JavaScript esté listo, reducimos efectivamente este retraso a cero, lo que resulta ser muy efectivo.

Y hay mucho más que decir sobre las razones para el enfoque opcional de JavaScript, pero en interés del tiempo, hablemos de una parte más interesante y veamos cómo podemos hacerlo. Entonces, para demostrar eso, vamos a construir una aplicación de comercio electrónico. Y para los ejemplos de código, voy a usar React componentes de servidor y acciones de servidor. Pero hay que decir que todas las técnicas que voy a mostrarles funcionarán igual de bien con Remix, y en algunos casos, las soluciones serán incluso más simples.

Entonces, ¿por dónde empezamos? Bueno, primero, comenzamos mostrando una lista de productos. Ahora, si tenemos una lista muy pequeña de productos, simplemente podemos obtener todos esos en un servidor utilizando un componente de servidor de React en este ejemplo y simplemente enviar una lista pre-renderizada de vuelta al cliente. Ya sabes, este método estará disponible ya sea que JavaScript esté activado o no. Pero esto es muy simple.

En un escenario más probable, vamos a necesitar algún tipo de paginación. Y vamos a agregar, para este ejemplo, paginación de desplazamiento infinito. Entonces, para hacer que funcione, en lugar de pre-obtener todos los data en el servidor, vamos a pre-obtener solo la primera página de los resultados. Y luego, en el lado del cliente, usaremos el estado local para llevar un registro de la página que necesitamos cargar y un observador de intersección que disparará una solicitud sincrónica para obtener la siguiente página de resultados siempre que el usuario esté a punto de desplazarse hasta el final. Y eso funciona muy bien, excepto en los momentos en que apagamos JavaScript, los usuarios se desplazarán hacia abajo hasta el final de la página y no pasará nada. Porque cuando JavaScript no está disponible, no tenemos acceso al hook de estado, ninguno de las APIs de JavaScript, e incluso no podemos hacer una solicitud sincrónica.

Entonces, para hacer que funcione sin JavaScript, vamos a utilizar un par de técnicas. Entonces, primero, vamos a emplear una técnica llamada degradación elegante, lo que significa que para cada elemento de interfaz de usuario más interactivo que absolutamente no puede funcionar con nuestro JavaScript, vamos a proporcionar una interfaz de usuario de respaldo menos interactiva que sí pueda. Y, en nuestro caso, es tan simple como volver a una lista más tradicional de anclas para la paginación. Ahora, en segundo lugar, vamos a mover el estado local a la URL, porque todavía necesitamos mantener un registro de la página que queremos cargar. Y dado que no podemos usar el estado local para eso, vamos a elevarlo y ponerlo en la búsqueda parámetros de la cadena de URL. Así que veamos la solución completa. Entonces, cuando renderizo la lista de productos a continuación, simplemente agregaré una sección que renderiza anclas para enlazar a diferentes páginas de resultados. Ahora, si no queremos mostrar esta interfaz de usuario a todos los usuarios, sino solo a los usuarios que desactivaron JavaScript en un navegador, podemos hacerlo envolviéndolo en una etiqueta de no script. Ahora todo lo que necesitamos hacer es en el lado del servidor dentro del componente del servidor, en lugar de pre-obtener la primera página, vamos a analizarla a partir de los parámetros de búsqueda y esa es la solución completa. Entonces, para los usuarios que sí tienen JavaScript habilitado, pueden disfrutar de una experiencia completamente fluida con estados de carga y data siendo obtenidos y agregados automáticamente. Para los usuarios que no tienen JavaScript, no obtienen nada de eso, pero al menos, tienen una paginación de estilo más tradicional que les permite usar la aplicación.

Bien. A continuación, veamos cómo podemos agregar artículos al carrito. Hay varias formas de hacer esto, pero una implementación típica se parece más o menos a esto. Tenemos un botón que, una vez pulsado, va a agregar este artículo a algún lugar en un estado global de la aplicación, tal vez incluso a un almacenamiento local para asegurarnos de que puede sobrevivir a las recargas de página. Y una vez más, sin JavaScript, este enfoque simplemente no funcionará. Y en este caso, para hacer que funcione, vamos a optar por una solución completamente diferente.

Entonces, en primer lugar, vamos a trasladar la responsabilidad de gestionar el carrito del cliente al servidor. Entonces, en lugar de tener el carrito en el almacenamiento local del navegador del usuario, lo vamos a trasladar al carrito en la sesión del usuario final en el lado del servidor. En segundo lugar, todavía necesitamos tener una forma de enviar el ID del producto que queremos agregar al servidor. Y para eso, vamos a utilizar los envíos de formularios nativos del navegador. Entonces, para mostrarles cómo puede funcionar, primero, eliminaremos todas las APIs de JavaScript a las que no tenemos acceso. En segundo lugar, convertiremos el botón en un botón de envío y lo pondremos dentro de un formulario. El formulario se enviará a la acción AgregarAlCarrito que veremos en un segundo. Y finalmente, añadiremos campos de entrada ocultos con el ID del producto porque los formularios necesitan entradas para enviar datos al servidor. Ahora, en el servidor, dentro de nuestra acción del servidor, todo lo que necesitamos hacer es analizar este valor de los valores del formulario enviado y luego usarlo para actualizar el carrito en la sesión del usuario. Y con este cambio, una vez más, déjame intentarlo de nuevo, la animación está jugando. Sí. Entonces, sí, los usuarios que sí tienen JavaScript disponible, todavía disfrutarán de una experiencia completa con estados de carga y notificaciones de toast. Los usuarios que no tienen JavaScript disponible no verán ninguna de estas características agradables, pero al menos, la funcionalidad funcionará y el artículo se añadirá a un carrito. Ahora lo que es importante destacar aquí es que, dado que no estamos utilizando envíos de formularios directamente sino a través de una abstracción de acción del servidor, podemos obtener lo mejor de ambos mundos, es decir que cuando no tenemos JavaScript disponible, el navegador va a enviar el formulario al servidor, obteniendo todo el HTML de vuelta como respuesta. Pero cuando sí tenemos JavaScript disponible, la abstracción o acción del servidor va a interceptar esta solicitud para nosotros y disparar una solicitud sincrónica obteniendo únicamente de vuelta el componente del servidor React que realmente se actualizó.

Bien. A continuación, quiero construir esta función llamada vista previa de la tarjeta. Entonces, cuando pasamos el cursor o hacemos clic en el icono de la tarjeta, vamos a mostrar una pequeña ventana emergente con una vista previa de los artículos en una tarjeta. Y una vez más, una implementación típica dependería de la bandera de visibilidad que nosotros simplemente alternaríamos al hacer clic en el botón y condicionaríamos la renderización del contenido emergente. La misma historia aquí. Sin JavaScript, esto no funcionará. Pero este es un buen lugar para considerar si necesitamos JavaScript en absoluto. Porque en estos días, muchos componentes que anteriormente requerían JavaScript para funcionar ahora pueden implementarse completamente sin él. Así que cosas como ventanas emergentes, diálogos de modelo, menús contextuales, carruseles simples, acordeones, todos estos elementos pueden construirse utilizando solo HTML y CSS.

Entonces eso es lo que vamos a hacer aquí. Vamos a aprovechar más HTML y CSS. Para este ejemplo en particular, voy a usar una de las nuevas APIs de popover de HTML. Así que me desharé del JavaScript, daré IDs al div popover y al botón, para que puedan referenciarse mutuamente, y luego marcaremos nuestro div popover como un popover y le daremos como ID al botón como objetivo de popover. Ahora esto los va a vincular semánticamente, por lo que el botón va a alternar la visibilidad del popover pero no van a estar visualmente alineados. Entonces, para solucionar eso, también podemos usar la API de anclaje de HTML que le dirá a este popover que esté anclado al botón que lo alterna. E incluso podemos espolvorear algo de CSS para alinearlo mejor y tal vez agregar algunas animaciones. Entonces, al final, obtenemos este componente que se ve y funciona exactamente igual, ya tengamos disponible JavaScript o no.

Finalmente, hablemos del proceso de pago. Ahora, el proceso de pago generalmente consta de dos pasos. Queremos recopilar los detalles de envío y luego procesar el pago. No voy a hablar de los detalles de envío porque es un formulario simple y ya sabemos que podemos aprovechar las presentaciones de formularios nativos del navegador para lidiar con forms. Así que veamos el procesamiento del pago en su lugar. Para esta demostración, utilicé la integración de Stripe para el procesamiento de pagos y una versión simplificada de la misma se ve más o menos así, donde hacemos clic en un botón, se activa una llamada a Stripe JavaScript SDK y este se encarga del resto. ¿Verdad? Se maneja en el sitio de Stripe. Y aquí nos encontramos en esta interesante situación en la que dependemos de un servicio externo que no está diseñado para funcionar sin JavaScript, y no hay nada que podamos hacer al respecto. Y es importante reconocer que situaciones como esta sucederán inevitablemente y lo mejor que podemos hacer aquí es desactivar de manera elegante las partes de la interfaz de usuario que absolutamente no pueden funcionar sin JavaScript.

Entonces, resulta ser un desafío bastante interesante en sí mismo porque quieres desactivar algo condicionalmente sin usar JavaScript. Entonces, en su lugar, vamos a usar un enfoque ligeramente diferente. Voy a definir esta clase require JS que ocultará el elemento al usuario. Ahora, queremos que esta clase se aplique solo cuando JavaScript no esté disponible. Así que pondremos esta definición dentro de una etiqueta sin script. Una forma alternativa de hacerlo sería usar una de las nuevas consultas de medios de scripting none, pero esta aún no tiene buen soporte de navegador. Y así, todo lo que necesitamos hacer es dar el nombre de la clase a nuestro botón de pago. Y cuando el JavaScript no esté disponible, simplemente estará oculto.

Ahora, no es una buena idea simplemente ocultar los elementos de la interfaz de usuario a los usuarios sin informarles qué sucede. Entonces, para que funcione, vamos a agregar otra etiqueta sin script junto a ella. Y pondremos un botón desactivado dentro. Y en este ejemplo, estoy usando el atributo de título para informar al usuario qué está sucediendo. Y al final, obtenemos una experiencia muy diferente. Pero al menos, las personas que no tienen JavaScript disponible pueden continuar hasta el paso de pago, y se les notifica que, ya sabes, has llegado al final. Ahora, es hora de obtener el JavaScript. Así que para resumir, aquí están todas las diferentes técnicas que cubrí hoy. Pero si piensas en ellas, esencialmente se reducen a la idea central de esta charla, que es saber qué es posible sin JavaScript y no usar JavaScript donde JavaScript no es necesario. Porque es muy común ver estos días que las personas que se meten en web development, se lanzan directamente a frameworks y bibliotecas, saltándose completamente los fundamentos. Y conocerlos, y conocerlos bien, te dará una gran ventaja competitiva. Y para volver a la pregunta del por qué que vimos al principio, también puedes querer darle una oportunidad a las aplicaciones opcionales de JavaScript solo para aprender algo nuevo y, con suerte, convertirte en un mejor desarrollador. Y eso es todo lo que tengo para ti.

Muchas gracias. Vale. Entonces la primera pregunta que tenemos es ¿por qué los usuarios desactivarían JS? Y creo que nos falta un micrófono. Podemos compartir. Compartir es vivir. Tengo el lavalier. Oh, perfecto. Ahí vamos. Lo siento, me distraje. ¿Cuál era la pregunta? La pregunta es ¿por qué los usuarios desactivarían JS? Sí, bueno, creo que mencioné el 0,2% del tráfico web y creo que es un montón de usuarios con preocupaciones de privacidad o que usan navegadores que desactivan JavaScript por ellos. Pero a menudo sucede que el JavaScript no está disponible y no es culpa del usuario. Por ejemplo, puedes estar en una red muy lenta y algunos dispositivos, como el navegador Chrome en dispositivos Android si detecta una red lenta, simplemente desactivará JavaScript por ti. Terminarás experimentando lo que mostré, una aplicación completamente rota y realmente no sabiendo por qué sucede. Bien.

La siguiente es ¿alguna reflexión sobre las repercusiones de accesibilidad de las soluciones opcionales de JS? Ejemplo, los lectores de pantalla anuncian forms de manera diferente a los botones independientes. Creo que puedes solucionar esto usando diferentes atributos de área. Por supuesto, no todas las soluciones funcionarán bien con esto. Y, por ejemplo, mencioné algunos elementos de la interfaz de usuario que puedes construir sin usar JavaScript, pero al final, tienes que prestar atención porque hay muchas soluciones que logran ese objetivo. Pueden funcionar sin JavaScript, pero son simplemente horribles tanto desde el punto de vista de la accessibilidad, como del rendimiento, por lo que necesitas saber lo que estás haciendo, pero para la La pregunta principal diría que sí, puedes solucionar estos problemas con los forms usando atributos de área. Y, si tienes alguna pregunta adicional, puedes twittear a Konstantin, encontrarlo en LinkedIn. Sí. Y estará encantado de ayudarte con las soluciones.

La siguiente que tenemos es ¿cómo haces los compromisos entre usar soluciones que no requieren JS y el soporte del navegador a las características? Estos dependen de, por ejemplo, la API de popover no es compatible con Firefox. Sí, es una buena pregunta. Quiero decir, mencioné específicamente la API de popover porque es una buena idea mantener un ojo en las cosas nuevas, así que no quería mostrar el aburrido enfoque solo con CSS. Pero también se puede hacer sin la API de popover. Y, sí, quiero decir, realmente no deberías sacrificar la experiencia de la mayoría de los usuarios que estarán usando navegadores modernos con características modernas por el bien de un número menor de usuarios, porque la proporción está muy sesgada, como hemos visto. Entonces, sí. Suena bien. Firefox.

La siguiente es, si un usuario construye un carrito sin JS y luego activa JS para pagar, ¿cómo mantienes los artículos del carrito? Bueno, si tienes el carrito en sí en el lado del servidor en la sesión del usuario, entonces no importa si el usuario tiene JavaScript habilitado o no, porque, ya sabes, siempre vive en el lado del servidor, y siempre que el usuario esté autenticado y la sesión de compra actual esté vinculada a ellos, no habrá ningún problema. Suena bien.

¿Cómo afecta este enfoque al performance para los usuarios que no desactivan JavaScript? Bueno, depende de las técnicas que uses, pero generalmente no afecta realmente al performance. Entonces, por ejemplo, las cosas que mostré con los envíos de formularios, como, obtienes ambos, lo mejor de ambos mundos. Entonces obtienes la alternativa a un envío de formulario más tradicional, pero no arruina la experiencia para los usuarios que tienen JavaScript. Entonces todavía obtienen todos los beneficios. Creo que el principal compromiso aquí es que como desarrollador, necesitas pensar en esto más y a veces la implementación resulta ser, lleva más tiempo para completar, pero desde la perspectiva del usuario, creo que está todo bien.

Misma experiencia. La siguiente es, ¿las etiquetas sin script todavía son manejadas por el navegador si JS está habilitado? ¿O la clase JS requerida todavía existiría para un usuario con JS habilitado? No estoy seguro de entender la pregunta. ¿Queremos un seguimiento de la pregunta? ¿Sabemos de quién vino la pregunta? Tal vez uno de nuestros, sí. Sí. Sí. ¿Se enviarían los data al usuario con JS habilitado? Bueno, los data en sí todavía estarían incluidos en la carga útil de la página. Es solo el navegador cuando procesa el CSS. Pasaría por la hoja de estilo, pero ignoraría esta parte dentro de la etiqueta noscript si JavaScript está disponible. Gracias. Gracias por el seguimiento. La siguiente que tenemos, lo siento, la pantalla acaba de refrescarse, démosle un momento. Estoy viendo algunas de las preguntas que ya abordamos. Estamos teniendo un poco de redundancia. ¿Puedes dar un ejemplo de que la implementación sin JS es mejor que usar JS? Creo que ya lo cubrimos. Bueno, probablemente este enfoque tenga más sentido para las aplicaciones que tienen mucho tráfico, tienen muchos usuarios, por lo que el impacto en el 0.2% es realmente significativo. Entonces creo que el New York Times, solo para dar un ejemplo muy específico, es muy bueno en esto porque incluso sus artículos más interactivos que usan visuales SVG animados para apoyar la idea, todavía funcionan sin JavaScript habilitado. Por otro lado, hay un sitio web como Medium donde ni siquiera puedes cargar la página de inicio sin JavaScript, entonces creo, bueno, la respuesta simple es, supongo, un blog o un sitio web que te da contenido simple no debería requerir JavaScript para una funcionalidad tan simple.

Entendido. Y luego la siguiente es que esto depende de la renderización en el lado del servidor. ¿Existe un enfoque de Node.js que funcione completamente en el lado del cliente? Por ejemplo, ¿renderizar JSX a HTML estático como parte de la construcción? Sí. Si no necesitas ninguna mutación de data o servidor en absoluto, puedes usar simplemente la generación de sitios estáticos, la exportación estática con Next.js o Remix o incluso Gatsby, y todavía funcionará. La siguiente es ¿cómo difieren estos componentes del servidor de otras aplicaciones históricas que ejecutaban la UI en el lado del servidor? Parece que estamos volviendo atrás. Bueno, parece así, pero hay un poco de oscilación entre las ideas que teníamos en el pasado sobre cómo construir aplicaciones y cómo lo hacemos ahora.

Pero creo que eventualmente vamos a llegar al punto donde puedes combinar las formas antiguas de hacer aplicaciones y las nuevas sin romper el ritmo. Por lo tanto, se vuelve significativamente más sencillo combinarlas.

Y esta dice, ¿algún tips para identificar las lagunas de conocimiento para aquellos desarrolladores que se lanzaron directamente a un framework sin dominar los fundamentos? Esa es una muy buena pregunta. Yo recomendaría, bueno, por ejemplo, para HTML y CSS, puedes seguir el estado de HTML y CSS. Normalmente se mencionan todas las nuevas IPIs que los navegadores lanzan y que muchas personas no conocen. Para mí, también es un buen ejercicio explorar los code pens solo de CSS, en CodePen, donde como mencioné, la gente intenta construir diferentes componentes solo usando CSS. Tienes que tener cuidado con esto, una vez más, porque a veces se esfuerzan demasiado en esto, pero es un buen lugar para mirar. A darlo todo o irse a casa. Bien, veamos. ¿Tienes que acceder al back end? ¿Tienes que tener acceso al código del back end para el ejemplo que mostraste para renderizar las páginas? Si tu servidor solo devuelve un JSON y no HTML, ¿qué haces? Bueno, supongo que si miramos esto desde la perspectiva de la architecture, tenemos aplicaciones que son más pesadas en el front-end, interactuando con back-ends externos, o puedes tener aplicaciones que de alguna manera hacen de proxy para las llamadas a la API a través del back-end del front-end. Suena un poco raro, pero sí, con Next.js y Remix, podemos hacer todo eso. Así que en este caso, realmente no necesitas tener acceso al código del back-end ya que posees todo el repositorio, por lo que la parte del servidor de tu aplicación front-end está ahí disponible para ti. No creo que esta sea una pregunta. Oh, desapareció. Ahí va. Node.js es genial para los servicios públicos de Tor, personas que viven en países con acceso a internet más riesgoso, etc. Así que supongo que estamos esperando una confirmación, ¿verdad? Lo es. Solo para los países que tienen una mala cobertura de internet y tal vez donde tus usuarios no tendrán los últimos dispositivos, también ayuda con el performance en dispositivos de gama baja, así como en redes más lentas. ¿Y esto es porque los tamaños de los paquetes son más pequeños? Es porque... bueno, el tamaño del paquete sigue siendo el mismo, pero no necesitas esperar a que se cargue el paquete para empezar a usar la aplicación. Tiene sentido. Bueno, hemos cubierto todas nuestras preguntas. Muchas gracias, Konstantin, por la increíble masterclass y por responder a todas las preguntas. No dudes en ponerte en contacto a través de LinkedIn, Twitter, si tienes alguna pregunta adicional. Gracias. ♪♪♪