javascript - side - programacion del lado del servidor

Plantillas del lado del cliente frente al servidor(¿cuál?) (2)

Básicamente, estás buscando una aplicación web isomorfa que comparta el mismo código para frontend y backend.

JavaScript isomorfo
Aplicaciones de JavaScript que se ejecutan tanto del lado del cliente como del lado del servidor. Los marcos de JavaScript isomórficos son el siguiente paso en la evolución de los marcos de JavaScript. Estas nuevas bibliotecas y marcos están resolviendo los problemas asociados con los marcos de JavaScript tradicionales.

Apuesto que este tipo me explica mucho mejor que yo.

Entonces, cuando un usuario llega a la página, el servidor procesa la página completa con el contenido. Por lo tanto, se carga más rápido y no requiere solicitudes adicionales de ajax para cargar datos, etc. Luego, cuando un usuario navega a otra página, se utilizan las técnicas habituales para las aplicaciones de una sola página.

Entonces, ¿por qué me importaría?

Navegadores antiguos / Dispositivos débiles / Javascript deshabilitado
SEO
Algunas mejoras de carga de página

Navegadores antiguos / Dispositivos débiles / Javascript deshabilitado

Por ejemplo, IE9 no es compatible con la API de historial. Por lo tanto, para los navegadores antiguos (y si el usuario también desactiva el javascript), simplemente navegarán por las páginas tal como lo hicieron en los viejos tiempos.

SEO

Google dice que es compatible con los SPA, pero no es probable que aparezcan en los mejores resultados de búsqueda de Google, ¿verdad?

Velocidad de la página

Como se indicó, la primera página se carga con una solicitud HTTP, y eso es todo.

OK entonces

Hay muchos artículos sobre eso:

Pero ¿me debería importar?

Depende de usted, por supuesto.

Sí, está bien, pero se necesita mucho trabajo para volver a escribir / adaptar la aplicación existente. Y si tu backend está en PHP / Ruby / Python / Java / Whatever, tengo malas noticias para ti (no es necesariamente imposible, pero está cerca de eso).

Depende del sitio web, puede intentar recopilar algunas estadísticas y si el porcentaje de usuarios con dispositivos antiguos es pequeño, no vale la pena, por qué no ...

DEJEMOS SUFRIR

Si solo se preocupa por los usuarios con dispositivos antiguos, entonces venga a 2015, y es un problema de su usuario si usa IE8 de sitios web de navegación con un iPod Touch 2. Por ejemplo, Angular abandonó el soporte de IE8 en 1.3 aproximadamente hace un año. entonces, ¿por qué no alertar a los usuarios que necesitan actualizar;)

¡Aclamaciones!

Últimamente he estado leyendo algunos artículos muy interesantes sobre la representación completa del cliente frente al servidor.

http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html

http://www.quirksmode.org/blog/archives/2015/01/angular_and_tem.html

http://tomdale.net/2015/02/youre-missing-the-point-of-server-side-rendered-javascript-apps/

Ahora he sido un poco fanático del lado del cliente, pero después de leer estos artículos, algunos puntos comenzaron a aparecer a favor de la representación del lado del servidor, para mi sorpresa ... Los puntos principales fueron:

1) Puede actualizar su servidor, pero no el dispositivo de sus usuarios . Esto significa que, bueno, sí ... usted tiene el control del servidor, por lo que si tiene un rendimiento bajo puede optar por actualizar / escalar. No puedes obligar a los usuarios a actualizar sus dispositivos.
2) Primera pintura frente a última pintura : ahora en el enlace experimentally verified... se muestra cuando los usuarios ven la página por primera vez (primera pintura) y cuando los usuarios pueden usar la página 100% (última pintura). Ahora, por lo que puedo pensar cuando el usuario ve la página, les lleva un tiempo al cerebro procesar las señales de la corteza visual a la corteza frontal y luego a la corteza premotora, donde el usuario realmente comienza a hacer clic en su dedo, eso Por supuesto, si el HTML se procesa primero para que el cerebro tenga algo que procesar mientras se realiza la carga en segundo plano (archivos js, enlace, etc.).

Lo que realmente me sorprendió fue lo poco que Twitter reportó que las personas tenían hasta 10 segundos de tiempo de carga para la representación del lado del cliente, ¡ nadie debería experimentar eso ! Es como decir: " Bueno, si no tienes un dispositivo lo suficientemente bueno, lo siento, tendrás que esperar ".

He estado pensando, ¿no hay una buena manera de usar los motores de plantillas tanto del lado del cliente como del servidor y que tanto el cliente como el servidor utilicen el mismo motor y código de plantilla ? En ese caso, solo es para averiguar si es beneficioso proporcionarle al cliente la página renderizada o dejar que el cliente la represente por sí mismo.

En cualquier caso, comparte tus pensamientos sobre mis dichos y los artículos si quieres. ¡Soy todo oídos!

Todas las conversaciones sobre este tema pierden un punto. Bytes enviados al cliente. Las páginas representadas como HTML en el servidor son mucho más pequeñas. Menos bytes transmitidos es mejor para todos, tanto el servidor como el cliente. He visto los costos de ancho de banda en los sitios de nube e incluso una reducción del 10% puede ser un gran ahorro. Las páginas JS del lado del cliente siempre son gordas.