J’ai retrouvé un vieux brouillon de mon intervention aux rencontres Django (novembre 2012) donné sous le titre « Pourquoi je ne veux plus utiliser Django ? ». Je le publie en l’état et je reviens dessus à la fin.
Titre clairement provocateur pour cette intervention aux rencontres Django de Toulouse qui est né d’un ressenti que j’ai depuis quelques mois/années. Je vais essayer de détailler les doutes que j’ai sur le futur de Django et Python. Je vois plusieurs défis majeurs pour les mois à venir :
Python 3
Python 3.0 est sorti il y a 4 ans quasiment jour pour jour (3 décembre). Qui l’utilise aujourd’hui ? Qui a un projet web en production qui repose sur cette version ? Très peu. Principalement car la rétro-compatibilité n’a pas été conservée pour cette version ce qui pose clairement des problèmes de mise à jour des bibliothèques sans lesquelles un projet ne peux pas se faire aussi rapidement qu’en 2.X. C’était un risque énorme qui a été pris et la communauté en paye le prix fort. Combien faudra-t-il encore d’années pour que cela change ? Quels sont les gains réels ? Qu’en est-il de Pypy ?
Et quitte à réapprendre une partie du langage, est-ce qu’il ne faudrait pas aller voir ce qui se fait ailleurs ?
Node.js
Node.js is a tumor on the programming community, in that not only is it completely braindead, but the people who use it go on to infect other people who can’t think for themselves, until eventually, every asshole I run into wants to tell me the gospel of event loops. — Ted Dziuba, Fibonacci’s lover
Phénomène de mode ou futur proche ? Il y a énormément de côtés plaisants à Node.js : notion de callbacks, promesse d’une validation des données partagée entre le client et le serveur, performances, etc. Par contre le manque de maturité est vite bloquant aussi : traceback incompréhensibles, outils insuffisants, manque de bonnes pratiques et de retours d’expériences, etc. Certains ont clairement fait le choix de s’engager dans cette voie mais ça me rappelle bien trop l’engouement autour de Ruby on Rails il y a quelques années auquel j’ai résisté et dont je me félicite aujourd’hui (ce n’est pas une critique de RoR sans lequel Django ne serait très certainement pas ce qu’il est aujourd’hui).
Flask
OH: "Microframework (n): A small amount of crap. See also Framework (n): A large amount of crap." — @nikita_ppv
Django se complexifie. Release après release. L’héritage des class-based views est assez symptomatique du problème (disclaimer : j’ai participé à ce sac de nœuds…) de la généralisation à outrance qui nuit au framework. Les alternatives comme Flask sont alléchantes mais il y a des frameworks basés sur Node.js qui arrivent aussi et qui apportent des réponses aux problématiques de temps-réel, ou plutôt…
Temps-humain
J’ai abandonné le terme temps-réel qui ne veut pas dire grand chose au profit de celui-ci qui repose sur la perception humaine de rapidité que l’on peut avoir avec une interface et qui me semble beaucoup plus proche de la réalité. Il est toujours relativement compliqué d’utiliser les websockets avec Django et même Python. Comment développer les applications interactives de demain ?
Et après ?
It’s so much easier to talk about how something sucks than to talk about how it could be awesome. Negativity is for the lazy. — @defunkt
Parlons d’avenir et de web. Il y a eu 2/3 évolutions ces dernières années dans les implémentations et leurs usages (car les standards existent depuis un moment) permettant d’introduire de nouveaux paradigmes dans le développement d’applications. Voici quelques exemples de pistes à explorer :
- API-first : le modèle MVC a pris du plomb dans l’aile avec la multiplication des périphériques et des moyens de consommation des données, il faut repenser la gestion de la donnée ;
- asynchronicité : certaines requêtes mettent plus de temps que d’autres mais ce qui importe c’est la perception qu’à le visiteur de la réactivité de votre application, il manque des outils permettant de gérer ces cas aux limites qui font pourtant parfois la valeur réelle de l’application ;
- single page apps : de plus en plus de sites se développent en n’utilisant qu’une seule page, il y a même un livre dédié à ce concept, or les frameworks ont bien souvent un contrat unique de requête/réponse par page qui répond mal aux exigences d’une mise à jour partielle de page ;
- mobilité : le web est dans de plus en plus de poches, à portée de doigts, avec une inégalité des accès au réseau en fonction de la localisation. Il faudrait que les frameworks soient adaptés à ces nouveaux usages avec du stockage local et de la synchronisation, avec des rendus adaptés aux vitesses de connexion, avec des concepts moins gourmands en énergie et en bande passante.
J’espère que ces pistes seront partie prenante des discussions relatives à Django 2.0 ou de nouveaux frameworks que j’espère en Python. Ces nouveaux paradigmes me redonneraient à coup sûr l’envie de développer en utilisant Django ;-).
Retour en 2015
Malheureusement, 2 ans plus tard, j’ai toujours les mêmes doutes sur le futur de Python/Django. J’expérimente avec ReactJS depuis maintenant un an. Relire ce tweet me fait sourire de naïveté :
ReactJS is to Web Components what microformats were to Semantic Web. And I can’t conclude anything from that.
Il y a une effervescence dans la communauté JavaScript qui serait grisante si elle ne cessait de réinventer la roue. Plusieurs fois. Mais force est de constater qu’il y a des pistes intéressantes dans ReactJS : ils ont justement « repensé la gestion de la donnée » avec Flux, ils permettent l’asynchronicité, on peut faire des SPA sans se prendre la tête, ils expérimentent avec la mobilité (React Native et GraphQL/Relay ont été annoncés ce jour). Autant d’approches que je n’ai pas vues dans la communauté Python. Je ne compte pas dire au revoir à Python (cache) car je prends toujours beaucoup de plaisir à coder avec mais je commence à me poser de sérieuses questions sur sa pertinence pour des projets Web réactifs (huhuhu).
