~bohwaz/blog/

Avec de vrais morceaux de 2.0 !

PHP, affreux ?

Je pense qu'il est important de rester critique par rapport aux langages que nous utilisons, mais dénigrer sans raison me semble une perte de temps complète. Je reviens ainsi sur l'article de sebsauvage sur PHP qui critique le langage en ces termes :

un langage assez amobifreux (de la contraction de "abominable" et "affreux")

Et de s'étonner ensuite du choix effectué par des projets comme Facebook, Wikipedia ou Wordpress d'utiliser ce langage, pourtant "abominable", "affreux" et "moche".

Je suis d'accord pour accepter le fait que PHP a une histoire plutôt anarchique, avec des incohérences et des comportements bizarres. Mais dire que c'est un langage "abominable", qui serait horrible en comparaison par exemple de Python, c'est un peu se tromper je pense.

De nos jours PHP, depuis au moins la version 5.2 et plus encore depuis la version 5.3, est un vrai langage moderne et agréable à utiliser au quotidien, il permet un peu tout ce dont on attendrait d'un vrai langage objet, et souvent de manière simple et efficace, avec toujours l'avantage de pouvoir déployer de manière très simple un peu partout et surtout de bénéficier d'une excellente documentation (et notamment les commentaires associés qui sont souvent très utiles).

Après, je me demande si la critique est réellement fondée. Autant j'apprécie beaucoup sebsauvage, que je lis depuis des années, et autant j'apprécie ses idées, autant son code PHP me semble dater d'un autre âge : souvent procédural, rarement objet, mélangeant allègrement définition de fonctions et code fonctionnel, etc.

Par exemple le code de Shaarli commence par la configuration du logiciel : 

$GLOBALS['config']['DATADIR'] = 'data'; // Data subdirectory

Suivi de : 

ini_set('max_input_time','60');  // High execution time in case of problematic imports/exports.

et autres gestion des directives INI, puis des define, puis un appel à des fonctions, puis des inclusions, suivi d'envoi de headers HTTP (alors qu'on n'a même pas encore défini à ce stade dans quel contexte nous sommes), puis des define, du code, des require, et enfin des définitions de fonctions, puis des define et des définitions de directives INI, encore des définitions de fonctions, suivies d'includes, de code procédural, puis ensuite de classes, etc etc. Je vous laisse regarder le code de Shaarli si ça vous intéresse.

Rien que dans tout ça on peut voir que le code est anarchique, pas structuré, bref impossible à maintenir à long terme car impossible de savoir où se trouve telle ou telle partie. Le problème n'est pas qu'au niveau de l'organisation du code, mais dans tout le reste aussi, par exemple parfois les erreurs sont gérées avec des exceptions, parfois avec des die().

Le code en lui-même est parfois alambiqué, par exemple : 

$last=strtolower($val[strlen($val)-1]);

Il faut relire deux fois la ligne pour comprendre ce que ce code est censé faire, alors qu'il aurait été plus simple de faire : 

$last = strtolower(substr($val, -1));

Évidemment on est très loin de la lisibilité du Javascript (un autre langage "horrible" mais pourtant tellement génial) : 

var last = val.toLowerCase().substr(-1);

Mais c'est dû à la syntaxe de PHP surtout.

On peut également noter que le code semble avoir été réalisé en PHP4, et n'utilise aucun avantage d'un PHP moderne, par exemple : 

function linkdate2timestamp($linkdate)
{
    $Y=$M=$D=$h=$m=$s=0;
    $r = sscanf($linkdate,'%4d%2d%2d_%2d%2d%2d',$Y,$M,$D,$h,$m,$s);
    return mktime($h,$m,$s,$M,$D,$Y);
}
<snip ... />
return date('r',linkdate2timestamp($linkdate));

Pourrait très bien gagner en clarté et en efficacité comme cela : 

$date = DateTime::createFromFormat('Ymd_His', $link_date);
return $date->format(DATE_RFC822);

Je ne vais pas procéder comme cela pour tout le code, mais il est assez simple de se rendre compte que PHP n'est pas si terrible que ça, si on a la rigueur de vouloir l'utiliser de manière correcte. Mais il semble que pour de nombreuses personnes PHP n'a pas évolué depuis PHP 3 ou PHP 4, alors que PHP 5 est disponible depuis 8 ans, et PHP 5.2 depuis 6 ans.

Au final, la question n'est pas vraiment celle du langage qui est plus une affaire de préférence personnelle mais, comme pointé dans l'article de Jeff Atwood cité par sebsauvage, de la compétence du développeur rapport au langage utilisé.

Critiquer pour critiquer n'apporte rien, si on utilise un langage le plus utile est de participer à son évolution, par les rapports de bugs, par les corrections de documentation, et les changements apportés au langage lui-même. Un excellent exemple est le travail de suivi et explication du développement de PHP sur le Mageekblog de Frédéric Hardy ou encore les billets du blog de Pascal Martin.

Écrire un commentaire
(facultatif)
(facultatif)
(obligatoire)
     _   __ _           _   
  __| | /_/| |__  _   _| |_ 
 / _` |/ _ \ '_ \| | | | __|
| (_| |  __/ |_) | |_| | |_ 
 \__,_|\___|_.__/ \__,_|\__|
(obligatoire)

Les adresses internet seront converties automatiquement.
Tags autorisés : <blockquote> <cite> <pre> <code> <var> <strong> <em> <del> <ins> <kbd> <samp> <abbr>

Lilian

Merci pour cette remise au clair sur PHP, c'est un langage que je trouve également très agréable. Et être en bonne compagnie au travail, quoi de plus important ?

lipki

Le langage en lui-même est amobifreux, il suffit d'avoir fait du java, python, as3, ou d'autres pour le voir.

Ce qui fait la qualité de PHP, c'est tous ce qui n'est pas PHP.

Les serveurs, la communautés, la documentation, et grâce à ça on a un langage très utilisable.

Mais PHP peut devenir mieux, vraiment.

sebsauvage

Ah... je me doutais qu'en écrivant cet article j'attirerais les critiques. :-)

Pour répondre à michel v, je bricole du php à temps perdu, pour Shaarli principalement.

Pour mon boulot, c'est plus généralement du Java et .Net, adossés à des frameworks d'entreprise (avec pages de bases, MVC ou DAL autochtones, et tout le reste).

Shaarli est moche ? Bien sûr que le code est moche !

Il a dès le départ été bricolé comme un truc rapide pour sauvegarder mes liens, à un moment où je n'avais vraiment pas que ça à faire. Alors oui, c'est moche, je le sais et j'assume. Et la structure du code à l'origine répondait parfaitement au problème (pas d'objets, écriture en mode 'script', limite jetable, code monolithique, aucune dépendance, compatibilité php4 tant que possible).

Vous oubliez un peu le contexte. Je prend un exemple: Il y a des die() ? Oui. Est-ce un problème ? Est-ce utile qu'un pirate qui essaie de contourner la protection XSRF voit une jolie page d'erreur bien formatée ou juste un die() dans sa tronche ? Voilà, vous avez saisi.

Je serais dans une entreprise avec des utilisateurs finaux, ou en temps que middleware, il serait absolument indispensable de bien architecturer tout ça, avec une bonne gestion d'erreur, qui logue tout bien et renvoie des réponses adéquates. Mais pour un petit script pour site perso pour partager quelques liens, on s'en fout. Question de contexte et d'investissement de temps.

Travaillez-vous de la même manière sur un script jetable pour traiter une masse de logs que sur un ensemble d'objets métiers destinés à perdurer ? Non. Moi non plus.

Je n'aurais jamais pensé que Shaarli intéresserait autant de monde. Oui, maintenant Shaarli mériterait une bonne ré-écriture... si j'avais le temps. Remettre en doute mes compétences sur un script bricolé à la va-vite, bof.

Ceci mis à part, il faut quand même avouer que php est laid et sa lib bordélique, non ? Honnêtement, il y a quand même des structures de langage que j'aimerais y voir (par exemple les list-comprehension de Python que je trouve magnifiques, à la fois concises et lisibles).

J'ai l'impression d'avoir lancé un troll, ce qui n'était pas du tout mon but. Tant pis pour moi.

sebsauvage

Encore un exemple:

$date = DateTime::createFromFormat('Ymd_His', $link_date);

return $date->format(DATE_RFC822);

ah oui c'est NETTEMENT plus élégant que:

$Y=$M=$D=$h=$m=$s=0;

$r = sscanf($linkdate,'%4d%2d%2d_%2d%2d%2d',$Y,$M,$D,$h,$m,$s);

return mktime($h,$m,$s,$M,$D,$Y);

encore faudrait-il que php 5.3 soit dispo partout, ce qui est loin d'être le cas (coucou Free.fr ? php 5.1 RC.... *RC* !)

Encore une fois, problème de contexte et de contraintes.

sebsauvage

Vous semblez aussi oblitérer certaines phrases de mon article:

"php est moche, mais ça n'a aucune importance. php suck, but it doesn't matter (très bon article, au passage). On y arrive. Avec de la discipline, on peut faire assez propre. Et puis il y a une quantité absolument formidable de logiciels, bibliothèques et frameworks qui rendent le travail plus simple et plus efficace."

Au final, on dit la même chose :)

bohwaz

@sebsauvage : DateTime est dispo depuis PHP 5.2, soit depuis 2006... L'immense majorité des hébergeurs dispose de PHP 5.2 au minimum quand même.

Quand à Free.fr, laissons les crever dans leur coin.

L'argument du truc bricolé vite fait me semble totalement à côté de la plaque, même quand je fait un truc vite fait, j'essaye de le faire bien, car on sait tous que ce truc bricolé vite fait y'a de bonnes chances qu'on s'en serve pendant les X prochaines années à venir. De plus, quand on l'habitude de faire du code de qualité, c'est au contraire plus long et compliqué de faire du mauvais code pour un truc vite fait, car on a normalement les automatismes de penser son code correctement.

C'est comme n'importe quel boulot, est-ce qu'un électricien va faire un pauvre bricolage moche plutôt que de faire un truc propre s'il doit réparer son tableau électrique chez lui ? Non, parce qu'il a l'habitude de faire quelque chose de propre, il ne devient pas mauvais comme ça d'un coup. De même pour un menuisier ou un garagiste. Je ne vois pas pourquoi ça serait différent pour un développeur.

Donc non c'est pas une excuse :)

Nabellaleen

Les problèmes que j'ai constaté vis-à-vis de PHP ne sont pas tant les avantages/inconvénients du langage en lui même que la piètre qualité des ressources utilisées pour se former au langage.

Je m'explique :

PHP est un langage assez permissif et demandant, par conséquent, une importante rigueur pour réaliser un code qui soit aussi joli que stable et puissant.

C'est donc un langage qui est "difficile" à maîtriser pour le débutant ou le "casual". Et paradoxalement, sa "domination" sur le web en fait le point d'entrée vers le web dynamique pour les débutants.

De plus, un débutant cherchant des tutoriels tombe très rapidement sur des exemples de mauvaise qualité. Du moins des exemples ne lui apprenant pas la rigueur sus-citée.

Effet boule de neige : ces débutants deviennent de "mauvais experts" et font du "mauvais code", qui se répand de + en plus, n'aidant pas PHP à redorer son image.

sebsauvage

"L'immense majorité des hébergeurs dispose de PHP 5.2 au minimum quand même."

Nope.

Déjà, une bonne partie de mes lecteurs veulent le faire tourner chez Free, pour qui j'ai dû adapter mon soft (oui, je pense à eux, les pauvres :)

Et ça, c'est sans parler des hébergeurs qui ont - HORREUR! - magic_quotes d'activé.

Donc il faut moyenner. Vers le bas, oui, c'est désolant, pour que ça passe sur un peu plus d'hébergeurs (pourris, on est bien d'accord).

"L'argument du truc bricolé vite fait me semble totalement à côté de la plaque [...] car on a normalement les automatismes de penser son code correctement."

Normalement oui. Mais on a parfois des impératifs de temps et de budget.

Expérience perso:

Une personne a fait une bourde monumentale sur la base de prod. Je dois extraire des données des logs pour reconstruire les données à réinsérer d'urgence sur la base de prod (car les backups n'ont encore tourné sur ces données fraîches).

Tu crois que je vais leur dire qu'il me faut 1,5 journée en plus, parce que, selon les règles de la boite:

- mon script/appli doit écrire dans les logs du framework maison.

- elle doit catcher toutes les erreurs possibles et envoyer un ticket adéquat au webservice de l'IT en cas de plantage.

- je dois impérativement passer par leur DAL objet, et donc développer les méthodes manquantes dans les classes qui touchent à la base (qui doivent donc être relivrées en prod avant mon prog)

- elle doit envoyer des signaux précis au scheduler quand elle passe certaines étapes.

- etc.

Non, on me demande de rétablir ASAP, parce que le business tourne et que c'est critique. Alors oui, je vais bricoler rapidement un script qui rétablira la situation, et *alors* on pourra voir d'où venait le problème pour corriger *proprement*.

Dans l'idéal, on a tous le temps de faire un code nickel-chrome.

Dans la pratique, on est parfois amené à trouver un compromis entre code nickel et impératifs de temps/techniques/business.

C'est moche, et je suis le premier à le regretter, mais c'est comme ça.

Pour reprendre l'image de l'électricien: En cas d'incendie, il va couper le courant, éventuellement mettre en route un groupe électrogène (solution sale temporaire) avant de bien tout réparer proprement et remettre le courant. :)

Paul

Bonjour,

en tant que dépanneur TV, il m'est arrivé de "bricoler" rapidement le téléviseur d'une personne âgée (par exemple) la veille d'un week-end de façon à ce que ce tvc soit fonctionnel le temps que la pièce arrive. Je parle bien sûr d'une pièce mineure assurant le filtrage de parasites secteur qui s'était mise en court-circuit empêchant le démarrage de l'alim SOPS et donc du TVC.

Je ne me serais pas vu enlever l'appareil à cette mamie pour un loooonnnnng WE alors que je savais pertinemment que la pièce ne serait commandée que le lundi et que j'avais ce bricolage pas propre mais sans danger a appliquer simplement.

Que celui qui n'a jamais bricolé me jette la première pierre ;) .

anonym

Troll inside;

le programmeur python qui dit au programmeur php tu pues,

c'est pas un tout petit peu comme si le roquefort disait au camembert tu pues?;

cordialement ruby , c++

Deste

Je déteste ce genre de personne, qui code des trucs a la va vite vraiment horrible...

En tant que dev, ca me sort simplement par les yeux...

L'argument "j'ai pas le temps" est juste irrecevable ! Imaginez cela transposé dans d'autre métiers :

- la bouff du restau est dégeu : "j'ai pas eu le temps car j'ai oublié d'allumer sous la casserole"

- ma plomberie fuit : "j'ai pas le temps de bien raccorder les tuyaux"

De plus, même pour les petit hébergeurs avec du vieux php, ce code reste immonde...

J'en connais plein qui sortent ce genre d'arguments, en général, des ingé dans des petite boite de dev. Quand on parle conception avec eux on se rend vite compte de leurs limites. Souvent cela est du a une formation de dev bien trop faible.

bref... Ce genre de bricolage je veux bien pour soit (car après tout, tant pis pour eux...) mais sur un code qui doit être partagé, ça devrait juste être bannis !

Donc désolé, mais pour moi, sebsauvage n'est pas un développeur mais un programmeur bricolo. Je ne me reposerai jamais sur ses codes, car j'aurai toujours plus vite faire de recommencer que de nettoyer...

Et si PHP est crade, c'est pas pour ce qu'il est, mais ce qu'il permet de faire. Un langage propre comme java, n'autorise pas de faire du code crade. C'est vrai que php a un lourd passé derrière lui et que c'est pas de sa faute, mais le résultat est la...

Résumé, j'aime pas PHP, j'aime pas ceux qui font du code dégeu, mais de manière général sebsauvage est bien plus balèze que moi !

Je suis concepteur d'application et ne sais faire a peu pres que ca ^^'

Merci pour l'article !

sebsauvage

"j'aime pas ceux qui font du code dégeu"

Moi non plus :) (Moi aussi j'ai eu à faire de la maintenance sur des projets pas écrits par moi. Moi aussi il m'est arrivé de hurler intérieurement en ouvrant du code).

"Ce genre de bricolage je veux bien pour soit (car après tout, tant pis pour eux...) mais sur un code qui doit être partagé, ça devrait juste être bannis !"

Grande nouvelle: j'avais écris Shaarli POUR MOI, dans mon coin, pour résoudre rapidement MON problème. Mais comme je ne suis pas égoïste, je partage.

"sebsauvage n'est pas un développeur mais un programmeur bricolo"

Vous croyez que je code tout comme j'ai codé Shaarli, sérieusement ? oO

"Un langage propre comme java, n'autorise pas de faire du code crade."

Euh... si si. Rien n'empêche des horreurs du genre: une méthode statique avec 1000 lignes dedans ou des héritages à 40 niveaux.

"Et si PHP est crade, c'est pas pour ce qu'il est"

Ah si. En partie quand même. Un exemple ? Regarde le bordel de la gestion de l'utf-8: www.phpwact.org/php/i18n/...

C'est juste pas possible de bosser avec ça.

Zleug

J'ai remarqué qu'on parle dans cet article de "l'effort" qu'un développeur doit faire et pas du langage.

Quand tu codes avec PHP ou tout autre langage "moche" syntaxiquement, t'es obligé de faire gaffe à comment tu codes pour rendre ton code lisible.

Quand tu codes avec Python ou Ruby ou tout autre langage "joli" syntaxiquement, t'es pas obligé de faire ce genre d'effort car le langage lui même ne te permet pas vraiment de produire du code moche.

Un simple exemple, quand tu codes en python, t'es obligé d'indenter, sinon, ton code marche pas.

JeromeJ

Et là on comprend mieux pourquoi sebsauvage désactive ses commentaires :D

(Fichu trolls rageurs)

Moi je dis merci à seb pour son partage et merci à l'auteur de cet article pour l'ouverture d'esprit. J'veux dire par là, c'est toujours mieux d'avoir plusieurs points de vue.

Après à chacun de se forger sa propre opinion.

Zleug

Et aussi :

"Et de s'étonner ensuite du choix effectué par des projets comme Facebook, Wikipedia ou Wordpress d'utiliser ce langage, pourtant "abominable", "affreux" et "moche"."

Leur choix n'avait rien de technique, ils ont pris PHP juste parce que c'est-ce que tout le monde utilisait. C'est encore l'argument de la majorité qui frappe.

Quand quelqu'un cherche à créer un projet, le choix du langage va se porter sur le langage le plus utilisé parce que tout simplement, il trouvera facilement plein de documentation et une assez grand communauté pour l'aider.

J'ai vu pleins de fois PHP se faire surpasser par python facilement.

PHP n'est pas le meilleur langage pour le web mais j'avoue qu'il fait bien son travail.

BohwaZ

Le choix du langage pour de gros projets où on maîtrise l'archi n'a rien à voir avec la "majorité", c'est un choix qui prends parfois du temps, principalement basé sur les compétences des développeurs à disposition, les performances et l'efficacité du langage, mais aussi plein de critères extérieurs, comme par exemple souvent ce qui existe déjà dans la boîte.

D'autre part, dire que Python ou Ruby ne permettent pas de produire du code moche c'est bien méconnaître ce dont il est question. D'ailleurs vous trouverez des dizaines de blogs sur le même thème que PHP : Why Python sucks, Why Ruby sucks, etc.

De manière générale vous trouverez toujours des développeurs pour produire du code horrible quel que soit le langage. Par exemple Javascript est également rempli d'exemples de code horrible alors que le langage est absolument génial, de même pour AS3. Dire que le code Python ou Ruby est forcément joli et tout rose c'est se fourrer le coude dans l'œil jusqu'au cerveau...

Zleug

"Le choix du langage pour de gros projets où on maîtrise l'archi n'a rien à voir avec la "majorité", c'est un choix qui prends parfois du temps, principalement basé sur les compétences des développeurs à disposition, les performances et l'efficacité du langage, mais aussi plein de critères extérieurs, comme par exemple souvent ce qui existe déjà dans la boîte."

Oui, sauf que les développeurs à disposition n'ont pas spécialement mis un mois pour choisir s'il faut apprendre ce langage ou pas. Un développeur qui cherche à faire du web va prendre du PHP sans hésiter, puis après un certain temps, il va commencer à philosopher et se demander si c'était vraiment un bon choix.

J'en connais pleins de devs web qui ont pris PHP directement parce que "c'est utilisé par la majorité des devs web", et les projets que tu cites, ils ont tous commencé comme "hobbies" et non comme un projet qui allait révolutionner le monde.

Facebook était lancé juste comme défi, un délire personnel. D'ailleurs, c'est pour ça qu'ils ont sorti pleins d'améliorations par la suite. (Le compilateur HIPHOP qui fait passer du php en C++, il est utilisé sur presque toutes les pages. etc.)

"D'autre part, dire que Python ou Ruby ne permettent pas de produire du code moche c'est bien méconnaître ce dont il est question. D'ailleurs vous trouverez des dizaines de blogs sur le même thème que PHP : Why Python sucks, Why Ruby sucks, etc."

Bien sûr qu'il y en a et heureusement, aucun langage n'est parfait. Mais je crois que vous avez pas vraiment saisi ce que je voulais dire.

Je parlais de la syntaxe du langages, la majorité des articles qui parlent de python/ruby, critiquent pas sa syntaxe mais plutôt sa lenteur ou bien le fait que leurs frameworks soient lourds.

"De manière générale vous trouverez toujours des développeurs pour produire du code horrible quel que soit le langage. Par exemple Javascript est également rempli d'exemples de code horrible alors que le langage est absolument génial, de même pour AS3."

Oui, absolument. Mais vous avez encore une fois mal saisi ce que j'ai dis.

Du code horrible, y en a deux types (ou plusieurs, j'en ai juste 2 en tête là): Le code qui marche mais qui n'est pas optimisé et du code qui marche mais qui est mal organisé.

Le premier, tu en trouves partout. Le deuxième, c'est rare d'en trouver dans du Ruby ou Python. Je dis pas que c'est impossible, je dis juste que c'est rare, parce que le langage que tu utilises te force en quelque sorte à suivre une certain méthode pour que le langage soit lisible.

Sous python, on dit qu'il y a une seule et bonne façon d'accomplir une tache, je crois que ça doit être ça :-)

Zleug

J'ai oublié de dire aussi que derrière les langages tel que python, il existe une philosophie, une sorte de poésie[1] qu'on trouve à peu près dans n'importe quel livre qui initie à python. Ça permet de dire à l'utilisateur que t'es pas juste entrain de pisser du code mais que t'es aussi entrain de produire quelque chose de beau.

[1] www.python.org/dev/peps/p...

Nicolas Chambrier (@naholyr)

PHP reste quand-même un des langages les plus dégueulasses qui existe, il ne faut pas se leurrer.

* L'incohérence de son API (ordre des paramètres, argument classique mais toujours aussi vrai).
* Gestion du modèle "objet" mauvaise, voire pathétique (le comportement de "self::" conservé et ajout d'un mot-clé "static::", du LOL en barre).
* Un parseur minable, qui donne lieu à des choix surréalistes (tiens, utilisons le "\" comme séparateur de namespace, sinon ça va être chiant).
* Une core-team qui a longtemps souffert du syndrome "tour d'ivoire" malgré un niveau de compétence qui ne méritait pas ce traitement (c'est en train de changer, mais doucement et dans la douleur…).
* L'absence du support d'Unicode. HELLO, on parle de *WEB* ? Pas d'Unicode ? LOL ? Même JS le supporte nativement depuis sa naissance...
* Des "fatal error" (pas des exceptions hein, ce serait trop simple) pour des choses qui ne relèvent pas de l'erreur de syntaxe ? Ben voyons, mais ça nous rappelle chaque fois que les exceptions n'ont été qu'un ajout tardif, et comme tout le reste mal intégré.

Ce langage n'a pour lui que sa popularité qui vient d'un autre âge (on parle d'une époque où le langage Web par excellence était Perl, PHP dans ce contexte a su s'imposer à juste titre de part une syntaxe proche mais une API globalement plus simple, et surtout très riche), et potentiellement son API effectivement très riche "out of the box".

À tous les autres niveaux, c'est un langage poubelle, il faut quand-même l'admettre, même si on l'aime bien parce qu'on a appris à vivre avec ses défauts.

MonkeyIsBack

Je code depuis très longtemps dans différents langages du web (asp php html javascript et autres) et le plus agréable à utiliser et à maintenir .....

Le javascript.

Bien sûr je ne parle pas du "vieux" JS (je n'en ferais plus jamais de ma vie, si j'ai besoin de retro-compatibilité j'utilise jQuery). Je parle du "nouveau JS", celui qui est supporté par tous les navigateurs récents (y compris IE :O), celui-ci est tellement BEAU, quand je code en javascript, je trouve que c'est de l'art.

Avant de m'intéresser réellement au javascript, je trouvais ce langage "inutile" et "dépassé", il ne représentait pour moi qu'une technologie obsolète, peu compatible et surtout TRES GOURMANDE en puissance (et ça, j'aime pas).

Je ne suis pas un "grand professionnel", je suis un autodidacte de la programmation. Mais coder en JS c'est ce que je trouve de plus agréable. La structure est minimaliste, l'imbrication des méthodes est fantastique et on arrive à un résultat concret en quelques lignes. Alors qu'avec d'autres langages (PHP pour le citer, puisqu'il est proche du JS dans son utilisation pour le traitement des données) ça prends souvent 3 a 4x plus de lignes, et donc de temps, pour arriver au même résultat. En plus c'est quasiment illisible et il faut tout commenter pour s'y retrouver ne serais-ce que deux semaines plus tard.

Je rêve d'un monde où PHP s'utiliserait comme le JS. Avec la même syntaxe. Tous ceux qui ont déjà dus compter et recompter le nombre de parenthèses fermantes à la fin d'une ligne PHP devraient être d'accord avec moi :P

J'avais lu quelques informations sur un hypothétique "server-side javascript" mais hélas je n'ai rien trouvé de bien concret. mais vu l'essort qu'a pris JS ces dernières années (et surtout son support vraiment amélioré dans tous les navigateurs), je pense qu'on peut espérer un jour avoir le choix entre PHP et JS :P

Tenez pour exemple, un système de "bureau virtuel" sur une page web en javascript/ajax (proof of concept uniquement) que j'ai réalisé :
http://www.monkey-shore.com/JSDesktop/

Je ne m'attends pas à des acclamations de la foule, mais je me demandais souvent POURQUOI toutes les applications "avancées" du javascript par les "gros sites webs contemporains" (genre boite mail yahoo) étaient si affligeantes en terme de performances (pourquoi Yahoo! mange 100% de la puissance de mon quad-core pendant 3 ou 4 secondes du chargement de la page ????), et je voulais créer moi même un code relativement "lourd" mais très optimisé sur une page, pour voir si c'était bien la faute des développeurs si JS semblait si merdique. La réponse semble être oui.