Sommaire
- Acte 1 : Exposition
- Acte 2 : On commence par la fin
- Acte 3 : Partir sur une base saine
- Acte 4 : l'heure du choix
- Acte 5 : Où l'on retarde le choix
Bonjour Nal.
Comme c'est la première fois que l'on se parle, je vais te raconter une petite histoire d'application web en cinq actes. Je vais essayer de te divertir et de te faire découvrir des choses. Tu aimes le théâtre, j'espère ?
Acte 1 : Exposition
Comme beaucoup, j'aime le web, et comme d'autres, je n'aime pas les applications natives. Ayant des données à présenter sur mobiles, je me tourne vers la création d'une application web en commençant par chercher des frameworks Javascript sympas et prévus pour ça, tout en gardant à l'esprit que :
On ne construit pas une application web comme on construit une page web.
N'ayant comme expérience que des pages faites avec amour et patience en HTML et CSS et un soupçon de jQuery sur un serveur mutualisé chez Free, je me dis que je suis mal parti (avant d'avoir même pu commencer quoi que ce soit). Surtout que je me rappelle d'un article de Sencha suite à l'abandon par Facebook du HTML5 au profit d'une app native disant en gros que "Non, le HTML5, ça marche et on le prouve. C'est juste qu'il ne faut pas s'y prendre comme un manche". Force est de constater que d'après la vidéo, le Fastbook de Sencha tourne plutôt pas mal.
D'un autre côté, il y a Firefox OS qui ne jure que par le HTML5 et ceux qui ont pu jouer avec sont plutôt unanimes pour dire que ca tourne bien.
Je me décide donc de tirer parti des connaissances existantes de quelques technologies web et de ne pas hésiter à apprendre de nouvelles choses pour faire la meilleure webapp du monde.
Acte 2 : On commence par la fin
Après avoir cherché quelques pistes sur Wikipedia, je me dit que je vais commencer par regarder ce que je connais et si jQuery ne propose rien pour m'aider dans ma tâche. Et voilà que je découvre jQuery Mobile qui m'en met plein les yeux. Des exemples sexy, une documentation sympa, je me dis "Vendu !" et je commence à jouer avec en faisant un petit prototype avec des données bidon codées en dur.
C'est super, j'ai rapidement un prototype qui présente bien, avec des animations qui feraient rêver un commercial et des raccourcis de navigation à base de swipe gestures qui raviront le power-user.
Sauf qu'il y a un problème, subtilement introduit deux paragraphes plus haut. En effet, quand je dis codées en dur, je veux dire gravées dans le HTML. Et jQuery Mobile, c'est une moulinette qui analyse le DOM et le transforme pour donner un résultat qui présente bien à l'écran. Ensuite, ajouter un élément dans une liste, ce n'est pas simple comme un $("#list").addItem("Carottes")
.
La mariée était trop belle, ça cachait quelque chose. Comme quoi, quand on dit que faire un truc beau, ça se fait en dernier, c'est pas totalement faux.
Acte 3 : Partir sur une base saine
Un jour de ma veille technologique, je découvre JSDB.io qui est une assez fantastique base de données recensant des librairies Javascript. La page d'accueil affiche les librairies les plus populaires toutes catégories confondues. Je sais que l'indice de popularité n'a rien de fiable, mais ça donne un ordre de grandeur.
Je clique donc sur la première, à savoir, Bacbone.js et je lis l'introduction. Relisons là ensemble.
When working on a web application that involves a lot of JavaScript, one of the first things you learn is to stop tying your data to the DOM.
Effectivement, ce que je n'ai pas fait pour mon proto jQuery Mobile…
It's all too easy to create JavaScript applications that end up as tangled piles of jQuery selectors and callbacks…
Ah oui, en effet, je me rappelle avoir déjà empilé des tas de $("#truc > .machin")…
all trying frantically to keep data in sync between the HTML UI, your JavaScript logic, and the database on your server.
Saperlipopette ! Ça semble bien cool. Continuons à lire :
For rich client-side applications, a more structured approach is often helpful.
OK, Vendu !
Après ce vent d’enthousiasme, je lis plus en détail, et il semblerait que le concept de MVC soit capital. N'en ayant pas entendu parler dans mon école d'élec où je n'ai appris en informatique que de l'assembleur et du C pur et dur, avec un soupçon de POO, je demande à mon vrai ami qui me répond sans détour que d'autres personnes avant moi ont eu les même problèmes, que certains d'entre eux ont cherché des solutions et qu'un concept est né. Et que c'est exactement ce qu'il me faut.
Acte 4 : l'heure du choix
Maintenant que je sais quoi chercher, il s'avère qu'il y a plein de candidats. Et comme c'est aussi un problème que de choisir, d'autres personnes rédigent d'intéressants articles, lesquels se terminent en substance par :
- Si tu cherches un truc léger, flexible, utilisable pour faire une grosse webapp et éprouvé, prends Backbone.js
- Si tu cherche un truc qui veut concurrencer une application desktop et qui propose des automatismes sympas, prends Ember.js
- Si tu cherches un truc plus léger, axé performance, qui s'intègre bien avec des jQuery ou Dojo, prends CanJS
- Si tu cherches un truc déclaratif qui utilises les vues pour définir le comportement à coup de balises HTML personnalisées, prends AngularJS
- Si tu cherches un truc plus roots qui serve de fondation pour ton app, prends Dojo
- Si tu cherches un truc qui permette de faire une UI-de-la-mort, prends YUI
- Si tu cherches un truc petit, bien documenté qui marche avec CoffeeScript, prends Spine
- Si tu cherches un truc qui créé une dépendance forte entre le modèle et l'interface en mettant tout à jour magiquement, tout en permettant l'utilisation de n'importe quel autre cadriciel, prends KnockoutJS
- Si je veux faire une petite webapp de rien du tout à l'ancienne, prends jQuery.
Bien, bien, bien. C'est cool, je veux un peu de tout, il me semble. Et comme j'aime bien rendre les choses plus compliquées qu'elles ne le sont déjà, j'ai fait une autre recherche et j'ai trouvé ces autres librairies qui semblent vendre plus ou moins le même rêve :
- Enyo
- The M project, juste car j'aime ce que j'ai fait dans jQuery Mobile
- Sencha's ExtJS
/me pense sérieusement à faire une pétition pour avoir un .js en TLD
Acte 5 : Où l'on retarde le choix
Face à tous ces choix, je ne suis plus que doute et incertitude. Bien sur, c'est en testant que l'on peut se faire un avis, mais je ne peux pas vraiment tester toutes ces possibilités. Certains font un bon boulot en proposant une simple application de ToDo en utilisant tout un tas de différents frameworks, mais le doute subsiste.
C'est vers toi, public, que je me tourne afin d'essayer d'avoir une réponse. Après cette longue pièce, tu as eu le temps d'avoir des idées, et il est temps d'en parler. Quel est ta librairie de prédilection pour faire une application web qui propose des éléments graphiques sympas (widgets et animations), sur un concept de MVC, qui propose des événements de "doigt glissé" et éventuellement qui aime bien jouer avec LeafletJS , et si possible pourquoi ? (Et on n'est pas vendredi, hein)
Applaudissements et huées, le rideau se ferme
Promis, je fais plus concis la prochaine fois, très probablement sans l'environnement théâtre.
# Sproutcore
Posté par ondex2 . Évalué à 4.
Moi, je fais du Sproutcore, et j'aime bien ça.
Mais, chacun ses goûts…
[^] # Re: Sproutcore
Posté par Xinfe (site web personnel) . Évalué à 1. Dernière modification le 17 février 2013 à 19:38.
Effectivement, j'ai vu SproutCore, mais je n'ai pas totalement compris son lien avec Ember. J'ai interprété comme "Ember, c'est Sproutcore v2, et une version 2, c'est toujours mieux qu'une version 1.x".
J'ai tout faux ?
Surtout que CapitaineTrain est passé de Sportcore à Ember
[^] # Re: Sproutcore
Posté par ondex2 . Évalué à 2.
EmberJS devait être Sproutcore v2. Sauf qu'ils sont partis tellement loin dans les changements, qu'ils ont finalement décidé d'en faire un projet à part. Par ailleurs, un vrai Sproutcore v2 est en approche (aucune date prévue).
Les deux approches sont assez différentes selon moi, mais on retrouve une partie des concepts de Sproutcore dans EmberJS (bindings, observers, …). J'ai essayé EmberJS, mais je n'ai pas du tout accroché. Question de goûts certainement (ou peut être que je n'ai pas assez fait d'effort pour me mettre à EmberJS)…
# Backbone.js
Posté par dave_null (site web personnel) . Évalué à 6.
J'ai jamais rien compris à l'utilité de Backbone.js.
On peut lire que ça permet de faire plein de trucs cools, mais ça ressemble à une usine à gaz vide. Est-ce qu'il y a une documentation simple et efficace, avec des exemples concrets ?
# AngularJS FTW!
Posté par Nicolas Blanco (site web personnel) . Évalué à 4. Dernière modification le 18 février 2013 à 00:48.
J'avoue que je suis tombé sous le charme d'AngularJS.
Après avoir testé des dizaines de frameworks JS, je considère vraiment ce framework à part.
<pub>
Quel joie de pouvoir directement "relier" ses modèles, ses propriétés et ses événements directement dans le DOM de la page. Plus de manipulation de DOM ou d'interpolation dans le JS, plus d'événement à poser en JS sur les éléments du DOM, plus besoin de système de templates ! Le JavaScript de la page devient soudain beaucoup plus axé métier.
Avec le système de requêtes Ajax par promise, il est possible d'écrire :
$scope.mon_objet = MonModel.query(). mon_objet sera "populé" en asynchrone lorsque la requête sera retournée par le serveur : un callback à écrire en moins :).
Le système de directive permet d'étendre le langage HTML de la page pour pouvoir créer ses propres balises réutilisables. Par exemple : créez un plugin AngularJS pour faire des onglets et étendez votre page avec des balises <tabs>.
</pub>
Ce framework est pour un moi un des premiers qui peut faire de l'ombre à jQuery. En tout cas je me verrai bien dans le futur faire une appli AngularJS sans jQuery.
Au niveau des défauts : problèmes de performance/compatibilité en dessous de IE 9 et des dernières versions de Chrome/FF. Pas de système d'animations par défaut (viendra avec une prochaine version).
J'ai des doutes avec les balises custom et le SEO (?).
Par conséquent c'est le plugin idéal pour faire des back-office "pro" / intranet / ou si vous vous en foutez d'IE.
[^] # Re: AngularJS FTW!
Posté par tanguy_k (site web personnel) . Évalué à 3.
J'utilise également AngularJS après avoir utilisé KnockoutJS.
Le gros atout d'AngularJS est de pouvoir absolument tout tester contrairement aux autres frameworks.
De plus il est complet : routing, directives, controllers, $http/AJAX… tout y est, pas besoin de rajouter d'autres librairies.
Pour moi c'est le grand vainqueur des frameworks JS.
Ça vaut ce que ça vaut, mais quand j'ai commencé à l'utiliser en octobre 2012, AngularJS était à peine à 2000 étoiles sur Github, derrière EmberJS, KnockoutJS… Il est désormais à pratiquement 7000 étoiles loin devant tous les autres en dehors de BackboneJS (12700) qui est plus ancien. On entend parler de ce framework de plus en plus.
J'utilise peut être mal les promises mais je reviens à l'utilisation des callbacks classiques pour pouvoir gérer les erreurs et je vois pas d'autres solutions.
Exemple :
Pas vraiment la même chose. D'ailleurs AngularJS inclue une re-implémentation light de jQuery qui contient les fonctions de bases.
AngularJS manque encore d'une doc complète incluant les "best-practices". Je galère souvent à trouver la bonne façon de faire.
# natives
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Pourquoi? C'est trop performant et trop bien intégré?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: natives
Posté par Philippe M (site web personnel) . Évalué à -3.
Je n'y connais pas grand chose mais je pense que le natif c'est comme avec une appli desktop. En plus de faire du débug pour ton programme tu va devoir faire du débug de ton programme spécifiquement sur telle ou telle plateforme… Ou peut être ai-je tors ?
Born to Kill EndUser !
[^] # Re: natives
Posté par Juke (site web personnel) . Évalué à 7.
Comme pour developpement web non ?
[^] # Re: natives
Posté par Framasky (site web personnel) . Évalué à 2.
Oui mais sur chaque version de ton appli, c'est plus chiant : iOs, Android, Maemo (lol).
L'avantage de faire une webapp, c'est de développer une fois, et tester un code sur les différentes plateformes, plutôt que développer x fois et tester x codes sur les x plateformes
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: natives
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
La phrase devrait être "je n'aime pas développer des applis natives" alors :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: natives
Posté par barmic . Évalué à 2.
Même pour l'utilisateur les webapp sont agréables car elles sont synchronisée de fait (pas la peine de faire attention à ce que ça le soit). C'est bien plus rare avec les appli natives (par exemple avec les agrégateurs de flux).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: natives
Posté par Xinfe (site web personnel) . Évalué à 4.
Effectivement, le temps de débug est plus court sur une webapp (je ne fais que présenter des données texte + une carte), et plus portable. Le gros du travail pour avoir quelque chose de cross-browser est déjà fait par les librairies Javascript.
J'ai aussi un vieux iPhone de récupération (3G), et bizarrement, je ne trouve plus rien qui soit compatible iOS 4.2.1. Je suspecte l'App Store d'avoir insidieusement modifié la liste de compatibilité et d'avoir abandonné cette version d'iOS qui est la dernière disponible pour iPhones 3G et iPod Touch 2G. Même si ce n'est pas le cas, ils peuvent très bien le faire du jour au lendemain.
Donc en gros :
Mais :
Pour finir, le XKCD de circonstance.
[^] # Re: natives
Posté par maboiteaspam . Évalué à 0.
Et en plus tu pourras faire un truc vachement plus sexy que sur une appli desktop.
Sinon, au sujet de knockoutjs, pourquoi dis tu qu'il créé une dépendance forte ?
N'est ce pas toi qui introduit (hmm) la dépendance lorsque tu décides de spécifier ton service de données pour coller pile poil à l'UI ?
[^] # Re: natives
Posté par Xinfe (site web personnel) . Évalué à 1.
Pour KnockoutJS, je n'ai fait que répéter ce que j'ai lu dans l'article…
Je n'ai pas essayé, donc je ne peux pas vraiment juger :)
[^] # Re: natives
Posté par maboiteaspam . Évalué à 1.
OK!
Au fait, pour répondre à ton journal,
JQuery incontournable pour le multi plateforme
jmobile éventuellement pour aller vite et faire standard
Ko pour la data et sa syntaxe bien fichue (le coup des balises Js mélangés à aux HTML me rappels vaguement un certain PHP, ou bien n'était ce ASP ?)
Pour l'heure je part sur Jasmine pour le testing
Le reste c'est maison en version 0.-1.
angularJS j'ai testé fût un temps, mais j'ai trouvé que c'était beaucoup trop compliqué.
YUI j'ai l'expérience d'une lib truffé de leak (le comble quand on sait que l'un des dévs de JS travail sur ce projet), mais c'est ptet ma faute…. On ne le saura jamais!
a+
# Meteor
Posté par Bob Maerten . Évalué à 2.
En voyant la démo en video sur le site (http://meteor.com/) on a de quoi être impressionné, même s'il faut bien entendu relativiser quant aux performances réelle.
Un exemple un peu plus concret peut-être consulté sur http://ladditionestpourmoi.fr/ (en plus de la découverte du concept du site, pas inintéressant).
[^] # Re: Meteor
Posté par maboiteaspam . Évalué à 1.
Clair!
La vidéo de meteor est absolument géniale.
En plus ils ont vraiment fais les choses bien à mon goût.
C'est simple et direct comme du html, c'est pensé pour faire face aux problèmes de latence, ça produit des livrables indépendants.
Tout simplement mortel.
Et précisément ce que je cherche.
Cependant, et j'ai eu cette réflexion dès qu'ils ont parlé de mongodb, il me semble que c'est difficile de l'intégrer dans un existant avec des sgbdr bien établit et bien remplit.
Le changement d'ui t'imposes de migrer tes données. Ça, c'est pas cool.
En tout cas à part imiter une interface mongodb dans les modèles consommés par météor, je ne vois pas bien comment faire dans l'immédiat.
Mais vraiment bon dans ce premier jet de vidéo.
[^] # Re: Meteor
Posté par maboiteaspam . Évalué à 1. Dernière modification le 20 février 2013 à 13:15.
Bon je peux plus m'éditer, alors je me parle tout seul, note que je commence à avoir l'habitude ce n'est pas la première fois,
toujours au sujet de meteor, une petite quote qui me plait beaucoup.
Au sujet des modèles stocké dans du sgdbr, http://stackoverflow.com/questions/10605796/meteor-with-mysql
# Javelin \o/
Posté par Gof (site web personnel) . Évalué à 4.
Perso moi je viens de découvrir JavelinJS.
http://www.javelinjs.com/
# DIY
Posté par steph1978 . Évalué à 2. Dernière modification le 19 février 2013 à 17:12.
Tout d'abord, merci pour cette synthèse de ta veille, cela m'évitera d'avoir à faire le même travail la prochaine fois que je me poserai
Par provocation je dirai, vu le nombre de candidats qu'il y a, fait le tien !
Je travaille sur un bout de webapp aussi et j'ai commencé from scratch, plus par manque de maîtrise d'un outil existant que par choix réfléchi.
Ensuite, je me suis rendu compte que j'aurai besoin de jquery si je voulais pas re-développer trop de choses. En fait, je connaissais jquery donc je savais que cela pourrait répondre à une partie de mon besoin.
Au final, je me rendrai peut être compte qu'un autre framework remplacera avantageusement une partie de mon code. Mais tant pis.
Ce que je veux dire, c'est que je pense qu'il vaut mieux partir de ce que doit faire l'application (besoin) que de l'idée d'utiliser tel ou tel outil (comment).
En tout cas pour ma part, les dev perso où je me suis dit "je testerai bien la techno X" ont rarement abouti alors que les dev perso où je me suis dit "il faut absolument que j'ai une application qui fasse ceci" ont plus facilement abouti même si ce ne sont pas des chef d’œuvre d'architecture logicielle.
[^] # Re: DIY
Posté par Xinfe (site web personnel) . Évalué à 1.
Justement, je suis tombé sur une petite webapp faire par quelqu'un de mon école, et qui a exactement le même comportement que ce que je veux faire :
récupérer des données depuis une API et les afficher dans une liste. Le tout en jQuery Mobile.
Donc finalement, je crois que je ne vais pas embrasser cette fois le modèle MVC, mais réutiliser mon prototype avec un bête
$('#list').listview('refresh');
pour régénérer la belle liste qui présente bien.Par contre, je crois que Ember.js me plaît bien pour le futur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.