Discussion :

[batataw]

Ba du coup pour le déploiement en PHP ça pourrait être juste l'automatisation par un script, qui va va gérer le copie des fichiers sur le serveur. Et justement comment ça se passe s'il y a des optims serveurs, je pense à la configuration du mod php et / ou du cache d'opcode. C'est géré à la mano ?
J'ai un ami qui me dit qu'il y a souvent des merde en prod parce que les ingénieurs systèmes ou les développeurs tête en l'air copie limite directe les fichier du repo svn vers les serveurs de prod, ce qui ne marche pas correctement avec les configs SVN.

En fait, comme je le répete souvent un bon developpeur PHP aura aussi de solide base en administration systeme, Il n'est pas rare de trouver dans une annonce Administration Systeme Requis. Dans mon cas je fournis a l'administrateur la liste des modules dont nous avons besoin pour le serveur de prod.
Tous ces modules ayant été testés et installés sur le serveur de Dev. Quant a la mise en prod j'ai connu de tout de ce coté la, ca allait de la copie de fichiers via FTP directement sur le serveur de prod a l'automatisation avec Webistrano (bien évidemment, ca n'a rien avoir avec PHP)

S'il y a une livraison, un zip versionné et archivé, ca permettrait de professionnaliser vos équipes logicielles. Ça permet de préparer éventuellement une recette, un PV. Bref un client exigent pourrait apprécier.

Oui, dans le cycle de développement logiciel "classique" une release est identifié pour passer en prod, sur cette release on ne fera que du bug fixing, comme cela serait fait dans n'importe quel autre language. Cette release peut etre fourni au client.
Cela dit je travaille beaucoup dans des environnements Agile et RAD les regles sont différentes (spécifications mouvantes et livraisons plus fréquentes).

Autre question justement à propos de ce mode "fichier", typiquement comment vous faites pour livrer des patch et savoir quels patch sont en prod s'il s'agit juste de faire un drag&drop. Question suivi de prod c'est important.
Si tout le monde peut faire n'importe quoi avec le serveur de prod, c'est pas très "clean".

Tout ca repose sur un bon outil de gestion de configuration et des bonnes pratiques mise en places des le départ.
Si des develloppeurs balancent leurs fichiers directement en prod c'est qu'une étape a été loupée lors de la mise en place des processus.

Ben non et encore heureux, la partie présentation est une infime partie de PHP.
Pour être tout a fait honnête je ne vois pas des entreprises se lancer avec PHP sur des sites envergure si c'était que pour dynamiser des pages HTML.
Je me répète PHP associé à un Framework comme Zend ou Symfony fait des merveilles.

Je conserve ce que j'ai dit plus haut, mais je reste quand même perplexe, celà dit PHP c'est un langage ET un écosystème à surveiller.

Je comprends mieux ce que tu veux dire, beaucoup de developpeurs font une confusion entre gros projet et projet avec de la profondeur.
En faite un projet meme avec des mécanismes complexes, meme s'il est tres gros. PHP et son écosysteme pourront faire l'affaire tant que c'est du Web.
En revanche si le projet prend beaucoup de profondeur (middleware, temps-reel), je ne dis pas que c'est pas possible mais ca risque de se compliquer, il faudra donc bien étudier l'architecture avant de se lancer.
Contrairement aux idées recus Facebook n'utilise pas que du PHP mais l'essentielle de son site est en PHP.
Je ne me lancerais pas dans une application pour une salle de marché ou de paris en ligne en PHP (contrainte de persistence et de temps réel trop forte)
en revanche une banque en ligne ne me génerait pas plus que ca.

Salut,
Je développe essentiellement en PHP. Mais je ne suis pas pro PHP, comme ça a été dit, il s'agit soit de comparer deux langages, soit de comparer des concepts et tout ce qui gravite autour. Il ne faut pas non plus confondre développeur et architecte logiciel. Et finalement c'est pour l'architecte que le langage qui sera utilisé aura bien plus d'impact que le développeur. Une syntaxe n'a jamais été une barrière pour un développeur, sauf mauvaise foi. Alors lire du "php c'est moche" c'est vraiment pas un argument. Un code peut-être joli avec les deux langages hein, c'est comme pour tout une simple question d'habitudes.

Comme je le dis souvent un developpeur doit etre polyglotte, PHP répond tres bien au besoin d'Agilité et du RAD.

Mais depuis j'ai découvert un nouveau framework en Java : Play!
Et la, je retrouve tout ce que j'appréciais en PHP avec la puissance de l'écosystème Java. Plus besoin de sortir l'artillerie lourde, de compiler 1 min, de lancer son serveur d'application pendant 10 minutes pour tester une pauvre modif de code.

Je suis pres a essayer ce Framework prometteur si j'arrive a la meme souplesse qu'avec les Frameworks PHP. Je le surveille de pres, j'attends les retours terrain. Je crains juste qu'il soit snobé par les puristes Java.

Afin de changer le frontal, des tests de charge ont donc été fait sur des CMS PHP comme Java (Drupal, Ez, etc..., Alfresco, Nuxeo, etc...). Ayant déjà l'expérience d'avoir un site fortement stressé, nous avons toutes les optimisations PHP possible dont bien sûr le cache d'OpCode.
Les tests sont sans appel, tous les CMS PHP sont tombés, alors que même le plus mauvais CMS Java tenait la charge. Dans les faits, on prendra tout de même un CMS PHP pour des raisons pratiques et de besoins. D'une manière générale si vous choisissez PHP faites attention aux performances, il ne faut pas soupeser ces besoins pour votre client, évidement ce genre de problème sera plus ou moins visible suivant le trafic.

Je ne suis pas surpris les languages de script ne peuvent pas conccurencer les langages "compilés" cela dit tout est une question d'équilibre.
Si les performances sont le premier critere et que ton client ne veut pas investir dans un load balancer, il faudra peut-etre choisir un autre langage.
C'est vrai qu'une mauvaise architecture peut planter un bon projet.
Nous avons opté pour un proxy cache sur le projet sur lequel je travaille actuellement comme pour les journaux en ligne (Squid, Ncache).

[TheNOHDirector]

Tous ces modules ayant été testés et installés sur le serveur de Dev. Quant a la mise en prod j'ai connu de tout de ce coté la, ca allait de la copie de fichiers via FTP directement sur le serveur de prod a l'automatisation avec Webistrano (bien évidemment, ca n'a rien avoir avec PHP)

Oui c'est bien ça qui fait peur et j'ai l'impression que c'est moins rock n roll en Java, même si les mauvaise pratiques peuvent toujours exister.

Cela dit je travaille beaucoup dans des environnements Agile et RAD les regles sont différentes (spécifications mouvantes et livraisons plus fréquentes).

Nos équipes travaillent en Scrum et les itérations sont sanctionnées par des releases. De la même manière s'il faut faire un patch, ou un patch de patch, nos équipes livrent une release clairement identifiée. Je pense que ce ne serait pas gênant en PHP.

A ce sujet, un ami m'a parlé d'archive PHAR, qui pourrait être l'équivalent de WAR ou de JAR. Je ne connais pas bien mais peut-être que c'est un bon moyen d'archiver les releases (je trouverais ça plus clair qu'un fichier zip).

Comme je le dis souvent un developpeur doit etre polyglotte, PHP répond tres bien au besoin d'Agilité et du RAD.

100% d'accord sur le polyglotte! Effectivement Facebook n'est pas fait que de PHP, de la même manière que Twitter n'est fait qu'en PHP ou Ruby.

Pour le RAD, j'avoue que Java manquerait parfois de souplesse vis-à-vis des langages script. A ce niveau je parle de souplesse de la syntaxe, et la souplesse de l'outillage (pas de l'IDE). Avec Groovy et Play, on retrouve cette souplesse, mais je pense qu'elle n'est pas adapté à tous les cas. Et l'intégration / interaction de ces deux "modes" n'est pas encore bien clair.

En ce qui concerne Play, je n'ai pas eu le temps de vraiment investiguer, mais ca fait quelques mois que je suis le projet, et je me demande encore dans quelle direction le projet va. Personnellement j'aimerais savoir comment ce projet marcherait sur/avec du code legacy.

[batataw]

Oui c'est bien ça qui fait peur et j'ai l'impression que c'est moins rock n roll en Java, même si les mauvaise pratiques peuvent toujours exister.

Comme en Java y'a pas de fichiers indépendants tu ne risques pas de copier un fichier en catastrophe sur le serveur de prod. Au final si le projet PHP est bien configuré y'a pas de soucis à se faire.

Nos équipes travaillent en Scrum et les itérations sont sanctionnées par des releases. De la même manière s'il faut faire un patch, ou un patch de patch, nos équipes livrent une release clairement identifiée. Je pense que ce ne serait pas gênant en PHP.

Oui je fonctionne de la même façon sauf avec l'intégration continu, ca se complique un peu.

A ce sujet, un ami m'a parlé d'archive PHAR, qui pourrait être l'équivalent de WAR ou de JAR. Je ne connais pas bien mais peut-être que c'est un bon moyen d'archiver les releases (je trouverais ça plus clair qu'un fichier zip).

Tout ce que je sais c'est que c'est en standard avec PHP 5.3 et que ce fichier peut être déployé tel quel sur un serveur Web comme les WAR. Cela dit l'intérêt est limité si c'est juste pour l'archivage. Tu vas te donner du travail pour rien.

[myspac]

c est mieux de travailler avec les deux mais php c est le top a mon avis

[VinceMD]

J'ai l'impression que les réponses sont tres orientées vers les aspects techniques meme si certains citent les processus de gestion de projet.

Je suis surpris de lire que Php ne tient pas de grosses charges face a Java. Car mon impression est que pour faire tourner une appli Java, c'est déja tres demandeur de ressource meme si l'application n'est pas utilisée. Le ratio charge/utilisation ressources n'est donc pas linéaire.

D'ailleurs pourquoi Facebook tourne en Php si ils considerent que c'est lent ? Question historique alors, ou de couts ?
Ca amene a ma réflexion selon laquelle la composante technique (rapidite, qualite du framework, etc), n'est qu'un des nombreux elements qui menent a un choix technologique.

Comme le dit TheNOHDirector, Php semblait une mauvaise solution technique, pourtant ... ils l'ont garder...

Il y a quelques mois, j'ai griphoné ce schema:



source: Quelle solution de technologie Web (n'hésitez pas a critiquer ou a apporter votre contribution, il manque pleins d'éléments)
C'etait un essai, mais je voulais juste émettre l'idee que finalement ... la technique ... c'est pas si déterminant. Et c'est dommage, mais c'est comme ca. Je me trompe ?
Actuellement je bosse sur un projet .Net (pour info je suis passé par Php, Java, Ruby). Je n'aime pas vraiment .Net. Mais bon, c'est un client corporate, historique Microsoft, tout ca. Meme pas la peine de se poser la question, il y a un gros effort d'integration dans leur environment pour cette application.

Y'en as d'autres qui ont le meme sentiment que moi ? Finalement comparer truc avec bidule, est ce que c'est important ? J'aimerai entendre que oui

[kaymak]

C'etait un essai, mais je voulais juste émettre l'idee que finalement ... la technique ... c'est pas si déterminant. Et c'est dommage, mais c'est comme ca. Je me trompe ?

Dans la mesure où on trouve un ensemble de fonctionnalités équivalente, que ton usage s'effectue sur une sous partie des fonctionnalités disponible, ALORS oui, la technique devient très accessoire.

D'ici là, non, la <solution> technique reste déterminante dans la réalisation de la tâche.

Actuellement je bosse sur un projet .Net (pour info je suis passé par Php, Java, Ruby). Je n'aime pas vraiment .Net. Mais bon, c'est un client corporate, historique Microsoft, tout ca. Meme pas la peine de se poser la question, il y a un gros effort d'integration dans leur environment pour cette application.

Y'en as d'autres qui ont le meme sentiment que moi ? Finalement comparer truc avec bidule, est ce que c'est important ?

Tu as mis le doigt dessus.
Tu as utilisé du .net car il possédait un sous ensemble de fonctionnalités qui arrangeait bien la vie de ton client.
Et que pour le reste des besoins, que j'imagine seulement, n'importe quelle technos en vogue aurait pu répondre.

Donc à situations égales, on prend celle qui semble la plus simple, ici c'est celle qui propose de s'intégrer dans la situation donnée le plus facilement.
A tord ou à raison, l’exploitation du projet résultant en donnera une réponse.

non ?

a+

[Hephaistos007]

D'ailleurs pourquoi Facebook tourne en Php si ils considerent que c'est lent ?

A ce propos : http://www.clubic.com/actualite-3230...hyper-php.html

[llaffont]

Je n'ai pas lu l'intégralité des échanges qui pour la plus part commence à dater.
Mais une point revient souvent sur l'utilité de PHP par rapport à JAVA et je m'interroge sur la véracité de ces propos aujourd'hui en 2011.
Je vous soumet donc mon interrogation.

PHP est-il toujours dédié seulement au site web ou est-il enfin apte à faire des application WEB tel que le fait JAVA ?

Sinon j'ai voté PHP ne connaissant pas JAVA

[batataw]

Je n'ai pas lu l'intégralité des échanges qui pour la plus part commence à dater.
Mais une point revient souvent sur l'utilité de PHP par rapport à JAVA et je m'interroge sur la véracité de ces propos aujourd'hui en 2011.
Je vous soumet donc mon interrogation.

PHP est-il toujours dédié seulement au site web ou est-il enfin apte à faire des application WEB tel que le fait JAVA ?

Sinon j'ai voté PHP ne connaissant pas JAVA

C'est pour le WEB, c'est sa force et sa faiblesse.
PHP = RAD orienté 100% WEB.

[sekaijin]

Je n'ai pas lu l'intégralité des échanges qui pour la plus part commence à dater.
Mais une point revient souvent sur l'utilité de PHP par rapport à JAVA et je m'interroge sur la véracité de ces propos aujourd'hui en 2011.
Je vous soumet donc mon interrogation.

PHP est-il toujours dédié seulement au site web ou est-il enfin apte à faire des applications WEB tel que le fait JAVA ?

Sinon j'ai voté PHP ne connaissant pas JAVA

Heu ! Tu es sur de ta question, car pour avoir beaucoup travaillé avec les deux c'est plutôt la question inverse qui me vient
Java est-il enfin apte à faire de vraies applications web comme PHP*?

Java est extrêmement riche face à PHP non pas au niveau du langage, mais au niveau des usages. On fait énormément de choses qui n'ont rien à voir avec les webApp avec java.

Mais pour ce qui est des applications Web, Java est longtemps resté un gros boulé.
Excusez le terme. Mais la génération d'IHM avec JSP voir struts et consorts et tout de même loin derrière la floraison de solution sous PHP. Leur complexité de mise en œuvre a longtemps fait que PHP était plus abordable.

là où PHP se montrait à ses débuts en retrait par rapport à java c'est sur la partie accès aux donnés, traitement métier, etc.
Mais les framework MVC en nombre montrent que ce n'était pas (que) un problème de langage.

Aujourd'hui, je ne saurais dire lequel je choisirais. Je pense que ce serait plus le projet lui-même qui m'imposerait une techno que les considérations sur les langages
car question montée en charge maintenance rapidité, etc. PHP a fait ses preuves.

Question professionnalisme, pareil. J’ai travaillé sur de gros projets PHP et je dois dire qu'ils sont aussi bien structurés que des projets java.

Je dois reconnaitre que pour ceux qui ne connaissent pas du tout une recherche sur le NET et on trouve tant de bricolages (infâmes) en PHP que ça laisse à penser que c'est un langage de bricolos.

Pour moi c'est un peu comme une brique et du ciment.
Pour faire une maison super pro, on peut utiliser du béton armé, avec des super structures, des calculs scientifiques, etc. et ça fera surement une super maison.
On peut aussi utiliser de la brique et du ciment.
Or la brique et le ciment peuvent aussi être utilisés par tout le monde pour bricoler un abri dans son jardin.
Les abris bricolés par dés amateurs enlèvent-ils de la valeur à la maison en brique*?

Il faut compter de nouveaux venus dans le cercle. Le mode traditionnel des webApp avec un fonctionnement page à page laisse la place à un mode plus client(IHM)/serveur(applicatif).
Je n'aime pas utiliser web2.0, car on y met tout et n'importe quoi.
Bref de plus en plus le client s'enrichit de fonctionnalité d'interface et ne fait plus appel qu'à des services applicatifs.

Du coup, Java vois la partie où il était plus contraignant s'éloigner.
PHP entre temps a montré sa force pour répondre à cette nouvelle approche. Il faut quelques minutes pour exposer une classe comme un service web selon les protocoles en vigueur dans ce genre d'échange.

Reste l'outillage. Peut d'outils de modélisation permettent de générer du PHP alors qu'ils sont floraison pour Java.

A+JYT

[batataw]

Très bonne analyse sauf pour les performances, PHP est un cran en dessous de Java.

En ce moment je suis sur un vieux projet Java full JSP, je peux te dire que c'est une vrai galère. En revanche dernièrement j'ai travaillé avec le Framework Java Play ce fut un régale. J'ai enfin retrouvé des automatismes que j'avais en PHP et le plaisir d'un IDE sur mesure (Eclipse). Même si je trouve qu'il lui manque quelques fonctionnalités importantes qu'on retrouve sur Rail, Django ou Symfony.

[RaphAstronome]

Java n'est pas vraiment un langage web, ça oblige à faire des applications très compliqués pour simplement faire un listing d'une base de données avec 3 critères.

Java est aussi très consommateur de ressources. Sur un service très utilisé ça ce passe assez bien mais le ticket d'entrée est très cher.

Critère supplémentaire Java n'est pas libre et à été racheté par Oracle, on est donc jamais sûr de ce qui va ce passer .

[hugo123]

Pour ma part je suis amusé par les derniers commentaires car au sein de la communauté Java il se dit justement que Java est avant tout un langage pour faire du Web, bien plus que pour faire du client lourd.

Swing (pour le client lourd) est en perte de vitesse et Oracle ne semble pas vouloir le faire évoluer. Java Fx se cherche encore et n'est pas une réelle alternative a Silverlight ou même GWT.

Par contre pour le Web Java est très prisé même s'il a souffert d'une réputation de lourdeur a une époque, faute aux EJB et a quelques frameworks un peu touffu (Struts 1).

Aujourd'hui le choix de framework est suffisamment bon pour faire plaisir à toutes les sensibilités.

Pour répondre en détail :

- côté lourdeur de codage, Java s'est largement amélioré avec l'utilisation des annotations et l'apparition de certains frameworks lights (Play, Grails etc...)
- côté consommation de ressources : je veux bien voir un benchmark qui prouve que Java serait plus consommateur à service rendu égal ^^ Ca me donne envie de faire un petit comparatif d'ailleurs entre Play et Php. Je vais m'y mettre ^^
- sur le côté libre, peux tu développer ? Jusqu'à preuve du contraire Java n'impose toujours aucune contrainte de droit sur les applications développées.

[sekaijin]

Ce qui veut dire par "Java n'est pas libre" cet que Oracle son propriétaire peut très bien demain comme il l'a fait avec Solaris décider de rendre JAVA payant et interdire son usage Or de ses propres produits.

Même si c'est peu probable. même si cela arrivait il y aurait une levée de bouclier. c'est un fait.
Ca ne se produira pas. l'équilibre des force est trop important pour Oracle. mais qui sait se que nous réserve l'avenir.

Le libre usage de JAVA est suspendu au bon vouloir d'Oracle.

A+JYT

[Ludalito]

Je suis surpris de lire que Php ne tient pas de grosses charges face a Java. Car mon impression est que pour faire tourner une appli Java, c'est déja tres demandeur de ressource meme si l'application n'est pas utilisée. Le ratio charge/utilisation ressources n'est donc pas linéaire.

Peutetre que Java demande plus de ressources au lancement, mais PHP gère mal la mémoire allouée, pour ne pas dire qu'il ne sait pas du tout la gérer (ok, la notion de garbage collector est arrivée avec PHP 5.3). Personnellement, j'ai une sainte horreur des "Fatal Error" de PHP comme le "allowed memory exhausted". On peut pas les attraper, ni les prévenir et c'est une plaie à débugger. Du coup, soit on joue la facilité et on modifie le 'memory_limit', soit l'administrateur interdit la manip et on tombe dans des considérations typiques au C++ pour chasser les fuites mémoires.

D'ailleurs pourquoi Facebook tourne en Php si ils considerent que c'est lent ?

Pour info, Facebook n'utilise PHP que pour son frontend et ils ont du réécrire le moteur pour améliorer les performances. C'est pas donné à tout le monde d'avoir des équipes dédiées au C/C++ et balèzes en algorithmie, pour éviter de refondre son frontend. Leur backend est en Java + Hadoop.
Personnellement, je préfère citer Google en exemple, avec ses Google Document et autres Google Wave, que je trouve inimaginables en PHP+Javascript.


On parle de lourdeur de codage en Java, je répondrai que la lourdeur est plutot la faute du développeur que du langage. Après, c'est beaucoup plus facile de refactorer en Java qu'en PHP, ne serait ce que parce que les IDE nous le permettent. Je trouverais vachement plus cronophage de refactorer une usine à gaz made in PHP, mm avec un IDE genre ZendStudio qui m'aura coûté un oeil.
De fait, je trouve qu'un développement fait avec Java est d'avantage pérenne que s'il est afit sous PHP.


J'orienterais mon choix entre PHP et Java suivant le dimensionnement du projet:
Si c'est un site statique ou sur un projet de qq semaines, ok pour PHP
Si le projet prend qq mois, ok pour PHP mais sous couvert d'un framework type Zend ou Symfony.
Si projet > 6 mois, je m'assurerais d'avoir un cadre de travail carré, avec des gens qui savent parler tests unitaires, motifs de conception, injection de dépendances, integration continue pour garder PHP.
Si on commence à parler d'interfaces dynamiques, c'est plutot le volume de fonctionnalités à développer en javascript qui me ferait réfléchir.
Si c'est un très gros site avec des centaines de connexions par jour, des besoins en temps d'accès rapides ou que sais-je, un compromis PHP-Java serait à étudier.
Dans tous les autres cas, je ne prendrais pas Java que si PHP m'est imposé.


l'avantage que je trouve à Java est de permettre au développeur de se concentrer plus facilement sur l'essentiel de la logique à implémenter. Il y a toujours un framework qui répond mieux que les autres à un besoin particulier. Alors que coté PHP, déja, le langage ne se suffit pas à lui même, ne serait ce que pour les IHM, et puis on doit réinventer la roue sans cesse pour encapsuler maladroitement telle ou telle fonctionnalité et enfin, il y a les erreurs fatales qu'on ne peut que subir.

[sekaijin]

Peutetre ...

à te lire je crois que tu connais particulièrement mal PHP

car question refactoring c'est l'outillage et non le langage qui est en cause et on trouve de très bons outils gratuit pour php qui le font (j'ai suffisamment refactoré du php pour le savoir)
pour ce qui est des fuites mémoire Java n'est pas mieux placé.
j'ai récemment explosé un serveur avec 36 Go de ram (oui Go)

comme tu le dit le développeur y est pour beaucoup et j'ajoute quelque soit le langage

une des force de java et une de ces difficulté est justement qu'il existe 30 framework pour faire ci ou ça et qu'il ne sont pas toujours très compatible avec un autre

je trouve qu'on perd beaucoup de temps à essayer de palier les problèmes relationnel des framework eux même.
Mais c'est surement du à une mauvaise connaissance de certain. il sont si nombreux.

inconvénient que je trouve à l'écosystème java (pas ua langage) c'est qui noie la logique applicative dans une cacophonie de composants.

alors on peut du coup se passer de tout un tas de framework et autre composant tout près. mais du coup les avantage de Java se réduisent car sa richesse n'est pas dans le langage mais dans l'écosystème qui l'entoure.

côté php c'est pour moi un peu pareil. soit tu te tape les chose à la mininee et tu ne bénéficie pas de la richesse du tout. soit tu en passe par des frameworks en tout genre et tu tombe sur les mêmes travers.

dans les deux cas c'est une question d'équilibre.
un point pour php dans les interaction entre framework c'est qu'il est faiblement typé. ça peut être un piège parfois et il faut être prudent
mais combien de temps je passe en java pour faire de la conversion de type !

par contre le cœur de php s'accompagne de lib compilées pour toute sorte de choses qui se retrouve dans la lib standard de java. et là je trouve que la lib java de base est mieux structuré plus propre que celle de php qui se traine encore trop de proc procédurale.

pour ce qui est de l'IHM deux chose soit tu as un IHM java et là php n'est clairement pas fait pour ça
soit tu as une webApp et perso je trouve que java est plutôt mal loti.

pour une appli dans le navigateur je ne trouve ni l'un ni l'autre à la hauteur. et de toute façon régénéré une page ou un morceau de page sur une simple action qui peut (et dois être faite chez le client) est un aberration. en 1996 dèjà sur les webApp dans le labo où je bossais j'avais intégré TCL dans le code HTML et j'éxécutais sur le poste du client tout ce qui n'a voir qu'avec l'IHM le serveur ne faisant que s'occuper du métier (logique et ressource) quand j'ai vu tout ce concentré sur les serveur j'ai crié à l'hérésie.
on avait tout mis sur le poste client qui était devenu ingérable avec les client lourd et le serveur qui ne s'occupait que des données qu'on à fini par demander au serveur de modifier les pixel de l'écran de chaque utilisateur.

aujourd'hui on redispatche intelligemment (enfin on essai) les fonction. l'IHM au client le métier au serveur.
à moins de passer à jnlp ou à ces applet Java je ne trouve as java des plus adapté.
Php ne fait pas beaucoup mieux trop encré dans la notion de webapp ou le serveur fait tout.

du coup Javascript qui maintenant est mieux supporté par les navigateur se présente comme une alternative. mais c'est une tout autre approche qu'il faut adopter. et on vos déjà les vieux travers revenir.
comme ouvrir un connexion SQL depuis son navigateur. ainsi on revient au client serveur avec tout les pb que cela pose.
perso je ne l'utilise que pour l'IHM dans mon approche MVC il gère la vue et le contrôleur le Métier côté javascript est un proxy qui fait appel à des service sur le serveur.
et pas plus.
dans ce contexte Java est robuste efficace et lourd. Php est rapide, vites mis en œuvre léger, et moins facile à faire monter en charge (énorme charge chez moi)

le plus souvent j'utilise SOAP, Rest ou Json-RPC entre le client js et le serveur php/java

l'avantage étant que lon peut changer de techno serveur (par exemple d'un proto à un grosse appli) sans rien changer au client si on respecte l'interface de service.

pour moi java ne se suffit pas à lui-même il lui faut toujours tout un tas de lib de framework et php est exactement dans la même position.
c'est vrai pour tout les langages.
ce qui peu éventuellement faire la différence c'est les librairies standard qui vont avec le langage.
C++ par exemple sans aucune librairie et tu ne peux même pas afficher un truc dans ta console. pour ça il te faut la STL c'est pareil en java.

Bref les manque que tu décris son pour moi plus un pb de connaissance du l'écosystème PHP que de réel manques. quelqu'un qui connais mal celui de java va lui faire les même reproche.

A+JYT

[Khalfe]

Bonjour à tous et à toutes;

J'ai besoin de votre, je suis un debutant en php j'ai réalisé un site web simple et je voudrais savoire comment réaliser un generateur de pdf après avoire valider la saisie d'un formulaire, j'ai fais pas mal des recherche mais je n'y arrive pas, j'ai essayé fpdf je n'arrive pas comprendre cmt l'implemanter ds mon code php, peut être je suis pas ds le bon forum mais vue votre debat, c'est un debat des pro donc je lance un appel d'aide à vous tous svp!!!

[benwit]

Pour le refactoring, je ne suis pas d'accord. Vu que java est fortement typé, les outils pourront faire beaucoup plus de choses qu'en php.
De meme pour la complétion (proposer uniquement ce qui est possible).
De toute facon, le débat est dans ces deux cas plus lié au typage.

[Gordin]

je prefere PHP pour sa facilité d'appretissage ou sa prise en main rapide.

[smarties]

J'ai programmé pendant plusieurs années en PHP, l'apprentissage est rapide, il y a de la documentation mais le manque de données typées est embêtant à mon gout.

Depuis quelques mois je suis passé au JEE avec le framework Spring et voici mon constat :
- l'apprentissage est long ;
- tout est objet et c'est bien pour avoir une un modèle MVC ;
- Maven est très pratique pour gérer ses dépendances ;
- l'IDE Eclipse gère très bien JAVA, je n'ai pas encore vu d'équivalent en PHP ;
- les scripts PHP sont limités en temps d'exécution, en JAVA il y a des crons disponibles.