Mejora Progresiva: Qué es y qué no es, una introducción práctica con Svelte

Para presentarme, soy un ingeniero de software en Versell que trabaja en nuestro departamento de crecimiento. En mi tiempo libre, ayudo a mantener Svelte y SvelteKit. Comencé mi vida profesional como analista de inteligencia de negocios y luego pasé a la arquitectura de datos analítica. Fue en este momento que me di cuenta de que eso no era realmente lo que quería hacer y comencé mi largo camino hacia la ingeniería de software, terminando como ingeniero front-end con una cantidad incómoda de experiencia en el backend.

El espacio front-end es muy diferente a cualquiera de los espacios en los que trabajé antes, especialmente en lo que respecta al soporte de características. En otros espacios, esto no es tan importante. Cuando controlas el hardware y el software, simplemente puedes implementar lo que quieras en su mayor parte. Si necesitas más ancho de banda, simplemente cómpralo. Si necesitas más potencia de procesamiento, simplemente actualiza tu instancia. Si necesitas una nueva versión, actualiza tu software. Sin embargo, en el espacio front-end, estás enviando código a lugares que no puedes controlar. A Dan con una conexión lenta. O a Carla con un teléfono de diez años que no puede permitirse reemplazar. O a Ebenezer, el dueño de toda la última tecnología que puede ejecutar cualquier cosa que le arrojes. A alguien en un país en desarrollo donde el mejor teléfono que pueden permitirse es equivalente a hardware de hace diez años. Estas personas experimentarán los sitios que escribo de diferentes maneras, y si no escribo mi aplicación teniendo en cuenta a todos ellos, degradaré su experiencia.

Pero escribir aplicaciones de esta manera es un desafío. Requiere comprender HTML, CSS, JavaScript y todas las demás tecnologías web que estaban más allá de mí incluso el año pasado. Una estrategia que he encontrado para lidiar con esto y que me ha cautivado últimamente es la mejora progresiva. A partir de MDN, la mejora progresiva es una filosofía de diseño que proporciona una base de contenido y funcionalidad esenciales para tantos usuarios como sea posible, al tiempo que ofrece la mejor experiencia posible solo a los usuarios de los navegadores más modernos que pueden ejecutar todo el código requerido. En resumen, podemos decir que la mejora progresiva tiene como objetivo proporcionar una experiencia funcional básica para tantos usuarios como sea posible, mejorando esta experiencia para aquellos cuya tecnología lo admite. En la práctica, esto se logra generalmente construyendo una experiencia base utilizando características de HTML, CSS y JavaScript ampliamente compatibles, y luego mejorándolas de varias formas. La primera es ejecutar código en el servidor. Nos alejamos brevemente de esto como industria con la llegada de aplicaciones de una sola página. Pero, más recientemente, este enfoque ha vuelto a ganar gran popularidad con nuevos meta-frameworks como SvelteKit o Next.js que adoptan un enfoque más orientado a SSR en el desarrollo web. La siguiente forma es detectar si las características son compatibles antes de usarlas. Normalmente, usaríamos alguna construcción como la consulta addSupports en CSS para ver si una característica de CSS es compatible.

Puedes lograr lo mismo a través de JavaScript utilizando CSS.supports. Hay bibliotecas para la detección de características que puedes usar. También puedes utilizar métodos específicos de detección de características.

Entonces, por ejemplo, si quisieras usar la API de geolocalización, podrías verificar si la clave geolocalización está definida en el objeto Navigator. Hay muchas formas de hacerlo, pero lo importante es pensar en que quieres usar esta característica. Sé que no es compatible con muchos navegadores. Tal vez sea muy nueva. Probablemente debería verificar si está presente antes de usarla.

Pero en algunas circunstancias, eso no es realmente realista. Podríamos estar usando una biblioteca que accede a características de esta manera de forma algo impredecible y realmente no tenemos forma de envolver todo eso en comprobaciones de seguridad para proporcionar fallbacks y mejoras. Entonces, otra forma de hacer esto es no detectar si se admiten características adicionales, sino estar preparado para que fallen y volver a opciones predeterminadas mejor admitidas cuando lo hagan. Esto se conoce técnicamente como degradación elegante, no mejora progresiva, pero son básicamente lo mismo en direcciones opuestas, y son tan complementarios que me gusta agruparlos juntos. Si eso te ofende, es una lástima.

Y la última forma que he visto comúnmente utilizada son los polyfills. Básicamente, se utilizan cuando tienes alguna nueva funcionalidad del navegador, como, no sé, object.create, que puede no ser compatible con navegadores antiguos, y quieres poder Entonces escribes código que emula ese comportamiento e lo inyectas si la característica no es compatible. Por lo general, estos tienen alguna desventaja, como un rendimiento reducido o casos particulares donde no funcionan correctamente. Pero si conoces los compromisos y estás preparado para aceptarlos, y tienes conocimiento sobre lo que aceptarlos implicará para ti, entonces pueden ser una buena solución.

También debemos tomar un momento para discutir qué no es el mejoramiento progresivo. Solo voy a citar a Rich Harris aquí, porque lo dijo mejor de lo que yo podría hacerlo. Algo que he visto cada vez más últimamente es que la gente habla de cero kilobytes de JS, como si este marco enviara cero kilobytes de JS de forma predeterminada. La implicación es que JavaScript es inherentemente malo, y por lo tanto, un marco que no sirve JavaScript es inherentemente bueno. Pero cero kilobytes de JavaScript no es un objetivo. El objetivo es satisfacer alguna necesidad del usuario, o, si eres cínico, satisfacer alguna necesidad empresarial al satisfacer una necesidad del usuario. A veces, el rendimiento es un factor en cuán efectivamente puedes satisfacer esa necesidad. Todos hemos visto los estudios que muestran que cada milisegundo de retraso le cuesta a Amazon miles de millones de dólares o algo así. Y a veces puedes mejorar el rendimiento inicial al reducir la cantidad de JavaScript en la página. Pero hacerlo siempre está al servicio de algún otro objetivo más grande. Colectivamente, corremos el peligro de confundir los medios con los fines. Como veremos más adelante, si quieres obtener el mejor rendimiento posible, el JavaScript es realmente esencial. El objetivo del mejoramiento progresivo no es enviar JS, aunque es fácil caer en esa trampa, ya que retrocedemos el increíble progreso que hicieron las aplicaciones de una sola página. En cambio, se trata de ser consciente de lo que enviamos y cómo eso cumple o no cumple las necesidades del usuario.

Ahora que hemos establecido de qué estamos hablando, abandonemos la teoría y pasemos a la práctica. El objetivo de la charla de hoy es presentarte la construcción de aplicaciones en SvelteKit y mostrarte lo fácil que SvelteKit hace el desarrollo de aplicaciones mejoradas de forma progresiva.

Todos conocemos el acrónimo LGTM. `Looks good to me` o `looks good to merch`, dependiendo del contexto. Durante meses, se me ocurrieron acrónimos falsos para esto, como `lumpy gorillas teach math`, `lunar grandeur tantalizes minimally`, `laggards growl to murder`, etc., y publiqué estos acrónimos como comentarios de aprobación en las solicitudes de extracción. Me cansé un poco de tener que ser creativo, así que creé una aplicación para crear estos acrónimos por mí. Simplemente usar combinaciones aleatorias de palabras que comienzan con LGT y M no es suficiente. Terminarías con demasiadas tonterías y no suficiente comedia, así que opté por un enfoque más exhaustivo, entrenando un clasificador de Bayes ingenuo con algunas miles de combinaciones de acrónimos buenos y malos y ejecutando 100,000 acrónimos aleatorios a través de él. No es perfecto, pero es bastante bueno.

Desde el principio, hubo algunos requisitos para esta aplicación para mí. Mostrar un acrónimo aleatorio cuando ingreso, siempre uno nuevo. Poder compartir ese acrónimo, por lo que si le doy a alguien un enlace para ir allí, deberían ver el mismo que yo vi. Necesitaba poder entrenar el modelo. No soy un gran fanático de las interfaces de línea de comandos sofisticadas. Preferiría tener algo que pueda abrir en mi teléfono y usar. También necesitaba que funcionara bien en conexiones a Internet lentas, donde es posible que no tenga JavaScript o que simplemente tarde mucho tiempo en cargar las páginas web. Los momentos en los que tengo tiempo para entrenar el modelo son cuando estoy en la fila de comestibles o en la gasolinera o algo así. Tiempo para entrenarlo unas cuantas veces y luego seguir adelante. Y mi conexión celular no es muy buena. Permíteme mostrarte lo que se me ocurrió y te mostraré cómo está implementado. Aquí tenemos dos páginas. La primera página, la página principal, es la página principal a la que envío a las personas. Esto te dará un acrónimo. `Layers greasing toadstool misrepresenting`. Y te dará solo algunas funcionalidades. Te dará la capacidad de rechazar ese acrónimo por uno nuevo. Te dará la capacidad de copiar ese acrónimo en tu portapapeles. Te dará la capacidad de rotar ese acrónimo. Algunos de estos se ven realmente bien en esta orientación. Sin embargo, pueden ser más difíciles de leer con palabras más largas, así que me gusta la oportunidad de verlos de ambas formas.

Tenemos la capacidad de compartir exactamente lo que estamos viendo porque tenemos dos parámetros de consulta que representan tanto la orientación como el ID de este acrónimo para que nunca cambie. Siempre podemos compartir esto. Vendrán aquí y lo verán.

Y luego tenemos un par de funciones exclusivas de JavaScript. Por lo tanto, solo podemos hacer la selección automática de toda esta caja con JavaScript habilitado, hasta donde yo sé. Y solo podemos hacer este comportamiento de copiado con JavaScript habilitado. Entonces, si desactivo esto, verás que cuando vuelva a cargar esta página, este botón estará desactivado y ya no puedo hacer clic en él para seleccionarlo, tengo que seleccionarlo realmente. Pero mi botón No y mi botón Sí, pero girado, siguen funcionando muy bien. Vamos a habilitar JavaScript antes de que se me olvide.

Luego tenemos una página que construí para poder entrenar este modelo. Si vienes aquí, verás una pantalla de inicio de sesión y te pido que no hagas un millón de solicitudes tratando de evitarlo, pero me permite básicamente estar en una cinta de correr de acrónimos infinitos y aprobar, desaprobar o modificarlos para poder mejorarlos y entrenar el modelo. Y luego me dará un acrónimo como `look out gleams tipsiest mold` y decidiré si me gusta o no. Sí, no o no del todo, donde puedo ajustarlo y enviarlo. También quería la capacidad de cargar un archivo con un montón de acrónimos porque se me ocurrían docenas de ellos y a menudo se me ocurren docenas de ellos y no quiero tener que escribirlos todos en esta pequeña caja. Así que tengo mi pequeño botón de archivo aquí y puedo seleccionar un archivo de texto lleno de acrónimos y cargarlos. Y toda esta página también funciona sin JavaScript. Y quiero mostrarte cómo lo hacemos en Svelte Kit porque es sorprendentemente fácil. Funciona muy bien. Y creo que te va a sorprender. Cuando entramos aquí en una aplicación de Svelte Kit, verás que es bastante simple.

Tenemos una carpeta lib y una carpeta routes. La carpeta lib es donde vive todo tu código de biblioteca, tus componentes, tu conexión a la base de datos. Todo lo que considerarías código compartido. La carpeta routes es como muchos otros meta frameworks, la forma en que definimos nuestras rutas en Svelte Kit, utilizamos un enrutador basado en el sistema de archivos que utiliza las rutas de las carpetas como tu ruta y los archivos dentro de esas rutas de carpetas determinan el comportamiento de esa ruta. Entonces, puedes ver aquí en la raíz que vimos que muestra el cuadrado con el acrónimo en él, tenemos un archivo de diseño, un archivo de servidor y un componente de Svelte. Básicamente, esto significa que todo lo que está bajo esta ruta se envolverá en este diseño, que es simplemente un contenedor principal alrededor del contenido con un poco de formato aplicado y algo de CSS importado. Y luego tendremos una carga del lado del servidor para esta ruta y una página para esta ruta. Y luego también tenemos nuestra ruta de entrenamiento, que acabas de ver, que también tiene un archivo de servidor y un archivo de página, y una ruta de éxito, que verás más adelante. Voy a omitir hablar de esto por ahora. Si tenemos tiempo, volveré a ello, pero no creo que lo tengamos.

Creo que lo más interesante para ustedes estará en esta ruta de tren. Para aquellos de ustedes que no han visto antes un componente de Svelte, son bastante simples. La mayoría de ellos tienen tres secciones. Una etiqueta de script, donde tenemos nuestro JavaScript, una sección donde colocamos todo nuestro marcado HTML, que está aquí mismo, y luego una etiqueta de estilo, que contiene CSS con alcance. Este CSS se aplicará a los párrafos de este archivo, pero no a ningún otro archivo.

Para las personas que han trabajado en JavaScript, el comportamiento de esta etiqueta de script probablemente será bastante autoexplicativo. Se ejecuta más o menos como se esperaría. Las definiciones de funciones se elevan al nivel superior. Las definiciones de funciones constantes no lo hacen. Se ejecuta de arriba a abajo, por lo que creará esta variable, le asignará false, creará esta variable, le asignará no, creará esta función, la asignará a una variable, y luego esta pequeña sintaxis especial aquí, no te asustes demasiado, es solo sintaxis de JavaScript. Es una etiqueta. El nombre de la etiqueta resulta ser el signo de dólar. Lo que le dice a Svelte Kit es que quiero que esto se vuelva a ejecutar y se asigne a name cada vez que cambie una de las dependencias del lado derecho. En este caso, solo tenemos una dependencia. Es form.name. Así que cada vez que form o form.name cambie, esto se volverá a ejecutar y asignará el resultado a name, lo que a su vez actualizará todo mi DOM para seguir eso.

Aquí tenemos dos exportaciones especiales. Tenemos data y form. Ambos se rellenan desde nuestro archivo page.server.ts y se tipifican automáticamente, por lo que puedes ver que nuestro data es page data y nuestro form es action data. Entonces, si escribo algo como data.blah, son cosas que estoy devolviendo desde mi función de carga en el servidor. Si escribo form.law, estas son todas las respuestas que mis controladores de formularios pueden enviar desde el backend. Es una característica bastante agradable. Realmente lo disfruto. Si miras nuestro contenido del DOM aquí, es bastante simple. Se parece mucho a un envío de formulario nativo. Tenemos un formulario con un método de post. Todos estos tienen una acción que apunta a la URL actual con un parámetro de consulta. Esto puede parecer un poco extraño. Lo que realmente significa es que quiero ir a train porque esa es la ruta en la que estoy ahora mismo y quiero agregar un parámetro de consulta llamado slash train. Ese parámetro de consulta nos llevará a una acción de formulario en este archivo.

Como puedes ver, también tenemos uno para autenticar y uno dentro de este cargador para cargar. Luego tenemos esta pequeña función use enhanced aquí que explicaré en un segundo. Sin esta función use enhanced, esto seguirá funcionando. Si entro en mi sitio aquí y hago clic en no con JavaScript desactivado, funcionará. Enviará mi formulario. Tomará un segundo. Se recargará y obtendré mi nuevo acrónimo, y se ha enviado eso. La razón es que esto es solo un envío de formulario nativo. Es un post al servidor y luego recarga la página.

Lo bueno es que tenemos esta función use enhanced. Use es solo una directiva que Svelte proporciona que te permite darle una función que se llamará con una referencia al elemento del DOM cuando se monte. Entonces, cuando este formulario se monte, llamará a enhance con el elemento del formulario. También lo llamará con el argumento de configuración que está aquí como su segundo argumento. Lo que hace use enhanced es emular el comportamiento nativo de envío de formularios en el lado del cliente. Entonces, SvelteKits envía un enrutador en el lado del cliente y si vuelvo a habilitar Javascript y recargo esta página, verás que hemos ido a train question train porque hemos recargado eso desde un envío de formulario nativo. Si hago clic en no ahora, es un poco más rápido y tampoco está recargando completamente mi página. La razón es que esto emula una recarga completa de la página al recargar todos mis data como si la página se hubiera recargado, pero no destruye todo el contenido del DOM y vuelve a crear todo. Solo vuelve a crear los que necesitan actualizarse según los nuevos data. Así que eso es realmente agradable.

Y este argumento de configuración también es realmente agradable porque me permite definir el comportamiento que ocurrirá durante el envío. Entonces, aquí, simplemente establezco un argumento de envío en verdadero y devuelvo una función asíncrona para ejecutar después de que se haya realizado el envío. Esta función asíncrona aplica la acción predeterminada llamando a update, que es emular esa recarga. Evita que se restablezca el formulario, desactiva nuestro estado de carga de envío y restablece el valor seleccionado a no, lo cual es realmente agradable. Entonces, cuando no tenemos JavaScript habilitado, hacemos clic en el botón de envío, no tenemos forma de saber que se ha hecho clic en el botón o que estamos haciendo algún trabajo. Entonces, si enfrentamos latencia de red, nunca lo sabremos. Pero aquí, cuando hago clic en enviar, se deshabilitará por un momento mientras piensa y luego se recargará. Es agradable. Podemos agregar ese comportamiento encima. También tenemos este comportamiento realmente interesante con este cargador de archivos aquí. Si hago clic en este icono, me dará la oportunidad de seleccionar un archivo y con JavaScript habilitado, simplemente me dará este pequeño mensaje aquí abajo que me dirá si tuve éxito o fallé en mi carga, lo cual es genial, porque no requiere que recarguemos toda la página.

Es una experiencia rápida, hace las cosas geniales. Pero cuando JavaScript está desactivado, no tengo la capacidad de ejecutar ese envío de formulario cuando agrego ese archivo. Entonces, si desactivo JavaScript nuevamente, si puedo ubicar mi mouse, ahí vamos, y recargo esta página, si voy a cargar mi archivo, cuando lo cargue, se convertirá en un pequeño botón de carga y cuando haga clic en eso, hará la carga, procesará el archivo y me dirá que he tenido éxito, y puedo volver a mi página anterior. Eso es genial.

¿Cómo funciona? Bastante simple. Realmente solo tenemos otro formulario. Es una sección muy corta de código DOM, y este formulario tiene un controlador de envío, muy similar al otro, pero tiene una entrada que acepta un archivo, y cuando ese archivo cambia, si JavaScript está habilitado, enviará el formulario, y si JavaScript no está habilitado, este controlador no se adjuntará, este controlador no se adjuntará, y lo que sucederá es que este botón se habilitará, porque nunca tuvimos la oportunidad de deshabilitarlo con esta variable de navegador, y cuando la entrada de archivo se vuelve válida y el botón se vuelve no deshabilitado, aparecerá el botón, lo que nos da la capacidad de enviar este formulario, que luego nos redirige a la otra página.

Esto funciona muy bien, con o sin JavaScript, y solo agregó unas pocas líneas de código. No tengo tiempo para hablarles más sobre esto, o lo haría, podría hablar de esto todo el día, pero realmente espero que esto les haya dado algunas preguntas filosóficas para pensar al respecto. Espero que puedan ver que la filosofía de la mejora progresiva, aunque definitivamente es un cambio mental de la filosofía de implementar todo en JavaScript, no es tan difícil como puede parecer en la superficie. Y la recompensa ciertamente vale la pena. Llegar a más clientes y tener un sitio que sea más resistente a fallas tecnológicas dará dividendos a largo plazo. Este código está disponible en github.com/tccsejohnson/lgtm. No dudes en contactarme con preguntas en Twitter en underscore Gruntled, o por correo electrónico a elliot.johnson en bursell.com. Muchas gracias por su atención, y realmente espero que tengan un gran día.