Wow, tuve esta regla larga y detallada que compara y contrasta Java y PHP. Estaba a punto de hacer clic en “escribir respuesta”, cuando me di cuenta de que tanto las respuestas existentes como las mías suponían que su pregunta era sobre cuál es mejor, cuando en realidad lo que realmente preguntó es cuál es la diferencia.
Lo siguiente no aborda las diferencias en el nivel de abstracción del lenguaje, el rendimiento, la escalabilidad, el soporte de API, la disponibilidad de herramientas o el tamaño del grupo de talentos del desarrollador o el mercado laboral.
Nota: JSP significa Java Server Page. PHP originalmente significaba “Página de inicio personal”, pero ahora es “PHP: preprocesador de hipertexto”. En uso general, parece común decir “una página PHP”, mientras que en el mundo de Java la gente simplemente dice “un JSP”.
- ¿Por qué no puedo implementar algo usando un lenguaje de programación?
- ¿Existe un futuro prometedor en el desarrollo web?
- ¿Es Java una buena forma de desarrollar aplicaciones web?
- Soy nuevo en el desarrollo web, ¿cómo puedo publicar mi aplicación web en el mundo?
- ¿Cuándo se usa generalmente un para cada ciclo para aplicaciones web?
Una página PHP es muy análoga a un JSP. Cualquiera de los dos es un archivo lleno de contenido con scripts opcionalmente integrados, delimitados por etiquetas especiales de inicio / finalización. Dentro de los scripts incrustados hay una fuente PHP o una fuente Java.
Los JSP también admiten etiquetas especiales basadas en XML para hacer muchas cosas, proporcionar un mejor soporte de herramientas para permitir que los que no son programadores agreguen interactividad a un JSP y disminuir la tentación de los programadores de hacerse fanáticos del Java incorporado. Sin embargo, las etiquetas JSP admiten tantas o más complicaciones, por lo que es dudoso que realmente hayan logrado este segundo objetivo.
Cuando envía una solicitud HTTP a un servidor apache para una URL con una extensión de archivo .php, el servidor apache (y mod_php) carga el archivo y lo ejecuta y devuelve cualquier texto (con suerte HTML) que imprime el script PHP en el archivo fuera.
Cuando envía una solicitud HTTP a un motor de servlet de Java para una URL con una extensión de archivo .jsp, el motor de servlet (y el compilador JSP) carga el archivo y lo ejecuta y devuelve cualquier texto (con suerte HTML) que imprime el JSP.
Sin embargo, ambos casos son, por supuesto, un poco más complicados.
Modelo de carga de página
No conozco el modelo subyacente para la interpretación de páginas PHP en el mismo grado que sé cómo se compilan las páginas JSP en la fuente de servlet java y la clase de servlet java instanciada y ejecutada en la memoria, etc. Sin embargo, en general:
Cuando se carga la página PHP, cualquier contenido no incluido en la etiqueta PHP se imprime en la conexión del navegador. Cualquier fragmento del archivo delimitado por etiquetas PHP se interpretará como script PHP. Si ese script PHP contiene una declaración de impresión, todo lo impreso se enviará a la conexión del navegador. Si ese PHP contiene una definición de función u objeto, esa función o definición de objeto se ejecuta y la función u objeto está disponible para cualquier script en la página.
Los scripts PHP pueden importar otros archivos PHP que definen funciones y objetos.
No existe una diferencia concreta entre una página PHP orientada al usuario y un archivo PHP de biblioteca de funciones o clases, excepto que el archivo función / clase no genera directamente ningún resultado para enviar al usuario y no está referenciado por algún otro usuario página o el mecanismo index.php. Los archivos importados también pueden tener contenido o scripts PHP de nivel superior que imprimen contenido, en cualquier caso, el contenido se enviará de vuelta a la conexión del navegador en la página PHP de importación.
Tenga en cuenta que hay herramientas PHP especiales que hacen más almacenamiento en caché de PHP, y estoy seguro de que apache y mod_php hacen algunas cosas inteligentes, posiblemente con almacenamiento en caché, para mejorar el rendimiento también. No sé cuáles son los detalles. Conozco el modelo para JSP / servlets, porque eso es obligatorio por la especificación del servlet.
Si bien una página PHP es el componente básico de una aplicación PHP, los JSP son en realidad secundarios en las aplicaciones web Java. Los JSP se compilan en servlets de Java. Los servlets llegaron primero, los JSP se agregaron más tarde y, en general, estaban destinados a ser una forma rápida de escribir servlets muy superficiales y orientados a la presentación.
Un servlet es una clase Java que el motor de servlet crea instancias y sigue ejecutándose en la memoria, entre solicitudes del navegador. Un archivo con una extensión de “.jsp” se compila en la fuente de Java para un servlet, y esa fuente se compila en el código de bytes de Java. Cada línea que no es de script se traduce en una simple declaración de impresión. En su forma más simple, un JSP da como resultado una clase de servlet que tiene un método único que contiene un montón de declaraciones de impresión.
Cuando un navegador envía una solicitud HTTP a un motor de servlet de Java para que una URL configurada en el motor de servlet se asocie con una instancia de una clase de servlet particular, el motor de servlet comprueba si el servlet se ha solicitado antes, y si entonces, conecta la solicitud a la instancia de servlet en memoria ya en ejecución asociada con esa URL.
Cuando un navegador envía una solicitud HTTP a un motor de servlet Java para una URL con una extensión de archivo .jsp, el motor de servlet (y el compilador JSP) verifica si el archivo JSP se ha solicitado antes y, de ser así, conecta la solicitud a la instancia de servlet en memoria ya en ejecución asociada con ese JSP. Si aún no se ha solicitado la página JSP, el servidor (y el compilador JSP) cargará el archivo, lo compilará en la fuente Java, compilará la fuente Java, creará una instancia y ejecutará el código de bytes Java resultante, conectará la solicitud a la instancia de servlet en ejecución para ese JSP, y envíe de vuelta cualquier texto (con suerte HTML) que imprima el servlet del JSP.
Los JSP se pueden precompilar antes de agruparlos en una aplicación web de Java antes de la implementación en un servidor de producción, y esto generalmente se hace con fines de rendimiento y pruebas.
Estado
HTTP no tiene estado, pero las aplicaciones web PHP y Java proporcionan un mecanismo de sesión incorporado similar para permitirle almacenar datos entre solicitudes.
El servidor establece una cookie en su navegador que contiene una ID de sesión, un valor único (no verdaderamente único, pero en términos matemáticos, lo suficientemente cerca), que el navegador luego incluye con cualquier solicitud posterior al servidor.
Cuando una página PHP almacena datos en la sesión, los datos se almacenan en el lado del servidor, en un mecanismo marcado por ese valor único. Cuando una solicitud posterior del navegador llega con el mismo valor de cookie y ejecuta una página PHP, la página PHP puede solicitar datos de la sesión. El servidor proporciona datos asociados con ese valor de ID de sesión.
Hasta donde yo sé, los datos de la sesión de PHP se guardan en la memoria, aunque no me sorprendería si existen mecanismos opcionales para diferentes tipos de almacenes de respaldo para los datos de la sesión. Ciertamente, hay una gran cantidad de tiendas de respaldo de sesión diferentes disponibles para aplicaciones web de Java, según el motor de servlet o el servidor de aplicaciones que utilice.
Las aplicaciones web Java tienen un mecanismo de sesión similar, así como varios otros mecanismos de sesión; pueden almacenar datos por solicitud http, por sesión de usuario, por aplicación web y en todo el servidor.
Además, los servlets de Java son inherentemente con estado, la clase se instancia y se guarda en la memoria entre solicitudes.
Los servlets de Java también son inherentemente multiproceso, lo que significa que la instancia de clase DEBE estar preparada para manejar múltiples solicitudes simultáneamente. Esto significa que si la clase configura cualquier estado compartido en variables de instancia, múltiples subprocesos pueden acceder a ese estado compartido en cualquier momento dado. La mayoría de las aplicaciones web Java están diseñadas para evitar eso, confiando en el mecanismo de sesión y otras técnicas para proporcionar una mejor gestión de estado segura para subprocesos.
En general, con una aplicación web java (una “aplicación web” es un concepto definido en la especificación de servlet java como un paquete coherente de servlets java, páginas JSP, activos estáticos, clases y bibliotecas java, configuraciones, etc.) las páginas JSP son Los servlets orientados a la presentación y codificados para fines sirven como policías de tráfico, reciben solicitudes, crean instancias e invocan clases de lógica Java, ocultan los resultados en los datos de la sesión y luego reenvían el control a las páginas JSP para extraer los resultados y enviarlos en medio de HTML.
Este enfoque general se llama “Modelo 2”, basado en el concepto de MVC, y existen muchos marcos de aplicaciones web de Java que reimplementan el Modelo 2 y MVC como una capa adicional en la parte superior de la especificación del servlet.
API y bibliotecas
Como se mencionó en la introducción, realmente no estoy abordando el soporte de API, pero; en PHP, si está orientado a la web, probablemente ya haya una biblioteca para hacerlo. Es posible que no disfrute usar esa biblioteca, pero probablemente esté allí. Java tiene una gran variedad de API para realizar todo tipo de tareas no orientadas a la web. Si está trabajando en menos tareas de vainilla webby, puede que le resulte mucho más fácil hacerlo en Java.
Una vez dicho todo lo anterior, en estos días se acepta con bastante regularidad el éxito en el desempeño de subcontratar una porción estratégica de su conjunto de características a un servidor independiente y acceder a él a través de una solicitud HTTP interna u otro protocolo de red. Un enfoque híbrido de una aplicación web front-end de usuario en un lenguaje más fácil, usando un servicio web para acceder a un servidor Java de back-end “pesado” es mucho menos probable que suscite sorpresa.
Bases de datos
Tanto las páginas PHP como las aplicaciones web Java suelen utilizar bases de datos para la persistencia de datos a largo plazo. En mi experiencia (que de ninguna manera es exhaustiva), las aplicaciones PHP tienden a depender más de la base de datos, cargando la mayoría de los datos de la base de datos con cada solicitud, lo que resulta en más “abandono de la base de datos”. Las aplicaciones PHP que se ocupan de cargas más altas generalmente pasan rápidamente a usar un mecanismo de almacenamiento en caché en memoria más elaborado, siendo Memcached una de las herramientas más populares cuando lo examiné por última vez, hace unos años.
Las aplicaciones web Java suelen depender más del estado de sesión en memoria. Si bien esto disminuye la pérdida de memoria y probablemente disminuye el tiempo de espera de E / S por solicitud, también significa aumentar el uso de memoria por usuario, lo que presenta un riesgo de limitaciones de escalamiento de la sobrecarga de memoria.
Tenga en cuenta que estas dos tendencias pueden ser simplemente el resultado de la tendencia a que las aplicaciones web Java se utilicen en aplicaciones empresariales menos públicas y más orientadas a la cuenta del usuario en comparación con las aplicaciones PHP que se utilizan en contextos más públicos. O esa tendencia puede ser simplemente un artefacto de mi propia experiencia.
Los servidores de aplicaciones web Java (generalmente llamados motores de servlet o servidores de aplicaciones) generalmente proporcionan conexiones de bases de datos agrupadas para fines de rendimiento. Un mecanismo estándar para esto se define en la especificación del servlet. Menciono esto principalmente porque es un error clásico de principiante no usar un grupo de conexiones y puede tener un gran impacto en el rendimiento de las aplicaciones web de Java. Cualquier discusión sobre el rendimiento de la aplicación web de Java que no incluye habitualmente el uso (o al menos el análisis) de la agrupación de conexiones de bases de datos es profundamente defectuosa.
URL y mapeo
Con PHP, la asignación de URL a PHP está bastante definida por la estructura del directorio, los nombres de directorio y los nombres de archivo y la extensión de archivo (.php). No es imposible que sucedan cosas más inteligentes, que se invoquen páginas php detrás de escena y que aparezcan rutas aparentes en la URL que no requieren la existencia de directorios y archivos equivalentes. Pero no parece hacerse con tanta frecuencia.
El mundo de las aplicaciones web de Java, por otro lado, se equivoca en la otra dirección. Si bien la especificación del servlet de Java proporciona inherentemente mucha flexibilidad para definir qué ruta de URL conduce a qué servlet, y de hecho requiere que los defina en sus archivos de configuración, muchas personas descartan esa flexibilidad y usan un marco que define un solo punto de entrada, y poner su configuración en otro archivo XML que utiliza el marco.
Marcos
Tanto el mundo de las aplicaciones web de PHP como el de Java tienen una gran cantidad de piñatas, sin esperar, eso es una gran cantidad de marcos. La moda del marco comenzó de nuevo en el mundo de Java y luego infectó el mundo de PHP. El mundo de Java tiene muchos más marcos y mucho más tiempo y energía gastados en marcos. Creo que los marcos están demasiado enfatizados, por lo que no es un punto negativo que no sean tan universalmente recomendados en el mundo PHP.
Hosting
El soporte de PHP está disponible de forma fácil y ubicua en el alojamiento apache en todo Internet. mod_php es prácticamente un módulo predeterminado en una instalación de apache. Hay algunos pasos que debe seguir el administrador del sistema, en particular la configuración del soporte para que php acceda a la base de datos elegida. Pero incluso hacerlo usted mismo en un sistema Linux moderno es bastante fácil, y casi todo el alojamiento básico incluye automáticamente PHP y soporte de base de datos de fábrica.
El soporte de alojamiento Java solía ser casi exclusivamente roll-your-own. Incluso los proveedores de hosting que afirmaban apoyarlo realmente no ofrecían mucho en cuanto a soporte. Sin embargo, en estos días hay mucho más soporte de alojamiento Java. Pero la mayoría de los servidores Java asumen un nivel inicial más alto de alojamiento; Un servidor virtual o alojamiento en la nube. Prácticamente no encontrará el alojamiento java disponible en ningún tipo de entorno de alojamiento web compartido o básico. Esto se debe en gran parte al hecho de que es más fácil cometer un error y consumir en exceso los recursos en una aplicación web de Java, y es más difícil aislar a los usuarios en un entorno de alojamiento compartido contra los errores de la aplicación web de Java de otro usuario.
