Bonjour à tous pour ce troisième article “côté développeur”.

Lorsqu’on démarre un nouveau projet de développement, les choix les plus déterminants sont celui de la technologie puis celui des outils.

Pour Simple Workspace comme pour la plupart des applications web, le choix logique reste JavaScript , acteur devenu incontournable aujourd’hui tant on le retrouve partout. Nous évoquerons aujourd’hui le choix des outils. 

Notre philosophie.

Le choix de ces outils repose sur plusieurs principes directeurs :

Rester à jour.

Un des défis que pose le développement web est l’évolution constante des navigateurs : rien que pour Chrome, nous comptons 7 mises à jour majeures cette année. Celles-ci ouvrent des possibilités mais nous contraignent également à nous maintenir à jour.

Alors, s’agit-il de sauter systématiquement sur le tout dernier framework à la mode, celui qui gère telle fonctionnalité expérimentale ? Bien sûr que non : le premier critère dans le choix de nos outils est qu’ils soient pérennes, c’est-à-dire demeurent maintenus sur la durée, et compatibles avec les derniers navigateurs.

Cela implique parallèlement de nous mettre à jour autant que possible. C’est certes un processus qui prend du temps mais qui reste indispensable. Sur le web, l’expérience nous a montré qu’il valait mieux être “trop” à jour que pas assez : la plupart des utilisateurs recevront la mise à jour de leurs navigateurs simultanément, parfois à leur insu. Or, il s’agit pour nous d’être réactifs et de ne pas avoir d’outils périmés lorsque ça arrive sous peine de ne pas pouvoir garantir un taux de disponibilité optimal sur nos productions. Un travail de fond nécessaire et qui porte ses fruits.

Ne pas mettre tous ses œufs dans le même panier.

Un des grands principes des applications du monde Unix, sur lequel le web est né, peut se résumer en “un programme, une fonction”. Ce découpage à l’extrême aboutissant à des programmes minimalistes et très spécialisés, se retrouve également dans le choix de nos outils.

Tout d’abord, cette approche permet une grande flexibilité pour répondre à un besoin, puisqu’on réduit les chances de se retrouver avec un outil tentaculaire “qui ne gère pas ce cas de figure”, ou un logiciel qui couvre 20 fois plus de fonctionnalités que ce dont vous avez besoin, risquant de vous perdre. Nous optons donc pour une démarche modulaire.

En outre, cette modularité nous offre une plus grande résilience face à un éventuel défaut (bug non contournable dans une bibliothèque, projet cessant d’être maintenu, etc) : si une pièce est défectueuse, on la change, tout simplement ; sans compromettre la stabilité de l’ensemble.

Enfin, le fait de découper en petites briques nous donne la souplesse nécessaire pour nous interfacer avec des systèmes externes (PIM, etc) plus facilement, mais aussi d’isoler des bugs plus efficacement pour améliorer les délais de correction.

Le choix de l’open source.

Notre dernier critère est de parier sur l’adoption d’outils open source , c’est-à-dire avoir l’accès au code source de nos outils pour comprendre comment ils sont fabriqués. Que cela nous offre-t-il ?

Une meilleure compréhension, donc une meilleure maîtrise de l’ensemble de notre pile applicative, que l’on peut résumer dans cette maxime : “La confiance n’exclut pas le contrôle”.

Mieux, nous contribuons occasionnellement à l’amélioration de ces outils, ce qui nous permettra en retour de bénéficier de dépendances plus robustes et plus sûres.

Le framework principal, Backbone.

Souvent, une des premières questions qu’on pose à un développeur JavaScript sera : *« sur quel framework tu travailles ? ». *Alors, qu’est-ce qu’un framework ? Tout simplement la colonne vertébrale du programme.

Plus que tout autre outil et parfois même plus que le langage, le choix du framework détermine la manière dont le programme sera articulé, pensé, et réalisé. Il conditionne les outils à utiliser, la structure des développements.

Pour Simple Workspace, notre choix s’est porté sur  Backbone.js . Développé en 2013, il a un âge vénérable pour n’importe quel projet JavaScript. Alors qu’on pourrait penser qu’il s’agit d’une technologie vieillissante, Backbone.js est tout sauf obsolète. Voici pourquoi :

Tout d’abord parce qu’en dépit de son âge, il est toujours maintenu, toujours utilisé, toujours conseillé car réputé pour sa stabilité et la facilité à l’intégrer dans des structures complexes.

Enfin parce que le choix du framework découle d’un besoin. Ici, en l’occurrence, le désir d’un framework léger, peu intrusif, nous permettant une grande fluidité dans le choix de nos outils, collant bien à notre philosophie modulaire exprimée plus haut.

Contrairement à d’autres solutions plus “tout en un” comme  Angular , Backbone ne nous contraint pas plus que nécessaire en nous dictant une méthodologie. Il soutient les briques de Simple Workspace en jouant son rôle de “colonne vertébrale”, ce qu’illustre bien son nom en anglais.

Tout ceci pour quel bilan ? En sept ans d’utilisation, Backbone n’a jamais été un frein et s’est toujours révélé compatible avec les bibliothèques que nous avons choisies ultérieurement : composants graphiques comme AG-Grid, couches de communication comme Socket.io, utilitaires comme Moment, etc.

Bien séparées, toutes les couches de l’application peuvent évoluer en quasi-indépendance. Ce qui nous permet de rester à la page, un pré-requis dans le monde de l’impression 😉

Petit mot pour la fin

Que ce soit pour assurer le bon fonctionnement du programme comme l’améliorer continuellement, ce choix d’outils a permis à J2S de tenir ses promesses et de faire de Simple Workspace un outil aisé à maintenir et à étendre, pour maximiser le confort d’utilisation, comme le montrent les dernières nouveautés .

Le choix des outils de référence ne se limite pas à la partie visible, bien entendu, puisque notre solution se base sur Adobe InDesign, l’outil de référence dans le print, comme l’illustre cet article .

Vous voulez en savoir plus sur Simple Workspace ?
Contactez-nous  !

Pierre Michel,
Ingénieur développement

____________________________

Retrouvez les précédents articles de la série Simple Workspace 2.0 côté développeur :

1 –  Simple Workspace 2.0 côté développeur

2 –  Simple Workspace 2.0 côté développeur II : le retour