L’impact de Django

Armin Ronacher, membre de la Pocco Team, est le principal développeur de nombreux projets libres comme le langage de template Jinja et le microframework Flask, qui sont des programmes Python très populaires et d’excellente qualité.

Le 8 juin, lors du DjangoCon Europe 2011, il a fait une présentation intitulée The Impact of Django ayant un contenu similaire en bien des points à mon article du 6 juin intitulé Et le meilleur framework web Python est… Django !. Vous pouvez voir la conférence en ligne et en consulter ou télécharger les slides.

Bien sûr, il est assez plaisant de constater qu’un développeur, qui n’est pas loin d’être le meilleur au monde sur le sujet, fait une analyse très proche de la mienne en particulier en prenant le contre-exemple de TurboGears et en montrant l’influence du langage de template de Django. Cependant, il ajoute deux éléments  d’analyse, l’un social et l’autre juridique.

Premièrement, Armin pense que, d’une manière assez similaire à Ruby on Rails pour Ruby, Django est actuellement la locomotive du langage Python :

Django is the reason Python is getting that much attention lately.

Ainsi, environ 1 200 des 15 000 paquets disponibles sur PyPi contiendraient « Django » dans leur nom, de même que 10 000 des 77 000 dépôts sur GitHub et 3 000 dépôts sur Bitbucket. Si Python est beaucoup plus utilisé que Ruby en dehors du web, l’importance de ce dernier est telle qu’il est logique que le logiciel qui y est leader soit aussi le leader du langage.

Deuxièmement, Armin lie le succès de la licence BSD dans la communauté Python avec celui de Django et de son écosystème. Ansi 700 des 2 500 paquets sous licence BSD sur PyPI sont classés Django. Et surtout la licence BSD semble être utilisée par des projets assez récents, quand les plus anciens privilégiaient la licence GNU GPL.

Le choix de la licence est quelque chose de fondamental pour un logiciel libre, et il faut réfléchir aux implications réelles qui en découlent. En pratique, dans le contexte du serveur web qui est celui de Django, la licence GNU GPL n’est pas spécialement plus contraignante qu’une licence BSD, n’obligeant pas à redistribuer le code source modifié, et choisir l’une plutôt que l’autre n’a donc pas vraiment de signification pertinente.

Pour ce type de logiciel, si l’on veut voir s’appliquer la puissance du copyleft, il faut utiliser la licence GNU Affero GPL. À titre personnel, c’est la licence que je conseille, mais si l’on veut une licence libérale, alors je trouve effectivement plus clair de choisir une licence BSD qu’une licence GNU GPL vidée de sa substance par le contexte du logiciel serveur.

Tags: , , , , , , , , , ,

4 Responses to “L’impact de Django”

  1. yoko dit :

    Je trouve dommage de chercher à mettre en concurrence pour chercher une meilleure solution au lieux de les évaluer et d’expliquer les avantages et les inconvénients de chacun.

    Il est extrêmement rare qu’une solution soit universelle et au contraire je trouve que la multiplicité des solutions est une richesse de python alors pourquoi « descendre » les alternatives à Django ? Il me semble que ce serait plus constructif.

    De plus les solutions à base de WSGI se basent complètement sur des standards PEP là où, il me semble, Django c’est adapté mais ne va pas jusqu’au bout (il reste monolithique).

    Bref, je trouve dommage cette industrialisation excessive de python (du point de vu web) où l’on présente et favorise une solution et où les alternatives sont relativement mal vue, même Java ne va pas jusque là. JEE c’est une foule de framework web qui sont réellement utilisés en entreprise :

    – GWT
    – JSF
    – Spring
    – Play
    – Struts
    – etc

    Chacune apporte quelque chose et il est rare de voir quelqu’un dire que l’un écrase les autres sans que ça soit du troll.

    • fgallaire dit :

      Regarde les slides d’Armin, et tu verras que l’une des innovations de Django était justement un bon support de WSGI dès 2005.

      Armin est justement une des personnes qui propose d’excellentes alternatives à Django, et elles sont citées comme telles dans mon article.

      Par contre, JEE peut bien avoir une foule de frameworks web, ce sera toujours nul de faire du web avec un langage statique.

      • number80 dit :

        Je trouve surprenant qu’armin qui connaisse bien WSGI puisse dire que Django a un bon support de WSGI. Django a un support très limité de WSGI, il peut être servi via WSGI, mais on peut toujours se brosser pour chainer les middlewares WSGI.
        En 2005, Django a été un des premiers frameworks web capable d’être servi via WSGI, mais en 2011, ça n’a pas évolué.

        Que Django ait attiré l’attention des développeurs web sur python est indéniable, mais je ne suis pas certain qu’il soit le « meilleur » framework web -si tant est qu’il y en ait un-, il a ses points forts et ses points faibles et les alternatives (Werkzeug/flask, Pylons/TG, etc … ) sont tout aussi intéressants, c’est ce que dit Armin.

      • yoko dit :

        Je suis désolé, mais je ne vois pas les « excellentes alternatives à Django » ni dans ce billet ci ni dans celui donné en lien (celui qui plombe TurboGear, pylon, pyramid, etc). Je viens de regarder ses slides (sur ce foutu scribd parce que le lien pour le télécharger est mort et que pour le téléchargé sur scribd il faut un compte chez eux ou chez facebook) et il n’est fait que mention de la version 1 de TurboGear (mais c’est déjà, je trouve plus positif, il veut parler de Django il parle de Django il va pas chercher à démolir les autres). Ou alors tu parle de Rail, mais je trouverais dommage que le monde du web se limite à Symphony/Django/Rail.

        Pour ce qui est de WSGI, oui Django le supporte, mais pour moi l’idée derrière WSGI c’est la mutualisation du code et obtenir des middleware les plus flexibles possible. Bref tout sauf le coté monolithique de Django. Django supporte cette modularité mais ce n’est pas fait pour.

        Pour ce qui est de JEE pour le web, je sais pas ce que tu entends par statique.

        Si tu parle du fait qu’il est compilé, c’est vrai que c’est moins agréable (il existe tout de même des solutions pour ne pas voir ça comme un problème lors du développement). L’avantage c’est d’avoir un fichier simple qui contient l’application, qui est simple à manipuler et qui se déploie sur tout serveur d’application (la configuration des bases de données est dans le serveur donc l’installation est simplifiée).

        Si tu parle du fait que le langage soit statiquement typé, je ne vois pas en quoi ça impact particulièrement le développement web.

Leave a Reply