• Le don du mois n’est pas mensuel. Il est juste limité à un par mois. Ça m’évite la pression d’être un bon samaritain. Sauf que du coup, j’oublie parfois pendant trèèèèèèès longtemps :)
• Il n’y a pas beaucoup de projets JS dans le lot. Ahem.

En fait le seul et unique projet JS supporté a été VueJS. C’est dire que la barre est haute, étant donné la qualité exceptionnelle de ce projet.

Donc quand je vous dis que j’ai donné 50 balles à Mobx, c’est que le projet déchire. Et il déchire malgré le fait qu’il soit codé en JS.

Mobx permet, en gros, de surveiller les modifications à une structure de données. Vous posez un marqueur sur la structure, et un sur les fonctions utilisant la structure, et c’est tout:

class TodoList {
    @observable todos = []; // dire à mobx de surveiller
}

...

@observer // dire à mobx de tenir à jour
class TodoListView extends Component {
    render() {
        return 

            {this.props.todoList.todos.map(todo =>)}
        
    }

C’est là la brillance du système: malgré sa simplicité, mobx va récursivement réagir à toute modifications, même sur des données complexes imbriquées; Et calculer toutes les dépendances de chaque fonction pour ne les appeler qu’au meilleur moment.

C’est facile à utiliser, et étonnamment rapide à exécuter.

Le résultat ? Quand un client me force à utiliser ReactJS, je saute redux, et je met Mobx à la place. Ca donne presque l’impression d’utiliser Vue: le code de manipulation d’état est simple à comprendre, gentil sur le CPU et les mutations d’état restent courtes et élégantes. Le reste est toujours moche, mais ça on y peut rien.

Bref, mobx est ce qui rend react acceptable. Et tout ce qui peut apaiser la douleur du dev en front-end n’a pas de prix.

J’ai regardé le code source, et la popote interne est bien complexe. Mais à chaque fois que je veux l’utiliser je me dis que ça ne pourra pas être si simple… et si.

La page de don, c’est par là.

Dans le dernier article, je vous offrais votre dose maintenant obligatoire de bashing de l’écosystème JS. En l’occurrence en suggérant que React était un bouquet de roses avec plus d’épines que de pétales.

Mais bon, si les gens utilisent React, ça n’est pas QUE parce que c’est la mode. C’est parce que cette techno répond à un besoin de plus en plus impérieux en dev front end : avoir un outil valable pour créer des GUI avancées en JS.

Parce que le combo jQuery + moteur de template, ça nous a mené loin, mais on arrive au stade où ça scale plus.

Pas mal de tentatives ont été faites pour répondre au problème : knockout, angular 1, polymer, etc.

La nouvelle génération (react, riot, vue, angular 2+, etc) est beaucoup plus mature et performante, et offre des fonctionnalités très sympas:

• DOM virtuel qui permet de faire des mises à jour fréquentes sur de très nombreux objets à l’écran sans freezer le browser.
• Découplage très élégant des données et de leurs représentations.
• Facilité de manipulation des éléments HTML, des events et du cycle de vie de tout le bordel.
• Création de composants graphiques isolés et réutilisables.

En gros, partout où on faisait avant $(selecteur).trucmuche(element), on peut maintenant faire ça plus facilement, plus rapidement et plus proprement. (Par contre Vue/React/etc font pas l’AJAX, tournez-vous vers axios ou gardez jQuery sous le coude).

Bon, si ils offrent TOUS ces éléments là, pourquoi diable est-ce que j’ai une préférence pour Vue.JS plutôt que Riot, Angular ou React ?

Souvenez-vous, je reprochais essentiellement ceci à React:

• Grosse courbe d’apprentissage. Ce qui impacte la productivité de tout nouveau dans l’équipe.
• Mauvaise ergonomie du JSX qui du coup s’écrit, se lit et se debug lentement.
• Mauvaise foi totale de la communauté qui prétend qu’on peut utiliser React sans la tonne de nutella autour, ce qui est comme argumenter qu’on peut faire du Java sans IDE.
• Nutella sus-nommé qui est blindé d’huile de palme et de vidange.
• Globalement une API inélégante et peu intuitive.

Mais alors, qu’est-ce que Vue.js fait de mieux ?

Ben tout, mes amis. Tout.

Légèreté

A l’heure où les codeurs hypes de la vibe du flex ont tous un fichier de conf webpack de 3 km, mais déjà obsolète et qui pétera à la prochaine upgade, Vue offre un point de vue rafraîchissant sur la question.

TOUTE, j’ai bien dit TOUTE, la puissance de vue.js est accessible avec une simple inclusion de balise script.

Vous en avez marre des pages de 3Mo ? Minifié et gzippé, Vue.js pèse moins de 30ko.

Dans un monde où il faut soit faire un site Web, soit faire une SPA (aux chiottes l’amélioration progressive !), Vue permet de ne remplacer que quelques bouts de vos pages si vous n’avez pas envie de tout transformer en un monstre de JS.

La doc, très bien faite, vous permettra de prendre l’outil en main en une après-midi. En buvant du thé.

Le tout, sans besoin d’aucun écosystème particulier. Aucun. Rien. Ca marche out of the box.

En gros, là où tout le monde vous vend du scale up, Vue vous permet de scale down.

Puissance

Malgré cela, Vue reste parfaitement adaptée aux gros projets. En fait, elle a été créée pour et par l’équipe du site du géant chinois, alibaba.com. Alors oui, c’est sûr, c’est pas Facebook et son milliard d’utilisateurs, mais comme mes projets ne servent pas 10 millions de pages par jour, contrairement à Alibaba, je pense que je suis ok.

Dans la pratique, qu’est-ce que ça veut dire ?

Et bien d’abord, Vue est plus rapide que React. Ouais ça fait mal au cul de lire ça quand on vient de finir d’optimiser son pipeline de rendu JSX, surtout que la techno a été créée pour la vitesse. Mais voilà, c’est le cas.

Vue supporte aussi parfaitement l’inclusion dans un écosystème plus gros si le besoin s’en fait sentir :

• Vous pouvez utiliser Vue avec Webpack.
• Vous avez un store et un routeur pour vue.
• Vous pouvez utiliser du JSX si vous êtes maso.
• Vous pouvez créer des SPA avec une hiérarchie de composants.
• Vous pouvez faire le rendu des templates côté serveur.

En gros, Vue peut faire absolument tout ce que les autres font. Mais ne vous oblige pas à commencer en sortant le bazooka. Vue est ce que React aurait dû être depuis le début.

Notez qu’on peut remercier les devs de React pour avoir popularisé de nombreux concepts que Vue utilise. Standing on the giants’ shoulders et tout, et tout. Vue n’aurait jamais existé sans React. Mais maintenant que Vue est là, on peut laisser React en paix.

Elégance

De par son design, Vue vous permet donc de commencer doucement, en ajoutant 30ko à votre projet et en l’utilisant un peu ici et là. Puis quand vous en avez besoin, vous pouvez commencer à utiliser des fonctionnalités avancées.

Par exemple, vous pouvez comme avec Angular 1 balancer toutes vos variables et binding dans le HTML de votre page en vrac. Et plus tard tout refactoriser en composant comme avec React. Tranquille.

L’API de Vue est petite, et surtout, facile à comprendre car tout est bien nommé, et bien rangé. Voyez plutôt:

Vue({
  el: "#app", // l'élément sur lequel attacher la vue
  created: function(){
    // code lancé au démarrage
  },
  mounted: function(){
    // code lancé quand la vue est attachée à la page
  },
  updated: function(){
    // code lancé quand la vue est mise à jour
  },
  destroyed: function(){
    // code lancé quand la vue est détruite
  }
  data: {
    // ben ici y a vous données statiques
  },
  methods: {
    // ici les fonctions à rendre disponibles dans le HTML
  },
  computed: {
    // ici on met les données à recalculer à la volée
    // à chaque refresh
  }
})

Voilà vous avez là 50% de l’API de Vue. Very hard indeed.

On sent partout que les devs ont apporté des soins à des petits détails comme:

Foo

D’une manière générale, tout template Vue est du HTML valide, ce qui fait qu’il est très facile d’insérer du Vue sur un site existant.

Un petit bout de vue

Mais alors, pour tous ceux qui en sont restés à jQuery et handlebar.js, à quoi ça ressemble tout ça ?

Ben un todo ressemble à ça en Vue:

  
  







  
  
 Ajouter



  
  
{{task}}

  

(Vous pouvez littéralement copier-coller ce code dans un fichier todo.html et ça marche. Essayez de faire ça avec React…)

Comme avec Angular/React/Riot on a séparé complètement la logique de manipulation des données de celle de l’affichage qui est mis à jour automatiquement quand les données changent.

Contrairement à React, on n’est pas obligé de créer un arbre complexe de composants qui transforme toute sa page en soupe de JS(X). Mais contrairement à Angular, on n’est pas obligé de rester sur cet exemple simple, et on peut créer une hiérarchie de composants.

Un composant peut complètement isoler le JS, le HTML et le CSS (qui n’affecte alors que le composant):

Et pour que ça marche, pas besoin de préprocesseur, pas besoin de ES6, ES7, typescript, babel, webpack, npm… Vous pouvez les utiliser. Sur un gros projet je me fais chier à setup ce qui vaut le coup. Mais vous n’êtes pas obligé.

La communauté

La communauté est importante pour un projet, et celle de vue est très agréable. Ce sont des gens polis, humbles, et compétents. Ils pensent aux petits détails. Regardez par exemple cette page pleine de jolis schémas.

En comparaison, la communauté React est criarde. Les confs des devs de Facebook sont faites par des présentateurs tout droit sortis de South Park. Quand on critique react, on se fait insulter personnellement sur twitter par les fan boys plutôt que de tenter de discuter, preuve systématique de l’absence d’arguments.

Enfin les seuls éléments donnés pour combattre les critiques sont les raisons des problèmes, un rappel de la taille des utilisateurs et des “moi j’aime” laconiques.

Mais faites un test. Prenez 3 dev, un react, un jquery, un vue. Faites leur faire un agenda CRUD avec recherche et autocompletion qui tape en Ajax dans un backend Django/Rails/Whatever. Donnez leurs des machines vierges. Et sortez le pop corn.

Pour le moment, React possède encore deux avantages: react native, et la masse (fb, les utilisateurs, le nombre de plugins, etc).

Mais honnêtement ? Il y a très peu de bénéfices à utiliser React plutôt que Vue sur la plupart des projets pur Web. Et un coût garanti d’être élevé.

Angular 1 est en train de mourir de l’abandon de Google. Après la sucette de l’incompatibilité d’Angular 2, je n’ai aucune confiance en la techno et ne compte donc pas réinvestir de billes dedans. De plus Angular 2+ souffre du même problème d’obligation d’installer la terre entière avant de commencer à coder.

Riot est une meilleure alternative, mais l’obligation de passer par des composants est un no-go IMO. Créer des composants pour moi est l’exception, pas la règle. Je le fais en dernier, à la phase de refactoring.

Donc ne vous emmerdez pas, prenez quelques heures pour jouer avec Vue, ça coûte pas cher, et c’est chouette.

————-

On me signale dans l’oreillette de linker dans la doc française.

Après tout, Facebook est codé avec cette techno pixel par pixel, et ils servent des milliards de pages chaque jour. Ça ne peut pas être mauvais. Ce ne sont pas de cons quand même.

Et puis tout le monde en parle, les asticots gigotent autour des restes du gigot d’ordre que les devs des GAFAS tentent de mettre au menu dans leur régime sans sel et sans typage.

Alors merde, quoi, react, keskeçavo ?

Je vais passer peut être pour un réact (hashtag lol), mais franchement le gigot au brouillard, c’est pas mon plat préféré.

Taillons un peu JS, ça m’avait manqué.

Mon royaume pour un hello world

React est tellement chiant à setuper que la doc officielle vous propose le hello world dans un code pen histoire de pas vous faire fuir tout de suite.

En fait, si pour vous installer un module avec npm/yarn/bower (plutôt que de copier le truc directement ou d’utiliser un CDN) est déjà un truc qui vous fait grogner, vous êtes loin derrière.

Il va vous falloir un outil de build (gulp, grunt ou l’usine à Vespene Webpack) et la série de recettes obsolètes customisées trouvées sur un coin de github pour connecter tous les bouts de votre pipeline. React bien sûr, mais aussi Babel pour transformer le JSX en JS.

Babel suit la left-pad philosophie, à savoir que tout est configurable et éclaté en centaines de petites dépendances et settings. C’est tellement chiant que des packages existent, appelés “presets”, dont l’unique but est de configurer Babel pour une tâche particulière.

Une fois que vous avez tout ça up, vous vous allez à la pêche au tuto, seulement pour remarquer que tout le monde code en ES6, voir ES7, et vous rajoutez donc un peu plus de plugins à tout ce bordel. Allah vous garde si vous tentez d’utiliser TypeScript.

Et vient alors le moment tant attendu pour faire coucou de la main programmatiquement. Ça foire, bien entendu. Le debugger vous pointe sur un bundle.js de plusieurs Mo, et vous apprenez que le support des sources maps est inégal d’un navigateur à l’autre.

Bienvenue.

Le X c’est pas toujours excitant

Une fois passée la douloureuse expérience de mettre en place votre environnement de travail, vous trouvez un certains confort. L’autoreload de la page est franchement pratique, et pouvoir utiliser l’unpacking (pardon le spread), les valeurs de paramètres par défaut et les arrow functions sans vous soucier de la compat du navigateur c’est quand même cool. Avec un webpack tout bien huilé avec amour (et douleur), vous pouvez faire des imports en JS et on a presque l’impression d’utiliser un langage de programmation.

Et puis le JSX, de loin ça à l’air pas mal ! Du HTML directement dans le JS ça parait un peu bizarre mais on vous le vend comme un avantage : finis les langages de templates limités, vous pouvez utiliser la pleine puissance (hum…) du langage JavaScript pour créer vos balises.

Sauf que non, le JSX, ça pue du cul.

D’abord, il y a le fait que toutes les structures sont à faire en JS. Les conditions, les concaténations et bien entendu, les boucles. Donc vous avez une liste de noms et numéros de téléphone, en VueJS, vous faites:

    

        {{ pers.nom }} : {{ pers.tel }} 
    
    

        Nobody's here!
    

Mais en React, vous allez faire péter une expression ternaire et une fonction anonyme en plein milieu rien que pour l’occasion:

    {
      (this.state.persons)
        ? this.state.persons.map((pers) => (
            
{ pers.nom } : { pers.tel } 
        ))
        : (
            

                Nobody's here!
            
        )
    }

Vous la sentez bien la puissance de JavaScript là ?

Et attention à ces boucles, car dedans vous guette cette erreur qui va vous poursuivre jusque dans vos cauchemars:

SyntaxError: Adjacent JSX elements must be wrapped in an enclosing tag

Babel vous signale gentiment que ne pouvez pas produire un snippet de JSX qui contienne plus d’un élément à la racine. Donc il faut TOUT wrapper dans un container. TOUT. Vous allez avoir vite des DIVs et des SPANs inutiles partout, juste pour faire plaisir à React. C’est absurde. C’est à vomir. Ca nique votre CSS et remplit vos sessions “examinez un élément” de tendinites dues aux clics pour déplier tout l’arbre des emballages cadeaux de vos balises. Et aussi, nique la sémantique.

Pour éviter ça vous allez tenter d’inliner un maximum de trucs dans une seule expression JSX ou tout foutre dans des arrays. Car je ne l’ai pas précisé ? Les arrays de JSX sont automatiquement et magiquement convertis en sous-éléments. Et du coup vous pourrez profiter au maximum des qualités de lisibilité de JS.

JSX est bourré de petits trucs comme ça, pour faire plaisir. Par exemple, j’ai un bouton, quand je le clique il delete la personne de la ligne de mon agenda. Je mets aussi une classe pour tous et une selon que la personne est importante ou non. Un prevent default pour éviter que le browser recharge la page si je suis dans un form.

En Vue, je passe un objet qui dit quelle classe afficher ou non. Le click handler contient une instruction prevent qui me permet d’appeler preventDefault automatiquement. Et j’appelle deletePerson tout naturellement :

    Delete

En react, on ne peut pas passer de paramètre à son handler. Il faut le passer dans une closure. Mais alors la closure va recevoir l’objet event, qu’on doit donc faire suivre à notre handler, afin qu’il puisse appeler preventDefault à la main. A noter aussi que class s’appelle className. Et n’accepte que des strings donc la concaténation se fait à la mano.

// plus haut on appelle preventDefault dans handleDelete

 this.deletePerson(pers, e)}>
    Delete

Ce n’est pas juste chiant à lire, c’est surtout hyper chiant à trouver, à taper et à debugger.

Un peu de nutella sur votre confiture ?

React, c’est verbeux, il va falloir vous y faire. Il suffit de comparer le code nécessaire pour faire une TODO en react avec les autres frameworks.

Mais ce n’est pas juste ça qui est lourd.

Non, le vrai truc qui est super pesant, c’est que react est un cancer. Quand il est utilisé, il contamine tout.

Par principe, une fois que vous utilisez react, il faut mettre TOUTE VOTRE PAGE en react. Pas juste un petit bout. Par là j’entends que 90% de votre HTML va devoir migrer dans le code JSX. Votre beau code HTML bien propre, converti en cette monstruosité de mélange entre le langage le plus dégueulasse du monde et un monstre mimic qui essaye de se faire passer pour du HTML pour vous bouffer.

Or, toute l’idée c’est de faire des composants, de diviser votre pages en plus petits bouts. Mais voilà, React n’a rien prévu de simple pour la communication. Pour passer des données des composants enfants, il faut les passer via les attributs de balise HTML (appelés les props, pour faciliter la rechercher Google). Si vous avez 5 niveaux d’imbrications, vous vous tapez ça 5 fois.

Plus amusant, il n’y a aucun mécanisme pour passer des infos de l’enfant aux parents. La méthode standard est d’écrire puis passer manuellement un callback du parent à l’enfant, via props, et appeler ce callback dans l’enfant avec la valeur que le parent utilise ensuite. POUR. CHAQUE. PUTAIN. DE. VALEUR.

Passer des callbacks, ça va 5 minutes. Et ça ne résout pas un problème de communication entre composants parallèles, c’est à dire ni parent, ni enfant. Du coup tout le monde finit par utiliser une lib supplémentaire type EventEmitter pour servir de bus de communication.

Quand vous entendez les gens se plaindre de la difficulté d’utiliser l’écosystème de react, les fans répondent souvent que l’écosystème n’est pas obligatoire. On peut très bien s’en passer sur un petit projet.

Sauf que react est absolument inutilisable sans. Sans un bus d’event, un transpiler ES6 + JSX, un builder et un hot reloader au mininum, le projet ne dépasse jamais le stade du prototype.

Mais bon soyons franc, beaucoup de projets react tout court ne dépassent jamais le stade du prototype. On parle de codeurs JS là.

Etat

Les props ne doivent jamais changer. Seul l’état d’un composant react peut changer, ce qui trigger un nouveau rendu du composant.

Mais l’état lui-même est en read-only. On est supposé uniquement créer un nouvel état à chaque fois et remplacer l’ancien.

Au début on le fait à la main, mais JS n’est pas vraiment fait pour faire de l’immutabilité, et ça devient uber chiant très vite. Changer la propriété d’un objet qui est lui même dans un array demande de recréer tout l’array et l’objet. A chaque fois.

On se tourne alors vers des libs (encore une) type immutable.js qui fournit des listes et maps qui sont immutables et permettent de faire ces opérations sans y laisser ses jours de congé.

Une fois de plus, les connards qui vous disent qu’on peut faire du react sans la tonne de boiler plate qu’on voit dans les tutos ne le font jamais eux-mêmes. Parce que oui, on peut faire Paris-Amiens à pied en théorie, mais bon…

Des décisions à la con

Clairement, react a été fait pour créer des UI. Mais au bout d’un moment, les utilisateurs se sont réveillés et ont voulu une encapsulation pour des composants non UI. Mais react ne sait pas faire. Quand vous avez donc un composant non UI, par exemple la déclaration de votre routing, vous le déclarez… en JSX:

  render((
      
        
        
      
  ), document.getElementById('app'))

Votre app va devenir très vite une pyramide de composants, certains qui s’affichent, d’autres non, tous se passant en cascade des données les uns aux autres.

Et au passage, quel est l’abruti qui a décidé des noms des méthodes des cycles de vie comme getInitialState, componentWillMount et componentDidMount ?

Surtout que vos méthodes et les méthodes héritées de la classe du component sont dans le même espace de nom.

Le bonheur des stores

Un truc dont on peut vraiment se passer par contre, ce sont les stores. Flux, redux, vuex, etc. On peut utiliser n’importe quelle solution pour stocker l’état de son projet côté client.

Mais si vous voulez profiter des promesses de react, comme le time travel et la concurrence parfaite, il vous faudra un store.

“store” c’est le nom huppé que react donne à ses modèles. Je ne vais pas rentrer dans les détails, et vous laissez décider par vous même du truc. Voici, comment la doc vous recommande d’ajouter une personne dans une liste d’un agenda avec redux, la store la plus populaire:

// Les imports
import React from 'react';
import { render } from 'react-dom';
import { createStore } from 'redux';
import { Provider } from 'react-redux';

// creation du store
const initialState = {'agenda': []};

function reducer(state=initialState, action){
  switch (action.type) {
    case 'ADD_PERSON':
      return {
        'agenda': [..., action.object]
      }
    default:
      return state
  }
}

const store = createStore(reducer);


// creation de l'action d'ajouter un objet dans le store

function addPersonAction(obj){
    return {
        'type': 'ADD_Person',
        'object': obj
    };
}


export function addPerson(Person){
    store.dispatch(addPersonAction(Person));
}


// composant qui affiche le form de l'agenda et la liste des personnes
var Agenda = React.createClass({

  handleAdd: function(){
      addPerson({
        "name": this.refs.name.value,
        "tel": this.refs.tel.value
      })
  },

  render: function(){

    return 

        
Add
    

    

        {
            this.store.agenda.map((pers) => (
                
{ pers.nom } : { pers.tel } 
            ))
        }
    
  }


});


// adapter qui permet de passer le store à l'agenda
const AgendaContainer = connect(function(state){
    return {'agenda': state.get("agenda")};
})(Agenda);


// affichage du bouzin
render((

  

), document.getElementById('app'))

Vous imaginez bien que trouver ça tout seul a été un bonheur. Parce que oui, la doc est absolument à chier, dans la longue tradition des stacks JS modernes.

Ça ne fait que quelques temps que j’utilise Vue.js, mais globalement c’est déjà mon outil par défaut pour toute UI en JS.

J’ai encore des demandes de formations et projets pour Angular 1 et React, mais si j’ai le choix il n’y a aucune hésitation.

J’ai essayé quelques alternatives, comme Riot, mais on arrive jamais à cette combinaison parfaite de simplicité, légèreté, puissance et performance. Ce projet est un petit bijoux du monde de l’open source. Un truc rare en Javascript.

Bref, c’est bien beau de cracher toujours sur JS, mais ça résout pas le problème. Il faut aussi aider, et c’est donc pour ça que je fais un don de 50 €, par ici.

Et si vous regrettiez l’époque de la simplicité de jQuery mais que vous avez envie de quelque chose qui automatise bien plus comme un framework moderne, vous savez ce qu’il vous reste à essayer :)

Pourquoi je vous dis ça ?

Et bien parce que sebsauvage a partagé un snippet pour utiliser l’API du clipboard en JS. Et j’ai donc voulu savoir comment détecter que cette functionalité est implémentée par le navigateur en cours.

Je suis ainsi allé voir les sources de modernizr, et il implémente en fait une combinaisons de 2 techniques.

D’abord, vérifier si l’objet window a un attribut ClipboardEvent. Si oui, c’est réglé. Si non, il crée un div, on check s’il a un attribut paste. Le reste sont les hacks de compatibilité avec les très vieux navs que je ne vais pas retranscrire ici.

Donc en gros, avant de faire un copier/coller en JS, vérifiez:

function implementClipboardAPI(){
   try {
     return (!!window.ClipboardEvent || 'onpaste' in document.createElement('div'));
   } catch(e) {
     return false;
   }
}

Et vous savez également comme j’aime troller JS.

De plus, il y a quelque temps, je vous affirmais que NodeJS n’était pas mature.

Est-ce que l’écosystème JS a muri depuis ?

Et bien maintenant je crois qu’on a passé l’enfance, et qu’on est dans la phase de l’adolescence. Ca crie, ça bouge, ça a plein d’énergie, et ça mérite des baffes.

Je sais, je sais, je vais encore avoir une horde de fans boys qui aiment le typage mou et les champs de moustaches venir me dire que je devrais arrêter d’écrire, de coder et m’enfoncer la version imprimée de Wikipédia dans l’anus.

Comment on appelle l’adulation de quelque chose par une communauté en dépit de toute rationalité déjà ?

Mais dans l’histoire de JS, y a pas eu un moment qui ne méritait pas un bon article de ce genre. A croire que c’est volontaire.

En l’occurrence, j’ai eu envie d’écrire cet article à la suite de plusieurs évènements successifs:

• Je me suis mis à React, et ai du remettre à jour, encore une fois, tout mon env de dev JS.
• J’ai discuté avec des clients qui ont voulu mettre ça en place et qui ont fait marche arrière, car impossible de choisir une stack.
• J’ai fait des formations AngularJS 1 pour des grosses boites qui vont faire tout avec malgré le fait que le 2 arrivent et casse tout.
• Mozilla annonce la cloture de persona.org (et merde…) et publie son code NodeJS en open source. Et c’est une très vieille version (0.4.5) ce qui fait qu’on lit des comments du genre : it’s F/OSS, but I’d strongly suggest learning from Persona’s design rather than directly re-hosting the code
• Je suis tombé sur un article déprimant sur l’état du front end qui m’a semblé sortir directement de ma tête.
• J’utilise NoSript depuis quelque temps et je constate un nombre incroyable de pages qui devraient être statiques ou quasi-statiques et qui sont inutilisables avec le JS désactivés.
• Les pages Web deviennent de plus en plus obèses.

Laissez-moi reprendre un peu de force pour la suite

Donc, reprenons.

NodeJS est toujours splitté entre 3 versions : Node, Io.JS et convergence.

Il y a plus de frameworks front end que jamais : Angular, React, Amber, Backbone, Polymer, ExtJS, Aurelia, Durandal, Knockout, Mithril, MarionetteJS, Vue.js, Meteor, etc. Et je ne liste que les plus connus, car la liste est interminable.

Ils ont tous des versions différentes, des addons (qui ont des versions et des dépendances), des docs et tutos répartis un peu partout..

Par dessus ça, on rajoute les langages qui compilent vers du JS qui eux aussi se multiplient comme les gremlins mouillés: Coffeescript, Dart, GWT, Closure, Haxe, Elm, TypeScript, Brython, Skulpt, PyJS, etc. Vous voulez, un listing complet ? Attention ça pique les yeux.

En clair, la seule chose que les gens aiment autant que de pallier l’absence de library standard de JS est de pallier la syntaxe de JS.

A cela s’ajoute le problème que visiblement les devs JS et le reste du monde n’en sont pas à la même phase. Ils en sont toujours au déni.

Mais on ne peut pas blâmer uniquement le langage. La communauté JS a pris la modularité tellement à l’extrême qu’aucune solution standard ne s’est démarquée pour rien : outils de build, libs de tests, solutions de routing, toolings fonctionnels, et même packages managers…

Même à l’intérieur d’un écosystème, c’est les poupées russes. Par exemple React peut être accompagné d’un pattern que Facebook appelle Flux. C’est du MVC monodirectionnel. Les modèles sont immutables. Le contrôleur est à base d’évènements. Les vues sont gérées par des widgets React. Rien de fou, mais ça faisait pas assez innovant alors ils ont inventé un nouveau nom.

Bref, ils ont leur propre implémentation, mais même la référence n’a pas gagné la guerre. Non, en JS, ça a déclenché immédiatement un concours de celui qui pisse le plus loin et vous pouvez (devez ?) choisir entre : Flux, redux, alt, reflux, flummox, fluxible, fluxxor, marty.js, fynx, MacFly, DeLorean.js, fluxify, fluxury, exim, fluxtore, Redx, fluxx. Les noms ne sont pas une tentative d’humour de ma part.

Ce qui donne les comments du genre :

What a wonderful example of the paradox of choice!

No wonder that it’s easier to get started with Meteor + React, than with Flux + React.

Pour rappel, Meteor est le truc le plus expérimental qui existe en termes de stack techno à l’heure actuelle.

Évidemment tous ces projets ont une documentation succincte, une durée de vie aléatoire, et on peut déjà lire des trucs comme :

Flummox 4.0 will likely be the last major release. Use Redux instead.

Ton projet

Et ils ne sont pas compatibles entre eux. Et en fait ils ne font pas exactement la même chose :

how does redux “replace” flummox, exactly? Seems like they have two very different approaches

Je vous mets les comments car je sais que vous n’avez pas le temps d’aller lire, et encore moins d’étudier chacun de ses projets pour décider duquel utiliser, déjà qu’il faut apprendre React… A vous ne saviez pas ce qu’était React ? Mais vous êtes à la bourre dites donc !

Rassurez-vous, choisir ce genre de techno a seulement un impact sur tout le code front de votre projet. C’est tout.

Mais les outils s’améliorent, et JS est de plus en plus facile à coder. Pas vrai ? Pas vrai ?

L’avancée technique ne veut pas forcément dire que la vie est plus belle

Nope.

React fait ramer misérablement la console de debug de Firefox.

Les préprocesseurs ont tout envahi, et si vous choisissez 4 libs, l’un sera en ES6, l’autre en typescript et la troisième en Dart. Et il faut un setup de connard pour debug du code de préprocesseur confortablement : détecteur de changement, builder, injecteur de code, source mapper…

Les frameworks comme Angular ou React ont une gestion d’erreur bien à eux, qui affichent des messages chelous.

Pourquoi ça marche pas ? Ben…

L’installation est devenue un enfer. Entre les dépendances dépréciées, les libs incompatibles, les différents outils de build, et les options de config et les plugins, c’est une merde incommensurable. Plusieurs standards d’installeurs (et outils joints) se tirent la bourre : AMD, CommonJS et Harmony. Vous vous souvenez du temps ou on copiait juste jQuery dans le répertoire static ?

Attendez, avec Webassembly on pourra même plus faire “read source”.

Donc JS…

On peut faire plus de choses qu’avant. De manière plus propre (enfin propre, on parle de JS là…).

Mais l’écosystème, c’est le bordel général, l’anarchie totale, et ça continue d’avancer, en laissant tout le reste derrière.

Les projets JS s’accumulent, de freelances en SS2I qui se pointent, codent ou (surtout) recodent, et repartent en laissant un projet qu’il sera imbuvable à reprendre, déprécié avant même d’être terminé, non documenté, non testé.

Un projet jetable.

Ca vallait le coup de quitter PHP

Comme récupérer les couleurs d’un site est compliqué, on s’est rabattus sur les couleurs du favicon, qui en théorie doit résumer l’identité d’un site. Ce n’est pas parfait, mais c’est plus simple à implémenter.

Au début, on avait écrit une solution avec Pillow et numpy. Ça marchait très bien, mais des extensions compilées juste pour faire de la déco c’était un peu lourd, surtout si un jour on libère le code source (mais vu comme les sources sont dégueues et qu’on a pas de doc, pour le moment c’est pas gagné).

On a donc changé notre fusil d’épaule, et on a choisit une nouvelle technique : faire la moitié du taff côté client.

Récupérer le favicon côté serveur

On ne peut pas faire des requêtes cross domain en JS, donc on doit toujours récupérer l’image côté serveur. get_favicon_url() parse le site à coup de regex (c’est mal mais ça évite de rajouter BeautifulSoup en dépendance pour une balise) pour récupérer son URL sur la page donnée, ou à défaut, sur la page à la racine du site. On se donne plusieurs essais en cas d’erreurs de réseau :

import urllib
import urlparse 

def get_favicon_url(url, retry=3, try_home_page=True):
    """ Try to find a favicon url on the given page """

    parsed_url = urlparse.urlparse(url)
    url_root = "%s://%s" % (parsed_url.scheme, parsed_url.netloc)

    try:
        # try to get it using a regex on the current URL
        html = fetch_url(url, retry=retry)
        html = html.decode('ascii', errors='ignore')
        pattern = r"""
                               href=(?:"|')\s*
                               (?P[^\s'"]*favicon.[a-zA-Z]{3,4})
                               \s*(?:"|')
                          """

        match = re.search(pattern, html, re.U|re.VERBOSE)
        favicon_url = match.groups()[0]

    except IOError:
        # this is a network error so eventually, let it crash
        if not try_home_page:
            raise
        # try with the home page, maybe this one is accessible
        favicon_url = get_favicon_url(url_root, retry=retry,
                                                       try_home_page=False)
    except (IndexError, AttributeError):
        # url is not on this page, try the home page
        if try_home_page:
            return get_favicon_url(url_root, retry=retry, try_home_page=False)

        # can't find the favicon url, default to standard url
        favicon_url = '/favicon.ico'

    # make sure to have the domain of the original website in the favicon url
    if url_root not in favicon_url:
        favicon_url = "%s/%s" % (url_root, favicon_url.lstrip('/'))

    return favicon_url


def fetch_favicon(url, retry=3):
    """ Returns the bytes of the favicon of this site """
    favicon_url = get_favicon_url(url, retry=retry)
    return fetch_url(favicon_url, retry=retry)

fetch_favicon() télécharge l’image proprement dite et retourne les bits tels quels. Notez que tout ça est synchrone et bloquant, mais heureusement le traffic de multiboards est sans doute trop faible pour poser problème.

Exposer le résultat au client

Ensuite il faut faire le lien entre le client et le serveur. On fait donc un petit routing (c’est du bottle) qui va retourner tout ça en base64 afin qu’on puisse l’utiliser directement dans un objet Image JS :

import base64
from bottle import post, HTTPError

@post('/favicon')
def fetch_favicon_base64():
    """ Return the favicon URL from a website """
    try:
        url = request.POST['url']
    except KeyError:
        raise HTTPError(400, "You must pass a site URL")
    try:
        # return favicon as base64 url to be easily included in
        # a img tag
        favicon = fetch_favicon(url)
        return b'data:image/x-icon;base64,' + base64.b64encode(favicon)
    except (IOError):
        raise HTTPError(400, "Unable to find any favicon URL")

Récupérer la palette côté client

Avec un peu d’AJAX sur notre vue, on récupère les bits de l’image, et on fout le tout dans un objet Image qu’on passe à la lib ColorThief. Cette dernière nous renvoie un array avec la palette. On convertit tout ça en code hexadécimal, et on diminue la luminosité de certaines couleurs pour rendre le texte plus lisible.

 $.post('/favicon', {url: url}).done(function(data){

        // load an image with the base64 data of the favicon
        var image = new Image;
        image.src = data;
        image.onload = function() {

            // ask ColorThief for the main favicon colors
            var colorThief = new ColorThief();
            var bc = colorThief.getPalette(image);

            // some tools to convert the RGB array into
            // rgb hex string
            function componentToHex(c) {
                var hex = c.toString(16);
                return hex.length == 1 ? "0" + hex : hex;
            }

            function rgbToHex(array) {
                return componentToHex(array[0]) + componentToHex(array[1]) + componentToHex(array[2]);
            }

            // make the color brigther
            function increase_brightness(hex, percent){

                // convert 3 char codes --> 6, e.g. `E0F` --> `EE00FF`
                if(hex.length == 3){
                    hex = hex.replace(/(.)/g, '$1$1');
                }

                var r = parseInt(hex.substr(0, 2), 16),
                    g = parseInt(hex.substr(2, 2), 16),
                    b = parseInt(hex.substr(4, 2), 16);

                return '' +
                   ((0|(1<<8) + r + (256 - r) * percent / 100).toString(16)).substr(1) +
                   ((0|(1<<8) + g + (256 - g) * percent / 100).toString(16)).substr(1) +
                   ((0|(1<<8) + b + (256 - b) * percent / 100).toString(16)).substr(1);
            }

            /* Define board colors */
            var header =  '#' + rgbToHex(bc[0]);
            var odd = '#' + increase_brightness(rgbToHex(bc[1]), 90);
            var even = '#' + increase_brightness(rgbToHex(bc[2]), 90);

});

Est-ce que la feature est utile ? Je ne sais pas, c'est un peu gadget, mais c'était marrant à faire, et c'est vrai qu'on identifie bien chaque site sur la page du coup.

L'idée ici est que le serveur et le client travaillent en équipe, et que grâce au navigateur on a une stack de traitement image/audio/video à portée de code. D'ailleurs on a viré le plugin flash des radios pour le remplacer par du chteumeuleu 5.

On peut imaginer la même chose avec tous les outils côtés en JS, ceci incluant les préprocesseurs et minifieurs JS ou CSS : pas besoin d'installer Node pour faire tourner tout ça, il suffit de déléguer le boulot à un tab du browser. Pour améliorer la stack, on pourrait par ailleurs utiliser du RPC avec WAMP et même prévenir le navigateur quand un fichier est prêt avec PUB/SUB afin qu'il le recharge. Vous avez vu comme j'arrive toujours à placer crossbar ?

J'ai un pote qui va venir dans quelques jours pour creuser cette idée qui permettrait d'avoir en pur Python une sorte de livereload sans extension, sans gros GUI, qui transpile tout et rafraichit tout avec un simple fichier de config. Peut être aurons nous le temps de faire un proto.

C'était l'inspiration du jour, passez une excellente canicule !

Je m’étais donc mis en tête de continuer. Malgré la mort annoncée du framework. Malgré une V2 qui va tout casser.

Voyez-vous, j’aime Angular. Bien que je pense que pour des grosses apps une approche comme ReactJS + BackboneJS est plus saine, pour une petit app rapide ou du prototypage c’est très productif et pratique.

En plus, je n’aime vraiment pas manquer à mes engagements, et en presque 3 ans de ce blog, je les ai tenu. J’ai toujours publié les articles promis. Toujours répondu aux mails. Parfois avec des mois de retard, certes, mais je n’ai signé aucun contrat moral sur les deadlines :)

Je vais néanmoins faire une exception ici et envoyer le tuto Angular au cimetière. Toute mes excuses à ceux qui l’attendaient.

Bien sûr il y a le fait que j’ai beaucoup de travail. Cependant si c’était la cause principale je n’écrirais plus ici car ça me demande des heures et des heures chaque semaine.

C’est surtout qu’il se trouve que j’avorte régulièrement des tentatives de retravailler dessus. C’est un signe de manque de motivation certain, et je viens d’en comprendre aujourd’hui la raison : c’est du Javascript.

Jusqu’ici le blog s’était autorisé régulièrement des sorties de la ligne éditoriale, mais un tel travail, un guide complet sur Angular, enterine le JS comme un sujet majeur du site.

Or ce n’est pas le cas.

Je n’aime pas Javascript.

Du coup non seulement me motiver à faire le dossier me demande une énorme énergie (qui pour le moment se transforme en procrastination coupable), mais en prime je me dis que c’est dépenser des ressources pour faire le taff d’une communauté qu’au final je ne supporte que par obligation professionnelle.

Le résultat est donc que bien que je vais continuer à parler de JS et à coder en JS (programmation Web oblige), je ne vais pas lui accorder autant de place sur S&M ou dans mes heures de loisir.

Je remercie ceux qui prennent le temps de le faire, après tout je profite de leur travail. De mon côté, je vais me concentrer sur les domaines qui me sont plus chers, et parler d’autre chose uniquement de manière ponctuelle. L’investissement me parait plus judicieux.

J’utilise AngularJS pour certains de mes projets, je suis payé pour former sur AngularJS et j’ai commencé à écrire un guide sur le sujet.

Mais je me demande franchement si ça vaut le coup de s’investir plus.

Je vais continuer à l’utiliser pour mes projets actuels, tout en regardant du côté de la concurrence ici et là.

Si j’écris l’article, ce n’est pas pour vous alarmer. Ni même pour vous dire “arrêtez d’utiliser Angular”. Je pense que la V1 va être maintenue par la communauté pendant des années.

Non, je me demande simplement si ça vaut le coup que je me casse le cul à finir le guide.

J’ai du travail à la pelle, le guide sur les tests en Python, Django une app à la fois, 0bin à porter en Python 3…

Bref, est-ce que vous êtes toujours aussi intéressés par ce guide ?

Le protocole WebSocket vise à développer un canal de communication full-duplex sur un socket TCP.

LOL. C’est clair non ?

Vous inquiétez pas, tonton Sam est là.

Le Web a évolué. On est passé de Gopher a HTTP 1 puis 1.1. Et on a eu AJAX pour rafraîchir la page sans tout recharger.

Et maintenant on a des apps complètes qui font des centaines de requêtes au serveur alors même que l’utilisateur ne change pas de page. D’ailleurs, je parie que plein de gens ne savent même plus ce qu’est une page…

Le problème c’est qu’AJAX, c’est toujours HTTP, et HTTP est sans état (stateless) : il ne garde aucune information en mémoire d’une requête à l’autre. Ça a des avantages, mais cela implique qu’à chaque requête, il faut ouvrir une connexion et la refermer. Ce qui bouffe quelques ms à chaque fois, et d’autant plus si on utilise SSL.

Une autre limite, c’est que le serveur ne peut pas envoyer de données au client (ici le navigateur) si le client ne fait pas une requête au préalable. Du coup, pour savoir si il y a quelque chose de nouveau, le navigateur doit régulièrement faire des requêtes au serveur ou utiliser des gros hacks comme le long polling.

Les websockets (c’est un abus de langage, on devrait parler du protocole Websocket) ont été créés pour répondre à ces besoins : elles permettent d’ouvrir une connexion permanente entre le navigateur et le serveur. Ainsi, chaque requête est plus rapide, et plus légère. En prime, le serveur peut envoyer des requêtes au navigateur pour le prévenir qu’il y a du nouveau.

Ceci permet de faire tout ce que permettait de faire AJAX mais en plus rapide, et en plus léger. Et également d’envoyer des notifications (ce contenu a changé, un message est arrivé, l’autre joueur a fait cette action…) au navigateur au moment où l’événement se produit.

En gros, de faire des apps Web quasi temps réel.

Il existe d’autre technos pour faire cela : applets Java, flash, comet, server sent events…

Mais aucune n’ont décollé. Websocket est donc aujourd’hui la solution de facto.

Caractéristiques

Le protocole Websocket utilise l’abréviation ws et wss si SSL, les URLs vers des endpoints websocket ressemblent donc à : ws://domaine.tld/chemin/vers/truc/.

Intelligemment, il utilise un handshake compatible avec celui de HTTP, permettant à un serveur de gérer les deux sur les mêmes ports. Donc on peut faire du Websocket sur le port 80 et 443. Néanmoins, certains proxy se gourent quand ils voient du websocket non chiffré et gauffrent votre connexion en la traitant comme du HTTP. Donc si vous voulez une app solide, investissez dans un certif SSL.

Tout ça fonctionne à partir de IE10. Notez comme IE est devenu le standard de ce qui ce fait de moins bien à tel point que je n’ai même pas besoin de vous parler des autres, vous savez que ça marche. Il existe en plus des plugins flash pour simuler des websockets sur les navigateurs anciens, c’est à dire les encore plus vieux IE.

Par défaut, les websockets permettent de faire de requêtes crossdomain, contrairement à AJAX. Avec les nouvelles apps qui utilisent NodeJS en local (comme popcorntime) on peut imaginer une nouvelle type d’attaque : une page web qui se connecte à un serveur websocket local de votre machine. Comme les websockets sont souvent utilisées pour du RPC, il y a du potentiel.

Bon, ta gueule, et montre le code

Vous noterez que ce qui prend du temps dans l’exemple c’est la connexion, qu’on ne fait qu’une fois. Ensuite l’échange de données est super rapide.

Ceci est un exemple Javascript, mais un client websocket n’est pas forcément un navigateur. En fait, c’est très précisément le cas avec WAMP, dont les clients peuvent être des programmes Python, Objective C, Java, C++, etc. L’avantage de WAMP, c’est qu’il automatise toute la machinerie pour découper la logique de son programme en divers fonctions et services, plutôt que d’avoir à tout faire à la main avec send() et onmessage().

Dans tous les cas, il vous faudra un serveur qui supporte les Websockets pour l’utiliser. En Python, c’est Tornado ou Twisted (sur lequel est basé le serveur WAMP crossbar). En Javascript, c’est NodeJS. Quoi qu’il en soit, il vous faut un logiciel qui gère l’IO de manière non bloquante, car il y a de nombreuses connexions ouvertes en simultanées, si on veut que ça soit performant.