Opcional Javascript: Aplicaciones React modernas que funcionan sin JS

Rate this content
Bookmark

¿Alguna vez has intentado navegar por tus sitios web favoritos con JS deshabilitado en tu navegador? Puede sentirse como cortar una línea de vida para internet. En lugar de interfaces amigables para el usuario, te enfrentas a una pared en blanco que dice “por favor, habilita JavaScript“ en el centro de ella. Pero no tiene por qué ser así.

En esta charla, exploraremos técnicas para construir aplicaciones web modernas que pueden seguir funcionando en un entorno sin JS, y proporcionar una experiencia completa cuando JS está activado.

28 min
13 Nov, 2023

AI Generated Video Summary

En esta charla, el orador discute el concepto de construir aplicaciones opcionales de JavaScript, centrándose en el uso de herramientas como los componentes del servidor React, Next.js, remix, React Router, Astro, SolidStarts y Weld. Exploran varios aspectos como la construcción de aplicaciones de comercio electrónico, la paginación, la adición de artículos al carrito sin JavaScript, y la implementación de características como las vistas previas de tarjetas utilizando HTML y CSS. El orador también destaca los compromisos y consideraciones al deshabilitar JavaScript, mantener los artículos en el carrito, y combinar formas antiguas y nuevas de construir aplicaciones.

1. Construyendo Aplicaciones Opcionales de JavaScript

Short description:

En esta charla, compartiré mis hallazgos sobre la construcción de aplicaciones de React que pueden funcionar sin JavaScript. Aunque las aplicaciones altamente interactivas dependen en gran medida de JavaScript, hay muchas aplicaciones que utilizan JavaScript con fines cosméticos. Herramientas como los componentes de servidor de React, Next.js, remix, React Router, Astro, SolidStarts y Weld están abordando el desafío de las experiencias sin JavaScript. Aunque solo un pequeño porcentaje de usuarios desactiva JavaScript, el impacto en el rendimiento de la aplicación, específicamente el tiempo hasta la interactividad (TTI), es significativo.

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.

2. Construyendo Aplicaciones de Comercio Electrónico Opcionales con JavaScript

Short description:

Si construimos nuestras aplicaciones para que sean utilizables incluso antes de que cualquier JavaScript esté listo, reducimos efectivamente el retraso a cero. Hablemos de la construcción de una aplicación de comercio electrónico utilizando componentes de servidor de React y acciones de servidor.

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.

3. Construyendo Paginación Opcional con JavaScript

Short description:

Para hacer que una aplicación funcione sin JavaScript, podemos emplear la degradación elegante y mover el estado local a la URL. Esto permite a los usuarios sin JavaScript tener una paginación de estilo más tradicional, mientras que los usuarios con JavaScript pueden disfrutar de una experiencia completamente fluida.

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.

4. Agregar Artículos al Carrito sin JavaScript

Short description:

Para agregar artículos al carrito sin JavaScript, trasladamos la responsabilidad de gestionar el carrito del cliente al servidor. Mediante el uso de envíos de formularios nativos del navegador, podemos enviar el ID del producto al servidor. La acción del servidor analizará los valores del formulario y actualizará el carrito del usuario. Los usuarios con JavaScript disfrutarán de una experiencia completa, mientras que aquellos sin JavaScript aún podrán agregar artículos al carrito.

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ó.

5. Construyendo la Función de Vista Previa de la Tarjeta

Short description:

A continuación, construyamos la función de vista previa de la tarjeta. Podemos implementar componentes como ventanas emergentes, diálogos de modelo, menús contextuales, carruseles simples y acordeones utilizando solo HTML y CSS.

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.

6. Aprovechando HTML y CSS para Popovers

Short description:

Aprovechamos más HTML y CSS utilizando las nuevas APIs de popover de HTML. Al dar IDs al div popover y al botón, podemos vincularlos semánticamente. Utilizando la API de anclaje de HTML, podemos anclar el popover al botón. Con algo de CSS, podemos alinear y animar el componente, haciéndolo funcionar independientemente de la disponibilidad de JavaScript.

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.

7. Pago y Dependencia de JavaScript

Short description:

Finalmente, hablemos del proceso de pago. El proceso de pago generalmente consta de dos pasos: recopilación de detalles de envío y procesamiento del pago. Aunque no cubriremos los detalles de envío, nos centraremos en el procesamiento del pago. A menudo dependemos de servicios externos, como Stripe, que requieren JavaScript. Para manejar esto, podemos desactivar de manera elegante los elementos de la interfaz de usuario que no pueden funcionar sin JavaScript. Podemos usar una etiqueta sin script para ocultar elementos y proporcionar elementos alternativos de la interfaz de usuario a los usuarios sin JavaScript. Al entender lo que es posible sin JavaScript y aprovecharlo donde no se necesita, podemos crear mejores experiencias de usuario y obtener una ventaja competitiva. Considere explorar las aplicaciones opcionales de JavaScript para expandir sus habilidades como desarrollador.

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.

QnA

Desactivando JS y Compromisos

Short description:

El 0,2% del tráfico web consiste en usuarios que desactivan JavaScript debido a preocupaciones de privacidad o navegadores que lo desactivan por ellos. Las redes lentas y ciertos dispositivos, como Chrome en Android, también pueden desactivar JavaScript. Las repercusiones de accesibilidad de las soluciones opcionales de JS pueden abordarse utilizando diferentes atributos de área. Sin embargo, algunas soluciones pueden sacrificar la accesibilidad y el rendimiento. Los compromisos entre las soluciones libres de JS y el soporte del navegador deben priorizar a la mayoría de los usuarios en navegadores modernos.

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.

Manteniendo los Artículos del Carrito y los Componentes del Servidor

Short description:

Si un usuario construye un carrito sin JS y luego activa JS para pagar, los artículos del carrito se pueden mantener teniendo el carrito en sí en el lado del servidor en la sesión del usuario. Este enfoque no afecta el rendimiento para los usuarios que no desactivan JavaScript. Las etiquetas sin script todavía son manejadas por el navegador si JS está habilitado, pero la clase JS requerida sería ignorada. La implementación sin JS puede ser mejor para aplicaciones con mucho tráfico, como el New York Times, donde incluso los artículos interactivos funcionan sin JavaScript. Existen enfoques de Node.js, como la generación de sitios estáticos con Next.js o Remix, que funcionan completamente en el lado del cliente. Los componentes del servidor difieren de las aplicaciones históricas de UI en el lado del servidor, ya que hay una oscilación entre las ideas pasadas y actuales sobre el desarrollo de aplicaciones.

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.

Combinando las Formas Antiguas y Nuevas

Short description:

Finalmente, las formas antiguas y nuevas de construir aplicaciones pueden combinarse sin problemas. Los desarrolladores que se lanzaron directamente a los frameworks sin dominar los fundamentos pueden identificar las lagunas de conocimiento siguiendo el estado de HTML y CSS. Explorar los code pens solo de CSS en CodePen también puede ser útil, pero se aconseja precaución para evitar una dependencia excesiva de los enfoques solo de CSS.

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. ♪♪♪

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
Node Congress 2022Node Congress 2022
34 min
Server-side Auth with Remix, Prisma, and the Web Platform
In this talk, we'll get a live coded demo of building custom hand-rolled authentication. When you have the right tools (and we do), authentication can be quite simple and secure. This is more (and better) than just: "Install this library and you're good to go." When we're done we'll have our own auth code that can evolve with our ever-changing requirements without a need to learn some library-specific APIs. We'll be leveraging the Web Platform the way it was meant to be done to give us simple and secure server-side authentication for the web.
You can check the slides for Kent's talk here as well as demo code.

Workshops on related topic

React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
Remix Conf Europe 2022Remix Conf Europe 2022
156 min
Build and Launch a personal blog using Remix and Vercel
Featured Workshop
In this workshop we will learn how to build a personal blog from scratch using Remix, TailwindCSS. The blog will be hosted on Vercel and all the content will be dynamically served from a separate GitHub repository. We will be using HTTP Caching for the blog posts.
What we want to achieve at the end of the workshop is to have a list of our blog posts displayed on the deployed version of the website, the ability to filter them and to read them individually.
Table of contents: - Setup a Remix Project with a predefined stack- Install additional dependencies- Read content from GiHub- Display Content from GitHub- Parse the content and load it within our app using mdx-bundler- Create separate blog post page to have them displayed standalone- Add filters on the initial list of blog posts
React Advanced Conference 2023React Advanced Conference 2023
104 min
Building High-Performance Online Stores with Shopify Hydrogen and Remix
WorkshopFree
I. Introduction- Overview of Shopify Hydrogen and Remix- Importance of headless e-commerce and its impact on the industry
II. Setting up Shopify Hydrogen- Installing and setting up Hydrogen with Remix- Setting up the project structure and components
III. Creating Collections and Products- Creating collections and products using Hydrogen’s React components- Implementing a Shopping Cart- Building a shopping cart using Hydrogen’s built-in components
VI. Building the home page with Storyblok- Cloning the space and explaining how it works- Implementing Storyblok in the repo- Creating the Blok components- Creating the Shopify components- Implementing personalisation
React Summit 2023React Summit 2023
154 min
Localizing Your Remix Website
WorkshopFree
Localized content helps you connect with your audience in their preferred language. It not only helps you grow your business but helps your audience understand your offerings better. In this workshop, you will get an introduction to localization and will learn how to implement localization to your Contentful-powered Remix website.
Table of contents:- Introduction to Localization- Introduction to Contentful- Localization in Contentful- Introduction to Remix- Setting up a new Remix project- Rendering content on the website- Implementing Localization in Remix Website- Recap- Next Steps