Moi, je connais les deux et j'ai actuellement des projets avec les deux ...
L'un est le site pour une association, petite taille, pas de miroir ==> PHP (de toutes façon l'hébergeur ne propose pas de JSP ;-))
L'autre est une partie d'une grosse application dont les données sont vraiment très complexes. Les données ne seraient pas raisonnablement manipulables avec PHP. La solution est donc EJB, Beans et JSP.
Conclusion, si tu n'as pas à faire de petit site, PHP ne t'aidera pas (ou alors tu te retrouveras avec une usine à gaz comme PHPnuke). Sinon, PHP s'apprend en deux jours avec la doc qui est en ligne sur http://php.net(...)
PS : j'ai fait quelques tests de charge avec mon projet JSP. Le serveur était sur un Pentium 233MMX, 64 MB de RAM sur réseau local 10Base-T. Avec 100 utilisateurs, temps moyen de réponse 2 s, temps maximum 5 s. Avec 1000 utilisateurs, 7 et 21 s. Donc Java n'est pas toujours lourdingue : il suffit de programmer autrement et arrêter de faire confiance au matériel pour récupérer les erreurs de conception.
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par François B. . En réponse à la dépêche Comparatif jsp/php. Évalué à 1.
- L'un est le site pour une association, petite taille, pas de miroir ==> PHP (de toutes façon l'hébergeur ne propose pas de JSP ;-))
- L'autre est une partie d'une grosse application dont les données sont vraiment très complexes. Les données ne seraient pas raisonnablement manipulables avec PHP. La solution est donc EJB, Beans et JSP.
Conclusion, si tu n'as pas à faire de petit site, PHP ne t'aidera pas (ou alors tu te retrouveras avec une usine à gaz comme PHPnuke). Sinon, PHP s'apprend en deux jours avec la doc qui est en ligne sur http://php.net(...)PS : j'ai fait quelques tests de charge avec mon projet JSP. Le serveur était sur un Pentium 233MMX, 64 MB de RAM sur réseau local 10Base-T. Avec 100 utilisateurs, temps moyen de réponse 2 s, temps maximum 5 s. Avec 1000 utilisateurs, 7 et 21 s. Donc Java n'est pas toujours lourdingue : il suffit de programmer autrement et arrêter de faire confiance au matériel pour récupérer les erreurs de conception.