index.md 2.9KB
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.
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 ou Falcon 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 serait sûrement de la partie et il faudrait que j’explore RethinkDB.
Côté client, l’équation est beaucoup plus complexe. Pour le style, cssnext me semble être l’approche la plus saine et pérenne, associée à une stratégie de nomenclature raisonnable. La question qui coûte cher, c’est de savoir comment gérer les web components et leurs données. Des solutions comme Polymer ou React sont vraiment trop coûteuses (cache) pour moi. Devoir mettre à jour des milliers de lignes 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 mais ça reste encore trop compliqué/magique et x-tag 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 avec Hoodie sachant qu’il est possible de commencer en douceur et d’aller plus loin (cache).
Sans JavaScript qu’il disait…