D'abord, qu'est-ce que "Paris JS" ? Paris, comme la capitale, et JS comme Javascript
Nous sommes une communauté sympa d'informaticiens, de développeurs qui créent des programmes informatiques en javascript et qui se réunit pour discuter des nouvelles technologies qui ont vu le jour autour du langage de programmation javascript (mais pas que, on parle aussi de typescript). Les anciens y voient une sorte de "café-philo" en référence aux débats animés de Marc Sautet au café des Phares, place de La Bastille à Paris. Nous nous réunissons depuis 2010, tous les mois, le dernier mercredi du mois, pour généralement 1h30 de présentations, avec un networking-pizza à la fin pour discuter technique, demander de l'aide sur tel ou tel sujet, du feedback, et faire connaissance avec les petits nouveaux.
Cette communauté de "javascripters" indépendante, il n'y a pas de "directeurs", de "chefs", il n'y a que des contributeurs, et chacun présente ce qu'il veut, du moment que ça intéresse la communauté. L'entrée est libre, tout le monde est le bienvenu. Merci aux Juliens, Pierrick, Alex, etc.
Pour contribuer, il suffit de proposer son aide en se rendant sur le Github ou sur le site web ou le Google group ou le Linkedin , faire les compte-rendus des rencontres, bref tout ce qui peut aider la communauté...
Merci à Google (Philippe) de nous recevoir dans leurs magnifiques locaux et de nous offrir les pizzas et les bières. Au coeur de Paris, c'est pratique, ça permet de se rejoindre facilement après la journée de travail.
Une question? Posez-la ici
Aide au développement d'applications
Marco nous explique comment gagner de la place dans son application EmberJS grace à GlimmerJS
Les applications Ember sont connues pour prendre beaucoup de place, car EmberJS est une grosse librairie. Heureusement, Glimmer arrive pour compresser tout ça et gagner de la place.
« Feel the glimmer »
Marco Otte-Witte simplelabs.com d’Allemagne
Travaille sur Ember
Glimmer.JS
Ce sont des composants legers pour créer des sites internet
On peut le comparer à ReactJS
C’est un moteur de rendu très rapide, car la glimmer VM est très rapide ele meme
On peut parler de REact : on a besoin d’un virtual DOM pour gagner en performances et n’afficher que les différences de rendus dans l’application, et pas la page toute entière.
C’est globalement un objet javascript qui adresse le virtual DOM. Au debut il y a une comparaison entre le DOM virtuel et le DOM. Ensuite, dès qu’il y a une modification, normalement on réapplique toute la template, avec une nouvelle représentation du DOM, on recompare le DOM, on a de nouvelles différentes, et on applique que les différences que l’on a constaté. C’est bien plus rapide que de remplacer le DOM complètement.
On n’applique que les différences. On n’a pas à relancer toutes les fonctions javascript au runtime.
Le pipeline Glimmer
1 Précompilation
2 Initial render
3 RE-render
- 1 pré-compilation
Pendant la pré-compilation, le template de l’application va être compilé.
Si l’on regarde le template, il y a des class par exemple, du texte en gras, des li, des ul….
Il va etre compilé en template avec des nombres, des chiffres, des tags, des attributs, etc…
On appelle ça le « wire format » ou format en fil de fer
Ce pseudo code est rendu ensuite grace au navigateur
Le navigateur n’a pas besoin de tout recompiler les fonctions javascript : il charge juste ce « wire-format » et l’affiche : on gagne un temps fou !
Ce n’est pas du Json, c’est encodé dans un format voisin plus petit et plus efficace.
Ce pseudo code est envoyé au navigateur.
- Initial render
Les elements du DOM sont créés et opcodes pour le re-rendu sont générés.
Glimmer implémente une machine virtuelle dans le navigateur qui lit ces opcodes et les lance.
Par exemple, si on a un texte en allemand et que l’on veut le traduire en français, cette étape se fera pendant la compilation, on gagnera du temps.
Si on regarde le template, le handle-bar est facilement identifiable, il peut changer au runtime
Les elements qui vont etre compilés sont entre les moustaches { et } c’est en quelquesorte de l’injection, comme avec AngularJS pour ceux qui connaissent.
Cet « opcode » sera créé par Glimmer, et mis à jour dans le DOM par le navigateur.
- Update renders
Les « opcodes » mis à jour sont rendus ensuite dans le DOM puis dans le navigateur.
Glimmer synchronise automatiquement le DOM, on n’a rien à faire il met à jour les valeurs de l’application qui ont changé automatiquement, tout seul.
Un objet référence embarque en entrée des variables, et ensuite en sortie fait un return de cette valeur.
On passe toutes les variables de l’application dans un objet
barReference
let fooReference : Reference<number> = {
value() {
return foo ;
}
} ;
Pour le texte : Il y a une méthode value qui prend le texte en argument et retourne vrai ou faux s’il a changé.
On a une référence TaffeReference<T> qui extends Reference<T>
On peut modifier les valeurs à la volée, les comparer, et si elles sont différentes, on les met à jour
Le code javascript est transformé en « opcode », qui est un pseudo code grace à la méthode UpdateOpcode.
Class UpdateOpcode {
Execute() {
…
This.domNode.textContent = newValue ; // update DOM
}
}
Tout le monde se base sur les benchmarks javascript : on compare Glimmer avec Preact, React et Inferno, le rendu initial est plus rapide sur inferno MAIS, au re-render, Glmmer est largement plus rapide ! 3 fois plus rapide on peut dire.
Glimmer VM a vu le jour avec EmberJS 2.0 ce qui veut dire que c’est stable et que l’on peut faire évoluer la plate-forme facilement. Les mises à jours sont compatibles avec les versions précédantes d’Ember.
Robin Ward annonce que l’application est 41% plus petite avec Ember 2.10
ember.prod.js était gros : 1.6 Mo ! Ah oui quand meême, c'est du lourd, les SEO vont raler
reacr-dom.js fait 1.1k
Si on se base sur la taille critique d’une application de 2MO maximum, la librairie EmberJS prend plus de place que ReactJS dans l’application.
MAIS ! Grace à glimmer, on diminue la taille de l’application, grace à ce mécanisme de pseudo code et d’opcode et on arrive à avoir une application identique en taille à ReactJS.
L’installation est très simple avec NodeJS, comme d’habitude:
Npm install –g ember-cli
Ember new my-app –b @glimmer/blueprint
GlimmerJS est fourni avec typescript aussi, on voit les .ts dans le paquet.
Les templates sous Glimmer
On remarque les < et les > et les @ avant les arguments et les attributs
On peut tracker automatiquement, ou observer si une propriété change, avec :
@tracked(‘todo’)
La demo est visble sur :
https://github.com/glimmerjs/tdomvc-demo
Quand on uncheck une propriété, en temps réel le DOM est donc mis à jour
Glimmer
Npm install @Ember/router
Npm install @Ember/service
Npm install @Ember/data
Ember
Une question? Posez-la ici
Aide au développement d'applications web mobile smartphone
Sécuriser son site internet, les bonnes pratiques
"Static websites get hacked"
Par Akexander Ottenhoff
Les sites web statiques sont-ils plus sécuriés que les SPA Single page applications ?
Il y a des informations critiques, des tokens, des API, etc à proteger. Une SPA Single Page application est un site internet inégré dans une seule page avec des menus, un routeur, et où tout est fait pour éviter le rechargement complet des pages pour gagner en bande passante et en expérience utilisateur. En même temps, c'est délicat d'indexer de telles applications sur les moteurs de recherche, mais heureusement que les SEO sont là pour ça.
Alors quelles sont les vulnérabilités possibles ?
Le Cross site scripting XSS
Clickjacking and Framevusting : on enregistre les clics et on les redirige
Man in the middle : ecouter le traffic au milieu
Leak du referrer
Document.referer on a une information sur le site que vous avez visité avant
Il faut forger les headers pour avoir de la sécurité.
Referrer-Policy : no-referrer
Referrer-Policy : origin
…
Le Click jacking
On voit un bouton « gagner de l’argent » on clique et en fait ça supprime notre compte Facebook ! Mince alors !
Il y a des techniques pour cacher une frame dans la page
Pour sécuriser ça, il fau bloquer les X-frame via les header :
Ou bien sandboxer les iframes :
X-Frame
<iframe sandox= « allow-scripts allow-forms »
Referrer= »no-referrer »
/>
Les attaques « Man in the middle »
Wifi : le login page est remplacé par un malware dans les cofeeshops
Utiliser le HTTPS ! car le traffic sera encapsulé et sécurisé, personne ne pourra lire les données
Strict Transport Security HSTS
http public key pinning HPKP
public-key-Pins :
pin-sha256= »preimary-key » ;
pin-sha256= »backup-key » ;
Attention en changeant les headers, on peut rendre le site instable
XSS, les injections Cross site scripting
On peut acceder au local storage et voler les cookies..
Modifier le Dom
Ouvrir des popups
Espionner les evenements utilisateurs
Comment se proteger ?
Utiliser la propriété textContent au lieu de innerHtml
Echapper les chaines < et > avec <, et > ;
Quand on charge du JSON, utiliser JSON.parse() au lieu de eval()
Dans certains navigateurs : X-XSS-PROTECTION à 1
Les CSP : content security policy à adopter
Content-Security-Policy :
Style-src « self » ;
Font-src fonts.google.com ;
Script-src sha256-c2NyaXB0 ;
Default-src ‘none’ ;
Report-uri https://reports-api.sqreen.io/browser/v0/
Une question? Posez-la ici
Aide au développement d'applications web mobile smartphone
Comment piloter sa machine à café à l'aide de Javascript
Par Dominik Kundel
IOT Coffee machine, pour piloter sa machine avec javascript
IETF RFC 2324
HTCPCP : Hyper text coffee pot control protocol
Reconnu par l’IETF
Build on top of http
Safe and accept
Coffe:// url scheme
C’est un eAPI qui permet de communiquer entre applications, video, chats…
Pourquoi ? Parce que c’est intéressant, c‘est une sorte de jeu.
On peut Controler la machine à café par la voix : « Alexa, fais moi un café »
Parce qu’une machine à café avec une API c’est genial !
Pourquoi en javascript et pas en C++ ou en Java?
Parce que le C++ et le Java c’est trop bas niveau et que ça me rappelle l’université et les mauvais souvenirs.
Avec javascript, tout est plus rapide !
Créer un serveur web en javascript c’est facile et c’est fun
Le hardware et javascript sont gérés par des evenements.
Parce qu’en javascript on veut tout le temps savoir ce qui se passe dans le DOM. En hardware c’est pareil on veut savoir combien il reste de grains de café dans la machine.
Option1 ESPRUINO
www.espruino.com avec ES6 beaucoup utilisé pour les projets IOT
on plug ça dans le PC en USB et le tour est joué
Mais ? pas de Wifi
Option2 TESSEL 2
La carte est plus grosse qu’une clé USB
Dans les 50 euros
Option 3 Johnny-Five
IO plugins pour manipuler facilement les objets connectés autour.
Et sur NodeJS !
Tessel2
Des classes pour plusieurs morceaux hardware
On a choisi Johnny five et tessel:
8 cables, 6 commutateurs pour gérer le type de café
1 cable est alimenté
On a besoin de 3 pins pour contrôler les boutons
On a besoin de 3 pins pour contrôler les lumièrese
Const five = require(‘johnny-five’) ;
Const five = require(‘tessel-io’) ;
Const board = new five.Board( {….} ) ;
Johnny five a une class bouton
Const b2 = new five.Button(‘b1’) ;
Buttons.forEach(btn=> {
…
Console.log (‘un bouton a été pressé’)
}
Utilisation de Fritzing pour réaliser le circuit imprimé
ET voilà
Javascript loves hardware
Voilà, j'espère que ça vous a plu. Vos commentaires/remarques sont les bienvenus