ParisJS #42

Hier soir, meetup parisjs chez In'Tech Info, une école d'informatique du coté des Gobelins (dont les locaux semblent être un ancien parking réaménagé). Néanmoins, grande salle, plein de nouveaux venus, ça fait plaisir.

Commençons par le gros point noir du meetup. Celui-ci était censé commencer à 19h, mais c'est seulement à 19h45 que les organisateurs commencent à prendre la parole pour annoncer le programme. Et présenter parisjs, et montrer le nouveau site, et essayer de faire une démo d'édition de markdown en live, et faire son auto-promotion, et donner la parole à tous les sponsors pour qu'ils fasse de même, et du coup c'est super long.

C'est le même travers que le meetup nodejs paris et paris.rb. Ça ne commence jamais à l'heure, et même quand ça commence, on doit encore se taper les publicités avant le film, comme au cinéma. La prochaine fois, je viendrai en retard.

Bon, fini d'être aigri, il y avait une annonce intéressante quand même. NUMA vient d'ouvrir un espace de coworking de 150m², avec café à volonté, ouvert 24h/24, à destination des développeurs, et avec un device lab.

Dev Avengers

Mais les talks ont ensuite relevé le niveau. Christophe Porteneuve, la bible vivante du Javascript, qui appelle tout les auteurs des grands frameworks par leurs petits prénoms et qui réfléchit encore plus vite qu'il ne parle était le premier sur scène. 37 ans, toutes ses dents, 19 ans dans le web, ça envoie du lourd.

Il nous a présenté les outils de travail intra-browser qui permettent d'améliorer la productivité de son workflow de travail. Fini le Ctrl-S, Alt-tab, Ctrl-R pour voir les modifications qu'on vient de faire, on est en 2015 bourdel.

Petite explication de l'utilité des sourcemaps, qui permettent, en ajoutant des commentaires dans un fichier minifié de faire le mapping vers les fichiers sources. Chrome les comprends depuis déjà 4 ans, et nous indique donc les erreurs dans la console réellement là où elles ont lieu dans les fichiers sources. Et encore mieux, elles peuvent faire le lien entre un fichier final et n'importe quel type de fichier source, même des preprocesseurs comme Sass, Less ou Coffescript.

Tout le reste du talk donnait des exemples avec Chrome, car c'est le browser qui possède actuellement les meilleurs outils, même si Firefox et IE12 sont pas loin derrière.

On sait tous qu'on peut modifier le HTML et le CSS à la volée avec l'inspecteur Chrome, mais on peut aussi le faire avec du JS. Le soucis c'est que nos modifs restent en live dans la page chargée, mais que c'est un peu plus compliqué pour les récupérer dans un vrai fichier sur le disque.

Du coup, la solution c'est les workspaces de Chrome. On lui définit un dossier de notre disque dur qui contient nos sources, et une fois qu'on lui a donné l'autorisation, on peut manuellement lui indiquer les mappings entre notre filesystem et notre network. Du coup, en faisant ainsi et avec les sourcemaps, on peut modifier directement un fichier source Sass depuis Chrome.

Bon, sauf que dans ce cas là, on perds la preview instantanée de nos modifs dans le browser, parce que Chrome n'a aucune idée de comment parser du Sass. Mais c'est là que notre outil de build en mode watch peut venir nous aider. Grunt, Gulp et Brunch proposent tous un moyen d'écouter les modifications du filesystem pour lancer des taches en fonction des fichiers modifiés.

Il nous a ensuite parlé de fb-flo, un outil de Facebook qui permet de lier un fichier actuellement chargé par Chrome (CSS ou JS) à un buffer ouvert dans son IDE, et de reporter automatiquement les modifs de l'un vers l'autre, sans avoir besoin de recharger la page.

Dernier outil pour gagner du temps en test crossbrowser, c'est BrowserSync. On ouvre autant de pages qu'on le souhaite sur différents browsers, desktop et mobile, et toute modification sur l'un (scroll, typing dans un formulaire, etc) est répercutée instantanément dans les autres. L'avantage est que pour les clics, il rejoue le même selecteur unique sur chaque device plutot que de cliquer à des coordonnées précises.

Du coup, si on récapitule :

• Sourcemaps pour avoir la liaison entre un fichier minifié et les sources des preprocesseurs
• Workspaces pour faire le mapping entre un fichier du disque dur et un fichier chargé par Chrome (marche avec les sourcemaps). Je modifie dans Chrome, ça change sur mon disque.
• fb-flo pour faire du livereload du browser dès qu'un fichier du disque change. Je modifie sur mon disque, ça recharge dans Chrome.
• BrowserSync pour tester sur plusieurs devices/browsers en parallèle.

On a discuté ensuite autour d'une bière et d'une pizza où il m'a convaincu d'essayer Stylus. Syntaxe "clean", à la ruby, jade ou coffeescript. Je ne suis pas fan de cette épuration habituellement, mais j'avoue n'avoir jamais réellement essayé. Par contre le fait de pouvoir redéfinir les propriétés de base CSS (du genre, dès que je mets telle propriété avec telle valeur, alors ça mets automatiquement telle autre). Et aussi, les variables des mixins sont scopées, ce qui est le truc qui m'ennuie le plus avec Sass.

Dans le même genre, il m'a vendu brunch comme étant un grunt-like à base de convention over configuration (ce qui est tout le contraire de Grunt et de son configuration over configuration over configuration...). Du coup, faut vraiment que je teste.

Et il a même dit du bien de famous (un peu moins d'angular, forcément).

IONIC

Cédric Lombardot nous parle de Ionic Framework.

Alors, Ionic c'est un framework qui combine Angular et Cordova pour développer des applications hybrides.

Cédric commence par nous expliquer les avantages et inconvénients de faire de l'hybride. Le gros avantage de l'hybride c'est que c'est le même code pour toutes les plateformes, ce qui évite de devoir faire deux applications, pour Android et iPhone, qui coutent deux fois plus cher.

Par contre, mieux vaut éviter l'hybride si on a besoin de perfs au top, parce qu'une surcouche sera toujours plus lente que du natif. Ce qui inclue tous les super effets d'animation mouf-mouf. Si on a besoin de certaines API très liées au device, Cordova ne nous y donnera pas forcément accès. Et finalement, si on n'a besoin de développer que pour une unique plateforme, autant partir sur du natif.

Dans les deux cas, pour pouvoir passer son app sur iPhone, il faudra passer par les 15 jours de validation Apple. Il n'y a rien dans les CGU d'Apple qui bloque l'hybride plus que le natif.

Maintenant, parlons de ce qu'apporte Ionic. Déjà, il utilise Cordova, qui est le moteur open-source utilisé par Phonegap. Il gère aussi parfaitement les affichages d'élements dans une page, même quand on fait apparaitre/disparaitre le clavier (source de bugs divers).

Avec Ionic, on fait une application, pas un site web. On passe sur un paradigme où on réfléchit en terme de "vues" (écrans), et on doit alors penser à comment ceux-ci s'emboitent, quel est le comportement du bouton back, etc.

Ionic est fourni avec des directives (Angular oblige) pour la majorité des éléments de UI classiques d'une app : header, footer, listes avec pull-to-refresh, swipe sur item pour avoir un menu, drag'n'drop, popup de choix d'action, slideshow, etc

Ça s'installe classiquement à base de npm et génère un code boilerplate avec une petite appli pour comprendre comment les différents éléments interagissent. Si vous voulez vraiment aller vite, il existe même le Ionic Creator pour générer sa UI à base de drag'n'drop.

Ça pêche encore du coté Android quand le browser par défaut est le stockbrowser, qui a des perfs bien moins bonne que Chrome. Il y a des solutions en cours de développement pour contrer ça. Il n'est pas non plus compatible sous Windows Phone pour le moment.

Coté UI, Ionic vient avec son propre style. Il y a des essais pour reproduire un style natif Android ou iPhone, mais c'est pas encore au point et jQuery mobile est plus avancé de ce coté là apparemment. Par contre, on a quand même le droit à une classe CSS sur le root indiquant si on est sous Android ou sous IOS pour tweaker notre app en fonction.

VIRTJS

Maël Nison est venu nous parler un peu plus de Ionic, qu'il a utilisé sur un projet perso nommé Start9.

Maël avait déjà présenté un émulateur gameboy qu'il avait développé en javascript. Il a cette fois-ci poussé le concept un peu plus loin en proposant un site web en Ionic, accessible donc depuis n'importe quel browser, sur lequel on puisse uploader ses roms Gameboy et y jouer directement dans le navigateur. L'avantage est d'avoir un système crossplatform, on peut commencer sa partie sur son téléphone dans le métro et la continuer au même endroit sur son desktop plus tard.

Le gros avantage est que c'est un simple site web. Pas besoin d'installer quoique ce soit pour l'utilisateur, et pas besoin de passer par la validation appStore pour le créateur.

Coté techno, c'est du node en backend, avec du sequelize (ORM pour taper sur PostgreSQL et SQLite). Systemjs et Traceur pour ses modules ES6 transformés en ES5. Comme ça, le jour où ES6 est partout, on peut enlever la transformation. Et sinon, du Ionic pour le front.

Pour la suite ils envisagent de supporter de plus en plus de jeux, et de plus en plus de consoles. Ils passeront aussi à Angular 2 quand il sortira (pour rester sur une stack ES6). Leur retour sur Ionic c'est que c'est cool mais encore jeune, les issues sont fixées rapidement (si les mainteners sont pas en vacances...).

Conclusion

Une bonne soirée ParisJS, avec 3 talks très intéressant, une grande salle, de la pizza pour tout le monde et des discussions intéressantes autour d'une bière.

Tags : #parisjs

Want to add something ? Feel free to get in touch on Twitter : @pixelastic