Créer des applications partagées pérennes qui peuvent être déployées à grande échelle.
Partagées signifie que différents utilisateurs vont pouvoir interagir et "travailler" ensemble sur l'application
Grande échelle, en 2013, signifie que des dizaines à des millions de personnes peuvent utiliser l'application. Une majorité de plateforme doit être accessibles (ordis de bureaux, portables, tablettes, téléphones mobiles) de préférence à moindre coût et donc sans avoir à tout refaire pour chaque appareil.
Vivant dans un monde régit par certaines lois physiques, il sera raisonnable de supposer que le réseau de communication est au pire ouvert. La sécurité de l'application ne devra pas supposer le contrôle du réseau, même dans si l'environnement de déploiement est considéré contrôlé.
Pérennes signifie que l'arrivée de nouveaux appareils sur le marché ne remet pas en cause plus de 1% du temps de développement. Personne ne peut prévoir le futur ; il conviendra de garder un œil ouvert sur les tendances hardware/OS.
Dans beaucoup de cas, une seule organisation créé l'application ou en a la responsabilité. La disparité des terminaux dans les mains des utilisateurs suggère des problèmes de sécurité si les terminaux possèdent trop d'autorité. On préfèrera une architecture avec un serveur central (on peut évidemment avoir plusieurs machines physiques), seule source de vérité et de confiance. Des applications "clientes" seront déployées sur les terminaux des utilisateurs et interagiront avec le serveur.
Une fois la contrainte architecturale posée, il convient de faire 3 choix :
- technologie(s) des applications clientes
- technologie(s) de l'application serveur
- protocoles de communication
Concernant les ordis de bureau/portable, il serait stupide de prétendre que le navigateur web n'est pas la plateforme de choix. Les tablettes et mobiles ont d'autres contraintes. Si ces appareils possèdent un navigateur, les utilisateurs ont une tendance à préférer les "apps" (iOS/Android), même si celles-ci ne présentent parfois aucune différence technologiques et ont seulement une différence d'accès (clic sur une icône au lieu d'une recherche dans l'historique). Des technologies comme Apache Cordova (anciennement PhoneGap) permettent de packager des applications écrites en HTML+CSS+JS en applications "natives" iOS, Android ou autre.
Autre piste pour Android. Pour iOS, il est aussi possible de créer un signet depuis Safari vers l'écran d'accueil
Le HTML peut s'avérer poser des problèmes de maintenabilité, notamment à cause de son manque de granularité et composabilité. Les standards émergeant "Web Components" sont prometteurs, mais ne sont pas encore suffisamment supportés par les navigateurs. Des technologies s'occupent d'améliorer cet état de fait.
Handlebars permet d'écrire des morceaux de templates, de les composer ensemble et de les nourrir en données.
Maturité : 5/5
Créée par Facebook, cette technologie prometteuse se base sur la notion de composant visuel et va donc un peu plus loin que les templates HTML. Typiquement, une checkbox est un composant visuel avec un état et on s'attend à ce que cet état soit géré au sein du composant visuel et pas ailleurs. Pour les applications très dynamiques, ReactJS permet d'obtenir de meilleures performances perçue en évitant un problème de performance appelé layout thrashing Vidéo
Maturité : 5/5 (utilisé par Facebook en production aujourd'hui)
Le CSS est extrêmement dur à maintenir et les gros projets tendent à avoir une seule feuille CSS où chaque page en utilise une minorité. Les préprocesseurs CSS comme SASS (+Compass) ou LESS aident à modulariser le CSS et le rendre plus maintenable (via l'utilisation de variables et mixins notamment)
Maturité (SASS/LESS) : 5/5
Technologie développée par Microsoft. Elle apporte certaines parties de syntaxes d'ECMAScript 6 (prochain standard de JavaScript) et une vérification de types. Contrairement à une technologie comme Closure Compiler qui force un peu le style d'écriture du code, TypeScript a trouvé un bon équilibre entre laisser les développeurs écrire le code comme ils veulent
Maturité : 4/5
Le hors ligne n'a pas été le fort des applications web initialement. Des technologies comme IndexedDB permettent d'écrire des applications web qui sauvegardent les données localement et les synchroniser plus tard. Les technologies pour faire ça (Appcache notamment) ne sont pas toujours adaptées pour rendre cette partie facile. D'autres technologies (ServiceWorker) émergent doucement pour rendre cet aspect plus facile à développer.
L'aspect hors ligne est possible, mais dur à développer aujourd'hui et pose parfois des problèmes mineurs d'expérience utilisateur (avoir à recharger la page, etc.)
Tout ceci devrait arriver à maturité vers début 2015.
A l'heure actuelle, il n'est pas vraiment possible de prendre un photo, enregistrer un son ou une image dans une application web. Ce genre de fonctionnalités arrivent avec la technologie WebRTC. A titre expérimental, Firefox et Chrome supportent cette technologie, mais la maturité n'est pas encore là.
On peut s'attendre à un bon niveau de maturité vers fin 2014
JavaScript est rapide. On est désormais capable de compiler un million de lignes C++ d'un jeu en 3D et le faire tourner à 60fps en JavaScript. Il n'y a pas de lenteurs inhérentes à JavaScript ou aux navigateurs comme il pouvait y avoir il y a 10 ans.
De manière anecdotale, pour implémenter la bibliothèque standard de JavaScript, les navigateurs remplacent leur C++ par du JavaScript, prouvant que JavaScript n'a pas grand chose à envier à C++ en terme de performance.
Concernant les débats sur l'application mobile HTML5 de Facebook, les ingénieurs de Sencha ont démontrés que l'application était mauvaise dus à certains mauvais choix de Facebook et non pas à une limitation de la technologie web mobile.
Il existe l'API orientation qui donne accès au gyroscope. Voir :
http://www.html5rocks.com/en/tutorials/device/orientation/
http://www.w3.org/TR/orientation-event/
Support navigateur (dont mobile) : http://caniuse.com/#feat=deviceorientation
L'API de geolocation est disponible depuis longtemps. Voir :
https://developer.mozilla.org/en-US/docs/Web/API/Geolocation http://www.w3.org/TR/geolocation-API/ Support navigateur (dont mobile) : http://caniuse.com/#feat=geolocation
Pour l'énorme majorité des cas d'utilisation, HTTPS servant du HTML ou du JSON compressé via gzip ira très bien pour couvrir les besoins de sécurités et performance (cache HTTP), tant son support est fiables sur la majorité des plateformes. Pour des besoins plus spécifiques de temps réel, on pourra utiliser descendre au niveau TCP (ou WebSockets dans un navigateur) échangeant des données binaires.
Côté serveur, on pourra choisir l'un différents frameworks web comme Python + Django, Node.js + express, Ruby on Rails, Java/Scala + Play Framework. Ils ont chacun des avantages, inconvénients en terme de bibliothèques, performance, réactivité de la communauté, sécurité, etc. Le web a grossit avec PHP et les applications J2EE. Même s'il est possible de faire de très bonnes applications dans ces technologies, on remarque une tendance des applications PHP à être des passoires en sécurité et les applications J2EE de ne pas être synonyme de performance. Si les technologies ne sont pas à blâmer directement, il semble qu'elles encouragent naturellement des pratiques de développement qui amènes aux constats précédemment évoqués.
Il y a deux dimensions pour prendre en compte pour choisir un type de base de données : la complexité des données (les données sont-elles fortement inter-connectées les unes aux autres ?) et le volume de données.
Les données à stocker sont par exemple des comptes utilisateurs. Ces utilisateurs ont des interactions entre eux et manipulent un nombre restreint d'objets (commentaires, préférences). Le modèle de données va être complexe et le volume modéré.
Les bases de données graphes comme Titan sont prometteuses, mais pour l'instant trop instables pour être fiables en production, à l'exception peut-être de Neo4J. Neo4J souffre de son côté de sa licence AGPL aux termes confus quant à savoir si l'application que vous développez avec Neo4J vous appartient ou leur appartient. Peut-être qu'OrientDB est assez mature. Dans tous les cas, se reposer sur Blueprint.
Un bon vieux SQL fonctionne bien et sera sûrement le meilleur choix jusqu'à ce que les bases graphes arrivent à maturité. Côté open source, on pourra choisir PostgreSQL ou MariaDB (fork de MySQL après le rachat de Sun par Oracle).
MongoDB n'est pas conseillé pour ce genre de cas d'utilisation. MongoDB est utile pour des logs peu structurés par exemple.
Ici, les données sont simples, mais très volumineuses (gros fichiers). Il s'agit de fichiers type résultats scientifique, imagerie médicale, etc.
Utiliser une des bases de données précédente n'est pas forcément le bon choix. On pourra se diriger tout simplement vers un système de fichier classique. Ca permettra notamment de garantir l'utilisation de streams pour traiter le gros fichier par petit bout côté applicatif.
Ce document rédigé principalement par David Bruant est sous licence Creative Commons 0
un grand merci @vjeux pour ta réponse.
J'ai pris un peu le temps hier soir de regarder la doc et de jouer (très très rapidement) avec, je comprends mieux la philosophie et le périmètre de la librairie. ça m'a fait penser à KnockoutJS sur certains points (notamment par l'orientation assumée "bibliothèque" plutôt que framework ; ce que je trouve très séduisant).
Je trouve aussi l'idée du DOM virtuel très très maligne, je suis plus réservé sur JSX, mais ça donne un code très lisible et simple. Encore merci pour le "débroussaillage".
Pour les lecteurs éventuels, ci-dessous 2 liens supplémentaires qui m'ont également aidé à mettre les choses en contexte :
http://skulbuny.com/2013/10/31/react-vs-angular/
http://programmers.stackexchange.com/questions/225400/pros-and-cons-of-facebooks-react-vs-web-components-polymer