¿Por qué muchos desarrolladores web usan lenguajes de secuencias de comandos del lado del servidor como PHP cuando todo lo que intentan hacer se puede hacer con JavaScript?

Respondamos con una pregunta: ¿quiere decir, Javascript del lado del servidor (que todavía es experimental y bastante inusual) o Javascript del lado del cliente (que expone la lógica al cliente y abre grandes agujeros de seguridad)?

A medida que discutimos la pregunta se hizo clara, así que aquí sigue una respuesta más completa:

El JS del lado del cliente es excelente, pero es muy difícil confiar en él para la funcionalidad central de su servicio. Es casi imposible garantizar la integridad de su código. Las personas pueden disparar llamadas arbitrarias (desde un depurador JS, por ejemplo); También pueden leer y modificar su código a voluntad. Incluso si lo ofuscas, aún se puede hacer.

Otra razón es que es muy difícil implementar la persistencia usando solo JS en el lado del cliente. Tarde o temprano, debe enviar datos al servidor, e incluso si realiza un preprocesamiento en el cliente, todavía tiene que validar los datos antes de escribir, porque su interfaz está abierta y se puede abusar de ella. El lado del cliente tampoco tiene una manera fácil de lidiar con los problemas de concurrencia (de hecho, ni siquiera sabe sobre el acceso concurrente). Por todas estas razones, JS se usa mejor para tratar
presentación, con la lógica central implementada del lado del servidor.

Donde el mejor lugar es realizar una operación dada (javascript del cliente vs. PHP del lado del servidor) depende mucho del tipo de operación, por lo que no hay una respuesta genérica a esa pregunta.

Algunas razones para realizar cosas del lado del cliente:

  1. Mejor rendimiento (respuesta más rápida a los eventos del usuario, menos viajes de ida y vuelta al servidor, más lógica manejada por el lado del cliente, etc.)
  2. Baja carga en sus servidores
  3. Retroalimentación visual más rápida
  4. Rendimiento dinámico de la página sin recargas de página.
  5. Aplicación interactiva

Algunas razones para realizar cosas del lado del servidor:

  1. Mejor rendimiento (computadoras más grandes, conexión a Internet más rápida, conexión más rápida a las fuentes de datos, etc.)
  2. Acceso más rápido a los datos del lado del servidor.
  3. Mejor gestión del ancho de banda para el cliente.
  4. Más fácil de asegurar y controlar el acceso a los datos del lado del servidor que del lado del cliente
  5. Menos problemas entre navegadores
  6. Páginas más pequeñas para que el navegador descargue
  7. La misma lógica de servidor se puede exponer a través de XML o una API de tipo JSON

Como puede ver, hay compensaciones en ambas direcciones, por lo que el lugar ideal es colocar la lógica depende completamente de la función específica y otros objetivos.

Todo se podría hacer con Javascript si usa el lado del servidor Node.js. Puede usar el mismo código en el servidor y el cliente en casos como la validación de formularios. Puede generar HTML en el servidor en los casos en que el cliente no tiene habilitado javascript, usa IE6, es un bot, etc. renderizar el lado del servidor HTML.

Muchas de estas características están al principio del ciclo de desarrollo, por lo que tienen errores. En unos pocos años, muchas tiendas PHP / Ruby pueden subirse al tren Javascript del lado del servidor, atraídos por la compatibilidad del código servidor / cliente.

Los servidores y PHP todavía se usan para funciones que se pueden manejar del lado del cliente con HTML5, como edición de imágenes, recuento de palabras, corrección ortográfica, etc. Lleva tiempo cambiar las prácticas de desarrollo. Muchas de las funciones HTML5 se hicieron ampliamente disponibles solo este año e IE aún no las ha agregado.

También hay una percepción cultural de que JavaScript es incapaz y molesto, y la web real está del lado del servidor, lo que llevará tiempo para desaparecer. A los programadores no les gusta la elección del lenguaje que les impone una plataforma y JavaScript es forzado. JavaScript y sus API evolucionaron a través de un consenso doloroso que dejó un mal sabor, mientras que las herramientas del lado del servidor avanzaron sin problemas.

More Interesting

Cómo mejorar la calidad de un sitio web en términos de simplicidad / complejidad, imágenes, escritos y páginas desvaídas

¿Puede una persona hacer seis figuras con el desarrollo web? ¿Qué idiomas obtendrá uno allí?

En var my = function nhy () {}, ¿la función nhy () también se encuentra en JavaScript?

Cómo ser un buen desarrollador frontend

¿Es el diseño web receptivo el futuro del desarrollo de sitios web?

¿Puede Python emular perfectamente un navegador?

¿Cuál es la mejor manera de practicar la programación web por tu cuenta?

¿Qué método puedo usar para ilustrar la diferencia en los tiempos de diseño e implementación a lo largo de un ciclo de vida del proyecto para bases de datos que usan SQL vs MongoDb?

¿Cuáles son algunas de las cosas que los desarrolladores de PHP no saben sobre PHP incluso después de 3 años de experiencia?

¿Es común que un único desarrollador web se desarrolle en HTML, CSS, JavaScript, JSON, jQuery y AngularJS como parte de su trabajo diario?

¿Cuáles son los mejores lenguajes de programación para facilitar la integración entre la arquitectura front-end y back-end?

¿Es posible excluir Linux y ser un profesional de PHP?

¿Cuál es la mejor tecnología ASP.Net para avanzar: Razor o aspx?

¿Qué opinas sobre Angular2 vs Reactjs?

¿Cómo puedo hacer que un sitio sea más amigable para dispositivos móviles? Desarrollé wizmobilerepair.com con un ancho fijo de 1024px y me di cuenta de que esto no tiene fluidez. ¿Qué puedo hacer para implementar un diseño web receptivo?