¿Existe algún razonamiento sólido de por qué los sitios no deberían desarrollarse con la funcionalidad ajax que carga las partes principales de cada parte (suponiendo que haya elementos como el encabezado, la navegación, etc., que permanezcan igual)?

Seguramente sería menos intensivo en recursos ya que el servidor no tendría que servir el contenido que aparece en cada página, beneficiando tanto al host como al usuario final.

Responda la pregunta teniendo en cuenta:

• El comportamiento del sitio javascript se degrada con gracia en cada instancia

• Para mi pregunta, estoy hablando de nuevos sitios donde este comportamiento podría implementarse desde el principio, por lo que técnicamente no cuesta dinero, no estamos regresando a un producto terminado para implementarlo.

Si se puede acceder al contenido sin JavaScript habilitado, entonces su pregunta no tiene ningún sentido. No es "completamente Ajaxified" si puede acceder al contenido por otros medios. Realmente, lo que estás preguntando es "¿está bien mejorar la experiencia de mi usuario a través de Ajax?". La respuesta es obviamente sí".

editar

Cuando Google presentó su propuesta rastreable de Ajax, fue considerada una muy mala idea . Hace una lectura interesante.

Lo primero es lo primero

Los profesionales

• AJAX puede permitirle usar una página "base" común y simplemente cargar las áreas de contenido, lo que puede reducir el tiempo de carga para los usuarios, ya que una gran parte de la página ya está cargada.
• Puede permitir algunos dulces visuales, como desvanecer el área de contenido dentro y fuera.

Los contras

• No juega bien si la página se descarga.
• Puede meterse con dispositivos de discapacidad.
• Los espectadores con JavaScript desactivado no podrán utilizar el contenido en absoluto a menos que también se emplee una versión que no sea JavaScript.
• Mucho más trabajo (¿realmente hay que decirlo?).

Ahora para tu pregunta

Suponiendo que su sitio se degrada con gracia para aquellos que no tienen Javascript, lo bien que resulte dependerá de cómo se haga. Por ejemplo, si solo muestra un enlace a una versión que no es JavaScript de la nada, es un inconveniente para esos espectadores tener que hacer clic en otro enlace. Por otro lado, si hay una "página principal" de noscript que usaría enlaces tradicionales, que funciona mejor para la mayoría de los usuarios, pero aún carece de soporte para aquellos que usan dispositivos de discapacidad, instancias en las que el usuario llega a una "página" específica de un enlace, etc.

En general, en el mundo de la conexión web cada vez más rápida, en realidad no justifica cortar una pequeña cantidad de tamaño de archivo (supondremos que todo el Javascript en sí, el CSS y las imágenes pueden y se almacenarán en caché, dejando solo la página "base" en sí misma para guardar bytes) por las desventajas que puede dar, es decir, la dificultad adicional (aunque eso no siempre es un desafío es bueno) y la falta de soporte que puede brindar a algunos usuarios.

En general, diría que depende de usted, probablemente funcionará bastante bien, y para la gran mayoría de los usuarios, probablemente verán el sitio como estaba previsto, pero personalmente, diría que no molesta, ya que no vale la pena una mejora tan marginal para el tamaño del archivo.

Visite http://gawker.com/ - este sitio se carga casi por completo después del hecho. Usan "hashbangs" ( http://mydomain.com/#!some_section) para determinar qué página de contenido debe cargarse, la navegación principal permanece estática.

Visite http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ para obtener un breve tutorial sobre el concepto que Gawker usó.

Hay ventajas y desventajas, debe tener en cuenta los motores de búsqueda (consulte http://code.google.com/web/ajaxcrawling/docs/getting-started.html ), las personas con JavaScript deshabilitado y realice muchas pruebas.

Dicho todo esto, el mayor argumento en contra de ellos es probablemente que cuando un usuario espera a que se cargue una página y luego tiene que esperar a que se cargue más, puede ser impaciente. En mi opinión, la mejor práctica es cargar el sitio principal, la navegación y el contenido primario en una sola pasada (a pedido) y guardar el AJAX para los incidentes no esenciales. Eso funciona con la idea de mejora progresiva y combina lo mejor de ambos enfoques.

Porque probablemente no sea necesario.
Cargar documentos HTML básicos es simple y funciona. La presentación de Ajax agrega una capa completamente diferente de proceso para navegadores, código y mantenimiento para Javascript, cosas de back-end, URL hashbang extrañas, etc. A veces esto puede estar justificado, a veces no. Podría ahorrarle algunos recursos del servidor (podría), pero ¿será eso suficiente para compensar el mantenimiento? Tienes que evaluar eso por proyecto.

Como ejemplo, cuando Twitter obtuvo su último rediseño, adoptaron el enfoque de que no se trataba solo de un sitio web (página), sino de una aplicación, y todo está basado en Ajax, aunque la mayor parte de lo que hace podría manejarse con solicitudes de página regulares. Uno de los mayores problemas, que todavía ocurre ahora, aunque mucho menos, es llegar allí y ser recibido con una página en blanco porque algo en el Ajax falló.

En la práctica, es mucho trabajo producir un sitio web 'completamente AJAX', especialmente para sitios web importantes que son muy complicados. Algunos sitios web que intentan esto son Google y Facebook, pero incluso ellos no lo hacen a la perfección.

Los problemas comunes son la navegación (es decir, hacia adelante y hacia atrás) y los marcadores, pero hay muchos otros errores con los que muchos desarrolladores preferirían no tener que lidiar. Básicamente, significa crear dos versiones del sitio web para que sean compatibles con usuarios de JavaScript y que no sean javascript (y arreglos para todos los navegadores con soporte AJAX incorrecto).

Sí, debería ser, sin embargo, debería ser al revés.

Las partes comunes de la página deben enviarse a través de HTTP. Luego, un pequeño control ajax (o incluso mejores sockets web) carga el contenido dinámico de forma asincrónica.

Por supuesto, primero debe detectar si javascript está habilitado (por cookie) y solo usar este método si está habilitado.

Entonces necesita la ruta HTTP completa normal y luego una ruta websockets. Esto requiere duplicación de código a menos que use una herramienta como node.js

La mayoría de la gente "piensa" que simplemente no vale la pena el esfuerzo extra. Y a veces no lo es.

Por otro lado, mucha gente ajaxifica páginas mal. De hecho, deciden que no necesita una versión que no sea JavaScript y que necesita todas estas URL de hash bang extrañas y botones de avance / retroceso rotos. Hacer ajax correctamente requiere un historial HTML5 (IE9 no lo tiene). También requiere que el desarrollador complete las versiones de su sitio web.

Dado que usted dijo que se degradaría con gracia para los visitantes con Javascript deshabilitado, solo puedo ver dos problemas reales (y un posible problema) que podrían surgir.

Mal para la accesibilidad

Los lectores de pantalla y otras tecnologías de asistencia a menudo se ven afectados por los cambios dinámicos del DOM. Procesan y leen la página de forma lineal, y cambiar el contenido de la página después de que se cargue podría no manejarse correctamente.

Puede haber técnicas para solucionar esto, pero no lo he investigado demasiado a fondo.

Complejidad incrementada

Mantener este tipo de sitio podría ser complicado. Por ejemplo: si creó un nuevo diseño y cambió la ID del área de contenido que estaba reemplazando con sus enlaces AJAX, podría romper su esquema de navegación de una manera bastante desconcertante.

Este tipo de comportamiento AJAX también complicaría cualquier análisis de tráfico que pueda estar haciendo; Google Analytics no registraría correctamente estas cargas AJAX sin una llamada manual a pageTracker._trackPageview('this_page');.

Agregar más complejidad al funcionamiento de su página también eleva el listón para los nuevos desarrolladores; cualquier persona que trabaje en el sitio probablemente tenga que ser consciente de cómo este comportamiento afecta las cargas de la página.

Posible: carga de página más lenta en la visita inicial

Dependiendo de cómo se estructuran las cosas, esta página que busca el código AJAX solo podría iniciarse después de que el documento se haya cargado por completo. Entonces, solo después de que su visitante descargó toda la página, y luego el Javascript (si era un archivo externo), y su navegador lo procesó y obtuvo el contenido a través de AJAX, vería el contenido de la página.

Cada enlace posterior en el que se haga clic sería más rápido, pero buscar la primera página que visitó un usuario en realidad tomaría más tiempo que una versión estática.

La razón por la que califiqué esto como un posible problema es que siempre puedes enviar la primera página de forma estática (ya que ya tendrás la versión estática como alternativa) y luego usar AJAX para los enlaces posteriores.

Para lo que vale, esto no me parece una idea terrible, especialmente para usos sensibles al ancho de banda como las páginas móviles. Sin embargo, deberías sopesar cuidadosamente los inconvenientes para asegurarte de que valió la pena en tu caso.

Tener elementos ajax en una página está bien cuando tienes una pequeña base de usuarios, pero cuando tienes más tráfico; desea utilizar un enfoque más estático para disminuir el abuso de recursos.

Por ejemplo: supongamos que hay 200 personas que intentan acceder a una página por segundo. Tiene aproximadamente 7 consultas de base de datos para sus llamadas ajax; es decir, 1400 llamadas de base de datos por segundo, que pueden atascar un sitio web

Un sitio web que debe diseñarse para un mayor tráfico debe tener páginas estáticas orientadas hacia afuera, para contenido que se pueda mostrar de forma estática. Esto se logra mediante el uso de un script del lado del servidor que se ejecuta cada segundo para reconstruir la página estática, que se obtiene para el usuario final, y por lo tanto, ha reducido su carga de 1400 llamadas de base de datos por segundo a 7.

Es un enfoque SOA para la construcción de sitios web.