Discussion :

[SurferIX]

Tu n'utilise pas PHP et Apache ?

Si j'utilise Php "pur" (éviter l'usine à gaz qu'est symfony) et Apache avec mes règles de réécriture. Mais... j'ai l'impression qu'on a un dialogue de sourds..
J'essaie de le dire autrement : j'utilise du Php extrêmement optimisé + Apache optimisé compilé main et je viens de faire quelques benchs avec un serveur Varnish en frontal qui redirige en direct soit vers la première (Apache + Php + MySQL) soit vers la seconde (NodeJS + NoSQL / Mongoose) et les réponses passent de 1s / page (pour une page "lourde", c'est déjà très bien (selon moi)) à 0.4s pour la seconde pour exactement la même page, et question maintenance, moi qui commence à devenir pas trop mal en JavaScript, je pense que les deux se valent donc au final... bah comme il est écrit dans un article ici qui montre que Microsoft va dans le sens de NodeJS, je pense qu'effectivement, il faut aujourd'hui revoir sa copie en fonction des besoins et mes prochains sites seront certainement du Varnish + NodeJS/Mongoose.

[RyzenOC]

Mais... j'ai l'impression qu'on a un dialogue de sourds..

Je voulais juste dire que les performances quand on fait un site web, sont en général secondaire, elle n'infuence pas olu tres peu le choix du langage, on se contente d'utiliser du php, car c'est un langage que n'importe quel hébergeurs propose, c'est un langage réputés, pas comme Node.js qui est trop jeune selon moi pour être utilisé en prod, et c'est un langage ouvert pas comme ASP, ce qui permet plus de flexibilité.

Sinon on coderais tous en C voir en Assembleur.

[Tsilefy]

Quand tu auras ton audience sur le Web multipliée par 4 (véridique) grâce à un serveur qui répond beaucoup plus vite et que tes gains de pubs seront plus que quadruplés (de 0.20 centimes à presque un euro par jour c'est pas énorme mais toujours ça de pris), tu reviendras me dire que la vitesse compte pas....

Tu as abandonné apache pour nginx, c'est ca?

Tu cites un cas spécifique d'utilisation pour lequel la vitesse est le facteur le plus important. Il y en a d'autres. Comme je le disais, il faut choisir l'outil approprié. C'est ce que tu as fait apparemment :-)

Dans tous les cas, si la modication de ton framework (ou de ton code) PHP, node, ruby ou python est ce qui a pu multiplier ton code par 4, c'est que tu as de la chance d'avoir déjà reglé tous les autres problèmes qui ralentissent typiquement un site dynamique: base de données engorgées (et mal conçues, mal indexées et mal utilisées), disques lents, mauvaise utilisation de caches. Un serveur répondra beaucoup plus vite avec des requêtes bien conçues, des disques SSD (rien que ce facteur donnera l'impression que ton site est plus rapide qu'un cycliste dopé), des caches comme Redis ou Memcached.

Après, encore une fois, tout dépend des circonstances du projet, et cela comprend les possibilités matérielles (switcher pour du SSD est-il possible? Et ajouter plus de Ram?), financières et humaines (a-t-on les compétences et le budget pour changer en Node certaines fonctionnalités?)

Donc, ma thèse de départ est que ces benchmarks entre Frameworks, et entre langages ne riment à rien dans l'absolu, et je continue à la soutenir :-)

[Tsilefy]

Si j'utilise Php "pur" (éviter l'usine à gaz qu'est symfony) et Apache avec mes règles de réécriture. Mais... j'ai l'impression qu'on a un dialogue de sourds..
J'essaie de le dire autrement : j'utilise du Php extrêmement optimisé + Apache optimisé compilé main et je viens de faire quelques benchs avec un serveur Varnish en frontal qui redirige en direct soit vers la première (Apache + Php + MySQL) soit vers la seconde (NodeJS + NoSQL / Mongoose) et les réponses passent de 1s / page (pour une page "lourde", c'est déjà très bien (selon moi)) à 0.4s pour la seconde pour exactement la même page, et question maintenance, moi qui commence à devenir pas trop mal en JavaScript, je pense que les deux se valent donc au final... bah comme il est écrit dans un article ici qui montre que Microsoft va dans le sens de NodeJS, je pense qu'effectivement, il faut aujourd'hui revoir sa copie en fonction des besoins et mes prochains sites seront certainement du Varnish + NodeJS/Mongoose.

POur vraiment comparer, il faudrait tester Nginx+php+mongodb vs nodejs+Mongoose (même si je pense que node l'emporterait quand même, la différence ne doit pas être aussi flagrante)

[RyzenOC]

Peut on comparer Node.js a php ?, même si les 2 technos on le même "but" (faire communiquer le client avec un serveur), elle n'ont pas les même finalité, les même objectifs, et ne s'utilise pas dans les mêmes contextes.

Après je dis ca, mais je en suis pas un spécialiste en Node.JS, je commence a peine a découvrir, mais sa semble pas être fait pour faire des formulaires comme en php par exemple, mais plus pour faire des applications qui communiques de maniere intensive avec le serveur (un mmo en html5 par exemple)

[Tsilefy]

Peut on comparer Node.js a php ?, même si les 2 technos on le même "but" (faire communiquer le client avec un serveur), elle n'ont pas les même finalité, les même objectifs, et ne s'utilise pas dans les mêmes contextes.

Après je dis ca, mais je en suis pas un spécialiste en Node.JS, je commence a peine a découvrir, mais sa semble pas être fait pour faire des formulaires comme en php par exemple, mais plus pour faire des applications qui communiques de maniere intensive avec le serveur (un mmo en html5 par exemple)

C'est bien ce que je disais. Faire un blog de type Wordpress en Node n'a pas de sens (à mon avis), même si Node peut le faire, de même que des applications avec une BDD relationnelle. Mais pour faire un site de chat texte et vidéo avec encodage de flux en temps réel, par exemple, ou toute sorte d'application avec beaucoup d'interactions en temps réel, Node brille. L'essentiel c'est de déterminer sur quelle partie de son site utiliser Node, sur laquelle utiliser PHP (ou ruby, ou python, ou [:grasp:] perl), etc...

[Sammo]

éviter l'usine à gaz qu'est symfony

On est déjà vendredi ? Qualifier Symfony d'usine à gaz il faut le faire

[SurferIX]

On est déjà vendredi ? Qualifier Symfony d'usine à gaz il faut le faire

C'est que tu n'as jamais fréquenté des experts Symfony qui ont développé une vingtaine de projet en full Symfony.
Après m'avoir donné plein d'explications techniques sur le pourquoi du comment, dont je ne me souviens plus (très honnêtement), j'ai développé deux applications en full Symfony dont une assez lourde, et professionnelle.
Donc, "oui", Symfony est une grosse usine à gaz. La plupart du temps, utiliser Symfony c'est prendre un bulldozer pour écraser une mouche.
Pour la note, les experts Symfony ont pris la décision d'étudier minutieusement chaque nouveau projet, et de ne rester que sur Silex à moins qu'une contrainte très spécifique ne les force à utiliser Symfony. Si tu ne me crois pas et tu veux leurs coordonnées personnelles écris moi en privé. Et donc, "oui", Symfony est une grosse usine à gaz.

[RyzenOC]

Après, encore une fois, tout dépend des circonstances du projet, et cela comprend les possibilités matérielles (switcher pour du SSD est-il possible? Et ajouter plus de Ram?), financières et humaines (a-t-on les compétences et le budget pour changer en Node certaines fonctionnalités?)

Actuellement je suis en train d'expérimenter un truc chez moi (serveur personnel je précise), je suis en train de mettre le serveur sur un ramdrive.

Ma distribution Linux+ package+site+BDD sa me revient a 5Go environ, comme mon serveur chez moi et brancher sur onduleur, et que j'utilise le noyaux 4.1 (avec live patching donc), il ne doit théoriquement plus rebooter.
J'ai 8Go de ram sur mon serveur, ce qui m'en laisse 3Go.

Sa fait 3 mois environ que sa tourne sans problème et surtout rapidement.

[vinmar]

C'est que tu n'as jamais fréquenté des experts Symfony qui ont développé une vingtaine de projet en full Symfony.
Après m'avoir donné plein d'explications techniques sur le pourquoi du comment, dont je ne me souviens plus (très honnêtement), j'ai développé deux applications en full Symfony dont une assez lourde, et professionnelle.
Donc, "oui", Symfony est une grosse usine à gaz. La plupart du temps, utiliser Symfony c'est prendre un bulldozer pour écraser une mouche.
Pour la note, les experts Symfony ont pris la décision d'étudier minutieusement chaque nouveau projet, et de ne rester que sur Silex à moins qu'une contrainte très spécifique ne les force à utiliser Symfony. Si tu ne me crois pas et tu veux leurs coordonnées personnelles écris moi en privé. Et donc, "oui", Symfony est une grosse usine à gaz.

Je ne suis pas un grand expert Symfony, Silex, etc. mais tu ne peux sortir de manière péremptoire dans la même phrase : "Symfony2 c'est une usine à gaz [...] c'est pas moi qui le dit mais des experts symfony [...] qui utilisent Silex".

Silex n'étant finalement qu'une branche "lite" de Symfony (utilisation des components) pour répondre à un paradigme de développement différent de Symfony, c'est-à-dire : des projets légers ou des projets qui ne rentrent pas dans le cadre de Symfony.

Après on peut effectivement utiliser Symfony pour faire un blog mais c'est pas le but de Symfony, et cela un simple "développeur non expert" te le dira. De même que je ne ferais jamais un ERP avec Wordpress.

Donc NON, Symfony n'est pas une usine à gaz, c'est un outil te permettant de développer des applications "d'un fort beau gabarit". Et quand on voit l'augmentation de la complexité dans le développement d'applications (peu importe le langage que tu utilises), à un moment donné, les Symfony, Zend Framework, etc. se complexifient irrémédabi... irrémédiabla... aussi.

[Nicam]

@Miky55

Oui je pensais à Asp.net et oui je pensais sincèrement à les comparer et pas qu'une demi-seconde puisqu'il s'agit de deux langages orientés web, que beaucoup de framework php s'inspirent en partie de asp mvc ou encore que .net n'est pas natif et tourne dans une vm comme les autres langages de ce comparatif :php vs python vs ruby.

Je comprend vraiment pas ton ironie, en quoi sont-ils incomparables?

Tu ne comprends pas mon ironie ?
Alors, attend, je t'aide 2 secondes :

Tu compare un langage (Php) à une plateforme complète (Qui comprend un langage doublement compilé, un moteur d’exécution (la CLR), une bibliothèque d'objets, etc ...). Tu ne peux pas comparer php à Asp.net, mais à C#. Si tu veux comparer qqch, compare ce qui est comparable, en l’occurrence, tu le compare à Php+Zend, ou Php+Synfony, etc ...

Ensuite, tu as deux courant en asp.net : Les webform, qui se traduit par des mécanismes d'abstractions gérant les états, et ASP.net MVC, plus roots, mais plus rapide, et plus webdev friendly (question de gout). IL ne s'agit pas de dire que l'un est mieux que l'autre, mais que l'un couvre un périmètre fonctionnel différent de l'autre. En 2001, coder des applications web bourrés de formulaires étaient bien plus rapide en Webform qu'en PHP. Simplement parce que les framework PHP comme synfony n'existaient pas, ou très peu, et que tu te paluchais tout à la mano. Là, Webform était une vrai révolution.
Mais MS à changé de direction, et ils ont poussé MVC pour répondre aux besoins des développeurs, qui voulaient bénéficier de la plateform .Net qui est excellente, mais qui voulaient tout gérer eux même. N'oublions pas que Webform et MVC utilisent exactement les mêmes processus interne de .Net : les mêmes !!!
C'est pour cela que tu peux passer de l'un à l'autre dans les mêmes projets.

Bref, tu ne peux pas comparer un moteur de voiture avec une voiture complète. C'est en cela que ta comparaison est fallacieuse.

Ensuite, parce que, même si PHP est un très bon outil, .Net offre des fonctionnalités bien plus élaborés (telle qu'une vraie gestion des threads, du parralelisme, etc ...) Je en parle même pas des différentes bibliothèques natives qui sont vraiment bien foutues, et ... natives (comme par exemples les différentes stratégies de caches en web).

Je t'invite sérieusement à te renseigner sur le sujet, plutôt que comparer des carottes à des choux fleurs ...
Enfin, .Net ne tourne pas dans une VM ... A moins que tu considères que la CLR soit une VM, mais là, je ne peux rien faire pour toi.
Je ne vais pas commencer à expliquer ce qu'est un langage managé ...
Concernant le code en natif, rebelote : renseignes toi ...

Enfin, et pour question de gout, je n'aime pas PHP car c'est un langage qui met trop souvent à contribution les Arrays.
En tout cas, la plupart des outils opensources sont codés à la papa avec des tas d'objets qui communiquent via des Arrays, ce qui me sort par les trous de nez depuis que j'ai codé sérieusement en Java et en C#.

Bien à toi.

[SurferIX]

Symfony n'est pas une usine à gaz, c'est un outil te permettant de développer des applications "d'un fort beau gabarit".

Tu as presque juste ! "Symfony est une usine à gaz, c'est un outil te permettant de développer des applications "d'un fort beau gabarit"."
Dans presque tous les cas d'entreprise, Symfony n'est pas utile. Silex au mieux. Et ce sont des experts que je respecte vraiment car ils font partie de la très (trop ?) rare population jeune bonne en informatique. Point à la ligne, merci au revoir je me désabonne, marre de lire des choses de gens qui se fient uniquement à ce qu'ils ont lu ou entendu, sans valider concrètement. Ils ne peuvent pas avoir beaucoup d'expérience dans un domaine, sinon ils ne diraient pas ça.

Comme dirait un vieil adage :

En théorie, la pratique et la théorie sont pareils. En pratique, ils sont différents.

Je te laisse nager dans tes océans, de théorie, moi je sais de quoi je parle. Tchao.

[vinmar]

Tu as presque juste ! "Symfony est une usine à gaz, c'est un outil te permettant de développer des applications "d'un fort beau gabarit"."
Dans presque tous les cas d'entreprise, Symfony n'est pas utile. Silex au mieux. Et ce sont des experts que je respecte vraiment car ils font partie de la très (trop ?) rare population jeune bonne en informatique. Point à la ligne, merci au revoir je me désabonne, marre de lire des choses de gens qui se fient uniquement à ce qu'ils ont lu ou entendu, sans valider concrètement. Ils ne peuvent pas avoir beaucoup d'expérience dans un domaine, sinon ils ne diraient pas ça.

Comme dirait un vieil adage :

En théorie, la pratique et la théorie sont pareils. En pratique, ils sont différents.

Je te laisse nager dans tes océans, de théorie, moi je sais de quoi je parle. Tchao.

Faut pas t'énerver comme cela. Tu feras pas avancer l'Humanité à dire : "Y'en a des biens et les autres c'est des chèvres et je sais pourquoi je dis ça mais toi tu ne le comprendras jamais parce que tu es un gros nul."

Je n'étais pas en train de dire que tes experts sont nuls ou que ce que tu dis est complétement faux. Mais la façon dont tu exposes la chose est assez maladroite. Mais je t'invites et nous expliquer la chose. Ce serait intéressant un petit thread là-dessus !

Allez bonne journée quand même, je retourne dans ma médiocrité (et je claque la porte en sortant).

[stailer]

Nicam : "Enfin, et pour question de gout, je n'aime pas PHP car c'est un langage qui met trop souvent à contribution les Arrays.
En tout cas, la plupart des outils opensources sont codés à la papa avec des tas d'objets qui communiquent via des Arrays, ce qui me sort par les trous de nez depuis que j'ai codé sérieusement en Java et en C#."

Je développe en ASP.NET MVC 4 et en PHP / Zend Framework tous les jours... Ce sont mes 2 outils préférés. Les 2 ont des avantages et des inconvénients.

Oui au fin fond du du ZF les arrays sont surement utilisés à foison... Mais de là à remettre en cause toute une techno c'est un peu "exagéré".
J'ai développé certaines de mes applis bcp plus vite avec le ZF que je ne l'aurai fait avec ASP.NET MVC (et tout aussi proprement)... Mais j'ai aussi fait l'inverse sur d'autres projets.

C'est le BESOIN qui décide.

[Gugelhupf]

Enfin, .Net ne tourne pas dans une VM ... A moins que tu considères que la CLR soit une VM, mais là, je ne peux rien faire pour toi.

Common Language Runtime (CLR) est le nom choisi par Microsoft pour le composant de machine virtuelle du framework .NET.

Source : Wikipédia, première ligne.

[jojosbiz]

Haaaa, ça tourne en débat sur les framework, j'adore.

Donc je vais en profiter pour me faire du bien et dire que les framework pour PHP style Symphony, Laravel, etc... ne servent à rien !!! (J'ai déjà utilisé Laravel pour info, qui est sensé être le framework "à la mode").

Je sais que tout le monde se fout de mon avis et qu'il est extrêmement minoritaire, mais il faut savoir se faire du bien de temps en temps

L'image du bulldozer pour écraser une mouche est tout à fait appropriée.


Sinon, j’attends cette version de PHP 7 avec impatience, tout cela m'a l'air vraiment intéressant.

[Tsilefy]

Haaaa, ça tourne en débat sur les framework, j'adore.

Donc je vais en profiter pour me faire du bien et dire que les framework pour PHP style Symphony, Laravel, etc... ne servent à rien !!! (J'ai déjà utilisé Laravel pour info, qui est sensé être le framework "à la mode").

Je sais que tout le monde se fout de mon avis et qu'il est extrêmement minoritaire, mais il faut savoir se faire du bien de temps en temps

L'image du bulldozer pour écraser une mouche est tout à fait appropriée.

Sans donner mon avis sur cette question toujours sujette à polémique (prochains sujets: pour ou contre les ORMs? Pour ou contre le typage strict?), tu remarqueras que le développement PHP s'oriente de plus en plus vers l'utilisation de composants plutôt que de full-stack frameworks.

[Nicam]

@Stailer : Sauf erreur de ma part, je n'ai pas remis en cause ni totalement, ni partiellement la techno PHP.
J'ai dis que je n'aimais pas PHP pour une raison précise, et encore, j'ai ajouté que c'est l'utilisation qui en est faite que je n'aime pas.
Et ca ne se limite malheureusement pas qu'aux sous couches de Zend. Il y a des tonnes d'applications PHP qui utilisent encore trop de paramètres sous forme d'array.
Php est une très bonne techno (que j'ai pratiqué aussi en tant que développeur et en tant que chef de projet technique).
Je me sens juste plus à l'aise avec des langage comme Java et C# dans des envirronement JEE ou .Net. C'est une question de gout,et ca n'engage que moi.

@Gugelhupf : C'était facile, je le reconnais.
Mais c'est un peu plus complexe que cela malgré tout. On compare la CLR à une VM car l'un de ses rôle est de convertir des codes en differents langages (C#, VB, etc ...) en langage intermédiaire : le CIL (un peu comme Java et son bytecode). Sauf qu'ensuite, avant exécution, ce code intermédiaire est compilé en langage machine. Alors que Java interprète son bytecode, la CLR le compile en langage machine.
On est plus du tout en condition de VM comme en Java. A l’exécution, la CLR gère l’exécution du code (accès mémoire, sécurité, etc ...) mais n’agis pas comme un VM qui est étanche. Le code exécute est bien spécifique à l'os et à la machine qui l’exécute. C'est pour cela que je refuse d'appeler ca une VM.
La CLR n'abstrait absolument pas les ressource physiques de la machine exécutante. Elle est là pour contrôler l’exécution, via le JIT.

[Gugelhupf]

@Gugelhupf : C'était facile, je le reconnais.
Mais c'est un peu plus complexe que cela malgré tout. On compare la CLR à une VM car l'un de ses rôle est de convertir des codes en differents langages (C#, VB, etc ...) en langage intermédiaire : le CIL (un peu comme Java et son bytecode). Sauf qu'ensuite, avant exécution, ce code intermédiaire est compilé en langage machine. Alors que Java interprète son bytecode, la CLR le compile en langage machine.
On est plus du tout en condition de VM comme en Java. A l’exécution, la CLR gère l’exécution du code (accès mémoire, sécurité, etc ...) mais n’agis pas comme un VM qui est étanche. Le code exécute est bien spécifique à l'os et à la machine qui l’exécute. C'est pour cela que je refuse d'appeler ca une VM.
La CLR n'abstrait absolument pas les ressource physiques de la machine exécutante. Elle est là pour contrôler l’exécution, via le JIT.

Je crois que le fonctionnement de C# est en tout point identique à celle de Java. Il n'y a que les noms qui changent (question politique).
CIL => bytecode
CLR => JVM
Le code intermérdiaire (CIL/bytecode) est lu par la VM (CLR/JVM) pour être compilé en langage machine à la volé (JIT). Que ce soit pour C# ou Java, le langage machine généré est spécifique à l'OS+architecture.

Voici une autre citation de Wikipédia (source) :

Le CLR est à .NET ce que la JVM est à Java, c’est-à-dire une machine virtuelle

[jojosbiz]

Sans donner mon avis sur cette question toujours sujette à polémique (prochains sujets: pour ou contre les ORMs? Pour ou contre le typage strict?), tu remarqueras que le développement PHP s'oriente de plus en plus vers l'utilisation de composants plutôt que de full-stack frameworks.

Et c'est tant mieux !

Je ne suis pas contre l'utilisation de composants pour se faciliter la vie et je remercie toujours ceux qui les font.

Mais quand je vois "framework" et "PHP" (ou "Javascript", c'est la même chose à mes yeux) dans la même phrase, j'ai la tension qui monte...
Et je trouve qu'on les voit beaucoup trop ces derniers temps.


PS : je suis contre les ORM
Pour le typage strict je n'ai pas vraiment d'avis, l'un ou l'autre ne me gêne pas.