Bonjour,

Depuis quelques jours (quelques semaines, même !), je furette le net à la découverte des "nouvelles mouvances" et nouvelles technologies de développement. Vous avez du le remarquer (sur les autres topics), j'ai fait une petite escale du coté de NodeJS, d'Angular, etc.

Très récemment (en réalité, hier), je me suis intéressé (un peu par hasard en lisant 2-3 trucs sur Redis, que je trouve plutôt sympathique au passage) à WAMP (Web Application Messaging Protocol), à Autobahn (librairie permettant d'utiliser WAMP facilement, dans plusieurs langages) et à Crossbar.io (un routeur permettant de mettre tout cela en oeuvre).

C'est très très jeune, et c'est encore flou sur certains aspects, mais j'aimerai savoir si certains parmi vous avaient eu l'occasion de chipoter avec ça, ou d'en apprécier les avantages (ou d'en détester les inconvénients). J'ai un peu de mal à voir ce que ça peut apporter dans le cadre d'une application web "classique" (genre Lexpage, même si certains aspects dynamiques du site bénéficieraient de ce genre de choses).

Plus d'informations pour les néophytes (comme moi) :
wamp.ws/
autobahn.ws/
crossbar.io/

Alors, là, tu me parles chinois, j'avais jamais entendu parler de WAMP (enfin, à part le faux ami qui aide pas du tout pour trouver de l'info sur le sujet, z'auraient pu sortir un autre acronyme).

Et là j'me rappelle de mon vieux projet de websockets pas entièrement fini, et ça me redonne envie de le retenter avec des outils et des implémentations bien plus mâtures... Dans mes tests de l'époque, c'était pas si immédiat que ça, j'avais parfois une sacré latence, alors que j'avais besoin d'une vitesse conséquente.

Le fait d’interagir entre applis autrement que via une API et de l'ajax ou un curl me semble également pas mal ... à tester.

Par contre, au détour des slides je découvre tessel ... cher (par rapport à espruino qui certes a moins de composants de base), mais intéressant aussi.

Oui, l'acronyme WAMP est vraiment un choix pourri, c'est une critique que je vois souvent dans les commentaires des blogs qui parlent du trio Autobahn/Wamp/Crossbar... et j'approuve (Déjà qu'Autobahn...)

J'aime vraiment l'idée sous-jacente (notamment dans l'optique d'un environnement basé sur des micro-services), mais j'ai du mal à percevoir l'usage réel qu'on peut en faire dans le cadre d'une "small webapp". Comme ça ne répond pas à un "besoin", et que ça n'ajoute aucune puissance réelle à ce que l'on peut faire (juste le faire plus simplement), c'est pas simple de se projeter et de voir ce que ça donnera d'ici quelques mois/années (bon, l'argument pour moi est que c'est une jolie techno basée sur Python, et que mes tests de NodeJS et le JS en général m'ont convaincu de ne pas me lancer tête baissée dans Node & co...).

Cela dit, quand on voit l'usage que les gens font d'Angular (apporter du dynamisme et simuler une application "temps-réel" coté client, via des appels à une API distante), je peux voir l'intérêt d'avoir un véritable système pub/sub + RPC via des websockets. Mais ça peut s'implémenter tout aussi bien avec du classique Ajax + API derrière... :-s

(Edit : ouais, $75 le contrôleur, ça fait cher quand même. Je connaissais pas Tessel (ni l'autre, d'ailleurs) )

L'AJAX + API, c'est lourd et lent. L'avantage du websocket couplé souvent à du node, c'est la grande vitesse du machin.

Faut que je réfléchisse un peu, que je teste aussi, mais ça pourrai me servir, peut être.

Tessel/Espruino : c'est encore cher, mais les microcontrollers programmables en js (ou en langage fonctionnel) sont extrêmement sexy sur le papier. Parce que c'est fonctionnel, parce que c'est non bloquant. J'ai un gros soucis avec des programmes que j'ai fait en arduino (un langage inspiré de processing, de java et de C), je ne peux pas avoir deux process en même temps. Si j'anime des leds, je ne peux pas en même temps écouter les input (note importante : c'est peut être possible, mais j'ai jamais trouvé lors de mes recherches, et je suis une quiche absolue dans ces langages, je ne les ai jamais étudiés). Du coup, un langage non bloquant pour un microcontroller pas cher (l'arduino a l'avantage d'avoir 20.000 clones chinois à vil prix, et/ou tu le fais toi sur la bse d'une puce aisément trouvable à quelques euros), c'est super interessant. Le soucis, c'est que pour le moment, les solutions à base de JS sont de niche et chères. Et prendre un raspberry pour ça, c'est dommage, il est bien trop puissant (et energivore).

TchouL'AJAX + API, c'est lourd et lent. L'avantage du websocket couplé souvent à du node, c'est la grande vitesse du machin.

On est d'accord. Mais à part pour des applications à forte fréquentation, as-tu déjà été limité par le couple Ajax/API ?
Même si c'est lent, c'est suffisamment rapide pour procurer du pseudo temps-réel aux yeux de l'utilisateur. Même pour des grosses quantités de données. En général, l'impression de lenteur qu'on peut avoir est surtout due aux nombreux "petits appels" qui sont effectués, et qui pourraient l'être en batch, ou parce que ces appels ne sont pas asynchrones dans le code appelant. Websocket retire un peu de l'overhead, mais à part pour des besoins spécifiques (vrai temps réel, par exemple dans un jeu en ligne, monitoring d'automates, etc.), je doute que ça soit "incontournable".

On vante souvent les mérites de NodeJS en mettant en avant le fait que pratiquement tout est asynchrone dedans. Non seulement, les gens ne sont pas habitués à coder de cette façon, mais il suffit de regarder 90% des tutoriels NodeJS pour se rendre compte que ces appels asynchrones sont en fait chainés. Le gain est nul. C'est un peu comme faire des threads dans une application, mais de les synchroniser à la moindre opération. Ok, t'as utilisé des threads, mais t'as rien gagné, à part la complexité du développement.

Un autre exemple : avec l'émergence d'AngularJS (et Embed, Backbone, etc.) au sein de nombreuses webapp, on voit de plus en plus des sites où pratiquement tout le contenu est chargé via des appels Ajax à une API... alors que ce sont des contenus statiques pour la plupart. C'est un peu comme si je chargeais la liste des billets de l'accueil Lexpage via un appel à une API. Et on voit de plus en plus ce genre de choses. A croire que les "petits cercles de chargement" (fa-spin fa-spinner, j'sais pas comment ça s'appelle ^^) est devenu une sorte de "marque de fabrique d'un site web moderne", alors que c'est tout le contraire. J'ai un autre projet pour lequel j'ai une page dont les données peuvent être rafraîchies après affichage. Plutôt que de charger les données "lors du chargement de la page" via un appel à l'API, j'injecte les données initiales dans ma template. De cette manière, je peux peupler ma structure initiale très facilement (et je supprime un appel à l'API, ce qui m'évite un round-trip sur toute l'authentification, le logging, etc.), tout en ayant ma partie "dynamique" disponible (via le refresh des données, avec du "classique" Angular).

De même, quel est l'intérêt d'avoir une single-page app où tu changes l'URL et tu charges des templates (souvent pratiquement tout le frontend) à la volée ? Les tuto te montrent souvent cette approche, mais tu ne gagnes rien (ou pratiquement rien), si ce n'est de la lourdeur (volume de données pour les librairies + calcul JS) coté client, rendant parfois la navigation horrible sur des appareils mobiles.


J'ai plein d'exemples en stock, mais je trouve que la mouvance actuelle est bizarre : on repère une nouvelle technologie, on se dit que c'est génial (même si ça ne fait rien de neuf), et pour dire que sa webapp est "moderne", on l'utilise... et on n'a rien gagné. Les projets deviennent au service des technologies, et non l'inverse (il suffit de voir le nombre de personnes jurant uniquement par Redis ou MongoDB, réimplémentant une approche relationnelle là-dessus, alors qu'ils n'ont aucun besoin de hautes-performances et qu'un SGBD relationnel classique, même SQLite, leur irait très bien).

Tchou[quote=Tchou]
Le soucis, c'est que pour le moment, les solutions à base de JS sont de niche et chères.

C'est un autre débat, mais j'ai vraiment du mal à trouver JS "élégant", "efficace" ou même "agréable" lorsque je code... Même des tentatives comme CoffeeScript ont encore de gros défauts, malgré la hype actuelle... Dès que je code un truc en JS, je trouve ça "fragile", et même avec des suites de tests (que je fais rarement ), j'ai bien du mal à me convaincre que le code marche, et qu'y aura pas un truc qui va partir en vrille au moindre cas particulier. Et la prédominance des librairies "convention over configuration", un peu comme en Ruby, me fait peur. Très peur !

GuybrushJ'ai plein d'exemples en stock, mais je trouve que la mouvance actuelle est bizarre : on repère une nouvelle technologie, on se dit que c'est génial (même si ça ne fait rien de neuf), et pour dire que sa webapp est "moderne", on l'utilise... et on n'a rien gagné.

Fais gaffe, tu te vieux-connise !
Non, clairement, c'est pour ça que le professionnalisme, c'est aussi avoir un regard critique et choisir le meilleur outil disponible pour toute la vie du projet (incluant l'après-développement, la maintenance, et le remplacement à la fin de vie). Utiliser les nouveaux jouets, c'est bien, mais quand le jouet n'est pas mâture, il ne faut l'utiliser qu'en connaissance du risque. La slide 30 du site wamp est quand même particulièrement claire (et honnête) : "attention, on casse l'implémentation souvent, on est compatibles avec pas grand chose, et la doc dit une chose et son contraire"

C'est un autre débat, mais j'ai vraiment du mal à trouver JS "élégant", "efficace" ou même "agréable" lorsque je code...

Je ne parlait que dans un cas précis d'un microcontroller, dans un cas spécifique d'utilisation : le gars (ou la fille) appuie sur un bouton (physique), un écran à led segment (les écrans des radio-réveil) fait une animation pour dire "je calcule", puis répond "ouvert" ou "fermé". Sur un langage de merde tel que le code arduino, pour écouter la saisie d'un bouton, je fais une boucle infinie (pas de concept d'événement). Quand le bouton est repéré poussé, je lance l'animation pendant 1.5s avant d'afficher le résultat. Pendant l'animation, inutile de represser le bouton, ça calcule dans le système d'animation (à base de delay de dizaines ou centaines de ms à chaque frame), et ça refuse l'input.
Dans ce cas bien précis d'utilisation, un langage JS serai parfait. Parce qu'asynchrone, parce qu'avec de la gestion d'événements, un langage fonctionnel.

En robotique aussi, plein de gens poussent à utiliser du node plutôt que de l'arduino. Notons aussi l'existence de johnny 5, mais la dernière fois que j'ai vu, tu ne pouvais pas flasher le johnny 5 sur un arduino, il fallait qu'il reste branché à l'ordi (ce qui limite fortement l'intérêt).

Après, j'ai jamais trouvé le JS particulièrement élégant. Mieux qu'il y a quelques années, mais c'est pas non plus de la poésie.

TchouFais gaffe, tu te vieux-connise !

J’extériorise

TchouNon, clairement, c'est pour ça que le professionnalisme, c'est aussi avoir un regard critique et choisir le meilleur outil disponible pour toute la vie du projet (incluant l'après-développement, la maintenance, et le remplacement à la fin de vie).

Les websockets "à tout va" me font un peu penser à ça. L'usage que j'en vois dans les tutoriels, c'est surtout pour compenser le coté "stateless" des API. Et vu que les gens commencent à faire des API pour tout et n'importe quoi...

TchouDans ce cas bien précis d'utilisation, un langage JS serai parfait. Parce qu'asynchrone, parce qu'avec de la gestion d'événements, un langage fonctionnel.

Python supporte très bien l'asynchrone (avec des librairies comme Twisted pour le réseau, sans doute le top du top tout langage confondu, ou encore Pulsar pour du générique). Le langage est plus mûr, plus rapide et plus élégant que JS. Si seulement, les browsers le supportaient directement...

Enfin, tout le monde n'a pas les mêmes critères pour choisir "son" langage. Quand je vois le nombre de personnes qui font du Ruby, je n'ai pas de meilleur exemple (Mes "critères" sont simples : élégant, non-ambigu et doté d'une librairie standard généreuse et surtout, bien conçue).

TchouAprès, j'ai jamais trouvé le JS particulièrement élégant. Mieux qu'il y a quelques années, mais c'est pas non plus de la poésie.

C'est la souplesse du JS (notamment via les prototypes et les high-level functions) qui le rend élégant. Pas directement, mais parce que des gens font des librairies élégantes avec ça, et que tu peux te passer de faire du "vrai JS" grâce à eux.