title: Partir de zéro

> At this point I’m going to park libraries, and leave them out of this discussion. The reason is that, in my view at least, libraries can be swapped out and replaced if they prove problematic. Don’t like the way a library does date formatting? No problem, just switch it for something else. Frameworks, on the other hand, tend to be a lot more difficult to swap, often requiring a rebuild of the app in question. And, by their nature, they’re a lot bigger and more involved.
> 
> <cite>*[The Cost of Frameworks](https://aerotwist.com/blog/the-cost-of-frameworks/)* ([cache](/david/cache/8d56b85a75797f70d0abe8a9f7cec2d6/))</cite>

Je me demande souvent quels outils est-ce que je prendrais si j’avais carte blanche, indépendamment des contraintes du produit (une autre note sera dédiée à ce sujet). L’équation efficacité vs. ergonomie de développement vs. accessibilité vs. transmission est difficile à trouver.

Côté serveur, je suis davantage attiré par des solutions comme [Nameko](http://nameko.readthedocs.org/en/stable/) ou [Falcon](http://falcon.readthedocs.org/en/stable/) qui restent minimalistes et pertinents pour des API. Sur le stockage des données, cela dépend vraiment trop de leur nature pour trancher, [Redis](http://redis.io/) serait sûrement de la partie et il faudrait que j’explore [RethinkDB](http://rethinkdb.com/).

Côté client, l’équation est beaucoup plus complexe. Pour le style, [cssnext](http://cssnext.io/) me semble être l’approche la plus saine et pérenne, associée à une [stratégie de nomenclature raisonnable](http://rscss.io/). La question qui coûte cher, c’est de savoir comment gérer les *web components* et leurs données. Des solutions comme [Polymer](https://www.polymer-project.org/) ou [React](http://facebook.github.io/react/) sont vraiment [trop coûteuses](https://aerotwist.com/blog/the-cost-of-frameworks/) ([cache](/david/cache/8d56b85a75797f70d0abe8a9f7cec2d6/)) pour moi. Devoir mettre à jour [des milliers de lignes](https://github.com/etalab/udata/pull/237) lors d’une montée en version est rédhibitoire, sans compter la courbe d’apprentissage et de ré-apprentissage. Je pensais avoir trouvé la solution avec [RiotJS](http://riotjs.com/) mais ça reste encore trop compliqué/magique et [x-tag](http://x-tag.github.io/) n’est pas encore suffisamment mature.

Mais cette approche où le couplage client-serveur est fort reste traditionnelle et il serait peut-être temps de passer à de l’[offline-first](https://speakerdeck.com/espylaub/offline-first-web-apps-beuth-hochschule-berlin) avec [Hoodie](http://hood.ie/) sachant qu’il est possible de [commencer en douceur](https://github.com/mWater/minimongo) et [d’aller plus loin](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) ([cache](/david/cache/27d1e42423963d4650201455ba67a068/)).

[Sans JavaScript](/david/stream/2015/11/18/) qu’il disait…