Architectures MV* : que mettre entre un Modèle et une Vue ?

Note pour la suite : ceci n’est pas un article décrivant les différences de MVC, MVP et MVVM (d’autres ont déjà très bien fait cela). L’article est centré sur MVC mais l’essentiel de ses conclusions est applicable à MVP et MVVM.

A la base des architectures MV*, il y a MVC. Et à la base d’MVC, il y a un « modèle mental » : décrire séparément le système tel qu’il est connu par la machine (le modèle) et le système tel qu’il est connu par l’utilisateur (la vue).

Une des nombreuses schématisations de MVC

Une des nombreuses schématisations de MVC

En effet, l’essentiel des applications modernes se contentent de faire cela : construire un dialogue entre une base de données et un utilisateur en mettant des choses entre les deux pour faciliter la compréhension mutuelle. Prenons immédiatement un exemple.

Lire la suite

Redux : un nouveau paradigme d’architecture web

MEAN, Meteor, React+Flux, voire Volt : les promesses de l’émergence de LA bonne architecture logicielle pour réaliser des Single Pages Applications ne cessent de se renouveler au cours des années. Malgré ce paysage bouillonnant d’idées innovantes, on ne peut vraiment dire que l’on ait obtenu jusqu’à aujourd’hui quelque chose de vraiment satisfaisant. Mais voilà que se dresse devant nous un nouveau challenger : Redux… et celui-ci vaut vraiment la peine qu’on s’y arrête un moment.

Redux vs Flux

Il n’a fallu que quelques mois pour que l’intérêt pour Redux surpasse celui pour Flux

Lire la suite

Les Single Page Applications ou comment exploser un budget pour rien

A titre personnel, je suis convaincu que les Single Page Applications sont l’avenir des applications web. J’en suis même convaincu depuis 10 ans et mes premières applications bourrées d’Ajax. Et à vrai dire, je pensais que la mutation vers ce type d’architecture irait plus vite : mais de toute évidence, même si les SPA sont désormais à la mode, l’environnement technique est loin d’être mûr pour ça.

SPA FAIL

Une belle architecture pour un bel échec

Oh bien sûr, on peut faire des choses qui fonctionnent terriblement bien, des applications remarquablement user-friendly sur ce modèle dès aujourd’hui, mais le coût de production engendré par cette architecture est la plupart du temps prohibitif. On aboutit au paradoxe suivant : dans la majorité des projets, l’investissement fait dans l’architecture SPA ne vaut clairement pas ses avantages… et pourtant, c’est l’architecture que pousse une majorité d’architectes aujourd’hui sans demander l’avis des maîtres d’ouvrages.

Lire la suite

20 ans de Ruby, 10 ans de Rails : des technos has been ?

La première version de Ruby publiée l’a été en décembre 95, la première version stable de Rails date quant à elle de décembre 2005. Alors que les semaines qui viennent devraient voir arriver la version 2.3 de Ruby et RoR 5, il est certainement temps de faire le bilan de tout ce que cet écosystème a apporté à l’univers logiciel, mais aussi ce qui lui reste encore à prouver par rapport à la concurrence.

Monday morning on rails

Monday morning on rails

Lire la suite

CoffeeScript vs ES6 vs TypeScript

Javascript a beau être incontournable et farci de vertus cachées, il n’en reste pas moins souvent pénible dans ses limitations. Trois tentatives majeures de dépassement de ces dernières existent aujourd’hui. Valent-elles la peine ? Si oui, pour quels usages ? Analysons.

CoffeeScript : faire plus avec moins

Je veux commencer par un hommage à Jeremy Ashkenas, l’auteur de CoffeeScript (et accessoirement de backbone et d’underscore.js, tout en bossant pour le NY Times… respect !). La manière dont il a pensé et conçu ce langage, qu’on le pratique ou non, qu’on l’aime ou non, est une grande source d’inspiration pour tous ceux qui réfléchissent à ce que doit offrir un langage de développement moderne. Je vous encourage à ce titre à jeter un oeil à sa version annotée des sources du compilateur de CoffeeScript qui constitue pour moi une leçon de génie logiciel.

Jérémy Ashkenas présentant lsa vision d'un compilateur vers Javascript

Jérémy Ashkenas présentant sa vision d’un compilateur vers Javascript

Lire la suite

La stack MEAN : quand ce qui est hype est nul

MEAN fail

4 composants unis pour un même échec

Sur le papier, l’idée est séduisante : vous prenez des technos Javascript dans le vent et vous les assemblez pour construire une pile logicielle intégralement JS. C’est d’ailleurs tellement séduisant qu’en 2015 quand on lance une start-up dans la Silicon Valley, il y a de forte chance que la stack MEAN (MongoDB, Express, Angular, NodeJS)  soit de la partie. Mais même dans ma petite province française, les étudiants IT ou les candidats à l’embauche les plus brillants que je croise ne manquent pas d’évoquer auprès de moi l’attirance que cet alliage révolutionnaire suscite chez eux. Et pourtant, il y a toutes les chances qu’un projet basé sur MEAN se conclue une déroute.

Lire la suite

Pourquoi l’essentiel des frameworks web n’est pas vraiment MVC (et pourquoi ils feraient mieux de l’être)

RubyOnRails s’est notamment fait connaître en popularisant 2 patterns, peu pratiqués à l’époque dans le petit monde du développement web :

  • Model-View-Controller, sur lequel je vais revenir
  • Active Record : les instances des objets des Modèles sont implicitement liés à des enregistrements de base de données.

MVC est loin d’être une innovation de RoR dans le web. La séparation des responsabilités préconisées par Rails était déjà présente de longue date dans les frameworks Java de référence, et même depuis 1996 dans WebObjects d’Apple. Mais c’est bien au moment de l’émergence de Rails, autour de 2005, que le MVC s’est peu à peu imposé en tant référence architecturale pour le web. Et pourtant, quasiment aucun des frameworks web modernes n’est véritablement fidèle à MVC. Un schéma valant mieux qu’un long discours, regardons ce qui cloche :

MVC web

Le « MVC » des frameworks web

Le MVC tel qu'il devrait être

Le MVC tel qu’il devrait être

Lire la suite