Les vrais-faux débats et polémiques autour des développements informatiques sont légions, et ceci dans tous les domaines, par exemple : sur le mobile HTML5 vs. Applications natives, Java vs .Net, C++ vs Objective C etc… Selon le point de vue ou la culture de chacun, les opinions divergent rapidement, mais au final, tout le monde à raison. 
Un billet de Mike Driscroll m’a interpellé et témoigne de l’évolution du développement web ces 20 dernières années. Celui-ci a en effet subi de profonds changements depuis sa naissance.
On peut en effet distinguer 3 phases. Tout d’abord dans les années 90, l’ère des pages HTML statiques. Les pages étaient développées une à une avec très peu d’interactions. Ensuite dans les années 2000, avec l’arrivée des bases de données en ligne et des langages pouvant s’y connecter, comme les plateformes LAMP (Linux, Apache, MySQL, PHP) ou similaire (CGI, Ruby On Rails, Python), le contenu et la structure des pages est devenu dynamique. Le serveur génère alors les pages HTML à partir de modèles (templates).
L’utilisation de plus en plus accrue du langage Javascript et notamment de la technologie AJAX intégrée au sein du navigateur client a permis d’offrir une interaction plus fluide entre l’utilisateur, la page web et le serveur. Les pages sont alors constituées d’éléments indépendants et autonomes, chargées de manière asynchrone grâce au langage Javascript. Fort de cette souplesse, nous n’avons alors plus de document composé à 100% de HTML, mais un document écrit en grande partie en Javascript. Des frameworks Javascript ont alors percé dans le milieu des développements web comme JQuery.
Le problème aujourd’hui est qu’utiliser cette méthode d’interaction avec une architecture technique comme LAMP impose une charge serveur relativement importante pour un simple rafraîchissement d’une partie de la page. Comme l’indique Mike Driscoll, “quand les templates sur votre serveur LAMP sont composés de 10% de HTML et 90% de JavaScript, il y a un problème“.
Dans cette configuration, il serait donc plus judicieux que le serveur envoie des données et des fonctions directement en Javascript et en JSON (le format de transmission de données adapté à Javascript). A partir de cela, c’est le navigateur qui va faire le rendu de la page. Le rôle du serveur est d’être à l’écoute de l’ensemble des actions et événements générés par l’utilisateur lors de la consultation de la page.
Node.JS répond donc à ce problème en proposant un serveur basé sur le célèbre moteur Javascript V8 (utilisé par Chrome), permettant de développer en JavaScript côté serveur. Sa gestion des connexions de manières non bloquantes permet d’avoir des applications performantes et pouvant tenir de fortes charges. Ce système de connexion va permettre de gérer les événements de manière interactive et en temps réel. Node.JS est Open Source, intégrant de nombreux modules, avec une communauté très active derrière.
Le Javascript va t-il supplanter les autres langages web ? Node.JS est une technologie pleine de promesse pour les développeurs. Les utilisateurs naviguent aujourd’hui de manières différentes avec une page web. Les attentes sont donc plus fortes et surtout tout doit aller encore plus vite. L’interaction et la réactivité d’un site est primordiale, sinon l’utilisateur s’en va. Node.JS est encore jeune, peut être pas encore assez stable pour une service à mettre en production. C’est un couche technique supplémentaire à savoir gérer. De plus le javascript n’est pas visible par les crawlers des moteurs de recherche, ce qui est un problème pour le référencement naturel. Mais une chose est sûre, si vous avez un bon développeur javascript sous le coude, ne le lâchez pas, il pourra vous être encore plus indispensable à l’avenir !
GWT is your best friend
C’est vrai, le javascript c’est du binaire, pas de soucis.
Comme je l’ai expliqué dans plusieurs conférences ces derniers mois (voir mon slideshare : http://www.slideshare.net/quentinadam ) bien d’autres outils vous permettent de faire du javascript serveur side… qui sont bien plus stables !
Je ne vous recommanderez jamais assez APE http://www.ape-project.org/ particulièrement intéressant pour commencer, ainsi que cloud9, IDE online.
Pour conclure en abondant : good javascript dev are just like unicorn, rare.
l’éléphant PHP me manque déjà :’(
Avant de commenter, je souhaite préciser que je n’aime pas du tout PHP et suis ravi de voir une solution comme node.js pointer son nez. Toutefois, cet article contient beaucoup d’imprécisions, de points non justifiés et d’omissions.
“Le problème aujourd’hui est qu’utiliser cette méthode d’interaction avec une architecture technique comme LAMP impose *une charge serveur relativement importante* pour un simple rafraîchissement d’une partie de la page.”
=> C’est dit, mais pas justifié. En quoi la charge est importante avec une application dite “ajaxifiée” en PHP ?
“Comme l’indique Mike Driscoll, “quand les templates sur votre serveur LAMP sont composés de 10% de HTML et 90% de JavaScript, il y a un problème“.”
=> Il l’indique, mais ne le justifie pas une seule seconde. Les templates sont peut-être composés de 90% de JavaScript, mais les autres composants serveurs pourraient répondre du JSON tout aussi efficacement qu’un node.js.
La composition d’un template ne varie pas en fonction du langage employé sur le serveur. PHP est un langage de template HTML, mais node.js promeut aussi des langages de template HTML: https://github.com/joyent/node/wiki/modules#templating
“Dans cette configuration, il serait donc plus judicieux que le serveur envoie des données et des fonctions directement en Javascript et en JSON (le format de transmission de données adapté à Javascript).”
=> L’argument d’envoyer “des fonctions” est idéalisé pour le moment. Je suis la question et je n’ai pas encore vu de projets qui utilisent intensivement cette fonctionnalité pour justifier d’utiliser le même langage côté client et côté serveur.
=> A propos de JSON, il n’est pas plus adapté à JavaScript qu’à un autre langage. Voir la liste des langages et bibliothèques en bas de http://json.org/. Certains langages comme PHP ont même un support natif : http://php.net/manual/fr/function.json-encode.php
JSON est bien pour ce qu’il est. Le fait qu’il soit inspiré de la description des objets en JavaScript est une (heureuse) coincidence.
“A partir de cela, c’est le navigateur qui va faire le rendu de la page. Le rôle du serveur est d’être à l’écoute de l’ensemble des actions et événements générés par l’utilisateur lors de la consultation de la page.”
=> Ce genre d’architecture est ce que fait Facebook par exemple. Ils n’utilisent pas Node et ne le feront sûrement pas dans le court ou moyen terme. La particularité de Node n’est pas là.
Il est aussi relativement abusif de comparer “une architecture LAMP” et “node.js”. Actuellement, node.js remplace le “P” de LAMP. Linux va rester (Node.js n’est pas un OS), Apache va rester (idéalement, Ryan Dahl aimerait un jour que le projet soit suffisamment stable pour le faire sauter aussi), MySQL va rester (Node.js n’est pas une BDD).
“Sa gestion des connexions de manières non bloquantes permet d’avoir des applications performantes et pouvant tenir de fortes charges.”
=> La vrai plus de node.js par rapport à n’importe quel langage est presque cité. “connexions non bloquantes”. En fait, ce sont toutes les Input/Output qui sont non bloquantes. C’est la première phrase sur le site de node.js : “Evented I/O for V8 JavaScript.” et je pense que c’est l’avantage majeur par rapport à tous les autres langages. Il est dommage que l’article ne commence pas par là !
Les requêtes aux bases de données, les lectures/écriture sur les fichiers sont évenementiels aussi. Pour mieux comprendre tout ça, je conseille de regarder les vidéos/présentations de Ryan Dahl où il présente node.js (voir à la fin de http://nodejs.org/#about ou sur Youtube ou google vidéo ou les vidéos de la JSconf). Il l’explique bien mieux que je pourrais le faire.
S’il n’y avait qu’une seule chose à retenir sur node, il faudrait que ça ne soit pas le buzz qui consiste à dire “du JavaScript côté client !”, mais plutôt l’excellent travail qui a consisté à définir une “API évenementielle” pour beaucoup de formes d’I/O et surtout de considérer toutes les I/O (réseau, file system, Base De Données…) de manière évènementielle.
“Ce système de connexion va permettre de gérer les événements de manière interactive et en temps réel.”
=> Cette phrase donne l’impression que ce n’est pas possible avec d’autres technologie. C’est faux. Le “temps réél”, on peut déjà le faire en PHP, en Java, en Ruby-on-Rails, en n’importe quel langage. Ce n’est pas une spécificité de node. Au mieux, node apporte une petite facilité dans l’écriture de tels programme. Et encore, ça reste à prouver.
“De plus le javascript n’est pas visible par les crawlers des moteurs de recherche, ce qui est un problème pour le référencement naturel.”
=> PHP, Java, Ruby-on-rails non plus. C’est un problème qui n’a rien à voir et qui est dû aux applis “ajaxifiées” en général. Je conseille de lire des articles sur la controverse des “hash-bang urls” pour mieux comprendre le problème et les différentes approches utilisées pour le résoudre. Celui-ci est très bien : http://www.jenitennison.com/blog/node/154
Je lis TCFR et aime beaucoup les articles en général, mais je ne vous cacherai pas que j’ai été déçu par cet article qui survole le sujet de manière superficielle et rate le point principale de node et de sa différence majeure par rapport aux autres langages.
Vous avez mon adresse mail, vous pouvez me contacter par mail si vous le souhaitez.
+1 sur toutes les remarques techniques qui m’ont également interpellées lors de la lecture de l’article et que tu as parfaitement expliqué.
+1 pour TCFR pr cet article qui rappel que c’est la technique et donc les développeurs qui créent réellement les sites, et pas les entrepreneurs qui sont surtout là pour lever de l’argent puis faire de la RH et avoir des idées (même si la croyance que les développeurs n’ont pas d’idées me dérange beaucoup).
@David Bruant TCFR s’adresse surtout aux entrepreneurs qui ne comprennent pas les détails de la technique, a leur niveau cet article fait plutôt bien son travail cf la conclusion et son conseil RH:
“Mais une chose est sûre, si vous avez un bon développeur javascript sous le coude, ne le lâchez pas, il pourra vous être encore plus indispensable à l’avenir !”
Merci pr cet article qui présente JavaScript de façon abordable pr tous. Ma réponse est celle d’un tech (qui a programmé en PHP, Java, C) et qui pense que JavaScript et Node.js vont casser la baraque dans les années à venir. Pk?
1-Le JS est le seul langage “obligatoire”. Vous pouvez faire votre site web 100% en JS (JS, Node, Mongo par ex) mais impossible de le faire 100% en PHP, Rails… (sauf en inlinant du JS ds les strings). En plus, le JSON, format de données le + utilisé sur le web, est natif au JavaScript et dc plus facilement manipulable. Manipuler du JSON en Java se fait très bien mais comme c’est lourd…
2-Côté Performance, Node offre des performances bien supérieures à PHP, J2EE, Rails car les connexions réseaux sont mieux gérées (sockets non-bloquantes VS threads). Derrière, c’est du C, C++ et du code machine V8 qui sont beaucoup plus rapides que des langages avec bytecode ou non compilés.
3-C’est de la programmation fonctionnelle qui permet de faire du code, certes moins verbeux qu’en programmation objet (cf Scala) avec des lambdas fonctions et des closures, mais surtout très adapté au modèle évenementiel des sockets et lecture/écriture non-bloquantes à l’origine des meilleures performances.
4-Node est très bas niveau (proche de la machine), et ça j’adore, on manipule directement les sockets et les processus, on joue avec les bibliothèques C, C++. Ce qui permet d’avoir des meilleures perfs et de faire des choses qui sont impossibles à faire avec du PHP ou Rails.
5-Il y a une guerre Javascript entre Google, Apple, Mozilla pr leurs navigateurs. Résultat les moteurs Javascript augmentent augmentent de vitesse d’au moins 150%/an. On peut pas en dire autant de PHP ou Java.
Pour finir, c’est vrai que Node est jeune, que les modules n’ont pas la meme stabilité qu’en PHP par ex. Mais surtout, il lui manque un géant du web. Aucun Google, Twitter n’a encore adopté Node comme back-end. On remarquera qd même qu’un géant comme VMWare intégre Node.js avec Rails et Java Spring (pas de PHP) comme les 3 plateformes majoritaires de son offre Paas Cloudfoundry. C’est pas insignifiant du tout.
Bref, je vs recommande de tester Node.js, c’est une bête de course assez sympa! Et pas trop dur à dompter!
2ème géant qui a adopté Node.js: HP dans WebOS.
Un peu de retour aux sources, on oubli trop souvent que dernière des sites, des concepts, des plateformes etc. Il y a des devs, des techos, des geeks qui rendent toutes ces idées possibles.
Merci Renaud de redonner à TECHcrunch une orientation technique !
Pour ce qui est de Javascript, c’est clairement un langage qui va devenir majoritaire.
Javascript est de plus en plus incontournable dans les développement Web surtout avec l’arrivée des différents framework tel que jQuery.
Mais ce qu’on oublie le plus souvent est que javascript n’est pas un langage 100% fiable et qu’un site fait uniquement avec Ajax ne marchera plus si l’utilisateur désactive l’exécution des scripts dans les paramètres de son navigateur !
Merci pour cette information, j’ai tout de même hâte de voir à quoi pourrait donner ce Node.JS, surtout cette idée de Javascript côté serveur, mais de mon point de vue je préfèrerais quand même rester sur PHP.
Enfin un article tech
ça fait qques temps que je le dit aussi … javascript est parti pour remplacer pas mal de choses
avec le html5, et les plateformes mobiles … le JS va rulez pour un bout de temps !
google l’avait pré-senti … ils ont racheté appjet il n’y a pas très longtemps … et l’appjet/javascript dans google app engine, à mon avis : ça va vraiment pas tarder !
mon petit doigt me dit qu’ils sont en train de lécher le produit, pour faire une arrivée fracassante, avec des slogans du style “coder en JS, ça s’executera, suivant les besoins, soit sur le client, soit sur le server” … on le verra encore cette année, à mon avis ! Le JS+cloud ; une évidence presque …
les probs de la POO étant mis à mal, et le prototypage/templates ayant le vent en poupe : c’est du tout bon …
+1 … “et ca marchera encore mieux si vous utilisez chrome comme navigateur ou os..”
et bientôt les Google Houses ou vous pourrez facilement garer votre Google Car !
Tient ce n’était pas l’idée de Netscape à la fin des années 90, le Web n’est qu’un éternel recommencement.
+1 avec David Bruant. Tout a été dit pour ma part.
Et merci à l’auteur, Renaud Euvrard, ça fait toujours du bien lorsqu’on est un digital native, développeur web professionnel (Symfony & Javascript), de voir des articles sur TechCrunch
Par contre pour jouer à celui qui a la plus grosse, PHP a quand même plusieurs beaux exemples de sites utilisant le “temps réel” … Facebook
Et qu’on vienne pas dire que c’est un “petit” site.
Ce que je pense du Javascript côté serveur, il va simplement rejoindre les différentes technologies déjà présente comme RoR, ASP, PHP, etc. PHP a encore de belles années devant lui en Europe, et plus particulièrement en francophonie, ayant enfin une version stable, mais surtout complète, et mature, grâce à sa version 5.X.
Facebook est en C++. Ils avaient commencé en PHP, et c’est justement parceque ce n’est plus un “petit site” qu’ils sont passé de PHP a C++. Ce qui leur a permis d’economiser 50% des ressources serveur
Source ?
Le chat Facebook c’est du Erlang du coté du serveur, cf http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf
Source : http://www.korben.info/hiphop-le-compilateur-php-de-facebook.html
http://www.zdnet.fr/blogs/greenit/hiphop-facebook-divise-par-deux-le-temps-d-execution-de-php-39712771.htm
http://www.presence-pc.com/actualite/facebook-php-38103/
Ils ont cree le framework HIP HOP expres pour ca.
Justement, tout ces articles confirment que les développeurs de Facebook développent toujours en PHP. Le code a beau être convertit en C++ avec “Hip Hop” avant d’être compilé, il faut d’abord l’écrire en PHP.
Thomas,
Ca change rien. Facebook est donc en c++, l’interpreteur PHP n’est plus utilisé , c’est ce qui d’ailleurs permet d’economiser en serveur.
Ils peuvent aussi ecrire directement en C++ pour HIP HOP, sans passer par PHP. Le but etait surtout de ne pas refaire tout ce qui avait deja ete fait.
Me souvenant de cette discussion et étant tombé sur cette article, je ne peux m’empêcher de le partager :
http://php.webtutor.pl/index.php/2011/04/04/hiphop-for-php-benchmark-revenge-of-php/
Merci pour tous vos commentaires ! Tous très intéressant… et très motivant de continuer sur cette voie.
Juste pour revenir sur l’approche de cet article, effectivement je ne suis pas rentré dans les détails et pour les plus “techniques” d’entre vous cela peu paraître un peu survolé. En faite, j’ai voulu juste partager avec les lecteurs de TechCrunch, qui je le pense, sont un peu moins techniques, les nouvelles tendances de dev dans le web.
N’hésitez pas à me transmettre d’autres sujets “techniques” que vous jugez intéressant de partager (renalid [at] gmail.com / @renalid)
Oui, je pense que je me dois de recommencer par un “merci”
Même si je pointe pleins de détails techniques et que je suis très pointilleux sur ce qui est dit, l’article est quand même très bon au vu de la cible pas nécessairement technique de TechCrunch ; je me suis un peu emporté.
Pour le côté technique de node.js, les vidéos de son créateur, Ryan Dahl sont excellentes (en anglais):
- http://www.yuiblog.com/blog/2010/05/20/video-dahl/ (1h. le son est mauvais. Je conseille de télécharger la vidéo, d’ouvrir avec un player et de jouer avec l’égaliseur pour rendre le son )
- http://www.youtube.com/watch?v=F6k8lTrAE2g (1h)
- http://jsconfeu.blip.tv/file/4306320/ (30min. Si vous aimez un peu le JS, regardez toutes les vidéos de la JSConf et JSConf.eu. D’ailleurs, la JSConf US commence demain !)
Si vous n’avez que 15 minutes, regardez les 15 premières minutes de la première vidéo.
La hype de 2010, qui continue sur 2011.
NodeJs + CouchDb = full javascript
IMHO, c’est une nouvelle boite à outils parfaite pour des projets de type nouvel outil parfait pour des sites-services de type Foursquare ou Twitter.
Mais les problématiques liées au référencement par exemple dissuaderont les sites de contenu à migrer.
Et c’est ce qui est chouette : le web apporte plein de solutions techniques. On a plus qu’à choisir la bonne en fonction de la direction de son projet
Comme le dit Truffo, c’est le retour de LiveWire de Netscape.
Qui est le %$#! qui a eu l’idée PHPisser sur le web dans les années 90?
C’est pas PHP qui a tué LiveWire, c’est Java si je dis pas de bétises
En refaisant le test de calcul récursif tout simple (fibonacci) trouvé sur http://www.metal3d.org/index.php/blog/ticket/2011/07/21/Et-si-on-regardait-nodejs
, j’ai calculé que NodeJS est juste environ 20x plus rapide que PHP, et 14x plus rapide que Python… et à peine 1.5x plus lent que le C…
Faut relativiser un peu (suivant ce qu’on essaiera de faire les rapports seront sûrement différents), mais c’est quand même plutôt séduisant et c’est pas ça qui va me faire aimer PHP..
Dans javascript la complémentarité avec HTML5 (multi-plateforme), la gestion des classes, des objets et des contextes (namespaces, closures) me branchent.
Le fait de pouvoir coder en javascript du coté serveur comme du coté client est un plus, notamment pour le sentiment de cohérence qui s’en dégage, et la possibilité de copier/coller pour faire passer quelque chose d’un coté à l’autre.
Sans compter qu’avec NodeJS, même le serveur est codé en javascript. (Peut-être qu’à l’échelle de Facebook c’est pas la meilleure solution, mais si ils avaient utilisé NodeJS, l’écriture d’un compilateur pour le code PHP existant aurait été 20x moins nécéssaire…)
Perso ça fait quelques mois que j’ai adopté NodeJS. Bien que les performances de V8 aient orienté mon choix vers cet interpréteur, en dehors de ce que j’ai déjà cité c’est surtout la gestion des évènements asynchrones et des modules que j’ai apprécié. Le fait que NodeJS pousse la notion de closure un peu plus loin est également intéressante.
J’intègre déjà mes applications web dans l’exécutable de NodeJS, il ne reste plus qu’à trouver une solution multi-plateforme pour rajouter un browser dans la combine ou inversement, afin de pouvoir écrire des applications web standalone et pas seulement des serveurs…
Le Roi est mort, vive le Roi
d’autres benchmarks, avantage V8
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=php