Les commentaires sont intéressants également dans cet article. Je ne sais pas si on peut considérer que c'est "l'ancienne façon de faire", mais j'avoue me retrouver dans les critiques adressées à ce "tout magique" de Rails (c'est pour ça d'ailleurs que j'aime particulièrement la philosophie du "configuration over convention" de Django et de Python en général).

Je ne connaissais pas medium il y a 2 mois et depuis ce moment, je n'arrête pas de voir des essais intéressants dessus. Je déteste l'ergonomie par contre, je clique sur un commentaire et 1 fois sur 2 ça m'affiche une nouvelle page avec juste le commentaire et un coup de backspace me ramène sur l'essai mais pas au même niveau des commentaires...

Sur le fond, je comprends la critique mais je ne suis pas d'accord sur le supposé responsable. Je ne connais pas bien Ruby et encore moins RoR mais j'ai du mal à croire que le responsable soit l'expressivité de Ruby ou le pattern objet... Le système de paquet à la rigueur. Pour parler de ce que je connais, quand je vois npm, ça fait un peu peur. Peur car n'importe qui peut ajouter un package avec un nom parlant et faire de la merde dessus. Du coup, la seule façon de juger la pérennité du paquet est de voir le nombre de téléchargement et de chercher sur github si le projet est toujours activement maintenu.

Pour moi, le responsable c'est le framework. L'auteur ne se trompe pas quand il dit qu'on a privilégié des solutions facile à coder plutôt que facile à maintenir. Assez vite, je me rends compte que ce qui importe c'est "est-ce que si j'ai un problème le debug me permettra de mettre rapidement la main sur le responsable de l'erreur?".

Le meilleur exemple que j'ai dans mon expérience, ça a été Hibernate.
J'ai bossé sur un gros projet, plusieurs centaines de requêtes SQL (en Torque à l'époque) qu'on m'a demandé de migrer en Hibernate. On a bossé pendant des mois, j'ai dû faire des protoypes, des classes utilitaire pour cadrer les développements pour au final réussir à migrer tout ça. Et puis sont venus les tests de performances et des résultats inexplicables.

J'avais créé un système qui par configuration permettait de passer de la persistance Torque en persistance Hibernate, ce qui malheureusement rendait très facile la comparaison des temps de passages des jeux de test. Et les temps ont toujours été plus faibles en Hibernate. L'abstraction apportée par Hibernate faisait que les requêtes n'étaient plus auditables, des prestas nous ont aidé pour essayer de comprendre comment optimiser Hibernate, JDBC, le mapping, le HQL pour au final avoir toujours quelques requêtes énigmatiquement plus lentes. Et ce qui est dramatique c'est que la requête SQL toute bête, on la connait et si le framework nous permettait de la lancer sans rien n'y ajouter, le temps aurait dû être optimal.

Au final, depuis que je suis parti, le choix a été de patcher le jar de Hibernate (beurk) pour permettre de lui faire comprendre les hint oracle (hint = permet d'orienter Oracle pour lui faire utiliser les bons index). La conséquence, c'est qu'Hibernate devient dépendant d'Oracle (alors qu'une de ses forces est précisément de pouvoir switcher facilement d'Oracle à Postgre par exemple). Et faire un patch d'une librairie standard rend la librairie non standard et les mises à jour de sécurité sont rendues difficiles à passer...

La leçon que je retiens c'est qu'il n'est déjà pas si facile d'auditer une requête SQL mais auditer une requête d'un langage supérieur est encore plus compliqué (et votre DBA ne va pas courir pour vous aider car il ne maîtrise pas les arcanes d'Hibernate) . Et je préfère les solutions boites blanches (avec configuration) que boites noires (avec magie). Et je me méfie des quickstart un peu trop séduisant.

pomSur le fond, je comprends la critique mais je ne suis pas d'accord sur le supposé responsable. Je ne connais pas bien Ruby et encore moins RoR mais j'ai du mal à croire que le responsable soit l'expressivité de Ruby ou le pattern objet...

Je pense que Ruby est un bon outil, et sans doute que Rails a d'énormes qualités (que je ne connais pas car je ne l'ai jamais réellement utilisé). Quand je vois ce que certains peuvent faire (sans rencontrer des soucis de maintenabilité !), c'est sympathique. Mais je pense que la plupart des gens se lancent à tort dans RoR. Ils y voient un moyen simple de développer pour le web (simple, rapide, accessible et hype !) et la magie des conventions fait qu'ils s'y perdent vite, que ça devient difficile pour eux de gérer les cas spéciaux, car ça nécessite de descendre dans des détails d'implémentation. Et ces détails, contrairement à des approches "à la Django", ils ne les connaissent pas, et doivent donc apprendre un second framework : il y a le RoR "convention", couvert par 99% des tutoriels, et puis le RoR "code toi-même", où même la doc est un peu lacunaire.

pomLe système de paquet à la rigueur. Pour parler de ce que je connais, quand je vois npm, ça fait un peu peur. Peur car n'importe qui peut ajouter un package avec un nom parlant et faire de la merde dessus. Du coup, la seule façon de juger la pérennité du paquet est de voir le nombre de téléchargement et de chercher sur github si le projet est toujours activement maintenu.

J'ai de nombreuses critiques à l'égard de l'éco-système JS (nodejs et npm, surtout ce dernier) et je vois de plus en plus de gens écrire des essais en ce sens. Y a même quelques papiers scientifiques extrêmement critiques à l'égard de npm.

L'écosystème est jeune, très jeune, mais très dynamique (trop !) et l'absence d'une véritable régulation risque de nuire énormément à cet écosystème. Je reste notamment convaincu que JS n'aurait pas du avoir un tel engouement. C'est un bond en arrière. Le langage a certes des qualités, mais il y a une quantité de langages meilleurs, plus riches, et tout aussi adaptés pour faire du web. JS n'est là "que" parce qu'il est déjà supporté (efficacement) par les navigateurs, et le pousser coté serveur, c'est juste pour faciliter la passerelle entre les deux (et j'ai de grosses attentes vu les nombreux projets poussés notamment par Microsoft, de faire tourner Python dans un navigateur !).

pomEt je préfère les solutions boites blanches (avec configuration) que boites noires (avec magie). Et je me méfie des quickstart un peu trop séduisant.

100% d'accord ;)

www.commitstrip.com/en/2…

pomAu final, depuis que je suis parti, le choix a été de patcher le jar de Hibernate (beurk) pour permettre de lui faire comprendre les hint oracle (hint = permet d'orienter Oracle pour lui faire utiliser les bons index). La conséquence, c'est qu'Hibernate devient dépendant d'Oracle (alors qu'une de ses forces est précisément de pouvoir switcher facilement d'Oracle à Postgre par exemple). Et faire un patch d'une librairie standard rend la librairie non standard et les mises à jour de sécurité sont rendues difficiles à passer...

Sinon, quitte à faire crade, ça l'aurait été moins d'utiliser du SQL natif dans Hibernate (et sans p*tain de hints )

J'aime bien cet article aussi, mais je ne suis pas très fan des conclusions.

On m'a toujours vendu Rails comme supérieur aux frameworks Java / PHP / tout le reste, car 1/ nativement restful et 2/ Active Record.

Et finalement l'article semble se faire rattraper par la police de l'architecture et de la conception comme quoi, oui bon, Active Record comme pattern de persistance, c'est une sacré daube, que finalement une bonne appli restful ça dépend plus du code métier que du framework et que ben ouais, si on se faisait chier à faire des interfaces de services et de l'injection de dépendances c'était pour pas pourrir les contrôleurs avec du code pas testable

La convention, la configuration, le sucre syntaxique le code fonctionnel ça me passe bien au dessus de la tête, c'est des bagarres de chapelle et chacun a sa religion.
En revanche, si on attend un framework qui permet de se passer d'une bonne conception objet et d'une bonne modélisation de domaine pour faire du Web, je pense qu'on peut arrêter tout de suite.

Bref, je pense pas que le problème vienne plus de Rails à qui on a donné plus de responsabilité que nécessaire, que du genre de développeur qui a écrit l'article et qui ne semble pas vouloir questionner ses pratiques.

J'aime beaucoup ce passage :

Problems are built into it by design, because of its preference for ‘easy’, which, somewhat ironically, is the very reason we moved away from languages like PHP in the first place.

Et du coup, plutôt que de se dire que le problème venait pas du langage, il attend "quelque chose d'autre".
Que "quelqu'un" réfléchisse à sa place pour que son appli / son domaine métier fasse de l'Event Sourcing et de l'immutable, et le mette dans Go ou dans Rust.

Oui, enfin juste pour dire que JS, c'est pas simplement le fait d'interpréter côté serveur qui le rend populaire, c'est également les performances avec V8.

Sinon on en serait a faire des alert() sur le serveur et bon... Ça a bien fait évoluer le langage.

Syssonwww.commitstrip.com/en/2…

Raaaah, j'ai cherché ce truc que j'étais certain d'avoir lu il y a quelques jours, j'avais pas retrouvé. J'aurais pas songé à reregarder commit strip (il y a le /fr/ btw).

krapouOui, enfin juste pour dire que JS, c'est pas simplement le fait d'interpréter côté serveur qui le rend populaire, c'est également les performances avec V8.

Le V8 est un "simple" compilateur JIT, très efficace, mais les techniques mises en place s'appliquent à pratiquement tous les langages interprétés. Ce n'est pas JS qui est rapide avec V8, c'est V8 qui est rapide tout court.

Il me semble que PyPy (ou le meta-compilateur JIT de MS) propose déjà des performances largement supérieures à V8, mais pour Python.

Sinon, deux articles (un peu partisan ^^) intéressants qui résument grosso-modo ce que je pense de tout ça :
sametmax.com/un-gros-tro…
http://sametmax.com/la-communaute-js-est-actuellement-une-machine-a-creer-de-la-dette-technique/

@Fabe : merci pour le name dropping sur l'event sourcing, toujours bon à savoir les mots clés. Cette problématique du stockage de l'état d'une entité ou seulement du delta m'a toujours posé des problèmes. Et c'est plutôt kiffant le fait de pouvoir recréer ex nihilo l'état d'un objet en lui appliquant à nouveau tous les évènements qui lui sont arrivés. Une sorte de log Oracle ou de blockchain Bitcoin ;).
Mais garder l'état de l'objet (sans se retaper à chaque fois l'application de tous ses évènements passés) est nécessaire aussi, donc les 2 sont importants et ça crée une redondance d'information (pas très compatible avec un MCD en xième forme normale).

Je suis d'accord avec toi pour dire que concevoir son appli an partant des données est hyper important et même plus que la technique. Je me souviens d'une phrase qui dit "il vaut mieux avoir un mauvais programme et une bonne structure de données que l'inverse" et j'y adhère complètement.

@Guy : le premier lien est juste une déclaration de guerre au JS totalement inutile.
De ce que je sais, JS a été conçu par Brendan Eich en 7 jours (sisi c'est relaté dans la Bible ;)). Avec mission donnée par Netscape de faire un langage de communication avec le navigateur. Voila pourquoi il y a des erreurs fondamentales qu'on a du mal à corriger (comme la portée des variables) mais ça reste tout de même un tour de force. Surtout d'avoir vu 15 ans avant tout le monde que le paradigme fonctionnel et non bloquant allait devenir une priorité. Ça fait partie de l'ADN de JS les callbacks et les fonctions de premier ordre. C'est plutôt rigolo de voir les lambda fonction arriver en Python, C# ou Java ensuite.
De plus tout est objet. Je ne sais pas où le gars de Sam et Max a trouvé qu'il ne fallait pas utiliser new mais c'est complètement faux. Tu veux créer une pseudo classe en JS, tu crées une fonction que tu invoqueras par new (et par convention tu mettras une lettre capitale à ta fonction). Rien de dramatique ni de choquant, juste une habitude qu'on n'a pas ailleurs.
Ensuite, les incohérences qui sont remontées existent aussi dans d'autres langages. J'avais un formateur qui nous expliquait que l'API Date de JS qui est si souvent critiqué a exactement les mêmes problèmes sous Java (mais avec Java 8 on a heureusement Joda time).

Je suis plus en phase avec le 2ème article, déjà un peu plus pragmatique.
C'est vrai que c'est le bordel de choisir une techno qui sera pérenne. Mais NPM est en train de tout bouffer (en particulier bower si on utilise browserify ou webpack). NPM devient le Maven et le lanceur de tâches et c'est très bien.

Ensuite vient le problèmes des modules avec plusieurs façons d'écrire mais ES2015 commence à tracer son sillon et tout le monde à intérêt à y adhérer. Avec Webpack, même si je ne prétends pas qu'il va gagner on a un outil pertinent pour bundler tous ses js en laissant le soin à l'outil de parcourir tous les require pour bundler tout et juste ce qu'il faut. La doc de Webpack est souvent moqué mais des tutoriels commencent à apparaître (au pif, sur Grafikart).

J'ai été à une journée de conférence sur le JS pour me rendre compte que question framework, Angular est le plus utilisé mais le passage à Angular 2 ne marche pas trop. Pour de mauvaises raisons d'ailleurs, une conférencière nous expliquait ce qu'elle aimait sur Angular (soit, elle a le droit) puis pour nous dire que Angular2 ne passera pas par elle car elle n'aime pas le TypeScript. Euh, tu renommes ton .js en .ts et ça devient du TypeScript donc j'ai du mal à comprendre ce blocage un peu bébête... TypeScript permet juste d'ajouter un typage (facultatif) et des interfaces, bref que des choses plutôt intelligentes et pertinentes mais je crois que le public JS n'est pas encore prêt ;).

D'autre part, la plupart des gens qui connaissent Angular et React préfèrent React dans ce que j'ai pu constater. React change le paradigme mais peut s'apprendre en 1 semaine (mais ce n'est pas un framework complet comme Angular).

GuybrushSinon, deux articles (un peu partisan ^^)

Naaaaaan !?!

Guybrushsametmax.com/un-gros-tro…

J'ai pas vu le second, à vrai dire arrivé au milieu j'ai ctrl-shift-backspacé pour pouvoir réagir sur le forum tellement il y a du bullshit dedans, mais j'irai quand même au bout.

Dans la famille "trop gros, passera pas" :

Google a utilisé massivement les pages dynamiques, et devant le constat des performances misérables de la seule techno qu’il y avait a dispo, il a pondu chrome, et sa VM Javascript ultra performante.

Bravo au maîîîître, il a guéri la peste, le cholera, la famine dans le monde, et comme il s'emmerdait, il a fait passer un langage d'asmathique tuberculeux à recordman du monde du 100m. Qu'est-ce qu'y faut pas lire comme connerie ! Ok, V8 a été efficace, mais pas d'un facteur 10. Et la perf JS s'est globalement améliorée chez les concurrents aussi.

Php est un langage avec une super doc et une communauté noob friendly.

Uhuh ! Super doc ? uhuh ! Trop gros, passera pas.

La partie avec les exemples sur le typage : ouais, c'est pas top, mais le '5' + 1 et '5' - 1, ou le ===, c'est des trucs à savoir, point. Déjà, si tu comprends pas que le + est le signe de concaténation, forcément tu vas saigner des oreilles quand tu vois ça, mais sinon, c'est logique que tu aies fait de la merde. C'est un langage non typé, si tu le sais pas et que tu concatène un string et un nombre, tu vas faire de la merde, mais c'est qui le fautif, le langage ou toi ?

Après, ça mélange des langages fait pour serveur et JS, en s'étonnant que les outils pour gérer un filesystem doivent demander un module supplémentaire. C'est vraiment de la pure mauvaise foi (et je suis expert).
Et les avantages du JS sont totalement mis de côté. Si, si, y'en a. L'approche fonctionnelle et sa gestion des événements sont parfois des trucs très importants.

Ok, JS est pas top, ok il existe effectivement parce qu'il n'existait rien d'autre que ce machine qui servait à faire clignoter une image ou faire tomber la neige au moment où on a eu besoin de faire de vrais applis dans le browser (finalement, netscape a eu raison) .... mais sa démonstration est quand même pétrie de mauvaise foi. Surtout quand il met php dans la liste des "bons" langages bien foutus.

Shais pas vous, mais y'a des moments où j'ai besoin d'un avion, et d'autres fois d'un vélo. Il faut utiliser le meilleur outil pour le besoin à ce moment-là, point.