Discussion :

[Gordon Fowler]

PHP s’imposera sur les serveurs face à Java et .NET
Il serait plus adapté aux évolutions liées à la mobilité, d’après un responsable de Zend

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 ?

[Voyvode]

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.

Ce ne serait pas la moindre des choses quand on veut faire dans le fracassant, surtout après tout ce temps ?

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

Celle qu'on maîtrise le mieux. Les technologies serveur ont tellement besoin de changer avec le mobile ? Se connecter à un serveur depuis un mobile est si différent d'un ordinateur classique avec son navigateur ou ses clients lourds ?

[Jean Meurtrier]

Peu crédible cette argumentation qui prend comme argument les technologies mobiles pour défendre un langage côté serveur.
De plus accuser un langage compilé d'être lent alors qu'il en représente un qui est interprété (même s'il peut être compilé mais ce n'est pas son but), c'est risible.

[moriarti13]

Débat stérile.

les pro-PHP seront d'accord avec l'article et ceux qui n'utilisent pas ou préfèrent d'autres technos seront contre.

Bref c'est encore le jeu de celui qui a la plus grosse.

Le mec de Zend vend son produit, il en rajoute donc forcément. mais il y a une part de vérité dans ce qu'il dit néanmoins.

[Xinu2010]

Face à cette news, plusieurs observations :

- Andi Gutsman, en tant que CEO de Zend, a un avis partial sur PHP.

- Il faut rappeler que PHP 6 avait été annoncé il y a déjà un moment, et n'a finalement pas vu le jour.

- Ruby avec RoR ne peut plus être qualifier de nouvel entrant aujourd'hui, c'était encore vrai il y a quelques années, mais c'est maintenant une solution mature et utilisée.

- Certaines technos montante n'ont pas été énuméré, quid de NodeJS, qui par sa nature est un concurrent sérieux pour php

[David_g]

Peu crédible cette argumentation qui prend comme argument les technologies mobiles pour défendre un langage côté serveur.
.

Ils sont censé faire une annonce bientôt concernant la mobilité et PHP.

- Il faut rappeler que PHP 6 avait été annoncé il y a déjà un moment, et n'a finalement pas vu le jour.

Ouep du coup ça serait marrant qu'il nous sorte une version 6 là (surtout si elle ne contient pas la majorité des choses que PHP6 devait apporter).

[Xinu2010]

Peu crédible cette argumentation qui prend comme argument les technologies mobiles pour défendre un langage côté serveur.

Même si à première vue ça peut sembler peu crédible, l’avènement des mobiles apporte son lot de changement, on voit par exemple de plus en de site mettant à disposition une API RESTFul.

De plus accuser un langage compilé d'être lent alors qu'il en représente un qui est interprété (même s'il peut être compilé mais ce n'est pas son but), c'est risible.

Tu fais beaucoup de simplifications, tu devrais te renseigner sur le fonctionnement de java, php et regarder quelques benchmark sur le net.

[Jean Meurtrier]

Tu fais beaucoup de simplifications, tu devrais te renseigner sur le fonctionnement de java, php et regarder quelques benchmark sur le net.

Oui je simplifie (Java compile du bytecode interprété ou compilé au démarrage par la JVM et certaines extensions de PHP sont compilées), mais les benchmarks sont généralement cruels pour PHP (et les langages interprétés en général), alors que Java a maintenant des performances du même ordre de grandeur que du C/C++ compilé.

http://shootout.alioth.debian.org/u6...=on&calc=chart

[pcaboche]

De plus accuser un langage compilé d'être lent alors qu'il en représente un qui est interprété (même s'il peut être compilé mais ce n'est pas son but), c'est risible.

Il y a bien pire que le compilé vs interprété...

Comment on met des données en cache côté serveur en .Net ou Java ? Ok. Maintenant comment on met des données en cache côté serveur en PHP ?

Ok, maintenant qui ose dire que Java est "lourd" (ou que .Net est pas mieux) ? Sans commentaire...

[Grabeuh]

Il y a bien pire que le compilé vs interprété...

Comment on met des données en cache côté serveur en .Net ou Java ? Ok. Maintenant comment on met des données en cache côté serveur en PHP ?

Ok, maintenant qui ose dire que Java est "lourd" (ou que .Net est pas mieux) ? Sans commentaire...

Sachant qu'on va généralement passer par un serveur Memcache dans les deux cas si l'application est un tantinet sérieuse, je vois pas spécialement où tu veux en venir ?

[Traroth2]

Sachant qu'on va généralement passer par un serveur Memcache dans les deux cas si l'application est un tantinet sérieuse, je vois pas spécialement où tu veux en venir ?

Euh... non. Pour PHP, effectivement, la seule solution, c'est d'utiliser un cache externe comme Memcached. En Java, il y a des solutions de cache full-Java, comme EHCache ou Hazelcast.

[transgohan]

Il y a bien pire que le compilé vs interprété...

Comment on met des données en cache côté serveur en .Net ou Java ? Ok. Maintenant comment on met des données en cache côté serveur en PHP ?

Ok, maintenant qui ose dire que Java est "lourd" (ou que .Net est pas mieux) ? Sans commentaire...

Je vais être totalement HS avec ce message mais la réponse détaillée m'intéresse pour ma culture personnelle.

[pcaboche]

Je vais être totalement HS avec ce message mais la réponse détaillée m'intéresse pour ma culture personnelle.

L'un des gros avantages de Java ou .Net, c'est que l'on peut garder des objets en mémoire côté serveur afin d'améliorer les performances.

Par exemple en .Net:
http://msdn.microsoft.com/en-us/library/dd997357.aspx

En php (sauf erreur), on recrée les différents objets à chaque évaluation du script. L'avantage, c'est que c'est plus simple à comprendre. L'inconvénient, c'est que c'est beaucoup moins performant.

Maintenant, ça fait au moins 7 ans que je n'ai pas retouché à du PHP et les choses ont peut-être changées, mais quand je cherche sur internet, je tombe sur des solutions qui s'apparentent plus à de la bidouille qu'autre chose.

Donc quand je lis que "PHP va s'imposer face à Java ou .Net", ça me fait doucement rigoler.

[alex_vino]

Personellement j'utilise ASP.Net (WebForms + MVC) et je trouve MVC bien meilleur que PHP (du moins concernant ce que l'auteur de l'article dit).
Son avis tres discutable car il ne vit que de PHP donc il ne va pas mettre en avant les autres solutions.
ASP.Net MVC est peut-etre trop centré sur Microsoft, mais cela a aussi certains avantages. De plus il est maintenant Open-Source et Microsoft souhaite rendre le systeme de plus en plus ouvert. Le seul inconvénient est qu'il faille obligatoirement l'installer sous Windows et bien souvent utiliser SQL Server, donc il faut prévoir ces licenses dans le budget.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Celle qu'on maîtrise le mieux. Les technologies serveur ont tellement besoin de changer avec le mobile ? Se connecter à un serveur depuis un mobile est si différent d'un ordinateur classique avec son navigateur ou ses clients lourds ?

Entierement d'accord, en ASP.Net MVC il suffit simplement de renommer sa vue (ex: accueil.iphone) pour que le serveur renvoie la page adéquat au matériel, pas besoin de remettre tout en question juste pour cela.

[hunyka]

Pesonnellement je pense qu'il ne faut pas oublier Python, qui gagne de la place en matière de language utilisé. J'obterais plus pour python dans l'avenir mais ce n'est que mon avis perso.

[Stopher]

Personnellement je pense qu'il ne faut pas oublier Python, qui gagne de la place en matière de language utilisé. J'obterais plus pour python dans l'avenir mais ce n'est que mon avis perso.

+1 pour python dont la news ne mentionne même pas ...

Et sauf erreur de ma part ... Mobile = Coté client, je ne vois donc pas en quoi le coté serveur peut jouer concrètement ( Aujourd'hui ) pour s'imposer au niveau des devs pour mobiles !
Si c'est la rapidité de développement alors il n'a jamais utilisé des FW tel que Django ou Flask ( désolé pour les autres technos ou je ne suis pas compétent, java/.Net ).

M'enfin .. encore une petite news qui va faire couler beaucoup d'encre pour rien ...

Moi même certifié PHP5, je développe beaucoup en Python que je trouve plus "sexy et carré" .. maintenant sincèrement le résultat est le même ... ( dans le sens ou les projets fonctionnent ).

Alors arrêtons d’idolâtrer une unique techno .. souvent elles sont complémentaires , l'essentiel est d'arriver au bout du projet !

Ch.

[alex_vino]

+1 pour python dont la news ne mentionne même pas ...

Et sauf erreur de ma part ... Mobile = Coté client, je ne vois donc pas en quoi le coté serveur peut jouer concrètement ( Aujourd'hui ) pour s'imposer au niveau des devs pour mobiles !
Si c'est la rapidité de développement alors il n'a jamais utilisé des FW tel que Django ou Flask ( désolé pour les autres technos ou je ne suis pas compétent, java/.Net ).

M'enfin .. encore une petite news qui va faire couler beaucoup d'encre pour rien ...

Moi même certifié PHP5, je développe beaucoup en Python que je trouve plus "sexy et carré" .. maintenant sincèrement le résultat est le même ... ( dans le sens ou les projets fonctionnent ).

Alors arrêtons d’idolâtrer une unique techno .. souvent elles sont complémentaires , l'essentiel est d'arriver au bout du projet !

Ch.

Sache que le principe des optimisations pour les clients mobiles ne sont pas toujours faites coté client. Quand un smartphone affiche une page souvent il y a moins d'informations a afficher et donc tu n'a pas besoin de renvoyer toutes les informations d'une page pour un PC. Deplus au lieu de renvoyer ton fichier CSS avec des media queries pour 15 types d'écran différent tu peux utiliser ton serveur pour renvoyer seulement la feuille de style adéquat a ton client.
Tout cela est natif dans d'autres technologies serveurs, contrairement a ce que Mr Zend annonce dans l'article qui ne voit pas plus loin que sont nez.
Il n'y a pas que PHP et les certifications Zend dans la vie

Par contre les technologies ne sont pas complémentaires, on ne mélange pas du PHP / .Net / Ruby / Java / Python dans un meme projet, le temps de Flash/Silverlight et compagnie devient révolue pour le grand public.

[Grabeuh]

Par contre les technologies ne sont pas complémentaires, on ne mélange pas du PHP / .Net / Ruby / Java / Python dans un meme projet, le temps de Flash/Silverlight et compagnie devient révolue pour le grand public.

Donc Twitter qui construit son interface avec une application Ruby On Rails et qui lit ensuite en AJaX des flux de données générés en langage Scala, c'est mal ?

Ou Google qui génère ses sites avec GWT (donc du Java) et qui effectue ensuite certains traitements en Node.JS, c'est mal aussi ?

Je vois aucun soucis à mélanger des technos SI C'EST PERTINENT !. Si ça apporte un gain réel à l'application (gain performance dans mes exemples au dessus) c'est justifié et même bénéfique.
Par contre, si c'est juste parce que les stagiaires qui se sont succédé sur le projet ne connaissaient pas tous le même langage, là c'est pas bien du tout.

[Graffito]

Ce débat PHP vs Java ou .net est biaisé au départ. Il porte sur l'aspect serveur des applications malheureusement conditionné par le coté client qui est pourri par le couple HTML/Javascript.

Sur la base de ce couple detestable, on n'a plus qu'un choix entre des solutions forcément batardes.

[alex_vino]

Donc Twitter qui construit son interface avec une application Ruby On Rails et qui lit ensuite en AJaX des flux de données générés en langage Scala, c'est mal ?

Ajax est utilisé dans la plupart des applications et est une technologie plutot complémentaire au sujet. Quant aux flux de données c'est un élément externe dans un découpage de l'application et indépendant du coeur de ton application (du moins dans les regles de l'art) ce qui hors-sujet, sinon a cette allure tu est partie pour considérer le type de base de données aussi