Journal Écrire une application web de nos jours

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
29
17
fév.
2013

Sommaire

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 :

/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  . Évalué à 4.

    Moi, je fais du Sproutcore, et j'aime bien ça.

    • J'aime bien que tout soit en Javascript (pas de HTML, pas de langage exotique comme Objective-J, …).
    • J'aime bien le concept des bindings où j'attache un élément de l'interface graphique à un attribut d'un objet, et que quand la valeur de l'un est modifiée, l'autre le soit aussi.
    • J'aime bien les observers où je peux déclencher une action quand une valeur est modifiée.
    • J'aime bien que je puisse utiliser des diagrammes d'état et que donc ça aide à éliminer une partie des bugs.
    • J'aime bien que les tests unitaires ne soient une sorte de vérue/rajout sur le projet existant.
    • J'aime bien qu'il y ait de la documentation écrite pas des humains, de la documentation écrite par des machines, et des exemples.

    Mais, chacun ses goûts…

    • [^] # Re: Sproutcore

      Posté par  (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  . É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  (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  (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  (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.

      $scope.mon_objet = MonModel.query().mon_objet

      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 :

      MonModel.query(
  {},
  function(response) {
    // Success
    $scope.mon_objet = response;
  },
  function(response) {
    // Error
    // Affiche un message d'erreur a l'utilisateur
    showAlertError(ServerResponse.translateError(response, ResourceActions.Query));
    $scope.mon_objet = null;
  }
);

      Ce framework est pour un moi un des premiers qui peut faire de l'ombre à jQuery.

      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  (site web personnel) . Évalué à 8.

    comme d'autres, je n'aime pas les applications natives

    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  (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  (site web personnel) . Évalué à 7.

        Comme pour developpement web non ?

        • [^] # Re: natives

          Posté par  (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  (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  . É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  (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 :

      • Je réutilise des connaissances que je connais, sans avoir à apprendre Objective-C et Java. (J'ai des bases, mais rien de sérieux)
      • Je n'ai pas à payer une dîme à Apple (un mac + 99$ pour avoir droit de publier)
      • Je cible plusieurs plateformes d'un coup (Android, iOS, Firefox OS?, Tizen?, Meego?, …) et les desktop (pas idéal, mais ça marche)

      Mais :

      • Performances moindres (mais mon projet est relativement léger, donc c'est bon)
      • Plus de limitations d'accès au matériel (qui ne me concerne pas non plus)
      • Moins bonne intégration dans le système, mais globalement les utilisateurs semblent pas s'en soucier des masses (cf. Windows)

      Pour finir, le XKCD de circonstance.

      • [^] # Re: natives

        Posté par  . É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  (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  . É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  . É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  . É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  . É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.

        Seven Principles of Meteor
        - Data on the Wire. Don't send HTML over the network. Send data and let the client decide how to render it.
        - One Language. Write both the client and the server parts of your interface in JavaScript.
        - Database Everywhere. Use the same transparent API to access your database from the client or the server.
        Latency Compensation. On the client, use prefetching and model simulation to make it look like you have a zero-latency connection to the database.
        - Full Stack Reactivity. Make realtime the default. All layers, from database to template, should make an event-driven interface available.
        - Embrace the Ecosystem. Meteor is open source and integrates, rather than replaces, existing open source tools and frameworks.
        - Simplicity Equals Productivity. The best way to make something seem simple is to have it actually be simple. Accomplish this through clean, classically beautiful APIs.

        Au sujet des modèles stocké dans du sgdbr, http://stackoverflow.com/questions/10605796/meteor-with-mysql

  • # Javelin \o/

    Posté par  (site web personnel) . Évalué à 4.

    Perso moi je viens de découvrir JavelinJS.
    http://www.javelinjs.com/

  • # DIY

    Posté par  . É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  (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.