Catégorie : Développement informatique

Je regarde un peu les frame­works JS pour « appli­ca­tions dans le navi­ga­teur ».

Plus j’avance plus je me dis qu’a­vec l’ap­proche mobile et la gestion du offline, on aban­donne le web tel que je le connais­sais. Même avec une foul­ti­tude de javas­cript et d’ajax, nous avons long­temps gardé l’ap­proche « vue sur le client, appli­ca­tion sur le serveur », et j’en ai été un grand défen­seur. Aujourd’­hui l’idée c’est plutôt « appli­ca­tion sur le navi­ga­teur, API sur le serveur ».

La démarche n’est pas neuve en infor­ma­tique et le milieu a déjà subit plusieurs aller-retour entre les modes « appli­ca­tion sur le client », « appli­ca­tion sur le client synchro­ni­sée avec un serveur », et « appli­ca­tion sur le serveur, vue sur le client ». Il s’agit juste d’un de ces mouve­ments mais côté appli­ca­tions web.

J’ai regardé quelques frame­works, nommé­ment Back­bo­neJS, Angu­larJS et EmberJS, plus quelques compa­ra­tifs plus éten­dus. Pour l’ins­tant j’ai l’im­pres­sion qu’ils proposent surtout une notion de MVC, avec éven­tuel­le­ment un système de rendu avec liai­son directe entre la partie modèle et la partie contrô­leur.

Je peux me leur­rer sur la complexité ou sur la valeur ajou­tée en main­te­nance mais j’ai l’im­pres­sion que ça ne sera pas mes points d’at­ten­tion. Orga­ni­ser mes classes je le ferai certai­ne­ment moins bien si je prends tout de zéro, mais ce ne sera pas ma diffi­culté prin­ci­pale. Les liai­sons directes entre vue et modèle ne me semblent pas non plus forcé­ment indis­pen­sable, ça peut même être contre­pro­duc­tif vue la perte de perfor­mance.

Par contre j’ai besoin de quelque chose pour gérer le côté appli­ca­tif :

1. M’abs­traire des diffé­rentes solu­tions de stockage client, si possible en gérant les quotas, en ayant un méca­nisme quand on se rend compte que ce stockage a été écrasé et néces­site d’être recréé, etc. Dans l’idéal quelque chose qui ne se contente pas d’être un simple wrap­per et qui sait faire la diffé­rence entre des préfé­rences et de gros conte­nus par exemple, en me propo­sant des solu­tions diffé­rentes pour les deux cas en fonc­tion de ce qui est dispo­nible sur le navi­ga­teur (on n’uti­lise pas les API File et le local storage dans les mêmes contextes)
2. Avoir en ligne de vue le fonc­tion­ne­ment hors ligne, avec un vrai méca­nisme de mise à jour de l’ap­pli­ca­tion, un vrai méca­nisme de mise à jour des données (synchro­ni­ser dans les deux sens, un premier méca­nisme de conflit ou de prio­ri­sa­tion en cas de conflit), des notions de « à exécu­ter plus tard une fois en ligne », etc. La ques­tion du login est aussi impor­tante (jeton tempo­raire ou perma­nent, quelle sécu­rité, etc.)
3. Un méca­nisme complet de gestion des URL à base de popS­tate et pushS­tate de façon à ne pas avoir qu’un seul lien vers la page d’ac­cueil mais pouvoir gérer le bouton retour arrière du navi­ga­teur, les favo­ris, les liens entrants, etc. Bref, si je regarde un contenu parti­cu­lier je dois avoir une URL spéci­fique, que je peux copier, trans­mettre, utili­ser. Et par pitié oubliez les #!. C’est aussi plus diffi­cile qu’il n’y parait dès qu’on fait inter­agir ça avec le mode offline.
4. * Une gestion de base pour les conte­nus. Si on stocke hors ligne, j’ai­me­rai avoir à jouer le moins possible moi-même avec les data:uri, et pouvoir réfé­ren­cer des images ou des conte­nus dans mes vues, à partir de choses stockées hors ligne dans un local­sto­rage, indexdb ou équi­valent
5. C’est annexe et peut être non relié, mais si possible un jeu de widget ou templates par défaut qui s’adaptent aux diffé­rents contextes de navi­ga­tion (android, ios, win8, la manière dont on présente les listes, les menus, les retours arrière, ne sont pas les mêmes)

Vous avez quoi pour gérer ces aspects parti­cu­liers ? Parce que pour dessi­ner des pages à partir de modèles et vues OK, mais pour gérer une appli­ca­tion j’ai l’im­pres­sion d’être sans rien.

Oh, et en plus vu qu’il s’agit d’être multi-device, je ne souhaite pas quelque chose qui rame sur smart­phone. Par contre j’ac­cepte de coder beau­coup de choses à la main, je ne cherche pas forcé­ment un truc qui fasse le café. Même 4 ou 5 petites lib qui s’oc­cupent de leur partie spéci­fique, ça me va.

Les webapps sont pour moi défi­ni­ti­ve­ment la direc­tion vers laquelle aller. Mozilla pousse beau­coup via Fire­fox OS. Pour jouer avec eux, jetez un oeil à Mortar, qui permet d’ini­tia­li­ser tout le néces­saire. Il y a un joli billet de hacks.mozilla.org qui peut vous permettre de démar­rer.

Pendant quelques années nous avons cher­ché le saint Graal pour rempla­cer du texte par des images dans les pages HTML. Il y a eu sIFR qui néces­si­tait le plugin Flash, des bidouilles à base d’in­den­ta­tion et marges CSS néga­tives qui risquaient de casser pour ceux qui n’af­fi­chaient pas les images, des trucs horribles à base de display:none qui empê­chaient le copier/coller, etc.

J’avais pas mal laissé tombé quand j’ai vu que certains jouaient avec des polices de carac­tères à la wing­dings. Ça ne faisait pas de rempla­ce­ment et ça néces­si­tait d’ajou­ter des carac­tères arbi­traires qui risquaient de mal passer en cas d’ab­sence de la police choi­sie.

Sauf que visi­ble­ment ils ont trouvé le saint Graal il y a un bon moment et personne ne m’a prévenu. Alors si vous aussi on ne vous a pas prévenu, regar­dez Symbol­set et Liga­ture Symbols.

L’idée c’est d’uti­li­ser les liga­tures. Les liga­tures ce sont ces arte­facts qui permettent de rempla­cer certaines suites de carac­tères par un visuel spéci­fique afin d’en simpli­fier la lecture. On cite souvent « fl » et fi » comme exemple de liga­ture mais Wiki­pe­dia a une superbe illus­tra­tion.

L’as­tuce est de décla­rer une police person­na­li­sée où « se connec­ter » est remplacé par une liga­ture qui contient l’icône corres­pon­dante. C’est vecto­riel, ça s’adapte en taille comme en couleur, ça se dégrade parfai­te­ment pour ceux qui ne savent pas relire la liga­ture ou la police de carac­tères, et pour le système ça reste encore le mot « se connec­ter » donc c’est tota­le­ment trans­pa­rent. Bref, comme en plus c’est léger en poids, on a presque trouvé le saint Graal. Pourquoi personne ne m’avais rien dit ? Comment ai-je pu passer à côté ?

Vous avez même un outil en ligne qui fait tout ça : Icomoon

Partagé sans commen­taires, mais vous pouvez faire les vôtres :

• Détec­ter les inser­tions de nouveaux noeuds DOM à l’aide des anima­tions CSS (dirty hack, mais bien pratique depuis que les événe­ments javas­cript prévus pour sont aban­don­nés)
• Une fonc­tion de rappel après chaque exécu­tion de script (je suis certain qu’on peut y trou­ver des usages sympa pour les char­geurs de script dyna­miques)
• X-Tag, pour étendre le langage avec ses propres balises (à défaut d’avoir un XBL propre pour faire ça, accom­pa­gné idéa­le­ment d’un méca­nisme d’es­pace de nom pour éviter de pour­rir l’es­pace global)
• Le shadow DOM (à rappro­cher du lien précé­dent)