Javascript : le futur du web ?

Javascript est le langage de programmation dominant en 2012

Ce graphique est une copie des stats de Github concernant les projets hébergés. Tous les projets ne sont pas intégralement basés sur Javascript et Github n’est qu’une partie infime de l’informatique réellement déployée. Mais. C’est le symptôme d’une évolution certaine. DHTML, AJAX, WEB 2.0, jQuery et maintenant NodeJS. Aussi trollesque que soit mon accroche, Javascript sera un élément majeur de la prochaine génération de logiciels.

L’autre jour, on comparait PHP et JS. Même mauvaise réputation auprès des vrais programmeurs, mais malgré des défauts reconnus, PHP est devenu le langage web le plus répandu. Il est passé du script de template à un langage de frameworks MVC « sérieux » (Zend, CodeIgniter, Symfony) ; un facteur de réussite parmi d’autres dont l’existence d’une aide fournissant une abondance de snippets à copier/coller ; sa symbiose avec Apache HTTPD et MySQL appréciés par les administrateurs système ; une gestion des modules assez limitée qui évite de partir dans un modèle diffus à la CPAN ; et il faut bien le dire une instance centrale contrôlant le développement du langage.

Tandis que de l’autre côté JS n’avait pas d’aide centralisée, était dépendant des implémentations des différents éditeurs de navigateurs, avec des méthodes pourries pour faire marcher le même code partout, sans parler des lenteurs. D’où longtemps un truc pas excitant. Et avec des défauts structurels évidents toujours renouvelés. Aujourd’hui, une interface sans JS, c’est dépassé, on fait tout en AJAX, et du coup on se retrouve à devoir implémenter les mêmes modèles en JS et en PHP (ou autre). Ce qui est idiot parce qu’on écrit tout en double et que les bugs ne peuvent que se multiplier.

Javascript un langage « sérieux » côté serveur ?

La première fois que j’ai entendu parler de NodeJS, j’ai eu du mal à croire qu’on veuille faire tourner du Javascript côté serveur. Je suis vraiment devenu un vieux con sérieux, non ? Le plus serait en dehors de la réduction du code que ça mette les données au centre de l’application avec une forme d’ORM et de synchro automatique. Mais ça n’a de sens qu’à condition de disposer de frameworks permettant de conserver les bénéfices actuels.

Sécurité : filtrage des données, Sécurisation des accès, Gestion des ACLs,
Stabilité : application serveur robuste, pas de DOS, des scripts interdépendants sans compilation,
Déployabilité : simplicité d’installation, Interdépendance des applications au sein d’un serveur.

Qu’en est-il ? Wikipedia fait une comparaison de solutions existantes et j’ai de mon côté relevé celles-ci en attendant de les tester.

NodeJS (Sa fiche sur Wikipedia) Node est un serveur (et pas un framework) encore jeune et évoluant rapidement. Du point de vue sécurité, si je crains le pire, les buffer overflows sont pour tout le monde ;). Pour la stabilité il faut relancer chaque application à la main en cas de plantage du serveur, donc médiocre. Et sur l’aspect déploiement il semble que ce soit plus infernal qu’autre chose à l’heure actuelle côté serveur pour l’administrateur Linux. L’argument de Node est d’être plus rapide et plus « scalable ». A voir. Une fois Node installé, il faut choisir ses outils de développement, et là ça se complique.

Quelques frameworks Node

Geddy, Express et son parent Connect, Flatiron… il est clair que les Frameworks Node ne manquent pas, sans compter les modules du NPM qui permettent de recomposer son propre stack en fonction de ses besoins. Aperçu de quelques.
Connect : est le premier framework Node ayant « décollé ». Il met à disposition un grand nombre de fonctionnalités essentielles et dispose de nombreux composants additionnels. Au niveau sécurité, il met à disposition un nombre minimal d’objets ( csrf par exemple ) mais la validation requiert des éléments supplémentaires.
Express : basé sur Connect, Express offre une gestion facilitée en MVC. Au niveau sécurité des entrées / sorties il améliore certes Express mais pas tant que ça.
Geddy : est une version plus complète, avec une sécurité améliorée, une gestion du scaffolding en ligne de commande et de l’ORM. Également basé sur Express il adopte le modèle MVC avec validateurs et gestion des vues. Il peut travailler avec plusieurs backends SQL & noSQL. Il semble que RailwayJS qui a pour objectif d’introduire les idées de Rails dans Node soit assez proche et bien pensé.
Flatiron est (encore) une autre solution qui combine plusieurs modules pour fournir les services de base attendus d’un framework MVC comme le routage, les logs, la gestion du backend et des vues. Son argument est identique à celui des autres projets : simple, « non-obstrusif », léger.

D’autres solutions existent pour Node (Matador, Monorail, Grasshoper… ) qui se fondent toutes sur ces mêmes arguments et il faut bien l’avouer, de loin ont un air de ressemblance assez marqué ;).

Et en dehors de Node ? Backbone & co.

NodeJS apparaît comme une boîte à outils avec un gestionnaire npm intéressant mais d’autres approches existent, dont un certain nombre exécutent le routage de l’application côté client, en gros en limitant au maximum les échanges entre le serveur et l’application à des appels d’API sans html. Ce qui entre autres laisse entrevoir des possibilités importantes concernant l’utilisation offline et le stockage en local.

BackboneJS (page wikipedia) est une référence autant que Node peut l’être. Comment marche Backbone ? Dit simplement, il met à disposition du navigateur tout ce qui est nécessaire pour transformer les données brutes reçues du serveur, les modifier et les renvoyer. Il s’appuie notamment sur la dimension prototypique de javascript pour les objets autorisant leur modification à chaud (ie. Monkey Patching et Duck Typing). Backbone est notamment réputé pour son efficacité en tant que client mobile universel : à la fois léger en termes de code et d’échanges réseau, il s’adapte bien à tous les systèmes. Exemple : Soundcloud l’a utilisé pour son client mobile et désormais va l’utiliser partout. Une fois encore, l’argument de légèreté, d’interdépendance et de simplicité est récurrent : Backbone n’a qu’une seule dépendance (UnderscoreJS) et laisse le choix des outils de template par exemple.
Et alors, côté serveur ? Pour en revenir aux critères de départ, la sécurité par validation est limitée et bon nombre de choses ne sont pas fournies. La stabilité est plutôt bonne avec un minimum de ressources côté serveur. Backbone échangeant directement des objects en JSON, la solution « naturelle » consiste à stocker les données dans une base NoSQL comme MongoDB en utilisant les mêmes objets pour la validation. Mais on pourrait aussi faire un backend dans un autre langage (genre PHP MySQL). Idem pour le déploiement, il peut être de fait minimal.
EmberJS est une solution plus récente qui se base sur le modèle de Backbone en ajoutant notamment une automatisation des changements d’apparence reliée aux flux de données. Si elle offre plus de fonctionnalités c’est au détriment de la simplicité. http://smus.com/backbone-and-ember/
SpineJS dans cette lignée est très complet : MVC, ORM, échanges asynchrone, relation directe entre affichage et données, stockage navigateur, version Mobile : pas grand-chose à demander de plus. C’est un framework encore jeune mais prometteur.
ExtJS (page wiki) a connu plusieurs itérations. Il se présente comme une solution plus lourde offrant traditionnellement une palette de composants. Il offre désormais en plus du MVC, une interface RestFul et des méthodes de générations de graphiques. Dans l’ensemble orienté vers l’application « Desktop » il manque certaines fonctionnalités importantes comme la validation de données. De même l’ORM est disponible mais sous forme de plugin externe.

Il y en a d’autres, cette liste (en anglais) donne les avantages et inconvénients. Un point intéressant concerne notamment la simplicité du « data binding », en d’autres mots la mise en relation entre éléments de l’interface et sources de données dans les vues pour parvenir à des mises à jour automatiques. En l’occurrence si certaines formes sont un peu laborieuses comme dans Knockout

First name:

Dans Ember en revanche on déclare les bindings directement dans l’objet

... attributeBindings: ['data','value','format','readonly','type','size'], ...

Ce qui est effectivement beaucoup plus léger et centralisé.

Automatisation des relations entre données et objets

Un des principes directeurs des différentes solutions évoquées, en tout cas parmi les plus avancées, consiste à simplifier au maximum le travail du développeur grâce à une définition des objets permettant à la fois leur manipulation, leur affichage, leur validation et leur stockage. Soit à mon sens une continuation des méthodes d’ORM/scaffolding utilisées notamment par Django ou Rails. C’est à mon sens une direction intéressante ; la dernière application PHP que j’ai testée dans ce domaine est PimCore qui s’appuie sur ExtJS pour proposer une ORM qui génère des fichiers de classes modifiables et des tables de bases de données tout en présentant graphiquement les champs comme des composants de formulaire, avec la possibilité de modifier son modèle en fonction des besoins. Pour la plupart des interfaces de gestion c’est une solution intéressante, rapide et souple.

Autre paradigme intéressant, l’échange direct d’objets sérialisés entre frontend et backend, qui justifie pleinement l’emploi de bases de données orientées document pour y stocker les objets json. Les problèmes d’indexation que connaissent ces bases sont connus mais à l’avenir ce genre de technique devrait largement justifier leur utilisation.

Conclusions

Première conclusion évidente, il y a une diversité de solutions qui répondent à des moyens et des besoins (taille du projet, temps de déploiement) différents. En l’état il n’y a pas de solution qui se dégage absolument mais un paysage contrasté et évoluant rapidement.

Les bénéfices potentiels qu’apportent les nouvelles solutions, dont il faut bien observer qu’elles reviennent à faire du Flash en HTML5, vont par nécessité devenir la norme des applications web haut de gamme et évoluées, tant elles peuvent avoir des attraits importants pour les utilisateurs en terme de confort et de portabilité.

Ensuite, il apparaît que certaines sont relativement faciles à déployer dans un environnement Linux du fait de leur exécution côté client, bien qu’à terme pouvoir exécuter du code JS côté serveur soit déterminant dans l’optique de l’isomorphisme du code (ie. modèles identiques des deux côtés), permettant de bénéficier au maximum de Javascript.

Dans la mesure où l’on peut utiliser des backends solides, on peut tout à fait utiliser ces techniques pour réaliser des applications web de gestion « sérieuses » qui resteront néanmoins coûteuses à produire.

Il apparaît aussi que NodeJS et nombre de ces solutions soient utilisés pour des applications à forte demande. Ce qui est assez amusant tant l’évocation de cette idée tend à faire fuir immédiatement un administrateur système traditionnel :)

TL ;DR

Wooh ! new JS code is awesome ! But… Hey guys did you know… that ummm… Your apps ? They need to deploy everywhere and be safe !