PHP s’imposera sur les serveurs face à Java et .NET

Si on regarde les codes qui composent ces benchmarks, il y en a tout de même un sacré paquet que personne n'écrit jamais, on vous demande souvent d'écrire des fractales ou de faire des réduction de matrices dans le code de vos applications PHP? Si c'est pour dire que le C est plus rapide que java qui est plus rapide que PHP quand il s'agit de faire de l'arithmétique sur les tableaux, merci mais on s'en doutait un peu. Mais ce n'est pas vraiment le cas d'utilisation le plus réaliste pour une technologie orientée web.

D'autant plus que pour passablement de sites, ce n'est pas performance brute du langage qui est en jeu, si vous commencez à faire des requêtes BDD ou interroger des services, le gain ou la perte d'un langage à l'autre sera bien souvent un vague petit % du temps passé dans des attentes "incompressibles".

Java lourd et lent, bon ben "lent" c'est faux, c'est un préjugé que java se traîne à cause d'API comme swing qui étaient salement à la ramasse il y a 10 ans. Par contre lourd, si on parle de lourdeur dans le sens difficile à mettre en oeuvre, je suis assez d'accord.
Je trouve beaucoup plus commode d'utiliser PHP pour un site simple que java. Par rapport à ce que ça demande comme compréhension des serveurs d'application et de la plateforme, y'a vraiment pas photo. A côté de 2 ou 3 scripts PHP prêt à uploader sur un serveur mutualisé, un tomcat + un war contenant 2 ou 3 jsp avec les dépendances JDBC et le reste qui vous demande quasiment un VPS, ça fait usine à gaz.
Après passée une certaine complexité, il y a d'autres inconvénients qui compensent l'effort de mise en oeuvre initial...

Citation:

---

Envoyé par fxrobin

Malheureusement tu me fais dire ce que je n'ai pas dit.

---

Mea culpa, ce n'était pas le but.
Le but était de montrer que ton argument avait un contre argument très simple et donnait l'impression que les améliorations de JAVA avaient permis le rattrapage si ce n'est le dépassement des autres.

Et mon post soulignait donc le fait que les autres aussi se sont améliorés également pendant ce laps de temps. Que l'écart se sois rétréci ou pas, je n'en ai aucune idée cela dis, et pour être franc, ça ne m'intéresse pas, ça fait quelques temps que j'ai compris qu'un langage rapide n'implique pas un programme rapide, seulement qu'il y contribue. Si je n'apprécie toujours pas vraiment les langages de vm, c'est pour d'autres raisons, dont certaines sûrement un peu subjectives qui ne méritent donc pas d'être citées :mrgreen:

Pour ce qui est des benchmark, ils montrent ce que tout le monde sait, j'ai envie de dire (quoique, peut-être que je généralise trop) :
Vlc > Vlmv > Vli

(Vlc: Vitesse langage compilé; Vlmv: Vitesse langage machine virtuelle; Vli: Vitesse langage interprété)

Par ailleurs, ces benchmark n'ont pas montré l'évidence, qui est l'amélioration des perf dans le temps, et n'ont pas été cités dans le même post. Navré, mais je ne suis pas capable de me rappeler l'auteur de chaque argument sur 5 pages de post :D
Re mea-culpa donc.

Et encore pour les bench... je ne m'y connaît malheureusement pas assez pour être capable d'interpréter correctement les résultats, sachant qu'en général les bench vont prendre en compte des choses pas forcément utiles mais qui sont censées utiliser à fond un point précis de la machine:
_ accès fichier
_ accès réseau
_ allocation
mais un programme normal, même s'il fera un usage intensif d'une ressource ou l'autre de temps à autre, ne le fera pas en permanence, sauf erreur de ma part.
En plus, ici, on parle de sites web, ou le plus gros est fait par la base de données...
Accessoirement, un benchmark n'est utile que si on en lit les divers codes sources, et je doute que beaucoup le fassent.

C'est pour tous ces points ainsi que celui de l'attaque frontale de ton post que j'ai utilisé la formule "sauf ton respect", et rien d'autre :P (d'ailleurs, superbe renvoi, j'apprécie le style :ccool:)

Citation:

---

Envoyé par _skip

D'autant plus que pour passablement de sites, ce n'est pas performance brute du langage qui est en jeu, si vous commencez à faire des requêtes BDD ou interroger des services, le gain ou la perte d'un langage à l'autre sera bien souvent un vague petit % du temps passé dans des attentes "incompressibles".

---

Ça dépend.

Si on fait systématiquement des requêtes sur la BDD à chaque fois, oui, les performance dépendront quasi uniquement du temps de réponse de la BDD.

Par contre, si on souhaite optimiser en mettant en cache sur le serveur certaines informations et ne faire d'appels en BDD que lorsque certaines informations ne se trouvent pas en cache (afin de réduire le nombre d'appels ainsi que le nombre de connections concurrentes (et donc limiter le risque de lock contention)), ça fait une énorme différence !

C'est d'ailleurs ce à quoi je faisais référence dans mon premier post sur ce thread (et expliqué un peu plus en détails dans le deuxième post).


Maintenant, c'est vrai que tous les projets n'ont pas forcément ce genre de besoin. Par contre si on veut mettre en place (par exemple) un web service capable de répondre à un grand nombre de requêtes Ajax en même temps, ça peut être pas mal d'optimiser ses accès à la BDD... :?

Donc :
- non, ce n'est pas ce genre de problématique que les benchmarks précédents tentent de mettre en avant
Mais :
- non, on ne peut pas dire qu'on se fiche totalement des capacités d'un langage parce que c'est la BDD qui fait tout le boulot (au contraire, si les programmeurs peuvent éviter de systématiquement tout déléguer à la BDD, les DBA vous remercieront ;))

Ce qu'il est important de noter ici c'est que même dans ton exemple, le point central de l'optimisation est l'utilisation d'un cache en lieu et place d'une opération redondante X fois plus coûteuse.
Ce que je voulais mettre en évidence, c'est que la vitesse dépend souvent plus du travail réellement effectué que de la vitesse brute du langage mesurée en combien de nanosecondes on met à accéder à un index d'un tableau. Mais oui il y a des langages qui se prêtent plus que d'autres à certaines opérations.

Après tout ce qu'on peut dire, c'est que sur ce point la nature stateless de PHP n'encourage pas ce genre de pratique (oui je sais y'a memcached) et que l'écosystème java est bien fourni en implémentation de cache en plus de permettre de stocker simplement des infos dans une simple hashmap côté serveur entre les requêtes.
Mais il en reste pas moins que les opérations effectuées ont plus de chance d'être un bottleneck que le langage, après il y a les outils à disposition pour les éviter qui entrent en ligne.

Citation:

---

Envoyé par Freem

Mea culpa, ce n'était pas le but.
C'est pour tous ces points ainsi que celui de l'attaque frontale de ton post que j'ai utilisé la formule "sauf ton respect", et rien d'autre :P (d'ailleurs, superbe renvoi, j'apprécie le style :ccool:)

---

Surtout qu'en plus, on est globalement "presque" du même avis ;):ccool:

Citation:

---

Envoyé par _skip

... la vitesse dépend souvent plus du travail réellement effectué que de la vitesse brute du langage ...

---

A pondérer ... mais je l'admet pour des applications bien particulières a très fort trafic. Pas inintéressant de voir de fortes différences entre plusieurs framework PHP, photon cité plus haut s'y est amusé: http://www.photon-project.com/doc/performance pour un simple "Hello World" si j'ai tout compris (d'ailleurs Zope a l'air plutôt mal placé ;)). Selon les framework, probablement plus ou moins de code et, en PHP, ça fait vite une nette différence.

Pour avoir travaillé a l'optimisation de solutions Java pour le mobile, quand tu as du cache, des pools un peu partout et autres subtilités, tu en es rendu a calculer le coût de l'overhead http, d'un connecteur mod_jk, mod_proxy ... d'une techno. de templating (cher!), d'un appel web service (très cher si plain XML!!!) ... a jouer du kill -3 pour analyser les goulots d'étranglements et à chasser au mieux les millisecondes (bon jusqu'à ce qu'un ahuri te balance une requête de la mort dans le code ...). Il n'y a que ceux qui n'ont jamais réellement affronté le problème pour croire qu'il suffit de rajouter des serveurs pour absorber du trafic.

C'est là où j'ai quand même un doute sur le post initial parlant justement d'applications pour mobile. Dans ce monde là, si on a du succès, on est vite a des centaines, voir des milliers de connexions simultanées a certaines heures, selon les objectifs de trafic, je ferais en ce qui me concerne une étude sérieuse sur les technos. sur lesquelles s'appuyer. Comme je le disais plus haut, un ratio de 10 a 100 en coûts de hosting (et d'exploitation!) peut rapidement justifier d'investir au départ.

Allez, j'ai envie de remettre un pièce : pourquoi PHP a eu (a toujours) autant d'adeptes ?

Mon analyse (peut-être très digne d'un bistro, mais j'assume) :

Ce n'est pas un choix de développeurs, mais un choix d'hébergeurs.

En effet les hébergeurs, fin des années 1990, offrent des espaces de publications gratuits à leurs abonnés pour mettre en ligne des pages statiques, voire des sites (la grande époque des FRAMES en HTML). Par la suite, ces hébergeurs offriront à moindre coût (pour l'hébergeur) une capacité dynamique (gestion formulaires, base de données, etc.) via un ou plusieurs langage de programmation.

C'est là que PHP rentre en jeux (à l'époque PHP signifie encore Personal Home Pages au passage) car PHP est peu consommateur de ressources (et oui c'est LIGHT en mémoire) peu consommateur en espace disque, gratuit, pluggable directement sur leur infrastructure de l'époque APACHE et finalement peu gourmand en CPU pour ce qu'on lui demande de faire.

A part PERL, peu d'autres langages pourront rivaliser avec une telle facilité d'installation / administration pour l'hébergeur qui se retrouve ainsi à proposer uniquement cette plateforme (en gratuit). Comparé à JAVA, pourtant au même niveau avec JSP/Servlet, mais nécessitant l'installation de plusieurs soft, de connecteurs, d'une JVM ... le choix de l'hébergeur est vite fait.

Et voilà comment des milliers d'apprentis "développeurs" commencent à apprendre PHP (souvent par recopie / adaptation de code existant d'ailleurs) : par manque de concurrence et par le choix imposé par l'hébergeur (PHP / MySQL (myisam beurk)) sinon rien.

Le langage PHP heureusement a évolué même si la partie objet est toujours largement sous utilisée, à mon humble avis, au profit d'un PHP procédural. Finalement un bon vieux PHP 4 aurait suffit (aux API différentes prêt). D'ailleurs il est devenu "PHP Hypertext Preprocessor" au passage.

Donc voilà, c'est l'héritage d'un "non-choix" ou plutôt du choix des "hébergeurs".

Enfin, petite digression par rapport au sujet de ce message (rappel : pourquoi PHP a eu autant d'adeptes ?) d'un côté purement professionnel, l'usage de la base de données ORACLE est souvent de mise. Or la couche OCI8, réalisée par ZEND, n'est pas certifiée par ORACLE. Il m'est arrivé, lors d'audit d'applications PHP / ORACLE que Oracle rejette toute analyse de l'infrastructure à cause de cela alors que ce n'est biensûr pas le cas avec le Driver JDBC Thin, réalisé par ORACLE, dans le monde JAVA. Ce dernier point, à mes yeux, est presque rédibitoire, quand on est "contraint" d'utiliser ORACLE en base de données.

Citation:

---

Envoyé par _skip

Ce qu'il est important de noter ici c'est que même dans ton exemple, le point central de l'optimisation est l'utilisation d'un cache en lieu et place d'une opération redondante X fois plus coûteuse.
Ce que je voulais mettre en évidence, c'est que la vitesse dépend souvent plus du travail réellement effectué que de la vitesse brute du langage mesurée en combien de nanosecondes on met à accéder à un index d'un tableau. Mais oui il y a des langages qui se prêtent plus que d'autres à certaines opérations.

---

Oui, mais le point de départ de cette discussion, c'est un responsable de Zend qui affirme que "PHP serait plus adapté aux évolutions liées à la mobilité", surtout concernant ce qu'il appelle les « cloud-connected mobile apps ».

Or le principe de ce type d'application, c'est :
- une interface web côté client qui se connecte à :
- un web service qui doit répondre rapidement à des requêtes Ajax

Dans cette histoire :
- PHP n'intervient absolument pas côté client
- même si c'est possible de faire un web service en PHP, ça ne sera absolument pas adapté pour des raisons de performances inhérentes au langage

Alors franchement, le responsable Zend peut bien affirmer que son langage est le meilleur et que les autres c'est nul, mais j'émets de sérieux doutes...

Citation:

---

Envoyé par pcaboche

Alors franchement, le responsable Zend peut bien affirmer que son langage est le meilleur et que les autres c'est nul, mais j'émets de sérieux doutes...

---

Sur le point des services web en mobile, il pourra toujours te dire qu'un serveur PHP avec cache bytecode, puis en renfort du memcached et du load balancer ça va déjà supporter pas mal.

Tu ajoutes le fait que PHP est facile à mettre en oeuvre, que les compétences, les experts (de tout niveaux), les hébergeurs et les prestataires sont légions (plus qu'en java de mon expérience), il a certainement des arguments en sa faveur ce petit PHP.

J'ai beau lui reconnaître un sacré paquet de défauts, encore dernièrement je me suis fait avoir par son opérateur "==" à la con qui confond Null et tableau vide, cependant je ne peux pas nier qu'il va certainement avoir une place de choix. Pas forcément par sa qualité mais par sa popularité et l'abondance de l'offre.

Après pour ce qui est des autres technos vues par Gutman, ben c'est un simple troll commercial. Les gens qui aiment pas .Net ils disent quoi en général? "Bouh c'est windows only, windows ça coûte trop cher à héberger", ceux qui aiment pas java? "bahh j2ee c'est l'usine à gaz, ça bouffe trop de mémoire, c'est lent, tous ces frameworks c'est indémerdable". Pour ça il a pas été cherché bien loin.

Est-ce que PHP est le meilleur langage? (Bof)... Est-ce que mysql est le meilleur SGBD? (haha c'est très drôle!). Pourtant c'est ça l'offre type de 90% des hébergeurs. Tous les prestataires connaissent ces technos, souvent elles suffisent, quand elles ne suffisent pas ben on prend un memcache, un reverse proxy, un balanceur, hop on fout tout ça en tas, 4 ou 5 tours avec du gros scotch et voilà généralement ça suffit...
En résumé, je pense que PHP aura clairement sa place dans le mobile et le web service, pas parce qu'il est le plus adapté, pas parce qu'il offre les meilleures performances brutes mais simplement parce qu'il est là, bien installé et que son principal concurrent a une réputation d'usine à gaz avec des ressources plus rares et plus chères.

Citation:

---

Envoyé par _skip

hop on fout tout ça en tas, 4 ou 5 tours avec du gros scotch et voilà généralement ça suffit...

---

Quand tu parles de faire tout tenir avec du gros scotch, ça m'a immédiatement fait penser à ça :
http://www.commitstrip.com/en/2012/05/28/langages-irl/
:lol:

Comme quoi, beaucoup sont d'accord sur la notion de "ça tient avec du scotch"... :P


Sinon, je suis d'accord avec toi sur les avantages du PHP :
- c'est simple à apprendre
- c'est simple à mettre en place
- il y a beaucoup d'offres (en termes d'hébergement ou de profils)
- la plupart du temps, cela suffit (ou on peut trouver des solutions style memcache)

Ce que je trouve beaucoup moins bien, c'est que certains membres de sa communauté ont tendance à regarder les autres technos avec énormément de condescendence (le discours de Gutmans fait office de caricature à ce niveau là).

D'autres, en revanche, prennent PHP pour ce qu'il est : c'est loin d'être le meilleur langage du monde, il souffre d'énormément de défauts, mais il permet néanmoins de faire des choses intéressantes à moindre coût.


Indépendemment de cela, la notion d' "expert PHP" m'a toujours laissé assez perplexe. Sachant que le but de PHP est d'être simple à apprendre et mettre en place, et que le but des frameworks et CMS est d'être plus productif, je trouve quelque peu ironique que des outils censés simplifier la vie requièrent certaine une expertise (et que visiblement, aucune de ces connaissances ne soient transférables).

Au final, qu'est-ce qu'on appelle un "expert PHP" ? Quelqu'un qui est capable de nommer différents frameworks ou CMS et de dire ce qui le différencie ? Quelqu'un qui connait suffisamment bien un framework ou CMS pour ne pas avoir à chercher la soluce sur internet ? Quelqu'un qui connait tous les comportements propres de chaque version du langage depuis PHP 3 ? (ce qui, au passage, fait un paquet de changements...). Quelqu'un qui bricole des scripts (ou réutilise plus ou moins les mêmes templates) depuis un certain nombre d'années ? Ou juste quelqu'un qui a payé sa certif ?

Citation:

---

Envoyé par pcaboche

D'autres, en revanche, prennent PHP pour ce qu'il est : c'est loin d'être le meilleur langage du monde, il souffre d'énormément de défauts, mais il permet néanmoins de faire des choses intéressantes à moindre coût.

---

C'est tout à fait ma ligne, je reconnais les services rendus par cette techno et sa simplicité de mise en oeuvre. Par contre si je commence à dire que c'est le meilleur truc que j'ai vu passé... c'est que je me suis pris la foudre :mouarf:.

Citation:

---

Indépendemment de cela, la notion d' "expert PHP" m'a toujours laissé assez perplexe. Sachant que le but de PHP est d'être simple à apprendre et mettre en place, et que le but des frameworks et CMS est d'être plus productif, je trouve quelque peu ironique que des outils censés simplifier la vie requièrent certaine une expertise (et que visiblement, aucune de ces connaissances ne soient transférables).

---

C'est un peu ce que je signalais dans mon premier post il y a quelques pages, php semble suivre la trace de Java sur le plan des frameworks et ça n'a pas que du bon.

Citation:

---

Au final, qu'est-ce qu'on appelle un "expert PHP" ? Quelqu'un qui est capable de nommer différents frameworks ou CMS et de dire ce qui le différencie ? Quelqu'un qui connait suffisamment bien un framework ou CMS pour ne pas avoir à chercher la soluce sur internet ? Quelqu'un qui connait tous les comportements propres de chaque version du langage depuis PHP 3 ? (ce qui, au passage, fait un paquet de changements...). Quelqu'un qui bricole des scripts (ou réutilise plus ou moins les mêmes templates) depuis un certain nombre d'années ? Ou juste quelqu'un qui a payé sa certif ?

---

Ah ça, dans ce métier, y'a vraiment de tout... Puisque je développe du middleware, je travaille avec beaucoup de prestataires de solutions, y compris de très connus et on voit vraiment le pire et le meilleur (par ordre constaté d'importance :mrgreen:).

Puis bon sans vouloir dévaloriser les certifications, c'est pas non plus une science absolue. Ma copine a passé une certification pour un outil de reporting BI très connu, l'examen consistait en gros à envoyer un chèque puis apprendre par coeur une série de questions en QCM portant pour certaines sur du vocabulaire. Mais bon ça fait bien quand tu es consultant et que ton patron montre ton CV à ses clients.

Citation:

---

Envoyé par fxrobin

c'est bien la technologie EJB.

---

EJB c'est pas une technologie, c'est une convention. Tout comme JEE qui n'est pas un framework et qu'on compare à PHP qui n'est pas non plus un Framework.

On parle de perfs en faisant des benchmarks PHP vs Java, comme si les applis web dépendaient vraiment de la résolution d'un algo mathématique bidon.

Au bout d'un moment, si les Javaïstes pensent que PHP est une bouse grand bien leur fasse. Moi ce que je vois, c'est qu'un simple CRUD me faut 1/4h pour le mettre en place avec Symfony 2, et 1 journée avec JEE et que la quantité de code double entre les 2.

Les questions de perf's, au bout d'un moment avec des solutions style Amazon ça n'est plus vraiment un problème que ce soit en terme de perfs ou de coût.

J'ai fait du Symfony2, du JEE et de l'asp.net MVC 4 cette année, de mon point de vue JEE est vraiment la pire solution au monde pour faire du web, l'asp.net MVC 4 est clairement pas assez documenté mais l'IDE est vraiment génial et le C# vraiment "élégant". Symfony 2 est ce qu'il manquait au PHP pour vraiment décoller, avec composer en package Manager et PHPUnit/Atoum/Travis/Jenkins pour envoyer du paté.

Sans parler de Facebook, Dailymotion, Youporn, Clubic, Wikipedia... tous ces sites sont fait en PHP et ont résolu leurs problèmes de perf's (il semblerait ?). A mon niveau ça me suffit pour me lancer avec un bon framework MVC en PHP.

Après je trouve le gars de Zend hilarant, surtout quand je vois la tête de Zend Framework 1 & celle de Zend Framework 2 : je comprends nettement pourquoi en 2007 certains sont parti faire du Java.


Bref, du troll comme on l'aime :)

Citation:

---

Envoyé par ange16

...Moi ce que je vois, c'est qu'un simple CRUD me faut 1/4h pour le mettre en place avec Symfony 2, et 1 journée avec JEE et que la quantité de code double entre les 2...

---

J2EE n'est pas Java, si tu avais utilisé Grails/Spring par exemple, tu n'aurais pas mis plus de temps pour faire ton CRUD et si tu avais "investi" en Java, tu aurais avec tes propres outils été capable d'en faire de même sur une base de facto parfaitement adapté a ton secteur/métier (ce qui ne sera pas le cas d'un framework "standard"). Beaucoup de "javaistes" ont décidé de ne pas utiliser J2EE en raison de son coté "usine a gaz" (maintenant tu peux aussi, en interne, travailler sur des sur couches performantes).

Il n'en demeure pas moins comme j'ai du le dire plus haut, qu'ajouter "des machines en cluster" n'est pas toujours la réponse adaptée quand ça fait exploser tes coûts d'exploitation. On en parle dans ce thread mais citer facebook par exemple est inadapté puisqu'ils ont résolu leurs "problèmes de perf" avec du C (drivers) et du Java (cassandra) :-)

Mais a me relire, je m'aperçois que je me répète sur ce thread ;)

Il faut quand même admettre que le parcours typique du programmeur java qui commençait le web il y a quelques années, c'était de partir sur du JSF 1 (techno standard s'il en est), de découvrir en même temps les servlets, les serveurs d'application, JDBC et consors.
Puis ensuite se rendre compte que côté composition de page il n'existait rien, hop on rajoute facelets, difficile de gérer une identification simple, go écrire des intercepteurs de lifecycle JSF de niveau gourou, JDBC un peu encombrant? Hop va chercher du EJB ou du hibernate, et là c'est le clou manquant dans le cercueil.

Par conséquent, je ne reproche à personne qui découvre le monde des applications web en java avec la stack "standard" de trouver cela horrible, insensé de difficulté, surtout avec un besoin qui ne suit pas.
Mais il existe un grand paquet d'alternative, quelqu'un a cité grails? Il y a play aussi, wicket, stripes et d'autres qui ont été faits par des gens qui ne savent à peu près quels sont les besoins et les enjeux du développement de site web (car quand je vois JSF, honnêtement je me pose la question de qui sont les génies qui ont pondu cette spec).

Mais il y a un autre java, juger java pour le web en n'ayant essayé que JSF, ce n'est pas suffisant.

Citation:

---

Envoyé par _skip

...Mais il y a un autre java, juger java pour le web en n'ayant essayé que JSF, ce n'est pas suffisant.

---

L'ayant vécu de près puisque je fais "du web" depuis le début des années 2000, toutes les technologies Java apparues depuis (servlets, JSF, MVC, web services ...) sont aussi des approches de développement censées répondre aux problèmes propres au développement "web"et plus généralement répondant aux évolutions de l'informatique du moment. Java a été parfois précurseur, parfois suiveur ... les technologies utilisées, rodées montrant leurs qualités, leurs défauts, retour d'expérience sur lesquels se sont appuyés les autres framework et autres langages.

Bref, il a participé des progrès du développement informatique pour répondre a de nouveaux problèmes jusque dans ses "erreurs" qui ont permis aux autres de ne pas les répéter 8-) Les frameworks comme Symfony en PHP n'ont fait que combler les carences sur ce type d'outil en PHP.

Quelque soit le domaine, il est toujours plus facile de reprendre tout a plat en démarrant après les autres. Il est aussi facile de pointer les erreurs d'une technologie massivement utilisée, attendons quelques années d'utilisation extensive du PHP et "ses framework", nous verrons logiquement apparaitre ses carences et ses défauts, déjà, la migration Symfony 2 pose de sérieux problèmes a ceux qui se sont appuyés sur ce framework. Venant du "monde java", je reste assez ahuri de voir les dégâts provoqués par les migrations de certaines "technologies" quand on sait ce que ça peut couter dans une entreprise.

Citation:

---

Envoyé par rimram31

Quelque soit le domaine, il est toujours plus facile de reprendre tout a plat en démarrant après les autres. Il est aussi facile de pointer les erreurs d'une technologie massivement utilisée, attendons quelques années d'utilisation extensive du PHP et "ses framework", nous verrons logiquement apparaitre ses carences et ses défauts, déjà, la migration Symfony 2 pose de sérieux problèmes a ceux qui se sont appuyés sur ce framework. Venant du "monde java", je reste assez ahuri de voir les dégâts provoqués par les migrations de certaines "technologies" quand on sait ce que ça peut couter dans une entreprise.

---

Tu as raison de façon générale on est toujours plus malin après mais là je me permet un petit troll comme on les aime. Il est quand même arrivé que les ptits gars de chez SUN se vautrent en arrivant (largement) après les autres.
Si tu prends JSF, il arrivait à un moment ou struts et asp.net étaient largement adoptés. Eux ils arrivent des années après avec cette daube, je m'excuse mais c'est critiquable.
Tout comme tu as JDO ou prenons plutôt JPA (une spec seulement), arrivé après hibernate et loin d'être à la hauteur à ce moment-là.

Donc SUN et ces super specs J2ee, merci. Déjà en 2008 un type écrivait sur un blog qu'il y a presque pas un serveur d'application qui n'avait pas eu droit à 10 versions majeures en 10 ans et que les applis basées sur des frameworks tiers avaient une plus grande chance d'être portable que celles basées sur les stacks standards.

En gros, je veux juste souligner qu'il vaut aussi la peine de s'éloigner du sentier tracé par SUN. Le problème des migrations, il est partout.

Citation:

---

Envoyé par _skip

...Donc SUN et ces super specs...

---

Très bien au début (jdbc, j2se ...) APIs qui allait plutôt a l'essentiel, vrai que c'est parti complètement en sucette et que Sun s'est évertué a faire très compliqué quand on pouvait faire simple :-) Maintenant pour avoir potassé un peu Symfony, la simplicité, c'est pas leur truc non plus, quand tu entres un peu dans les détails, j'ai revécu mes maux de têtes que j'avais eu avec struts ...

Souci de migration, oui, encore que, mais au niveau d'une équipe, le coût essentiel est celui de l'acquisition de la technologie, quand elle change trop fréquemment, c'est rédhibitoire. Pour avoir utilisé Grails par exemple a ses débuts, insupportable quand le moindre bout de code ne tient plus la route d'une version a l'autre (quand il en sort 3 ou 4 en une seule année !!!)

Citation:

---

Envoyé par ange16

Moi ce que je vois, c'est qu'un simple CRUD me faut 1/4h pour le mettre en place avec Symfony 2, et 1 journée avec JEE et que la quantité de code double entre les 2.

---

et bien moi il me faut 15 secondes pour faire un CRUD en JAVA :

Code:

---

1 2 3 4 5 6 7

@Stateless class MonCrudMetier extends AbstractCrud <Metier> { // oui tu ne rêves pas, il n'y a pas de ligne de code dans cette classe. // c'est l'héritage et le Generics qui fait tout. }

---

et c'est fini car AbstractCrud fait déjà toutes les opérations CRUD et avec les "generics", cet EJB Session Stateless est opérationnel en 15 secondes.

Après que AbstractCrud repose sur du JDBC pur ou du JPA (j'ai les deux versions) ... tu choisis ce que tu veux.

Bref, ce que tu donnes comme exemple ne tient pas. ;)

Citation:

---

Envoyé par ange16

EJB c'est pas une technologie, c'est une convention.

---

Si tu pinailles sur les termes à mon égard, sache que les EJB sont régis par une spécification ratifiée en JSR. Ce qui est bien plus qu'une simple convention.

Citation:

---

Envoyé par fxrobin

Si tu pinailles sur les termes à mon égard, sache que les EJB sont régis par une spécification ratifiée en JSR. Ce qui est bien plus qu'une simple convention.

---

Avec si je ne m'abuse une API publique, et, principe d'une JSR plusieurs implémentations disponibles donc une meilleure indépendance d'un fournisseur, a priori, plus de précautions pour les évolutions de version. A titre de comparaison, Symfony reste dépendant des initiatives d'une seule société, mais vrai aussi pour d'autres framework y compris en Java (spring ...).

Mais ton exemple illustre assez bien mon propos, on peut regretter les "errements" de la spécification EJB dans ses différentes versions, très franchement, nous nous sommes essayés a l'époque a la V1, usine a gaz inutilisable et on doit se réjouir qu'elle ait été "secouée" par d'autres framework mais elle a participé comme d'autres, a l'évolution des "pratiques de programmation" se traduisant par les différents framework.

Edit: Et en me relisant, je me dis qu'il est inapproprié de comparer EJB a des frameworks comme Symfony, la spécification couvrant bien d'autres besoins que les accès database.