Mejora progresiva frente a aplicaciones de una sola página

Acabo de regresar de una conferencia en Boston llamada An Event Apart .

Un tema realmente popular entre los oradores fue la idea de la mejora progresiva : el contenido de un sitio debe ir en HTML y JavaScript solo debe usarse para mejorar el comportamiento.

Los argumentos que dieron los oradores para una mejora progresiva fueron muy convincentes. No solo es un patrón sólido para admitir navegadores más antiguos y dispositivos en una red con bajo ancho de banda, sino que HTML falla con mucha más gracia que JavaScript (es decir, el marcado que no es compatible simplemente se ignora, mientras que si un navegador arroja una excepción al ejecutar su guión: estás manguera).

Jeremy Keith dio una charla particularmente perspicaz sobre esto.

Pero, ¿qué pasa con las aplicaciones web de una sola página como Backbone y Angular? Todo el diseño detrás de estos marcos parece empujar al desarrollador a mover el contenido fuera del HTML, y hacia algo como una API JSON.

Parece que no puedo combinar estos dos patrones de diseño: mejora progresiva frente a aplicaciones web de una sola página. ¿Hay casos en que uno es mejor que el otro? ¿O ni siquiera son tecnologías antagónicas, y me falta algo aquí con mi modelo mental?

Me parece que las aplicaciones de una sola página trazan una línea en la arena de la mejora progresiva. Donde antes podríamos tratar de evitar el hecho de que las implementaciones y características varían entre los navegadores desde hace décadas, los SPA suponen que hay una cierta línea de base que razonablemente podemos acordar que la mayoría de los visitantes de un sitio determinado cumplirán. No creo que los dos estén en desacuerdo. Todavía puede continuar mejorando progresivamente después de que comience el SPA, como comenzar con una <video>etiqueta y luego superponer su propio reproductor rico en funciones.

Luego están los visitantes con secuencias de comandos deshabilitadas, pero saben en lo que se están metiendo. No veo por qué los desarrolladores deberían inclinarse hacia atrás para esos visitantes, aparte de la nota "Necesita secuencias de comandos para este sitio". Si permitimos eso, ¿por qué no también atender a los visitantes con CSS deshabilitado? ¿Qué hay de las imágenes deshabilitadas? Estas son las principales tecnologías web. No deben esperar tener una experiencia web completamente funcional cuando van a recoger y elegir piezas.

Para asegurarme de no escapar sin una analogía de automóvil, no debería esperar que mi automóvil funcione si decido que no me gustan ciertas características. Podría decirle a los ingenieros civiles: "Desactivé las luces delanteras, así que asegúrese de instalar luces de la calle cada 125 pies en todas partes que pueda visitar". Sin faros, mi automóvil funcionaría la mayor parte del tiempo, pero algunos lugares no podré visitarlos.

SPA es más beneficioso si está creando una aplicación que no se ajusta al modelo clásico de páginas de solicitud / respuesta. Hay una tendencia reciente en la que los sitios web regulares se escriben como un SPA incluso cuando encajan perfectamente en el ciclo de solicitud / respuesta de la web, en mi humilde opinión, lo que están haciendo son esfuerzos tontos. Lo que están haciendo los gustos de estos sitios web es reimplementar mal un navegador web con muchos más errores y menos funciones.

La idea de mejora progresiva y SPA no es mutuamente exclusiva para estos tontos sitios web de aplicaciones de una sola página. Simplemente necesita el javascript para realizar algunas negociaciones de contenido (es decir, aceptar encabezado) para que reciban el recurso JSON que el Javascript en el SPA puede representarse por sí mismo en lugar de una página HTML previamente representada. Los problemas con este tipo de SPA de sitios web son obvios, debe tener una implementación duplicada de la representación del sitio web tanto en el servidor como en el cliente.

Para aplicaciones web verdaderas, es decir, una que realmente tiene que ser un SPA ya que no se ajustan al patrón estándar de solicitud / respuesta; La mejora progresiva es mucho más difícil para las aplicaciones verdaderas porque en realidad solo están usando un navegador como plataforma tecnológica para escribir una aplicación de forma portátil. El lenguaje de secuencias de comandos es una parte esencial de una verdadera aplicación web, no solo una que se puede atornillar opcionalmente para mejoras. Sin embargo, algunas técnicas de mejoras progresivas aún pueden funcionar (por ejemplo, reemplazar video / audio flash con <video>/ <audio>etiqueta), pero las aplicaciones web verdaderas requerirán javascript como línea de base.

Creo que las aplicaciones web de una sola página y la mejora progresiva son casi antagonistas. Si el html se calcula en el cliente a partir de los datos recuperados de una API json, difícilmente puede degradarse con gracia. Sin embargo, puede ofrecer una interfaz de usuario más rica y agradable.

Puede configurar un bot que rastree su aplicación y guarde una versión estática. Esta técnica se puede utilizar para servir HTML a los navegadores sin JavaScript (utilizado por personas ciegas o robots de motores de búsqueda). Esta es una inversión, por lo que realmente se reduce a sus requisitos.

¿Está haciendo una aplicación web de gestión de recursos humanos para una empresa específica? No necesita una degradación elegante, y un SPA puede ser más simple de construir. La compañía puede exigir el uso de un navegador específico, por lo que es posible que tenga menos pruebas que hacer.

¿Está creando un sitio web público para una asociación con los requisitos de accesibilidad y las necesidades de visibilidad del motor de búsqueda? Luego considere construir el HTML en su servidor. O hacer un SPA con una versión estática, dependiendo de su presupuesto.

Creo que depende de cuán lejos quiera llegar con la Mejora progresiva: es un paradigma de diseño en lugar de un conjunto de reglas rígidas y rápidas.

Si está utilizando un marco SPA, creo que permitir Javascript es un hecho. Sin embargo, el Javascript que escriba para mejorar su página debe ser lo suficientemente inteligente como para manejar cualquier HTML que el marco pueda crear.

También puede beneficiarse de otras técnicas de PE, como aprovechar las últimas funciones de CSS para una versión reciente del navegador o la degradación de HTML5 a HTML4.

La mejora progresiva y una aplicación de página única pueden coexistir. Los dos argumentos más convincentes que he escuchado para crear aplicaciones de esta manera son:

• Tolerancia a fallos en situaciones en las que el archivo HTML se descarga en su totalidad, pero los scripts referenciados no se descargan por completo gracias a la conectividad de red que entra y sale (posible en redes móviles)
• Potencial para mejorar el rendimiento percibido en la carga de la página inicial (al reducir los tiempos de inicio de procesamiento)

La representación del lado del servidor (esto es para usuarios, no solo por razones de SEO) y cortar la mostaza son dos técnicas que pueden ayudar a construir aplicaciones de página única mejoradas progresivamente con marcos JS modernos del lado del cliente.

Algunos marcos JS del lado del cliente son más fáciles de trabajar con el renderizado del lado del servidor que otros ( tenga cuidado con algunas soluciones de renderizado del lado del servidor y las combinaciones de marcos no producen SPA funcionales ya que la página renderizada del servidor solo está destinada al consumo del motor de búsqueda, no al final -usuarios ).

Al momento de escribir, React.js y Ember (con el próximo FastBoot) son los dos que conozco que tienen o están tratando de hacer que la representación del lado del servidor sea un ciudadano de primera clase; la página renderizada del lado del servidor sigue siendo un SPA que funciona cuando se analiza en el navegador del cliente.

Soy de la opinión de que la carga de página reducida es probablemente bastante buena para los servidores y la red. Me encantaría ver más SPA utilizados correctamente.

Sin embargo, estoy fuera de la vista de que esto requiere dos cosas:

1) configurando todos sus enlaces como enlaces de solicitud / respuesta estándar en la carga inicial, deje que su marco / biblioteca SPA luego los reemplace con una versión actualizada (interactiva) una vez que se carga el navegador y el motor JS identifica que el soporte SPA está disponible. Esto realmente es una mejora progresiva; el JS se carga en la parte superior del sitio web html existente, y esto es mejor para motores de búsqueda, tecnologías de asistencia y navegadores más antiguos.

y

2) El servidor debe responder a rutas como / foo / bar / json y foo / bar sirviendo el formato correcto; de manera realista, si está envolviendo todo en diseños y parciales para obtener la primera página, también debería poder obtener todo a través de diseños y parciales para la segunda y posteriores páginas.

Hay bastante trabajo aquí; es cierto, pero si tienes control sobre la pila completa, equilibra las dos tecnologías.