# Web Components et développement

2015-05-26

> By moving to a component model, we should strive to have our components be completely self-contained and, ideally, made up of a single file. But thinking in terms of components might actually make our project end up with a larger number of files than a project which did not. The goal is to make it such that those files are not implicitly coupled with one another, and implementing a change in one will not usually necessitate updating a chain of other files.

> By moving in data retrieval and styling into the component itself, we actually start to shed a lot of the weight off of the other parts of the app that were a little bit heavier before. The need for the "M" and the "C" in "MVC" might go away entirely...

> One Concern, One File (cache)

J’aime beaucoup les approches actuelles (cache) qui tendent à regrouper les fragments de code relatifs à un même composant visuel. L’ajout d’un périmètre permet d’imbriquer les composants (cache) de manière plus saine (cache). En attendant de pouvoir utiliser le scope des `CSS` de manière native, je vais me contenter d’utiliser RiotJS qui les supporte.

J’espère qu’à terme les navigateurs permettront d’afficher la source des composants web de manière lisible et exploratoire pour un nouveau-venu dans le développement web. C’est un point stratégique critique pour la compréhension du web par le plus grand nombre.

Articles choisis : Commodité et effondrement, Des données aux communs, Accompagner un enfant, Senior developer, L’illusion sociale, Instantané Scopyleft, Enseigner le Web, Simplicité par défaut, Minimalisme et esthétique, Travail en transition, La pairmutation du travail, Principes Web, Travail en transition, Un web omni-présent, Manifeste de développeur, Confort et convivialité, Testament numérique, et bien d’autres…