Construcción de un frontend robusto mediante mejora progresiva

 (gov.uk)
1 puntos por GN⁺ 2024-09-30 | 1 comentarios | Compartir por WhatsApp

Cómo construir un frontend robusto: mejora progresiva

  • Comenzar con HTML

    • Los servicios gubernamentales deben ser funcionales incluso solo con HTML
    • La capa de HTML es tolerante a fallos, por lo que puede funcionar incluso en navegadores antiguos
    • Se debe usar marcado semántico correcto y estructurar el documento de forma lógica

  • Uso de CSS

    • Se puede usar CSS para dar estilo al servicio
    • La capa de CSS es tolerante a fallos, ya que puede ignorar declaraciones individuales
    • Se deben evitar tecnologías como CSS-in-JS

  • Uso de JavaScript

    • JavaScript se usa para agregar elementos interactivos
    • La capa de JavaScript no es tolerante a fallos y puede presentar errores
    • Se puede mejorar la compatibilidad mediante detección de funcionalidades de la API del navegador, inclusión de polyfills, transpilation, etc.
    • JavaScript debe cumplir un papel complementario para HTML y CSS

  • Alternativas a JavaScript

    • Se deben considerar soluciones simples que puedan satisfacer las necesidades del usuario incluso sin JavaScript
    • Entre las alternativas están mostrar tablas de datos, exportar datos y prerenderizar gráficos como imágenes

  • Uso de frameworks de JavaScript del lado del cliente

    • Se debe evitar usar frameworks si no se trata de una interfaz de usuario compleja
    • El uso de frameworks puede causar problemas como aumento del tamaño de la base de código, problemas de rendimiento y dependencia de código de terceros
    • Si se usan frameworks, cada interfaz de usuario debe diseñarse como un componente independiente

  • Razones por las que CSS o JavaScript pueden no cargarse o no ejecutarse

    • Las causas pueden incluir errores de red, extensiones del navegador, caídas de proveedores externos, fallas en la resolución DNS o errores provocados por actualizaciones del navegador
    • Algunos usuarios pueden desactivar intencionalmente funciones del navegador

  • Aplicaciones de una sola página (SPA)

    • No se debe construir el servicio como una aplicación de una sola página
    • Las SPA perjudican la accesibilidad y pueden generar problemas como el manejo del foco al moverse entre páginas o la imposibilidad de usar los botones de atrás/adelante

  • Pruebas del servicio

    • Los componentes que dependen en gran medida de JavaScript o de frameworks de JavaScript deben funcionar en distintos navegadores y dispositivos
    • Se debe probar la accesibilidad

  • Casos de estudio y guías relacionadas

    • Por qué usar mejora progresiva
    • Diseño para distintos dispositivos
    • Cómo probar el rendimiento del frontend
    • Entender WCAG 2.2

Resumen de GN⁺

  • La mejora progresiva es una forma de construir sitios web en el orden HTML, CSS y JavaScript
  • Este método mejora la tolerancia a fallos del servicio y permite que funcione en distintos navegadores y dispositivos
  • JavaScript debe cumplir un papel complementario y se deben considerar soluciones alternativas
  • Las aplicaciones de una sola página deben evitarse debido a problemas de accesibilidad
  • Las pruebas del servicio deben garantizar la accesibilidad en distintos entornos

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-09-30
Comentarios de Hacker News

  • Al usar frameworks de JavaScript, se debe poder demostrar qué beneficio aportan al usuario

    • Si es una app que puede funcionar sin conexión como una aplicación de escritorio, conviene hacerla como una aplicación de página única (SPA)
    • Algunos ejemplos son Photopea, Google Docs/Sheets y tldraw
    • Si es una app que necesita conexión a internet y varias páginas, es mejor dejar que el navegador maneje la navegación

  • Puntos señalados como desventajas de las SPA

    • Los usuarios de tecnologías de asistencia no perciben los cambios de contexto al navegar entre páginas
    • No se puede manejar correctamente el foco al cambiar de página
    • No se pueden usar los botones de atrás y adelante del navegador
    • Si se corta la conexión de red, no se puede recuperar del error
    • Pero estos problemas también pueden resolverse en una SPA

  • Ojalá todo internet siguiera este consejo

  • Hay que priorizar las soluciones simples

  • Me pregunto por qué Linux no está en la lista

  • Parece que a mucha gente le gusta este enfoque

    • Me pregunto por qué la tendencia general es usar innecesariamente JavaScript y frameworks como React

  • Se usa HTML y datos obtenidos previamente desde el servidor, y lo que se puede hacer en el cliente se hace en el cliente

    • Se usa CSS mínimo y JavaScript vanilla
    • Puede parecer anticuado para los compañeros, pero no se pierde nada

  • Muchas SPA tienen problemas, pero no todas los tienen

    • Si ves ejemplos como VitePress y SolidJS, funcionan bien
    • Casi no hay personas que no usen JS
    • No hay problemas para procesar JS incluso en dispositivos de bajos recursos
    • Los problemas de accesibilidad no están relacionados con usar o no una SPA
    • Svelte incluso incluye una función de advertencias de accesibilidad

  • El renderizado del lado del servidor tampoco es bueno en todos los casos

    • Hay que tener cuidado al usar frameworks de JavaScript del lado del cliente
    • La base de código crece, aumenta el trabajo que debe hacerse del lado del cliente y pueden surgir problemas de rendimiento
    • Se puede terminar dependiendo de código de terceros y eso puede dificultar el mantenimiento
    • Al usar frameworks de JavaScript, se debe poder demostrar qué beneficio aportan al usuario
    • Hay que reconocer los efectos negativos y poder mitigarlos
    • Los frameworks deben usarse solo en las partes que no pueden construirse solo con HTML y CSS
    • Cada parte de la interfaz de usuario debe diseñarse como un componente separado
    • Aunque JavaScript no cargue, el resto de la página debe seguir cargando con normalidad