# ? Cours IUT : Frameworks Web Publié le 16 février 2015

> By now, the purpose of web frameworks should be clear: to hide the boilerplate and infrastructural code related to handling `HTTP` requests and responses. Just how much is hidden depends on the framework. Django and Flask represent two extremes. Django includes something for every situation, almost to its detriment. Flask bills itself as a "micro-framework" and handles the bare minimum of web application functionality, relying on third-party packages to do some of the less common web framework tasks.

> Remember, though, that at the end of the day, Python web frameworks all work the same way: they receive `HTTP` requests, dispatch code that generates HTML, and creates an `HTTP` response with that content. In fact, all major server-side frameworks work in this way (excluding JavaScript frameworks). Hopefully, you're now equipped to choose between frameworks as you understand their purpose.

> What is a Web Framework? (cache)

Ce cours était une introduction aux frameworks web. Au départ on devait faire du `PHP` en essayant Laravel mais quand j’ai vu la complexité qu’il y avait dans ce framework (générer un projet de test c’est 18 Mo ?!) et le manque de documentation j’ai vraiment douté. Du coup on a commencé par (re)voir les bases avec les concepts (routing, controllers, models, ORM, views, templating, middlewares, etc) avant d’opter pour un framework JavaScript : SailsJS. Qui demandait l’installation de NodeJS ainsi que ses multiples dépendances. Autant dire qu’en environnement hostile (connexion plus que limitée) il est compliqué d’arriver à la première ligne de code pour tous…

Une fois les quelques machines coopérantes partagées, on a pu plonger dans le code et essayer de comprendre comment faire des choses simples à partir du gabarit de projet. Or l’exemple proposé ne sert qu’une page statique par défaut ! Il faut parcourir l’énorme arborescence générée pour trouver où placer les fichiers pour les controllers ou les templates ce qui est n’est vraiment pas intuitif pour un débutant qui essaye de comprendre les concepts sous-jacents. SailsJS nous aura au moins permis de discuter de la dualité framework front-end/back-end et de l’importance des données et des URLs en allant même vers du offline-first (cache). Au final j’aurais mieux fait de partir sur ExpressJS ou Flask. Cela ne résout pas le problème des dépendances pour autant.

C’est le moment où j’ai envie d’écrire mon propre framework. Portable. Copiable. Documenté. Hackable. Simple. Un générateur de sites statiques en somme :-p. L’enseignement est vraiment en train de m’ouvrir les yeux sur la complexité inutile créée par nos métiers. Complexité qui re-crée une pyramide de pouvoir et donc de contrôle. Au même titre que l’énergie.

### Discussion suite à l’article :

Étant moi-même développeur (Javascript, Coffeescript, NodeJS, CouchDB, etc.), je comprends tout à fait ce problème de la complexité des frameworks.

@David : connais-tu Hoodie ? Un framework JS dont le but est de permettre au plus grand nombre de développer une application web. Leur objectif est de permettre aux designers et aux personnes sans grande connaissance en programmation. Quelques mots-clés : noBackend, Dreamcode, OfflineFirst, diversité, empowerment, décentralisation.

En attendant que Hoodie soit stable, j’essaye de mon côté de remplacer dans mes projets AngularJS par une palette de petites bibliothèques qui feraient la même chose. Pour l’instant j’ai un moteur de templates (Ractive.js) et plusieurs routers à tester (Crossroads.js, Finch.js, etc.).

Sylvain Duschene, le 2015-02-17 à 11:15:45

> @David : connais-tu Hoodie ?

Oui je suis d’assez près ce qu’ils font, j’apprécie vraiment leur travail et il faut que je trouve le temps de contribuer. Au passage, leur site est génial (notamment la page de contribution).

David Larlet, le 2015-02-24 à 22:17:11