J2EE vs. PHP

Mon formateur Java, Pierre, s'interrogeait sur PHP, se demandant pourquoi les gens s'obstinaient à l'utiliser plutôt que les techniquement supérieurs Java et J2EE.

Connaissant un peu PHP et maintenant J2EE, cette question m'a frappé et je vais essayer d'apporter ici quelques éléments de réponse. Je n'ai pas la prétention d'affirmer qu'une technologie est supérieure à l'autre, mais je vais seulement essayer de donner des arguments pour chaque camp.

• PHP est répandu.

  De très nombreux hébergeurs, tant gratuits (Multimania, Free) que payants proposent PHP en standard, parfois Perl, voire Python, très rarement J2EE.
  L'hébergeur que j'ai choisi pour le site d'e-commerce de ma femme, Agora System, a tenté de proposer Tomcat sur les serveurs mutualisés – c'est-à-dire au processeur et à la mémoire partagés entre plusieurs hébergés. Ils ont finalement renoncé, l'application étant trop gourmande en ressources, désavantageant ceux qui n'en avaient pas besoin.
  Pour ceux qui veulent un hébergeur supportant Tomcat, un utilisateur recommande Llord.com.

• PHP est simple à apprendre.

  Ceux qui sont familier avec le C sont en terrain connu, mis à part quelques bizarreries comme la nécessité de déclarer les variables globales dans une fonction avant de s'en servir.
  Il est, à la base, procédural, donc plus facile à maîtriser, les notions objet n'étant pas évidentes à apprendre (au moins en autodidacte) et moins encore à appliquer efficacement. Je parle d'expérience ici :-)
  Je ne suis pas le seul à le dire : « PHP est plus facile à prendre en main que le modèle objet de Java pour des développeurs AS/400. »
• En contre-partie, j'ai lu un article qui affirmait que plus de 80 % des programmeurs PHP ont découvert la programmation en autodidacte sans expérience du développement auparavant. Cela confirme que PHP est facile à apprendre, un peu comme le Basic, mais malheureusement qu'on voit aussi beaucoup de code médiocre, les programmeurs n'ayant que de vagues notions d'algorithmie, de concept de maintenance, de structuration, etc.
  Java, plus difficile à maîtriser, bénéficie d'une communauté plus mûre, plus aguerrie aux techniques avancées comme les design patterns.
  Cela dit, j'ai aussi vu du code PHP superbe, modulaire, utilisant judicieusement les patterns, etc. Par example, le framework PHP Seagull.

• PHP est facile à mettre en œuvre.

  Son installation est facile : sous Windows, il suffit d'utiliser EasyPHP ou XAMPP pour avoir rapidement un serveur complet.
  On peut bricoler un petit programme de test vite fait, son caractère interprété permet un cycle de développement rapide (pas de compilation, pas besoin de redémarrer le serveur d'application...) et son caractère faiblement typé (comme la plupart des langages de script) est très permissif. Ce qui est bien pour le Rad, mais moins bien pour les applications ambitieuses...
• En contre-partie, j'ai vu quelques grosses applications PHP qui, malgré l'utilisation des pseudo-classes PHP4, étaient assez peu lisibles et difficiles à maintenir.
  Le projet d'e-commerce que j'ai choisi, Zen Cart, se traine un passé assez lourd : il est dérivé d'un projet plus ancien qui souffrait d'une construction monolithique. Zen Cart est plus modulaire, utilisant des templates, mais reste difficile à faire évoluer. Les responsables du projet essaient de le rendre plus modulaire encore, introduisant des (saines) notions de modèle-vue-contrôleur, etc.
  Pour des applications plus robustes et plus facilement maintenables, PHP5 propose enfin un système (optionel !) objet digne de ce nom. En fait, il a été presque entièrement copié sur Java... Ce qui n'est pas une mauvaise idée : bons concepts éprouvés, familiarité pour les programmeurs Java, etc.
  Le problème est que PHP5 n'est pas encore présent chez tous les hébergeurs (serveurs mutualisés) comme Agora System.

• La syntaxe de PHP n'est pas très cohérente.

  Par exemple, on teste si une variable existe avec isset() (verbe + complément, un schéma répandu et logique), mais on teste si elle est vide avec empty(), au lieu, par exemple, de isempty(), et on teste si une constante est définie avec defined() au lieu isdefined().
  Autre exemple : les fonctions de chaîne de caractère. On trouve des strrev() ou des strtolower() à côté des str_repeat() et str_word_count(). Soit un mélange d'utilisation des mots collés et séparés par un souligné.
  Dans la même section, on voit aussi des nl2br() à côté des strtoupper()...
  Il semblerait que le langage a été enrichi par de nombreux contributeurs, ce qui est bien, mais sans autorité centrale de coordination et de décision qui aurait renforcé la cohérence des noms de fonctions.
  De ce point de vue, Java, qui a une bibliothèque à peu près aussi riche, a un schéma de nommage beaucoup plus cohérent.

• PHP ne supporte pas Unicode en natif.

  Java le supporte de façon native, ici il a un net avantage.

• PHP est un projet libre, à source ouvert.

  Un aspect important pour certains. Cela garantit une certaine pérénité et une grande portabilité : même sur un serveur exotique, on peut toujours recompiler les sources. Cela dit, Java est supporté sur les machines les plus exotiques...
  PHP est aisément extensible avec des modules écrits en C, donc rapides et utilisant des bibliothèques existantes.
  C'est une des choses reprochées à Java : son caractère propriétaire, Sun gardant jalousement le contrôle du langage.
  
• ZDNet a publié une intéressante étude sur J2EE où ils remarquent que les EJB ne sont guère utilisés ailleurs que dans de grands projets (banques, assurances), mais que le couple JSP+servlets souffre de la compaison avec PHP et ASP : « En choisissant un serveur qui ne supporte que JSP et les servlets, l'entreprise acquiert une technologie identique à ASP et PHP. Sauf que PHP et ASP sont largement plus répandus, mieux maîtrisés et coûtent moins cher en prestation. Seules, les JSP ont donc peu d'intérêt. »