article.md 11KB
title: ★ Choisir un framework web slug: choisir-un-framework-web date: 2006-09-07 09:25:19 type: post vignette: images/logos/frameworks_web.png contextual_title1: Sortie de Django 1.0, une année de nouveautés contextual_url1: 20080902-sortie-de-django-10-une-annee-de-nouveautes contextual_title2: Google App Engine : avantages et inconvénients contextual_url2: 20080409-google-app-engine-avantages-et-inconvenients contextual_title3: ★ Astuces et bonnes pratiques Django contextual_url3: 20080211-astuces-et-bonnes-pratiques-django
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 :-).