Guillaume Gendre

A vrai dire en enlevant tout l'overhead du réseau et du serveur... vous n'en avez que 200ms !

Et parce que parfois, entre "application qui rame" et "application réactive" il n'y a pas grand chose, il conseille d'utiliser les CSS inline (entre autre) pour afficher le début de la page ASAP 

SenchaTouch est tellement « ios-like » que vous devrez la plupart du temps tout casser pour tout reconstruire lorsque vous passerez à la version Android de votre application. Le scrolling rame, et apprendre les subtilités de la doc va vous prendre tout votre temps.

jQueryMobile est presque bien, mais si vous visez de vieux terminaux votre application risque tout de même de commencer à ramer. Il faiut jQuery pour utiliser jQueryMobile et même après un custom build (en bêta), le total est assez lourd. Bien qu’ils aient récemment réduit la quantité de manipulations de ce type, jQueryMobile manipule aussi pas mal le DOM lorsqu’il « améliore » votre HTML pour le rendu des différents composants. Cette opération peut s'avérer coûteuse en performances sur un smartphone.

Go Zepto !

Zepto.js par contre est pas mal ! C'est une librairie JavaScript qui reprend les principales fonctionnalités de jQuery mais avec juste ce qu’il faut pour les mobiles. Il a l’énorme avantage d’être tout petit (25ko) et de ne pas vous dépayser si vous venez de jQuery.

Complétez Zepto par un système de templating JavaScript comme mustache.js ou mieux Handlebars :

Handlebars est un système de templates évolutif à base d’accolade. Il permet de générer du code HTML à partir de données. Il peut gérer les listes, les conditions et permet même de définir ses propres tags.

Un problème de sécurité

L'Ajax, fonctionnalité qui permet d'aller charger dynamiquement des données sur un serveur, en javascript, sans quitter la page en cours, pose des problèmes de sécurité : Théoriquement, rien n'empêche un code javascript bienveillant d'insérer un script malveillant qui irait publier sur un serveur inconnu l'ensemble de vos données personnelles. Du coup, la plupart du temps, sur un site web classique, les scripts doivent venir du serveur qui a servi la page web ou d'un CDN connu (Google, Yahoo, etc).

Sur iOS ou Android, si l'on utilise Apache Cordova, on trouve une "whitelist" : chaque application défini une liste des serveurs autorisés à lui fournir du code JavaScript. 

Hélas, côté Cascades, rien n'est prévu : tous les appels AJAX sont bloqués et renvoient l'erreur 0 : signe qu'ils ont été bloqués pour des raisons de sécurité.

Le QML à la rescousse

La bonne nouvelle c'est qu'en Javascript, côté QML, les appels Ajax ne sont pas bloqués! Et que la webview et le natif peuvent relativement facilement communiquer entre eux.

Voici donc un palliatif à l'ancienne : une passerelle entre web et natif afin de pouvoir communiquer avec le monde extérieur via Ajax.

Le principe est le suivant :

Côté web, on écrase la fonction $.ajax utilisée par jQuery ou Zepto par la notre.

Celle ci envoie l'ensemble des paramètres et options de l'appel AJAX au natif.

Elle stocke côté web au passage une fonction qui va traiter le résultat et envoie l'identifiant de cette fonction au natif.

Le natif fait l'appel Ajax en respectant au maximum les options (type POST ou GET, les paramètres, etc) du $.ajax de jQuery

Une fois le résultat obtenu, le natif envoie au web le résultat en lui redonnant l'identifiant de fonction préalablement reçu.

Le web appelle la fonction identifiée en lui passant les résultats reçus de la requête ajax.

Le web appelle la callback "success" ou "error" initialement passée à $.ajax afin de traiter le résultat.

Ainsi, aucun besoin de changer vos habitudes, appelez vos fonctions $.ajax, $.post ou $.get comme avant !

Attention voici le code :

https://gist.github.com/ggendre/6507448

Ce "fix" fonctionne pour jQuery et Zepto mais vous pourrez sûrement l'adapter à d'autres frameworks.