Quels sont les pour et les contres d’un Framework javascript fait maison ?
Vous souhaitez mettre votre solution en avant en haut de cet article ? Contactez-nous
Lors de mon précédent article, j'avais évoqué le fait de se construire un framowork sur mesure à partir de ressources plutôt que de choisir une solution complète comme Angular.
Quel framework pour votre application Web ?
Je vous propose de revenir aujourd'hui sur les plus et les moins que peut avoir ce choix par rapport a une des solutions présentes sur le marché.
Les Plus
Une collection de ressources est plus simple à appréhender
Un framework complet comme Ember ou Angular est certes très puissant, mais aussi incroyablement complexe. Toutes les pièces sont interconnectées et il sera dur de comprendre le fonctionnement de chaque pièce sans une bonne idée du fonctionnement de la pièce d'à côté. Nous nous retrouvons donc obligés d'envisager le framework dans son ensemble pour apprendre correctement à l'utiliser, avec toutes les difficultés que cela implique.
À l'inverse, fonctionner avec un ensemble de ressources est plus simple. Une journée ou deux permet de bien comprendre le fonctionnement de Rivetsjs, EventEmiter s'appréhende en quelques heures, et un petit router en quelques minutes. De plus, la création de la structure permettant d'unifier tout ce petit monde vous obligera à appréhender tout ce petit monde et à bien comprendre le fonctionnement de chaque pièce avant de passer à la suite.
Un mauvais choix de technologie n'est pas aussi pénalisant.
Comme je le disais dans le point précédent, apprendre à utiliser un framework prend du temps, et se rendre compte après plusieurs heures qu'un framework ne nous plaît pas dans sa façon appréhender tel ou tel problème, ou qu'il ne sera finalement pas possible de le lier à telle technologie nécessaire pour un projet est assez frustrant. Sans parler de temps "perdu", il ne sortira rien de concret de ces heurs passes à apprendre une technologie que vous n'utiliserez pas.
D'un autre côté, il est plus simple de "bien" choisir une ressource quand elle fait peu de chose, car les éléments à comparer sont moins nombreux.
Quel lib au ratio souplesse/puissance le plus intéressant ? Est-ce que cette ressource est encore maintenue ? Sauf besoin spécifique, c'est la bonne.
Autre avantage, il est plus simple de changer d'avis. Le router choisi ne vous plaît finalement pas . Changez-le. Cela vous demandera peut-être deux heures, mais ce n'est rien compare à réapprendre un framework complet.
Une meilleure sécurité contre les virages brusques et les arrêts de projets
Lors de l'annonce d'Angular 2, il a été dit qu'il ne sera pas rétro-compatible. Que va-t-il donc arriver aux applications de vos clients que vous avez-déjà faits sous Angular 1, quand vous devrez les mettre à jour ? Resterez-vous sur une technique obsolète, ou bien ferez-vous l'effort de tout mettre à jour sachant que cela vous demandera de nombreuses heures ?
Le fait de travailler avec de nombreuses pièces détachées nous dispense de ce genre de problème. Telle ressource n'est plus maintenue ? Il suffit de changer la pièce. Cela vous coûtera quelques heures, mais reste souvent dans le domaine du raisonnable.
Les moins
Le manque de documentation
La plupart du temps, les ressources que vous déciderez d'utiliser seront documentés, mais qu'en sera-t-il des parties que vous fassiez vous-même pour lier le tout ?
Si vous travaillez en équipe, il leur faudra une documentation pour s'y retrouver, comprendre les choix de design que vous avez fait pour votre framework, et se sentir à l'aise (si vous pensez ne pas travailler en équipe, dites-vous bien vous travaillez toujours en binôme avec la personne que vous serez dans 6 mois).
Il existe une solution simple à ce souci : tout documenter, tout noter, tout commenter. Néanmoins, je ne suis pas tout le temps très studieux sur ce point, ce qui explique la présence de ce point dans les moins.
Des résultats souvent plus lourds que des frameworks monolithiques
Les frameworks complets sons faits avec un nombre restreint de librairies de bases, qui servent dans toutes les portions nécessaires du framework. Partager l'EventManager entre l'application, le modèle et le router (par exemple) fait que l'on aboutit sur un nombre de lignes plus restreint, et donc un framework plus léger.
Une collection de librairie multipliera forcément les dépendances, et ces quelques ko peuvent parfois jouer si vous avez une orientation très mobile.
Les risques de bugs, erreurs, mauvais designs
Il est important de garder en tête que si toutes les ressources que vous utilisez sont fiables (nombreux utilisateurs, beaucoup de contributeurs, …), ce n'est pas le cas du code que vous aurez fait vous-même. Moins testé que les gros frameworks, et dévelopé par une équipe évidemment plus restreinte (vous, avec un ou deux collègues dans le meilleur des cas) les risques de bugs restant indétectés sont réels.
La solution pour contrer ce point est de limiter au maximum la quantité de glu code nécessaire à notre framework, en choisissant des ressources qui travaillent bien ensemble.
Un autre point très important est de decoupler au maximum chacune des portions de votre application. Le changement d'une ressource précise doit impacter le minimum possible de fichiers, et donc demander un nombre restreint de changements.
Bien delimiter le périmètre de votre glu code.
Un des gros risques avec cette technique est de se laisser emporter, et transformer notre simple glu code en des pans entiers de notre framework.
Si vous avez besoin d'une classe qui vous servira de modèle et qu'aucune ressource ne vous convient, faites donc votre ressource, puis incluez-la à votre framework grâce à votre glu code. De cette manière, il sera plus simple de l'inclure dans un autre projet, ou de la remplacer par une autre ressource si besoin.
Conclusion
Construire son framework soi-même a quelques avantages, mais aussi de nombreux inconvénients, j'en conviens. C'est néanmoins un choix tout à fait envisageable si vous avez déjà une certaine expérience avec d'autres frameworks.
Cela vous demandera peut-être un peu plus de travail, mais la souplesse que cela vous fournira compensera largement cette perte de temps.
Besoin de ressources pour démarrer ? Je vous propose de découvrir votre bonheur dans cette série d'articles !
By
