# ★ Choisir un framework web

Depuis l'annonce faite par Guido concernant sa préférence pour Django il y a deux semaines, il n'y a pas une journée sans article comparant les frameworks web Python ou comparant Django à RoR ou... bref. C'est intéressant car ça fait monter le buzz et ces frameworks méritent d'être connus mais le choix d'un framework web se fait bien souvent grâce à d'autres critères peu évoqués lors de ces comparatifs.

## Critères techniques

Le tout premier point à considérer est qu'un framework web est un outil. Le travail du technicien n'est pas de comprendre cet outil mais de savoir s'en servir. Un bon framework web est donc avant tout un framework qui sait se faire oublier. Mais attention, le terme d'outil n'est pas vraiment représentatif, en fait c'est plus une caisse à outils qu'il faut pouvoir adapter à ses besoins. Pour y arriver, deux conditions sont nécessaires :

- une bonne documentation pour connaître et savoir utiliser les outils qui sont déjà présents dans la caisse ;
- une caisse assez grande pour permettre d'étendre sa panoplie d'outils pré-intégré au besoin (et ça arrive toujours).

Actuellement, les frameworks s'étalent sur une échelle allant de l'application web à la publication web. Il faut donc encore une fois choisir en fonction de vos besoins, le framework le mieux adapté pour faire un blog ne sera assurément pas le même que celui avec lequel vous allez faire votre appli web-2.0-de-la-mort-qui-tue. Une fois vos besoins cernés, il suffit d'avoir connaissance des différentes solutions existantes pour déjà pas mal déblayer le terrain. Il devrait en théorie vous en rester 2 ou 3 maximum.

Reste maintenant une question de goûts/compétences du technicien qui est rarement prise en compte mais qui est pourtant capitale dans le déroulement du projet. Un technicien sceptique est moins impliqué et donc moins performant. Prennons l'exemple totalement aléatoire du choix entre Python et Ruby comme langages de programmation pour un framework. Quelqu'un qui aura codé depuis 3 ans en Ruby ira beaucoup plus vite dans le développement de son application, même si à connaissances égales celui-ci aurait été plus rapide en Python (bon ok pas si aléatoire). C'est tout à fait normal et si ce n'était pas le cas un seul framework dominerait le marché actuel.

Pour en finir avec la technique, il ne faut pas sous-estimer le problème de l'hébergement. Il existe peu d'hébergeurs proposant des services de qualité sur des technologies relativement jeunes et c'est bien dommage. C'est la principale raison pour laquelle PHP est soit-disant le langage de prédilection des dévelopeurs web (de plus de 40 ans ? Mouhahaha, pardon).

## Critères commerciaux

Il y a les boîtes où le service commercial est le cauchemard du service technique et puis... non, en fait ça se passe toujours comme ça ;-). Comment en arrive-t-on là ?

Il est difficile de vendre quelque chose que l'on ne connait pas à quelqu'un qui ne connait pas non plus. Jouer du pipeau à propos d'une technologie dont tout le monde parle c'est relativement aisé. Faire découvrir et ouvrir le portefeuille d'un client en évoquant un nom tribal inconnu de tout son service informatique déjà c'est plus risqué. Si en plus le seul exemple qu'on a de développement utilisant ce framework web n'a pas été réalisé par la boîte on comprend mieux l'inertie que peut avoir une technologie.

Deux autres arguments sont souvent évoqués :

- le manque de ressources humaines disponibles relatives au langage ou au framework et là c'est le serpent qui se mord la queue ;
- les garanties en termes de pérennité du framework, l'open-source en est une mais si vous êtes là vous le savez déjà :-).

## Critère décisif

C'est vous ! Évaluez vos besoins, testez plusieurs frameworks (si vous n'avez pas le temps, penchez-vous sur RoR ou Turbogears pour une application ou Django pour une publication) et lancez-vous. Les seules besoins sont un peu de temps et vous pouvez généralement faire le tour d'un framework en moins d'une demi-journée (exemples+doc+communauté+limites). Imaginez un prototype basique de ce que vous avez en tête et essayez de le faire après cette demi-journée pour chaque framework web, vous allez vite vous rendre compte des frameworks adaptés ou pas. Les connaissances acquises ne sont pas du temps perdu, le fonctionnement des frameworks web modernes actuels est quasiment identique et mêmes s'ils évoluent très rapidemment, ils sont dans une phase de stabilisation (indispensable pour l'entreprise).

En conclusion, il n'y a pas de meilleur framework que celui qui sera adapté à vos besoins. Passez plutôt du temps à réfléchir à votre modèle de données, changer d'outil est facile mais une fois que l'on a commandé les planches... il faut faire avec !

Bon, j'ai toujours pas le net mais du coup je bricole dans mon nouvel appart, à défaut d'une application web j'ai une vie... et une caisse à outils ;-)

[edit du 11] : ajout de quelques liens pour poursuivre la réflexion.

Pronouncement par Jacob (l'un des core-dev de Django) qui est l'un des meilleurs billets que j'ai lu à ce sujet :

> But there's a second, insidious form of evangelism which tries to convince people that the tools they're using are somehow "wrong" and that they ought to switch to using the "right" tools. These arguments inevitably involve vague statements that Option A is intangibly "better" than Option B: "You're using Ruby on Rails? Dude, you suck -- Django's totally better!"

Et les commentaires du billet qui tro^W^discutent de Zope constructivement :

> Beyond that, if you want a CMS, choose Plone, if you want a content-centric framework, choose Zope 3, if you want an RDBMS framework, choose Django or TurboGears, if you want pain and suffering, choose J2EE.

Frameworks make software easier, but only the easy part par Ned Batchelder au sujet de son expérience avec Django et de l'importance relative du choix d'un framework web :

> When the hype-masters claim that their frameworks and languages make coding an application easier, they are absolutely right. But that's already the easy part.

Snakes and rubies for the scientific community par Fabrice Jossinet (merci Enro pour le lien ! On trouve pas souvent de Bioinformaticien 2.0 alors si vous avez d'autres liens sous le coude n'hésitez pas). À ce sujet, vous pouvez aussi lire (argh impossible de retrouver le lien, pour la peine le point de vue d'un ruby-lover sur Django).

> In bioinformatics, the main goal is the biological discovery. You need to be productive as quickly as possible. And being productive in bioinformatics means to easily parse heterogeneous biological formats, display and manipulate biological data with 2D and 3D rendering, extract automatically biological knowledge using different algorithms (HMMs, neural networks, k-nearest neighbors, SVMs, semantic reasoner, ....). Python can provide such libraries now. Ruby cannot (except BioRuby). Today, Python is the best compromise between funny (web2.0) and less funny (science) stuffs.

Of snakes and rubies; Or why I chose Python over Ruby. Finalement, j'ai retrouvé le lien grâce à mat :

> Yes, Ruby is an excellent language. But you can have the most elegant and wonderful language in the world, and if it doesn't have library support, it is ineffective. A lot of apps in Rails are being built without the need of solid-third party libraries, and that's great, but there are those times when you need to read a DBASE file. And there are times when you'd like another templating system than erb. In Python you've got Cheetah, Kid, Myghty, Django's templates, PSP, the list goes on and on.

Why so many Python web frameworks? par Joe Gregorio qui nous fait une démonstration de la facilité à réaliser un framework web en python, impressionnant !

> So let's give it a shot, we'll pick some components and spend a couple hours seeing how far we can get building a web framework, which we'll call Robaccia.

Sur le choix d'un framework web... la réaction de NiCoS à ce billet, pleine d'expérience et de sagesse :

> Si je reviens sur les avant vente que j'ai pu réalisé ou auxquelles j'ai assisté depuis ces trois dernières années, j'ai toujours constaté que les prospects/clients étaient plus rassurés lorsqu'on leur proposait un produit avec des développements autours plutôt que par des développements sur mesure.

Let’s talk about Python and Ruby par James Bennett car c'est un des meilleurs comparatifs python/ruby (commentaires compris) que je connaisse :

> So I’d like to have an honest talk about Python vs. Ruby. From where I sit, there are two things about Ruby that don’t have to do with syntax or ad hominem attacks or whatever that, were I coming fresh to the choice today, would lead me to Python over Ruby.

Bonne lecture !

[edit du 15] : excellent billet « Un mythe sur les responsabilités dans le processus d’adoption des nouvelles technologies » de Christian Fauré à mettre en relation avec ma recherche d'un site sémantique. En ce moment je découvre pas mal de blogs de qualité, c'est rassurant :-).

### Articles peut-être en rapport

- Sortie de Django 1.0, une année de nouveautés
- Google App Engine : avantages et inconvénients
- ★ Astuces et bonnes pratiques Django

### Commentaires

pouype le 07/09/2006 :

"Quelqu'un qui aura codé depuis 3 ans en Ruby ira beaucoup plus vite dans le développement de son application, même si à connaissances égales celui-ci aurait été plus rapide en Python. "
Hmm ça sent le troll ça :) Plus rapide en Python ? :D
Je n'en ajouterais pas :-p

NiKo le 07/09/2006 :

En effet, quelques trolls se sont glissés dans ce billet, sauras-tu les retrouver ? :D
Le problème est que bien souvent quand on bosse on a pas le temps de tester en profondeur tous les frameworks qui sortent. Je pense de plus en plus qu'il faut sélectionner celui qu'on trouve potentiellement le plus versatile, documenté et maintenu puis rentrer à fond dedans.

David, biologeek le 07/09/2006 :

Désolé j'ai pas pu m'en empêché ;-)
@NiKo : le problème est de sélectionner justement. Sur quels critères ? Buzz ? Réseau de confiance ? Pas évident, surtout que des améliorations peuvent être faites par la suite. Il faudrait créer une ressource permettant de mutualiser ces connaissances...

PhE le 07/09/2006 :

Ne pas oublier Pylons pylonshq.com !

David, biologeek le 07/09/2006 :

Ni spyce. Ni webpy. Ni... bref tout est là :-)

NiKo le 07/09/2006 :

@David: Les frameworks qui restent plus de 6 mois dans le buzz sont AMHA à priori dotés de suffisamment de qualités le justifiant. Le gros problème rencontrés devant la pléthore de frameworks, c'est justement l'heure du choix. J'estime que pour éviter de predre tout son temps à cogiter quand au choix, il vaut mieux se jeter à l'eau à fond et surtout rapidement. Il sera toujours temps de changer d'outil si celui choisi ne correspond finalement pas à sa vision des choses, aux performances attendues, etc.
De plus, il ne faut jamais oublier qu'un framework se base avant tout sur un langage de programmation ; à ce titre il peut parfois se réveler périlleux voire contre-productif d'apprendre un nouveau langage utilisé sur tel framework à la mode plutôt que d'essayer d'utiliser un framework existant dans un langage que l'on maîtrise parfaitement.
Prenons l'ex. de RoR, tant qu'on reste dans le ramework Rails tout va bien mais dès qu'on doit coder des classes métier en Ruby nécessitant des traitement complexes, la courbe de productivité se trouve du coup moins interessante si on est pas familier du langage à la base.

David, biologeek le 07/09/2006 :

Mais c'est qu'il me piquerait presque mon troll... et franchement le buzz, ça donne un coup d'accélerateur mais c'est pas toujours justifié à mon avis. Il y a de très bon frameworks python que personne n'utilise car leurs auteurs sont peu connus et/ou ne trollent pas à tour de bras ;-).

NiCoS le 07/09/2006 :

Je dirais même plus (même si cela a l'air d'évoluer ces dernières années) que python est assez peu connu en france et donc que le monde python souffre un peu de publicité & co (contrairement à PHP, Java par ex).
La courbe d'apprentissage étant apparemment plus longue que PHP et les ressources plus limitées, les boites n'osent pas (à tord peut être d'un point de vue technique) miser sur python. Avec PHP/Java, ils sont surs jusqu'à présent de trouver des prestataires en mesure de reprendre leur projet.
Avec des langages plus rares, l'entreprise peut avoir peur de la pérénité du truc et/ou craindre d'être pieds et poings liés par son prestataire.

kib2 le 07/09/2006 :

J'aimerai beaucoup me lancer dans l'étude des frameworks web, mais pour l'instant qu'en est-il vraiment de l'hébergement ?
Pour le moment il faut payer pour avoir Python ou Ruby, la transparence et surtout les compétences techniques des hebergeurs m'ont l'air plus que floux, comme tu le soulignes si bien avec ta phrase : "Il est difficile de vendre quelque chose que l'on ne connait pas à quelqu'un qui ne connait pas non plus".
Beaucoup de développeurs en sont restés à un simple blog sous Dotclear ou WordPress ne serait-ce que pour des histoires d'argent.
Comment peut-on en effet envisager de payer pour une alternative belle sur le papier mais dont on ne maîtrise encore rien (et pour cause, il faut débourser pour voir comment l'on s'en sort) lorsqu'on nous propose des alternatives gratuites et qui ont fait leurs preuves ?
Sinon, j'aime beaucoup le logo de l'article, tu l'as fait toi même ?!
à Pouype : Je savais que tu craquerais...difficile de se retenir non ?!
A plus,
Kib².

Noé le 07/09/2006 :

www.nitroproject.org/ pour ceux qui adorent Ruby mais qui n'adorent pas Rails.
Et en plus il m'a fait découvrir Og, le truc dont je rêvais depuis des mois !

Xavier le 08/09/2006 :

"Il y a de très bon frameworks python que personne n'utilise car leurs auteurs sont peu connus et/ou ne trollent pas à tour de bras ;-)"
Juste par curiosité : lesquels ? A part ça, bon billet... Juste un peu rude avec les développeurs PHP de moins de 40 ans !

David, biologeek le 08/09/2006 :

@NiCoS :
> La courbe d'apprentissage étant apparemment plus longue que PHP
Alors là je ne crois vraiment pas que ce soit le cas (sans compter que Python apprend à programmer objet ce qui n'est pas négligeable...). Pour le reste je suis d'accord.
@Kib² :
> la transparence et surtout les compétences techniques des hebergeurs m'ont l'air plus que floues
C'est vrai que c'est pas évident. Concernant les compétences, ceux qui proposent ces services le font en connaissance de cause à mon avis.
> Comment peut-on en effet envisager de payer [...] lorsqu'on nous propose des alternatives gratuites et qui ont fait leurs preuves ?
Tout est question de besoins et de liberté.
> Sinon, j'aime beaucoup le logo de l'article, tu l'as fait toi même ?!
Non, il vient de la conférence www.snakesandrubies.com/ dont la vidéo est très bonne.
@Xavier :
> Juste par curiosité : lesquels ?
Pylons et Spyce qui sont cités en commentaire sont très bons mais bénéficient de peu de publicité. Du coup la communauté est moins grande, ils ont moins de contributeurs, etc. C'est du Darwinisme à l'échelle des frameworks ;-).

NiCoS le 08/09/2006 :

@Kib² => ben tu as toujours la possibilité dans un premier temps de faire ton projet ou au moins un prototype en local sur ton pc.
La question de l'hébergement n'est pas forcément un obstacle à l'apparentissage d'un framework web. Le problème est par contre si tu veux diffuser/utiliser ton projet/prototype sur un serveur de prod...
@David : pour la courbe d'apprentissage : il est communément admis (comprendre la légende urbaine raconte...) que python est plus complexe. Pour ce que j'en ai lu (mais pas encore mis en oeuvre), je relativiserais pas mal cette légendre urbaine ;-)
J'avais en outre lu/vu que dans les écoles d'ingé ou universités, python était assez peu enseigné contrairement à Java/PHP/... donc ça aidait pas au décollage du langage (car du coup requiérerait un apprentissage sur son temps libre et non dans le cadre de sa formation)

Un Electron Libre... le 09/09/2006 :

Sur le choix d'un framework web...

David a écrit un billet sur "Choisir un framework web", très pertinent (comme d'habitude ;-) ) mais cela m'a fait penser à une autre problématique : qui dit framework dit développement sur mesure et là est peut être une des raisons pour...

X-Blaster le 11/09/2006 :

J'ai essayé de me mettre à un ou deux frameworks, et il faut du temps pour s'y mettre, ça fait beaucoup trop de trucs tout seul sans que tu le saches(et ça ça m'enerve) et souvent les bons frameworks sont dans des langages que l'on n'a pas l'habitude d'utiliser.
Je préfère personnellement attendre qu'un ou deux frameworks émerge vraiment et deviennent standard. Le seul qui me parait bien pensé c'est rails, mais comme j'ai très peu de connaissance en ruby... je préfère attendre un peu pour être sûr de m'y mettre.
En attendant, je me suis fait mon pseudo framework en PHP, un petit modèle MVC, quelques helpers, des macros pour generer du javascript/ajax et ça n'impacte pas trop ma productivité.

JS le 11/09/2006 :

Tant que je suis là, le truc super chiant dans python, c'est l'identation... Genre entre 4 espaces et 1 tabulation, à l'oeil nu, aucune différence, mais python lui la voit et dit qu'il y a une erreur de syntaxe...
Ca existe un IDE pour Zope/Plone ?

Bader le 11/09/2006 :

L'indentation n'est un problème que si on utilise les mauvais outils. Un espace et une tabulation ce n'est même pas la même chose visuellement sur certains éditeurs.
Pour le choix de l'IDE ils sont pléthores, sous Linux comme sous Windows ou Mac OS X. Le tout est de trouver un éditeur faisant aussi bien du XML/HTML que du Python et éventuellement du javascript. Moi j'ai alternativement utilisé SPE et emacs.

David, biologeek le 11/09/2006 :

@X-Blaster :
> En attendant, je me suis fait mon pseudo framework en PHP, un petit modèle MVC, quelques helpers, des macros pour generer du javascript/ajax et ça n'impacte pas trop ma productivité.
Tu devrais jetter un œil à symfony si tu aimes php, c'est pas mal du tout : www.symfony-project.com/
@LS :
> Tant que je suis là, le truc super chiant dans python, c'est l'identation...
Euh, il suffit comme l'a dit Bader d'avoir un bon éditeur, genre SciTE : www.scintilla.org/SciTE.h... (au passage mon fichier de config : vrac.biologeek.com/SciTEU... )
SPE est très bon aussi, cf screencast : http://showmedo.com/videos/...

NiKo le 11/09/2006 :

Le billet sur JesusPhreak résume parfaitement ce que j'essayais de dire dans mon commentaire, désolé si j'étais pas clair (#2312) :-)

Enro le 12/09/2006 :

Puisque tu réclames ;-) , voici un autre bio-informaticien 2.0 français : Pierre Lindenbaum à plindenbaum.blogspot.com/ ...

Xavier le 12/09/2006 :

"Tu devrais jetter un œil à symfony si tu aimes php, c'est pas mal du tout : www.symfony-project.com/"
Alors celle-là, il faudrait l'encadrer. Elle mérite sa place sur bashfr ;-)

NiCoS le 13/09/2006 :

"Sur le choix d'un framework web... la réaction de NiCoS à ce billet, pleine d'expérience et de sagesse"
J'aime beaucoup le "plein d'expérience et de sagesse"... je pensais pas que j'étais/je faisais si vieux... :-/
Ah ces jeunes, aucun respect pour leurs ainés ;-P

David, biologeek le 13/09/2006 :

La sagesse est indépendante de l'âge :p

NiKo le 17/09/2006 :

Tiens, un billet interessant en droite lignée avec mon précédent propos : linux.blogweb.de/archives...

David le 27/11/2006 :

Salut David, on parle de ton site aujourd'hui sur la mailing-list Python-Fr :
"Je pense avoir trouvé mon FrameWork, Django ! Il y a de la bonne doc sur www.biologeek.com "
Profite d'avoir le vent en poupe ! :-D
David

David, biologeek le 27/11/2006 :

Héhé, merci de m'avoir prévenu ;-)

Amirouche B. le 10/06/2007 :

Xavier == Troller
self == Troller too
ça c'est fait.
J'ai fait un croquis d'argumentation... mais tout a deja été dit. Le plus simple pour comprendre c'est vraiment de faire python dans une console.