Mejora progresiva frente a aplicaciones de una sola página

33

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?

— SeanPlusPlus
fuente

Tienen dos casos de uso diferentes. Sí, hay superposición cuando el servidor está haciendo el trabajo pesado.

— BobDalgleish

55

Creo que es justo decir que, por diseño, los requisitos del navegador para aplicaciones de una sola página son más estrictos que los de las aplicaciones web "comunes".

— Robert Harvey

3

debe pedirle a Jeremy Keith que le brinde un ejemplo del mundo real en el que la mejora progresiva realmente valga la molestia de complacer al 1-10% del total de personas de Internet y pregunte los datos del otro 90% del usuario, si realmente se preocupan por la mejora progresiva o si están contentos si pueden visitar el sitio web con IE 5.0 o sin javascript

— kirie

1

Si el tipo de personas que deshabilitan JS / images / etc no está en su grupo demográfico objetivo principal, entonces no hay una razón comercial válida para buscar la Mejora progresiva.

— Graham

1

El soporte para 'dispositivos en una red con bajo ancho de banda' es en realidad un argumento para SPA, ¡no en contra! En SPA solo hace una solicitud grande, ¡sin JS la tiene siempre!

— Dmitri Zaitsev

21

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.

— Collin Allen
fuente

3

I don't see why developers should bend over backwards for those visitors. Si su contrato especifica que necesita proporcionar una versión accesible de su sitio web, puede ser más difícil usar un SPA. ¿Y qué hay del SEO?

— Simon Bergot

77

@Simon: También puede hacer que un SPA sea accesible (consulte, por ejemplo, stackoverflow.com/questions/15318661/… ). Del mismo modo para el SEO (si el SEO importa, que dependerá de la aplicación).

— sleske

2

Algunas de sus analogías son un poco de paja. Deshabilitar Javascript tiene un propósito de seguridad; sería difícil argumentar que agregar faros delanteros a un cuidado lo hace menos seguro.

— Robert Harvey

1

Es cierto que deshabilitar las secuencias de comandos tiene beneficios de seguridad. Pero para la mayoría de los visitantes, la seguridad adicional que ofrece hacer esa elección no vale la pena. Sin secuencias de comandos, Facebook se niega a trabajar, LinkedIn se rompe, Pinterest se rompe, Instagram carga una página en blanco, etc. Si los principales jugadores lo requieren, su SPA también puede hacerlo.

— Collin Allen

Solo conociendo FB y LinkedIn, no hay una buena razón para que esos sitios se rompan sin JS, excepto para aplacar a los desarrolladores que no quieren esforzarse por hacer un sitio web que funcione de manera aceptable (o para obligar a los usuarios a aceptar prácticas de navegación menos seguras que puede beneficiar sus resultados finales). Si se tratara de aplicaciones web completas como Plunker, es posible que tenga un punto, pero la mayoría de las "aplicaciones web" son solo "aplicaciones" en el sentido de que se basan en algún tipo de marco. En términos de uso, son solo sitios web con más detalles que solían tener.

— Disident Rage

6

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.

— Lie Ryan
fuente

+1, pero no siempre es fácil decidir si algo "verdaderamente" requiere un SPA. Por ejemplo, aplicaciones de negocios que son principalmente entrada de datos, con una amplia gama de complejidad en los formularios. Si la mayoría de los formularios son simples, un SPA no es "verdaderamente" requerido, por lo que todavía hay tensión entre las soluciones SPA y las que no son SPA.

— sinelaw

@sinelaw: la mayoría de las aplicaciones comerciales generalmente no deberían ser un SPA. Hay algunas excepciones, por ejemplo, Hoja de cálculo, Procesamiento de textos, pero esas son las extrañas. Indicadores que necesita SPA: si necesita enviar datos del servidor al cliente, no solo para una o dos notificaciones, sino como un elemento crucial de la aplicación, por ejemplo, juego, seguimiento de stock, aplicación de chat; si su aplicación no tiene un concepto sensato de "Página" o el concepto de "Página" ha sido totalmente retorcido en la aplicación, por ejemplo, aplicaciones de Office. Las aplicaciones comerciales que funcionan principalmente en formularios mejor permanecen como no SPA.

— Lie Ryan

De acuerdo. Otro indicador para un SPA: si desarrollar un SPA es más barato que desarrollar un sitio web "clásico". Las aplicaciones empresariales que apuntan a un público específico a veces pueden imponer requisitos como "usar un navegador moderno", de modo que la mejora progresiva conlleva pocos beneficios.

— sinelaw

@sinelaw: Crear un SPA casi nunca es más barato que desarrollar sitios de varias páginas; especialmente si no está atendiendo navegadores antiguos de todos modos.

— Lie Ryan

Si su equipo está formado por expertos en SPA con poca experiencia en proyectos centrados en el servidor, será más barato.

— Sinelaw

2

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.

— Simon Bergot
fuente

1

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.

— philicomus
fuente

1

Parte de la mejora progresiva es que el contenido básico debería estar disponible sin javascript. No estoy seguro de cómo escribir un SPA sin javascript.

— Alan Shutko

@AlanShutko Quizás con iframes. Varias páginas, pero técnicamente la URL no está cambiando ...;)

— Izkata

1

Sí, supongo que estaba pensando más en términos de HTML 5 frente a HTML 4, y cosas como CSS específico del navegador (por ejemplo, es posible que desee utilizar una función implementada recientemente que solo está disponible en la última versión de Chrome, pero que se degrada a más control primitivo en navegadores antiguos). Prescindir de javascript sería complicado en un SPA, pero eso es solo una parte del concepto de mejora progresiva.

— philicomus

La mejora progresiva podría ser tan simple como usar css3 cuando está disponible para redondear esquinas. La idea básica no tiene nada que ver con JavaScript.

— Daniel Little

1

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.

— Eliot Sykes
fuente

0

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.

— Crispen Smith
fuente