Depuis quelques jours, je vois passer différents messages relayant un projet de portage du SDK de Cordova vers Firefox OS. Pour mémoire, Cordova permet d’encapsuler une WebApp dans un conteneur d’application mobile natif, tout en offrant un bridge accessible via JS vers les API du device. De cette façon, toute la codebase est réalisée en utilisant les technos web (HTML/CSS/JS), l’app peut accéder aux ressources natives (accéléromètre, caméra, etc) et est distribué dans une app native (le tout exécuté dans une webview) via les stores.
Or, Firefox OS, c’est Gecko. Les Apps développées pour la plateforme le sont donc en utilisant la stack web traditionnelle, et l’ensemble des API du device sont exposées via JS. Pourquoi donc réaliser un bridge supplémentaire pour exposer en JS au sein d’une webview des composants qui sont… déjà exposés en JS au sein d’une webview ! On marche sur la tête. J’ai donc posé la question autour de moi, et la réponse est systématiquement la même : pour n’utiliser qu’une seule codebase transverse au développement d’une app multi-plateforme. Je comprends l’attrait d’une telle idée. Mais la notion « une seule codebase pour les gouverner tous » est totalement utopique. Pour mémoire, c’était aussi le pari de Java. En 2013, on développe toujours nos app desktop en Objective-C / DotNet / C# / C++ et Java n’a absolument pas pris le pas. Pourquoi serait-ce différent avec le Web ?
Ces réactions témoignent d’un ancrage plus profond de mauvaises habitudes, et d’une méconnaissance de la conception d’une app (et, a fortiori, d’une WebApp). On ne peut pas concevoir une app et la faire tourner sur toutes les plateformes disponibles indistinctement. Ce n’est pas une limitation technique. C’est une limitation conceptuelle. Chaque OS, chaque environnement apporte ses propres guidelines, ses propres interfaces, ses propres composants, et l’ensemble construit les habitudes de ses utilisateurs. Mettez donc un utilisateur habitué d’iOS devant une app Android pour voir… Imaginer pouvoir imposer la même interface à tous ses utilisateurs, sans tenir compte de leurs habitudes d’usage de l’environnement n’est pas seulement contre-productif : c’est suicidaire.
L’utilisation d’un socle comme Cordova devrait donc se dérouler comme suit :
– un socle de logiques métier et de modèles de données commun, partagé de façon transverse (via un Git Subtree par exemple) ;
– des vues et leurs logiques JS associées, éventuellement enrichies des composants Cordova pour l’accès au device, dans des projets séparés.
On a donc N+1 projets pour une même application : autant que pour chaque famille de device, plus le socle de logiques génériques. Alors effectivement, c’est un peu plus de travail parce que c’est autant de code à maintenir. Mais l’ensemble utilise la même stack de technos, donc un développeur peut intervenir à tout moment sur chacune des codebases, et une partie du code est partagé. C’est moins coûteux qu’un développement spécifique sous forme d’app native de toutes façons. Et dans cette optique, seuls les OS n’exposant pas directement leurs API via JS utiliseront les bridges Cordova. Pour FirefoxOS, aucune utilité donc, les vues sauront déjà tirer parti de l’OS directement.
CQFD : Cordova est un formidable projet, mais arrêtons d’imaginer qu’une seule codebase satisfera à tous les besoins. Rien n’est plus faux, et FirefoxOS n’en a clairement pas besoin.
Boris
12 novembre 2013
Autre piste favorisant Cordova comme bridge dans le développement d’applications Firefox : la nécessité de mettre en place dès maintenant un injecteur de dépendance pour la future segmentation des Firefox OS en circulation.
Je ne connais pas le développement sous Firefox OS (et notamment, je ne sais pas comment ou si il y existe la notion de « manifest ») mais sur les autres OS avoir une coquille servant d’isolation entre le code de l’application et l’OS n’est pas dénué d’intérêt.