2011-05-24 16 views
20

Normalmente cuando configuro etiquetas HTML generadas dinámicamente, he estado usando PHP para almacenar la información y luego recorrerla para crear elementos en la página. Un ejemplo es la navegación; crear una matriz de objetos y luego recorrerlos para repetir el marcado. Esto me ayuda mucho por momentos en los que podría tener que realizar cambios menores (o importantes) durante el desarrollo o el mantenimiento.PHP vs JavaScript para páginas HTML dinámicas

Últimamente me he estado preguntando si debería usar JavaScript para hacer esto. Mismo principio, pero usando addElement.

Solo queríamos obtener algunas opiniones sobre esto; pros, contras, php vs js, consideraciones seo, etc.

Gracias amigos!

+1

Gracias a todos por su contribución. Esto ha ayudado a confirmar mis sospechas, especialmente en el SEO. Stack Overflow FTW! – Eric

+0

Bueno, parece que, a pesar del consenso aquí, JavaScript es el camino a seguir ahora (Angular, Reaccionar, etc.). Un importante pro para JavaScript que nadie mencionó, no es la recarga de página, lo que resulta en una mejor experiencia de usuario. –

Respuesta

4

No es una situación de uno u otro tipo; en general, necesitarás hacer ambas cosas.

Hacerlo del lado del cliente probablemente sea más lento, ya que el servidor aún necesita descifrar todos los datos pero el cliente necesita renderizarlos; esto implicará múltiples solicitudes (lo más probable) y la manipulación DOM es lenta (especialmente en navegadores más antiguos).

1

Si el SEO es su preocupación, las cosas son simples: JS no está indexado.

También hay problemas de interfaz de usuario: si JS no está habilitado, no se cargarán elementos dependientes de JS.

40

Hacerlo lado del cliente significa:

  1. Hacerlo en un montón de diferentes entornos en lugar de uno solo
  2. tener que romper cada vez que un usuario llega sin JS (por cualquier razón)
  3. Tener no funciona para la gran mayoría de los bots (incluidos los motores de búsqueda)
  4. Inversión tiempo de desarrollo en la conversión de toda su lógica
  5. Exigir que el navegador haga solicitudes adicionales a el servidor, lo que frena la carga veces

la hora de decidir si se debe hacer en el cliente algo en vez de lado del servidor, como una regla de oro hacerse dos preguntas:

  1. ¿El beneficio para el usuario de conseguir instantánea retroalimentación en respuesta a ellos haciendo algo? p.ej. Un mensaje de error para datos incorrectos en un formulario que intentan enviar. Si es así, entonces hacerlo del lado del cliente sería beneficioso.
  2. ¿Se puede hacer desde el lado del servidor? Si es así, hágalo primero desde el servidor ya que es más confiable (y para cosas no cosméticas, es más difícil interferir). Build on things that work.
+2

Mi regla de oro es "hacer tanto como sea posible desde el servidor". JS solo para mejora progresiva. Anywho, buena respuesta. +1 – mpen

+0

@Mark - ¿No es eso lo que dije? :) – Quentin

+0

+1, buena respuesta, más detallada y pensada que la mía. –

4

La mejor práctica sería producir cualquier marcado necesario en el lado del servidor. Las razones para esto incluyen:

SEO: La mayoría de los robots de rastreo no analizan Javascript, por lo que se saltearán cualquier cosa crucial que esté generando con addElement.

Accesibilidad: Su sitio debe ser básicamente funcional sin Javascript.Considere las personas que podrían estar navegando en su sitio en Kindles, Blackberries anteriores, Nokias u otros teléfonos con datos. No necesitan todos los estilos y efectos sofisticados, pero al menos deberían poder moverse por su sitio.

Consistencia: JS puede agregar otro nivel de variabilidad entre navegadores. ¿Por qué confiar en la representación del margen necesario del cliente? Hazlo en el lado del servidor.

Por supuesto, este consejo puede tomarse con calma si está desarrollando una aplicación de escritorio JS o usando algo como el marco Sencha Touch.

0

Una posibilidad sería detectar qué tipo de usuario está viendo su sitio:

  • Si se trata de un robot: analizar en el lado del servidor, es posible que sólo la producción lo que se necesita por el bot, sin cosas gráficas, ...

  • Si se trata de un móvil: muestran una versión optimizada para móviles, usando algo como Sencha Touch, como Charlie señaló

  • Si se trata de un navegador estándar, sin javascript: hacen que la página en el servidor lado

  • Si se trata de un navegador estándar, con javascript permite: acaba de enviar los datos a partir del lado del servidor (o cargarlo con Ajax) y representar los datos del lado del cliente

Usted puede usar algo como Mustache, que es un motor de plantillas que se ejecuta en muchos lenguajes del lado del servidor (PHP, Ruby, Java, ... pero también en Javascript, lo que permite la representación de páginas del lado del cliente).

y tratar de utilizar un marco Javascript como jQuery, Mootools, Dojo o ExtJS, que le ayudará a escribir código que se ejecutará en todos los navegadores.

+0

El uso de esos "marcos" solo hará que su código se ejecute en un pequeño número de navegadores de reccesos. Ciertamente no "todos los navegadores". Es mucho mejor usar la lógica del lado del servidor y almacenar en caché las páginas estáticas (o la mayoría estáticas) tanto como sea posible. – RobG

+0

La mayoría de ellos también son compatibles con navegadores antiguos, y por lo que probé con jQuery funcionó bastante bien. Y con suerte, pronto podremos tirar IE6 ... (Sé que no es el único navegador antiguo ... pero uno de los más feos ...) – ygosteli

0

PHP es bueno para algunas cosas, incluyendo plantillas de tipo Handlebars y reemplazo rápido de contenido del lado del servidor. Pero tampoco es bueno para algunas cosas, como aplicaciones y juegos de una sola página, actualizaciones en tiempo real para sitios web. Esas cosas son donde JavaScript es fuerte.

+1

¿Podrían explicar estas diferencias? –

Cuestiones relacionadas