Zend : PHP s'imposera sur les serveurs face à Java et .NET

Les rubriques (actu, forums, tutos) de Développez
Tags
Réseaux sociaux


 Discussion forum

Le , par Gordon Fowler, Chroniqueur Actualités
Andi Gutmans, un des responsables la société qui édite l’EDI Zend Studio, a travaillé au développement du PHP depuis 1997. Ce qui en fait un des meilleurs observateurs de l’évolution de la technologie alors que l’on parle de plus en plus d’un PHP 5.5.

Même s’il n’y a pas de feuille de route officielle, Andi Gutmans assure que la communauté travaille activement sur la prochaine version du langage de scripts. La 5.5 ? Pas sûr. Ce pourrait en effet bien être une 6.0. « La décision sera prise en fonction des fonctionnalités que l’on ajoutera » explique Andi Gutmans à nos confrères de VentureBeat sans fermer aucune porte.

En fait, peu importe le numéro. L’essentiel est ailleurs. PHP 5.5 ou PHP 6.0, pour lui une chose est sûre : la mobilité et le tactile vont impacter le langage « parce que ce nouveau paradigme a des implications aussi bien côté client que côté serveur ». Ce qu’il résume avec la formule de « cloud-connected mobile apps » (« les applications mobiles connectées au Cloud ») qui montre bien les deux pendants de la même évolution.

Or, à en croire Andi Gutmans, la manière actuelle de gérer le côté serveur aurait grand besoin de s’adapter.

« L’agilité, la rapidité et l’interopérabilité dont vous avez besoin dans ce type de développement donnent une opportunité au PHP », analyse-t-il. Avant de passer en revue les technologies concurrentes actuelles.

.NET ? « Trop Windows-centré dans un univers Cloud qui ne l’est pas ».

Ruby ? « Un nouvel entrant [qui] n’a pas le support professionnel que nous avons construit depuis des années autour du PHP ».

Java ? « Trop lourd et trop lent ». Même si « vous aurez toujours du Java pour le back-end ».

Bref, PHP serait le bon cheval dans cette course au Cloud liée à la mobilité.

Quant au développement des applications clientes, Andi Gutmans parie que les technologies Webs s'imposeront. « A mesure que la mobilité se démocratise, vous allez avoir une fragmentation grandissante et, de telle sorte que le Web sera de plus en plus la plateforme [qui devra unifier tout cela] ».

Tous les acteurs n’iraient cependant pas dans ce sens de l'ouverture et de l’interopérabilité. Surtout un.

« Apple ne nous permet pas aujourd’hui de faire des applications mobiles de la meilleure manière qui soit, constate-t-il, ils ne nous donnent pas accès aux mêmes APIs que celles que vous pouvez utiliser sur Android ».

L’expert en PHP ne croit pas aux explications d’Apple sur la sécurité pour justifier cette fermeture. « Je pense qu’ils essayent de mettre des bâtons dans les roues […] pour protéger l’écosystème de l’objective-C ».

Mais Andi Gutmans n'est pas du type rancunier. De son aveu même il reste un « grand fan des produits Apple »(sic) avec son iPhone et son iPad. Et bientôt son nouvel iPad mini.

Source

Et vous ?

Quelle technologie vous semble la plus adaptée pour répondre aux exigences de la mobilité côté serveur ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de pcaboche pcaboche
http://www.developpez.com
Rédacteur
le 08/11/2012 11:57
Citation Envoyé par _skip  Voir le message
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/


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

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 ?
Avatar de _skip _skip
http://www.developpez.com
Expert Confirmé Sénior
le 08/11/2012 13:25
Citation Envoyé par pcaboche  Voir le message
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 .

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.

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 ).

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.
Avatar de ange16 ange16
http://www.developpez.com

le 07/03/2013 23:35
Citation Envoyé par fxrobin  Voir le message
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
Avatar de rimram31 rimram31
http://www.developpez.com
Membre confirmé
le 10/03/2013 16:03
Citation Envoyé par ange16  Voir le message
...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
Avatar de _skip _skip
http://www.developpez.com
Expert Confirmé Sénior
le 10/03/2013 19:54
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.
Avatar de rimram31 rimram31
http://www.developpez.com
Membre confirmé
le 11/03/2013 13:17
Citation Envoyé par _skip  Voir le message
...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 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.
Avatar de _skip _skip
http://www.developpez.com
Expert Confirmé Sénior
le 11/03/2013 14:52
Citation Envoyé par rimram31  Voir le message
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.
Avatar de rimram31 rimram31
http://www.developpez.com
Membre confirmé
le 11/03/2013 19:32
Citation Envoyé par _skip  Voir le message
...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 !!!)
Avatar de fxrobin fxrobin
http://www.developpez.com
Membre Expert
le 12/03/2013 8:42
Citation Envoyé par ange16  Voir le message
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.
Avatar de fxrobin fxrobin
http://www.developpez.com
Membre Expert
le 12/03/2013 8:49
Citation Envoyé par ange16  Voir le message
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.
Avatar de rimram31 rimram31
http://www.developpez.com
Membre confirmé
le 12/03/2013 11:50
Citation Envoyé par fxrobin  Voir le message
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.
Offres d'emploi IT
Ingénieur Java J2EE(H/F)
CDI
Opensourcing - Ile de France - Paris (75000)
Parue le 07/07/2014
Medical software development engineering (C++) - Dubai
Stage
Gulf Interns - Autre - Dubai
Parue le 17/07/2014
Ingénieur réseau et sécurité h/f
CDI
EXPERIS IT - Rhône Alpes - Chambéry (73000)
Parue le 07/07/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula