La semaine dernière, j’ai gagné une entrée à la conférence JS.Everywhere grâce à un article sur RudeBaguette. Merci aux organisateurs de m’avoir donné cette opportunité de participer. Le planning était alléchant et je n’ai pas été déçu, que ce soit par les conférences ou par le salon en lui même. Il y a avait de plus quelques pointures du web, comme par exemple Douglas Crockford (évangéliste célèbre du Javascript) et Tristan Nitot (fondateur de Mozilla Europe).
Au niveau logistique, tout s’est bien passé : les conférences avaient lieu au Tapis Rouge, un hotel plutôt classe dans le Xe, à Paris. La nourriture et les cafés n’ont pas manqués toute la journée. Les conférences étaient à l’heure, et elles se sont toutes globalement bien déroulés (à 2-3 soucis techniques près, comme toujours). Les écrans étaient gros, on y voyait bien, et on entendait bien les conférenciers. Bref sur le plan pratique, félicitation aux organisateurs qui pourront difficilement faire mieux.
Au niveau des conférences, c’était très bon également. Certaines étaient pour tout le monde, mais pour la majorité des autres, il fallait choisir une conférence parmi 4. Toutes ne m’intéressaient pas, mais j’ai parfois regretté de ne pas avoir le don d’ubiquité. J’ai choisi de faire des conférence sur un peu tous les sujets : scalabilité, applis mobiles, sécurité, bonnes pratiques…
Qu’en retenir ? Le mieux c’est de vous parler un peu des conférences auxquelles j’ai assisté. Je ne suis clairement pas un expert sur tous les sujets, autant le dire tout de suite. Mais c’est l’occasion de faire un tour d’horizon de ce qui se passe dans plusieurs domaines.
La journée a commencé par une présentation faite par Pierre Gilot, de chez Amazon, sur la conception de grosses applications qui ont besoin de grosse capacité, et de bien scaler. Comme Vimeo et SoundCloud, qu’ils hébergent.
Comment concevoir des applications de ce genre ? 3 choses essentielles selon lui :
A suivi une conférence sur le design d’une architecture JavaScript full stack pour des applications business. C’est à dire une application que n’aurait que du JS chez le client, le serveur, et pour communiquer avec la base de données. Un tel design pourrait être une solution au problème des autres architectures, que ce soit pour du PHP, du Ruby ou de l’ASP, qui sont obligées d’utiliser plein de langage et d’outils. Ca a été l’occasion de parler de la solution développée par 4D, organisateur de l’évènement (promis, après on a eu des conférences non sponsorisées). Il s’agit de Wakanda.
Le but du logiciel est de gérer le design de l’appli via un editeur WYSIWYG, le design des entités en base, ainsi que d’écrire le code serveur depuis l’IDE (avec un serveur similaire à du nodeJS), et de déployer l’application… Une fonctionnalité très sympa, c’est celle de pouvoir faire des drag-n-drop d’une entité vers un widget : quand on fait glisser l’icone « Client » vers une listbox, l’application sait que l’on veut remplir la liste avec tous les clients. Après, on customize pour obtenir le résultat voulu, mais une bonne partie du travail est mâché.
Je suis pour le moment partagé sur cet outil. C’est une bonne chose de voir des solutions javascript full-stack émerger. C’est une bonne chose de voir que des outils de ce genre soient de plus en plus présents : cela montre que le web se dote d’outils de qualité pour résoudre des problèmatiques pour lesquelles il est de moins en moins possible de bricoler, comme c’est encore le cas actuellement pour pas mal de choses. Le web a beaucoup de retard par rapport à l’informatique industrielle à ce sujet, et ce genre d’initiatives me rend plutôt optimiste pour l’avenir.
De l’autre côté; il y a mon expérience de développeur. Pour avoir travaillé en C# et WPF, c’est à dire avec des outils .Net qui permettent de faire des choses similaires (glisser-déplacer d’entité et hydratation « magique » des widget, entre autres), je reste dubitatif. En WPF, on passe beaucoup de temps à se documenter pour arriver à modifier des comportements triviaux pour remplacer les comportements de base, que l’on utilise au final très peu. Au lieu de gagner du temps, on en a passé autant qu’avant, mais il a fallu se former sur des API peu intéressantes. Dans mon expérience (un gros projet en SSII, quelques milliers de jours hommes de dev), le WPF, qui était au départ une bonne idée, s’est donc rapidement révélé contre productif. J’espère que Wankada, passé l’euphorie initiale, saura se montrer plus convaincant sur cet aspect.
La conférence sur les applications pour télévision ne m’a pas convaincu. J’ai eu un peu de mal avec le speaker, qui nous balancait des Ferrero Rocher sans que l’on comprenne vraiment pourquoi. Parfois pour féliciter les interventions pertinentes, parfois pour réveiller une salle qui s’ennuyait un peu.
Le côté qui peut sembler attirant, c’est le marché nouveau : tout est à faire dans le monde des applications pour télévision. Mais côté avantages, ça s’arrête là, et l’enthousiasme est largement calmé par les inconvénients qu’il peut y avoir à concevoir son application pour une telle plateforme :
En plus de tout ça, Douglas Crockford a été assez critique sur ce type d’applications : pour lui cela n’a pas de sens de mettre des technologies très changeantes comme les technologies web dans du matériel censé durer au moins 10 ans comme les télévisions.
J’ai raté les conférences de Sebastian Golasch (@asciidisco sur Github et Twitter) sur l’internationalisation. Par contre, sa présentation est sur le web.
C’est une problèmatique importante et qui va probablement se développer dans les années à venir, étant donné l’expansion du javascript côté client comme côté serveur. Pour le moment, peu de choses existent pour faire de la « vraie » internationalisation, c’est à dire gérer correctement la pluralisation, les genres, les dates, les nombres… en javascript.
Sa présentation était axée autour de 2 librairies :
Je vous invite à regarder la présentation de Sebastian ainsi que les pages Github de ces 2 librairies pour aller plus en profondeur sur le sujet.
La suite de mon compte rendu dans un second article, la semaine prochaine.