Vous savez, quand on ne brule pas un Troll, ses blessures se soignent rapidement, et il attaque à nouveau.
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
C’est simple, je suis parti sur Go, c’est simple et efficace. JS non merci et Python répond de moins en moins à mes besoins (misère du packaging, pas assez de perfs).
Petit soucis sur les deux premiers liens, le premier est cassé, le deuxième envoie sur le login de l’admin wp :)
@zanguu : merci – fixed
@louis : le web n’existera plus o_O
D’ici le début du 22ème siècle, une page web standard pèsera 1 Giga Octet.
Le progrès : acceptez le.
Sam, faut que tu tentes RiotJS … C’est un React Like, en 23ko de JS.
Au rayon des avantages : c’est minimaliste, light, speed, … et surtout : ultra lisible (pas comme react/jsx ou angular2).
Ils ne réinventent pas la roue, mais font avec ce qu’on connait déjà : du coup, on fabrique aisément n’importe quel composant (ou vue).
Pour moi, riotjs est au clientside, ce que python est au serverside : simple, lisible et rapide.
et tout ça pour au final voir toujours la même single page app avec les raccourcis claviers cassés et l’historique buggé :p
“Il y a plus de frameworks front end que jamais”
ça me rappelle les critiques des windows fan boy contre Linux :
‘Linux c pourri, on c pas quelle distrib choisir… Et puis il y a trop de Frameworks : Qt, GtK, etc.’
PHP aussi regorge de frameworks très différents les uns des autres, et un programmeur PHP en général en maîtrise au moins 2 ou 3 (Zend, Symfony, Cake, Yii, Laravel, etc.), plus les frameworks des CMS type Joomla ou WordPress ou Drupal (pour le kernel de Joomla on peut vraiment parler d’un framework)
Bref, les monomaniacs formés à l’école Windows + Visual Shit + .Net sont incapables de comprendre que l’extrême diversité des outils est au coeur du processus de développement Open Source. Quand ce type d’handicapés du code apprend un langage de script à l’école, en général, ce sera le Python (Ruby c trop dur, PHP pas assez “scholar”). Cela donne des trolls low level tout juste bon à se moquer de PHP et de JavaScript sans comprendre pourquoi ces deux langages lead le monde des applis web OpenSource.
Bref, cet article montre avant tout la totale incapacité de l’auteur à comprendre la nature des applications OpenSource, et leurs différences avec les logiciels privatifs.
“Il y a plus de frameworks front end que jamais”
ça me rappelle les critiques des windows fan boy contre Linux :
‘Linux c pourri, on c pas quelle distrib choisir… Et puis il y a trop de Frameworks : Qt, GtK, etc.’
PHP aussi regorge de frameworks très différents les uns des autres, et un programmeur PHP en général en maîtrise au moins 2 ou 3 (Zend, Symfony, Cake, Yii, Laravel, etc.), plus les frameworks des CMS type Joomla ou WordPress ou Drupal (pour le kernel de Joomla on peut vraiment parler d’un framework)
Bref, les monomaniacs formés à l’école Windows + Visual Shit + .Net sont incapables de comprendre que l’extrême diversité des outils est au coeur du processus de développement Open Source. Quand ce type d’handicapés du code apprend un langage de script à l’école, en général, ce sera le Python (Ruby c trop dur, PHP pas assez “scholar”). Cela donne des trolls low level tout juste bon à se moquer de PHP et de JavaScript sans comprendre pourquoi ces deux langages lead le monde des applis web OpenSource.
Bref, cet article montre avant tout la totale incapacité de l’auteur à comprendre la nature des applications OpenSource, et leurs différences avec les logiciels privatifs.
Bon, c’est bien joli ce rant (et ça fout la trouille pour ceux qui veulent se mettre au front end Oo) mais tu choisirais quoi comme stack, toi ? C’est pas une question enervé, hein, c’est une vrai question. je suis en train de jouer doucement avec une idée, mais je suis avant tout un dev backend donc la partie front end, j’ai un peu la trouille…
@Louis2: le mot clé ici est “extrême”. Rajoute à cela l’instabilité et la manque de doc ainsi que des problèmes de compat, et tu as le souci. Déjà sur des projets comme Linux, qui sont très stables généralement se pose problème pour l’adoption, pour le déploiement, pour le packaging. Par exemple les wheel Python n’existent pas encore sous Linux précisément à cause de ça. Alors dans un env aussi instable que le JS, qui produit bien plus de versions de choses que PHP, Ruby et Go réuni (qui sont aussi OpenSource, je le rappelle), ça donne du nawak. Ok pour la diversité, mais là c’est n’importe quoi. Faut arrêter d’essayer de défendre ce genre de comportement, c’est se mettre des oeillères.
@Teocali : je suis comme toi, je fais comme je peux. Je teste des trucs ici et là, mais je reste conservateur. J’ai arrêté Angular, je continue un peu sur React car la techno est pas mal, mais après je fais un max côté serveur pour éviter tout ce merdier.
s/React peut est accompagné/React peut être accompagné/
:-*
@Louis
javascript lead la totalité du developpement frontend pour une bonne et simple raison : au début, aucun éditeur de navigateur ne s’est jamais cassé le cul à proposer autre chose, et après, c’était trop tard. Javascript est leader par défaut.
Quand a PHP, j’ai aussi une oprinion dessus, mais je vais la garder pour moi, je risquerais d’être grossier.
@Sam :
Il est tout à fait naturel et sain d’avoir un très grand nombre de solutions techniques différentes, provoquant un bazar monstre et ingérable.
Un ptit conseil de lecture :
https://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar
Vous êtes dans la mentalité “logiciel privatif”, qui veut que tout soit bien rangé, bien optimisé, avec une seule manière de faire.
Vous ne vous en rendez même pas compte.
Un autre conseil de lecture :
Lisez les codes sources de Drupal et WordPress, vous verrez une énorme dette technique, un énorme bordel, et aussi les deux leaders actuelles des solutions CMS OpenSource.
OpenSource == Bazar. C’est nécessaire. Sans bazar, pas d’Open Source.
Bien sûr, quand on a le crâne écrasé par la bureaucratie des écoles d’ingé, c’est difficile à comprendre.
T’as raison c’est vraiment chiant. Quand je relance un projet vieux d’un an avec node.js après un npm install tout est HS. De grosses erreurs de partout qui sont aussi limpides que les explications d’un pote après 10 shots de Teq.
La merde, tu dois avoir des outils à configurer en permanence etc. La galère, je me lance dans Grunt on me dit que c’est hasbeen, qu’il y a Gulp. J’avale un coup et bam on me balance que faut pas utiliser de trucs comme ça que ça pue etc. Bref npm scripts. Après galère on me dit non webpack… Pfiou
Au moins sur mon CV je peux dire:
– Grunt
– Gulp
– Webpack
– Browserify (putain j’ai zappé dans parler)
– [] (la suite demain)
Puis je fais du JavaScript, il faut faire de l’ES6 maintenant, avec
6to5babel. Bon je suis bon là non ?Mettre en place du CSS, ha oui j’utilisais
Compass,Bourbon,Sass/less, PostCSS ? C’est quoi la suite ?Puis je fais du HTML, no utilise
Mustache,Handlebars,Lodash.template,Angular, JSX.Sportif, non ?
Je ne suis plus dev je suis un gymnaste professionnel et je vous emmerde, de webmaster à dev front je suis now Gymnaste de Guichet ça en bouche un coin n’est ce pas ?
Par acquis de conscience je lance mon projet PHP avec laravel d’il y a 2 ans. Cool composer install = apocalypse. Je me dis, finalement le PHP se casse la gueule tout aussi bien ça me rassure.
Alors oui sur mon CV je peux lister plus d’outils et de technologies que de projets et alors ?
Plus sérieusement, oui c’est le bordel. Oui on se cherche, mais je suis un dev front et si je ne sais pas me remettre en question je suis à la masse et mort, car les autres évoluent. Une lib devient vite obsolète.
On fait du code “virtuellement” obsolète. C’est chiant, mais on n’a pas le choix.
Mais surtout je bosse sur un env qui évolue vite donc être à jour veut surtout dire, tirer le meilleur de cet environnement pour le bénéfice de qui ? De l’utilisateur. Et comme un site doit évoluer…
Au final je progresse j’ai une meilleure vision de ce qui m’entoure et je découvre de nouveaux concepts.
Le reste c’est un choix, la vie est difficile mais, il faut s’adapter.
ok, donc React peut être une bonne idée mais avec parcimonie, donc. Je note
Expliquons pourquoi la nature chaotique des lib javascript est une EXCELLENTE chose, 100% raccord avec le pattern de dev OpenSource :
“Une des conclusions partant de ce constat est le concept « Release early, release often » (« Publiez tôt, publiez souvent »). Mieux vaut publier un logiciel fonctionnel mais imparfait, dynamique et pouvant bénéficier des contributions de chacun (marché) que d’attendre un stade de développement avancé (cathédrale).’
https://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar
Mieux vaut 10.000 bibliothèques/frameworks JS imparfaits, en concurrence les uns avec les autres, ultra-dynamique, en perpertuelle évolution, qu’un unique framework JS propre, monolithique, beau comme une Cathédrale Microsoft.
Le mot OpenSource a été créé par Eric Raymond, qui l’associe immédiatement au concept de ‘Bazar’. Si vous ne comprenez pas cela, vous n’avez pas compris ce qui différencie le mode de développement Open Source du mode de développement privatif, vous n’avez pas compris pourquoi PHP (le plus bordélique des langages) a pris le lead des langages Web (extrêmement loin devant ses concurrents), vous ne pouvez pas comprendre pour le JavaScript (qui devient encore plus bordélique que le PHP) va passer devant PHP.
Bref : go back to votre cathédrale microsoft.
@Louis : je ne suis pas contre le bazar. Je suis sous Linux. La grande majorité de mes outils sont du FOSS. Je vis ce bazar au quotidien. Et visiblement tu ne viens pas souvent sur le blog pour venir me sortir que je suis formaté par une grande école. Mais Il y a juste une différence entre un marché marocain et le burning man. Ce dernier ne peut avoir qu’une durée de vie très limitée.
Puis on est dev, un peu de bon sens aussi. Ce n’est pas parce que tout le monde fait du react sur des APPLICATIONS que faut en faire même pour un portfolio pour afficher 4 images en lazy load…
Faut pas zapper qu’on fait du JS avant tout.
L’histoire de tuer la mouche avec un lance-roquettes, oui ça marche mais c’est con.
@Louis: Ton avis a l’air franchement intéressant et tu as l’air d’avoir de bonnes idées mais franchement le ton agressif de tes messages et les petites remarques du genre “Bien sûr, quand on a le crâne écrasé par la bureaucratie des écoles d’ingé, c’est difficile à comprendre” te deservent totalement et ne donnent en rien envie de te lire.
Cette attitude est tout simplement inutile et puérile…c’est dommage pour quelqu’un citant Eric Raymond.
Merci pour toutes les corrections.
@dhoko : certes mais la communauté JS est particulièrement touchée par ce problème en ce moment. Le syndrome de Web partout, de l’OPA à outrance, tu JS chargé juste pour un menu. Installe NoScript et tu vas voir, c’est édifiant.
@Louis: il y a des milliers d’autres technos Open source qui ont un côté bordélique, mais aucun n’attend le dixième de ce niveau. Particulièrement en terme d’échelle de déploiement et de petite taille de timeline. C’est de la mauvaise foi là.
@Teocali : seulement si tu as besoin d’une UI très dynamique.
@sam
Le JavaScript prend le lead des langages frontEnd PRÉCISÉMENT CAR c’est le gros bordel.
La plus grande qualité du JavaScript ? C’est le bordel
La plus grande qualité des framework javascript ? Ils sont nombreux et bordéliques
Tout ce que vous reprochez au JavaScript dans cet article est extrêmement précisément la raison pour laquelle le JavaScript prend le lead.
Bien entendu, des 10.000 librairies/frameworks actuels, il ne restera au final que quelques uns. Après que les armées de dev JavaScript adeptes des alphas et bétas ce soient entre-tués, seule la crème des technologies restera. C’est pour cela que personnellement j’attend que les choses se tassent un peu avant de m’y mettre sérieusement. Mais pour critiquer comme vous le faites l’extrême vivacité de la communauté JS, il faut vraiment ne RIEN avoir compris à la nature du développement OpenSource.
Que se passe-t-il en ce moment dans le monde JS ? Open Source in progress, Bazaar everywhere.
Tout pareil ….
On m’a de force angularjisasionne … quelle merde ce truc … y fait tout un tas de trucs
dans ton dos … le debug? va chier! le deuze va faire pire c’est sur ….
du coup tentative de monter un backend rest tout JS … trois mille libs/fm et autres
bouzes de tests … pas moyen d’avoir un rest sur du oracle 11g (vieux de 10 ans presque).
un mois sans aucun resultat livrable .. alors va chier le bakend rest JS.
Backend python rest? Deux jours. Done.
JS on y revient quand Mr Gogol aura mis du typage dans son chrome et ne surportera
plus que cela.
Le front en JS en ng … pas le choix par ici … sinon c’est maxi-plug anal et tournante
de yetis! Je refuse de donner des delais! FUCK OFF !!
@Louis : JS prends le LEAD parce que le Web explose et que c’est le seul langage dispo nativement sur les navigateurs. Retire les navigateurs, plus personne ne fait du JS. Retire une plateforme, on continue à faire du C ou du Python ailleurs . Le bordel est une caractéristique, pas une qualité. La diversité est une qualité. Le dynamisme est une qualité. Ce sont des qualités de la communauté JS. Mais on peut avoir une forme d’équilibre. Et même abuser un peu. Mais là on a une techno qui est là clairement par hasard et qui part dans tous les sens.
@Sam
C’est ce que je dis. Tu n’as pas compris que le bordel est une qualité dans le mode dev OpenSource, et que c’est précisément la raison pour laquelle PHP (qui est côté serveur pour rappel) a eu le lead pour le développement d’applications Web pendant des années. Et c’est la raison pour laquelle aujourd’hui le JS prend le relais. Du début des années 2000 à aujourd’hui, les langages à la papa type C# ou Java auraient tout à fait pu servir de base à la création de l’éco-system Open Source des appli web. Cela n’a pas été le cas : pas assez bordélique, trop organisés (et le typage est en effet le symptômes le plus évident de cet excès d’ordre).
Ceux qui n’ont pas compris que la principale qualité de PHP était son côté bordélique, mais était envieux de son succès, ont tenté de ke remplacer par des langages de scripts bien ordonnés : Ruby ou Python. Ruby a performé dans le domaine du développement privatif, et a été un échec cuisant dans lOpen Source : beaucoup trop rigide, pas assez bordélique.
Python et Django sont très bien organisés, les teams de dev du langage et du framework sont très hiérarchisées. Résultat, ces 2 technos évoluent extrêmement lentement, et sont à la traîne. Quand la communauté JS aura fait le passage au quotient de ses technologies et aura choisi parmi ses frameworks et bibliothèques, le monde JS sera performant, stable, et extrêmement moderne ; alors que Python et Django en seront encore à peu prêt au même point qu’aujourd’hui.
Le gros bordel dans un secteur du développement informatique est le signe qu’il s’y passe quelque chose d’important, ce quelque chose se nomme : Open Source. Ceux qui le comprennent se réjouissent de voir le dynamisme extrême du monde JavaScript, totalement inédit dans toute l’Histoire de l’informatique
Ce qui me fait doucement rire c est ReactJS … plus besoin de MVC c est super on fout le code dans la mise en forme (markup) ! C est une revolution ! (Ca me rappel php3 et le code php direct dans le html)
@Benoît HERVIER … faut pas tout confondre ;-)
Autant angular*, c’est du mvvm(~mvc) … Autant React, c’est juste un toolkit pour faire des widgets (aka des composants réactifs). Après, tu peux faire du MVC, avec React, a toi de bien séparer les couches.
@louis le gros + du JS et du PHP c’est surtout aussi que c’est accessible. C’est très simple de faire quelque chose avec, le setup basique est ridiculement simple, pas de compilations etc.
@Louis: Tu ne dois pas avoir beaucoup de projets pros à gérer sur du moyen ou long terme pour sortir de tels arguments. Ou alors dans une boite suffisament grosse (ou prenant suffisament ses clients pour des pigeons) pour qu’une personne qui passe 4 fois le temps nécessaire ne soit pas problématique…
Si les technos JS sont bordéliques, c’est en partie parce qu’elles sont en effervescences (monté des techno web partout, même quand c’est pas vraiment du web), mais aussi parce que le JS est intrinsèquement bordélique (typage, compat, homogénéïté, syntaxe etc.).
Ce que je trouve amusant, c’est que tu aggresses ceux qui ne sont pas d’accord avec toi en faisant le raccourcis qu’ils sont “contre l’open source” (et à ça, “mdr” est très adéquat…), mais tu dis toi même : “C’est pour cela que personnellement j’attend que les choses se tassent un peu avant de m’y mettre sérieusement”. Donc j’en conclu que tu ne mets pas vraiment d’énergie autre que tes propos dans ce que tu défends ^^. Je suis persuadé que Sam qui chie joyeusement sur le JS et technos associé à ouvert bien plus de tickets sur les trackers de ces projets que toi. Et oui, dire que tel truc marche pas ou que c’est de la merde, c’est bien plus participer à l’opensource que de dire à ces gens là qu’ils n’ont rien compris car ils ont “le crâne rasé et sortes d’école d’ingé” ^^ (d’ailleurs je ne sais pas où me placer : je n’ai que la moitié du crâne de rasé, et je sors d’une école d’Angers…)
@Louis @Sam
Vous avez tous les 2 raisons.
La bonne question à se poser est la suivante :
Vous avez un projet web à développer, au départ t’as 2 3 users, puis par chance tu x2 les users toutes les semaines (faites les calculs, ça monte très vite). Comment faites-vous pour maintenir votre stack JS ?
Bien évidement que c’est génial d’avoir plein de technos à tester, mais quand tu pars sur un projet d’un an, comment choisir la stack JS ?
Sam parle de projets professionnels qui peuvent durer plusieurs années, pas des projets de fin d’études sur 3 mois.
Comment faire pour maintenir la stack JS sur un projet d’au moins 1 an ?
La question centrale est la.
@Dylan
Cet article a été officillement rédigé sur le mode du troll, je réponds sur le mode du troll. On aime tous ça, va falloir l’admettre ^^
Sinon, avec le troll en moins, on dit en effet à peu prêt la même chose :
l’effervescence dans le monde OpenSource se traduit par un très gros bordel, et plus ce bordel est gros plus l’effervescence est de qualité.
Donc : oui, je ne conteste pas que c’est le bordel. Oui, je déconseille l’utilisation des technos javascript dans le cadre de projets professionnels (tout comme je déconseille Laravel dans le cadre professionnel). Mais, contrairement aux auteurs qui ont été nourris à la sauce Microsoft, je me réjouis de voir un tel bordel dans la communauté JS, je sais que c’est un excellent signe, je sais que cela veut dire que le JS est le langage d’avenir.
Bref, à même analyse de la situation : conclusions opposées. Cela vient du fait que j’ai lu ça :
https://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar
Alors que les auteurs de l’article ont lu ça :
http://pmcdn.priceminister.com/photo/846544138.jpg
Je suis impressionné par le calme de Sam face aux attaques écervelées de Louis.
Louis a tout de même raison: il vaut mieux attendre que ça ne soit plus le bordel pour faire du FrontEnd :D
L’Open Source c’est bien, le Logiciel Libre c’est mieux.
C’est bien connu que PHP était populaire car il était bordélique et non pas parce que c’était le langage le plus simple / moins “cher” à utiliser.
Le fait que Microsoft te demandai de vendre un rein pour payer les licences et les serveurs nécessaires à faire tourner ton blog alors qu’en fasse tu pouvais faire la même chose pour le prix d’un resto avec PHP n’a aucun rapport.
Ni le fait qu’il te fallait une semaine pour comprendre comment déployer ton app java avec la config de tomcat qui t’obliges à t’arracher les cheveux (peut être pour ça que les mecs sortent rasé d’école d’ingé) alors que PHP t’avais juste à dropper 3 fichiers dans ton ftp.
La cathédrale prendra plusieurs années pour être construite mais sera encore là plusieurs siècles plus tard. Le bazaar c’est deux tréteaux, une planche et un auvent en tissu.
C’est sympa les touristes qui trouvent le bazaar plus joli et coloré, mais les commerçants savent qu’il est préférable d’avoir des murs en dur pour s’éviter des soucis.
whao, pas relu… -fasse +face
@Dylan
Cet article a été officiellement rédigé sur le mode du troll, je réponds donc sur le mode du troll. On aime tous ça, va falloir l’admettre ^^ On aime quand ça saigne ^^
Sinon, avec le troll en moins, on dit tous les 2 en effet à peu prêt la même chose :
l’effervescence dans le monde OpenSource se traduit par un très gros bordel, et plus ce bordel est gros plus l’effervescence est de qualité.
Donc : oui, je ne conteste pas que l’écosystème JS est actuellement un vrai bordel. Oui, je déconseille l’utilisation des technos javascript dans le cadre de projets professionnels pour l’instant (tout comme je déconseille Laravel dans le cadre professionnel). Mais, contrairement aux auteurs qui ont été nourris à la sauce Microsoft, je me réjouis de voir un tel bordel dans la communauté JS, je sais que c’est un excellent signe, je sais que cela veut dire que le JS est le langage d’avenir.
Bref, à même analyse de la situation : conclusions opposées.
Cela vient du fait que j’ai lu ça :
https://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar
Alors que les auteurs de l’article ont lu ça :
http://pmcdn.priceminister.com/photo/846544138.jpg
@batisteo
Dans le monde du logiciel libre, le bordel règne en maître. Même côté appli de bureau, de Qt à GTK en passant par les 100.000 choix de bibliothèques, les 10 versions différentes de la LibC, les versions stables ou instables des dépendances, qui peuvent être codées en C, en Python, en perl, en bash, etc. Le bordel est ce qui fait la force des logiciels libres. Tu préfères quoi ? MySql, postgreSQL, MongoDB, Cassandra, etc ? Le logiciel libre provient du bordel, est source de bordel, a besoin du bordel. Reprocher à une communauté libre d’être bordélique serait comme de reprocher à une coopérative anarchiste de ne pas avoir de chef : c’est faire une critique d’écervelé.
Open source …. mes fesses … essayez de lire du code d’un driver linux …. Mouahahaha
ou d’une lib JS …. Mouahahah. Sauf si vous etes PAYES pour le faire c’est pas jouable.
Logiciel Libre …. mes fesses …. 3 milliards de $$ pour le support … incessant … et les
problemes incessants … Et paf plus de support du jour au lendemain parceque des
urluberlus on decide de : VA CHIER le soft, on change la techno et fuck les users !!
Ouais super!! Ya que les gens payes pour qui font du open free. Les gens de gogol
ou ceux de face-de-bouc ou ceux des universites ou ceux des centres de recherche ….
Z’avez remarque que tous ces open free machins qui tiennent le haut du pave
viennemt de gros industriels?? Bah ouais le modele microCrotte de faire
tester par les croyants de l’eglise de l’infini Open-ass et free-porn.
Amen.
@Batisteo : moi aussi, mais en meme temps il reste calme parce qu’il s’est exposé de lui même avec ce sujet ;)
N’en reste pas moins que le donneur de leçon ne sait pas où il a mis les pieds.
JS c’est peut-être nul, mais c’est disponible partout. N’importe quel gamin un peu curieux peut s’amuser à faire des flocons de neige dans son navigateur. On a le même problème avec Excel et VBA ceci dit.
Python, c’est l’exact contraire. Le langage et les bibliothèques disponibles sont excellentes. Le packaging (coucou cx-freeze) et le déploiement sont des infâmes chiures. À mon sens, c’est sur ces points que la communauté devrait travailler si elle espère voir Python se démocratiser.
Par ailleurs, personne n’a envie d’utiliser dix langages différents pour son application web. JS est le seul disponible côté client, il est donc normal que les développeurs aient la même préférence côté serveur.
C’est juste pour faire monter les salaires tout ça.
Pour moi tout est parti en couille depuis qu’un hurluberlu s’est dit que ce serait rigolo de faire du JS côté serveur.
Plein de connards en ont profité pour essayer professionnaliser le front-end.
Moi de mon côté je continue a tout faire avec la triforce jQuery / HTML5 / PHP, et ça me fait bien rigoler quand le branleur d’à côté passe plus de temps à galérer à déployer un misérable plugin de 40 lignessous un flot d’erreurs en command line , que moi pour tout refaire de A à Z…
Sympa les commentaires, on se rapproche de youtube :-)
Je suis développeur backend (PHP) mais aussi admin sys et à l’écoute de ce qu’il se passe chez les front. Je rejoins le fond de l’article et ce sont des critiques que j’émets assez souvent. En tant qu’admin sys, c’est compliqué de suivre les versions pour les packages managers mal branlés comme npm (versions packagés sur mes debian != de versions chez Windows, compilations nécessaires cassant potentiellement d’autres projets). Par ailleurs, je trouve décevant que les développeurs JS ne s’appuient pas sur des choses qui fonctionnent déjà depuis des années : guilp & compagnie, c’est le MakeFile du hipster. Et comme cela a été évoqué, soit les libs ne sont pas utilisables à long terme car imatures ou soit elles demandent un très gros investissements couteux en temps (et en argent) et on ne sait absolument pas si ça va tenir la durée.
Et qu’on se le dise bien, les gens développent souvent à l’arrache on essayant de temps en temps de faire du code potable, mais entre la documentation, le code réellement produit et les dufférentes compétences dans une équipe de développeurs (back et front), c’est vraiment TRÈS compliqué à gérer…que ce soit à court ou à long terme
Sauf que.
io.js et convergence n’existent plus (voir: https://iojs.org/fr/)
La guerre des frameworks se tasse. React semble bien parti pour gagner (Angular 2 et ça réécriture complète, on va s’en passer)
On peut se contenter de Flux et Redux pour gérer la state de notre app.
Utiliser et pousser ES6, ignorer tous ces langages qui transpilent en JS.
Effectivement, c’est un gros chant de bataille, mais une fois une bonne solution trouvée, le calme semble retomber (ex: Depuis l’arrivée de Redux, combien d’implémentations de Flux sont sorties?)
Après, la mise en place d’une stack “universelle”, ça reste pas demain la veille.
La stack js semble être encore destinée à un contexte très particulier, de la startup qui ne sera peut-être plus là dans 3 mois, ou dans la grosse boîte type Facebook, Google Microsoft qui maîtrisent énormément leur processus de dev.
Pour la SSII et le client final, c’est une autre paire de manche si on considère :
les cycles longs (besoin utilisateurs, MOA, MOE, RFP, etc…)
le niveau global des développeurs
On a proposé récemment de passer de Flex à une stack js (angular 2). Ça risque d’êtintéressant !
Après il y a toujours la possibilité de trouver une stack stable en js à base d’es5, backbone et JQuery.
A part essayer de troller en utilisant des GIF rigolo, est-ce que le point de cet article c’est vraiment :
JS c’est mieux qu’avant mais c’est toujours le bordel pcq j’ai trop de choix ?
PHP c’était n’importe quoi. Les gens sont partis vers le JS.
Sauf que comme c’était les mêmes gens, ils ont aussi fait n’importe quoi avec.
Ce “problème” n’a pas de solutions.
Il y a aussi une histoire de conflits d’intérêts.
Sam et Max ont leurs propres projets dans leur propre boite, ils veulent un truc qui marche, maintenable sans y passer des heures.
En revanche, si tu développes pour d’autres et que t’es payé à l’heure, qu’est ce que tu t’en fous d’avoir un bordel pas possible ? Bien au contraire, plus c’est le chaos, plus il y a un empilement de stacks, de dettes techniques, plus tu seras payé cher pour faire marcher le bousin.
Le nombre de freelances qui vendent des sites avec des technos improbables et impossibles à maintenir est énorme, c’est quasi 90% du marché.
Pourquoi s’en priver ?
Ils se font la main sur une nouvelle techno, ils la rajoutent à leur CV et les soucis du client pour la maintenance arrivent après qu’ils aient touchés l’argent. Les freelances en ont rien à foutre de livrer de la merde, c’est un autre prestataire qui réglera le bordel. Quand je lis les posts de Sam, je pense qu’il est celui qui répare le merdier, tu m’étonnes que ce soit un boulot ingrat et que ça se termine en posts rageux.
En revanche les freelances qui testent des nouvelles technos, livrent de la merde et se font payer, tu m’étonnes qu’ils s’éclatent.
Autre remarque, tous ceux qui créent des frameworks, c’est pas pour être pérenne, c’est juste pour rajouter une ligne sur son CV et faire augmenter leur salaire.
Bazaar n’est pas chaos.
Je vous lis et comme vieux con de webdev depuis 17 ans et j’ai l’impression que le souci n’est pas le langage, affûté travaillé et précis, mais ce qu’on en fait. Le bazaar est dans l’offre mais l’offre de qualité. Le chaos est dans cette précipitation hallucinante, étrange course à la hype des framework fragiles et sans fondation.
Pour faire une bonne appli, rien ne vaut tes propres outils que t’as mis des semaines à monter et que tu connais par coeur. Apprentissage par expériences, utilisation du nécessaire pour chaque tâche.
Les frameworks des autres, faut les apprendre, les manier correctement, les adapter à tes besoins, et risquer de perdre pour une mise à jour ou un abandon. C’est beaucoup trop de temps perdu où tu aurais pu apprendre bien plus.
Voilà.
Le JavaScript c’est comme la coke c’est mieux pure.
Je ne fait surement pas des dev de haut vole, mais au moins mon code tout le monde peut le comprendre avec juste une doc de js (genre celle de la fondation Mozilla).
Et j’ai très peut de problème de compatibilité avec les différent navigateurs, car je ne vais pas chercher la compatibilité avec des navigateur de plus de trois ans (et franchement pour 3 utilisateur de ie6 par ans je fait pas quintuplé mon temps de dev pour ça).
Au finale je n’utilise que des librairies sur des chose vraiment compliqué (genre leaflet pour la carto), mais pour faire un document.getElementById ça vas j’ai pas besoins d’aide mon IDE fait déjà le taf avec l’auto-complétion.
Non franchement j’aime bien ce langage, le coté fonctionnelle et en même temps très objet. Moi je trouve ça cool.
Il n’est pas parfait, j’aimerais avoir la puissance des interface sjava et le typage de ruby.
Mais je fait avec, no body is perfect.
Et puis ça pourrait être pire, ça pourrait être du LISP ⸮
Concernant PHP, les problème sont assez similaire :
Énorme ce troll, j’ai bien rigolé :-)
Plus sérieusement, il est possible de ne conciderer le JS que comme le “bytecode” du front, et utiliser d’excellente alternatives comme Haxe ou Typescript.
C’est d’autant plus vrai avec l’arrivee de Webassembly
@Sam
Avoues que tu bosses à la NSA. Je me suis fait la même réflexion huer : nouveau projet à lancer, un peu de connaissances de Meteor, React, je me suis cassé trois dents sur la conf avec gulp puis webpack avec Babel et là je me dis : merdasse, qu’est-ce que j’utilise comme stack au final pour démarrer ? Meteor + Flux || Relay ? Node Mongo React Express ? Je me fais pas chier backend Flask || Django et React en front à l’arraché sans Flux ? Coder son propre ‘framework’ ? L’écosystème JS est passionnant mais ne rend pas service aux débutants en augmentant autant les barrières à l’entrée.
@Zoontek: le fait que le merge se soit passé ne change rien à la base de code io.js et convergence qui sont maintenant là et bien là. Il y a toujours 3 versions dans la nature. La dette technique. Le sujet de l’article
@prenezvotreretraite: non. Le choix n’est pas un problème, la surrabondance de solutions concurrentes, mal documentées, peu teststées à durée de vie courte pour le moindre composant couplé à l’absence de lib standard et un changement régulier de l’écosustème et le problème. La charge de travail augmentée et la garantie de pérénité diminuée est le problème. Et j’ai pas dis que JS était mieux maintenant qu’avant. J’ai dis qu’on pouvait faire plus de chose avec, de manière un peu plus propre.
Il y a une effervescence indéniable, et pénible pour les débutants. Beaucoup de projets très importants qui sont nés à peu près en même temps parce qu’il y a une tendance générale : la venue d’ES6, la mort de Flash, Node, plein de causes extérieures qui ont poussé les développeurs JavaScript à changer leur façon d’appréhender le développement d’applications.
Il y a aussi le fait que de nombreux developpeurs front-end se sont par la force des choses improvisés développeurs d’applications CLI ou de serveurs.
Tout ça s’est produit dans un laps de temps très court, d’où une évidente (et très saine, pour reprendre les précédentes discussions sur le bazar) ébullition. Là il y a deux approches :
tu attends que l’eau ait refroidi, et tu prends les œufs qui n’ont pas explosé
tu surveilles, tu prends les paris, tu perds, tu reprends d’autres paris…
Le problème de JavaScript c’est qu’il n’y a aucune autre alternative donc ceux qui auraient volontiers pris une attitude attentiste ne peuvent pas se le permettre, se retrouvent obligés d’utiliser des technologies de transition à contre-cœur, et finissent par poster des billets de ce genre, parce qu’épuisés par un bouillonnement dont ils n’avaient ni envie ni le temps de gérer.
Oui, de transition, car je pense que tout le monde, pour ou contre, est conscient que l’état actuel de JavaScript est dû à sa transition de la version 95 à la version moderne. Cette transition s’est initiée lentement avec Protoype/jQuery il y a quelques années, et ne fait qu’accélérer depuis. Je pense qu’on est arrivé au cap de ce que peut tolérer un humain, et la tendance va donc être à l’apaisement (mais pas pour longtemps ;)). Je suis donc d’accord avec le fond de l’article : on sait en utilisant un framework JS aujourd’hui que le code écrit sera obsolète dans quelques mois, et il convient donc de le maintenir régulièrement, sinon oui on est devenu rien d’autre qu’un générateur de dette technique. Et si on ne peut pas ou ne veut s’engager sur cette maintenance, alors il ne faut pas utiliser de framework, ou ne pas faire de JS.
Pour beaucoup, je leur conseillerais de laisser tomber JS pendant encore un ou deux ans, vous reviendrez quand ça sera calmé. Pendant ce temps nous on construit, ça fait des étincelles, des flammes, ça brûle, on détruit 90% de ce qui est construit pour ne garder que le meilleur, mais si ce “chaos” vous est insupportable, alors effectivement il vaut mieux rester au JS d’il y a 5 ans ou rester de côté un moment.
C’est quand même le seul langage où des mecs d’un institut de recherche essayent de comprendre le pourquoi du comment:
“The JSCert project aims to really understand JavaScript.”
http://jscert.org/
@Louis:
Avant d’attaquer je préfère poser le décor, je suis à 10000% utilisateur de l’opensource (archlinux, python, debian, firefox, etc….), je suis informaticien autodidacte, mais j’ai par la suite suivie une école d’ingé, je connais donc les deux facettes du truc
Je ne comprends pas pourquoi tu t’évertue à comparer l’opensource à un bordel ?
Je pense que tu confond diversité et qualité.
Je suis pour la diversité, par contre pour avoir pratiqué avec du JS et du PHP autant de temps qu’avec du Python je peux te dire une chose ces deux premiers (JS et PHP sont totalement bancale (à mes yeux)).
PHP est à la base un langage de templating qui par la force des choses a évolué vers un langage de programmation à proprement parler, il en découle un langage immature (le passage à utf8 en est la preuve) et mal conçu… PHP doit sa réussite effectivement au nombre d’offres coté serveur sur le marché (ovh, etc…), mais également au fait qu’il est effectivement simple de l’utiliser afin de générer des maquettes et autres POC. Le problème c’est que les marketeux et les commerciaux ont bondi sur l’occasion et l’ont propulsé au rang de langage de référence pour le web, et malheureusement bien souvent ces “maquettes” finissent en prod faute de temps, de budget, et de gens couillus pour contrer cette stratégie.
Il en découle des projets immonde, inmaintenable et pour couronner le tout, le monde du web étant dirigé par des webagency, qui “embauche” stagiaire sur stagiaire, sans le moindre référant technique ou leader dans leurs équipes, ils ne font qu’entretenir ce cancer !
JS est à peu près similaire à PHP, mal nait et difforme. Comment construire un mur droit sur des fondations bancales ?
JS doit sa popularité au fait que…. behhhh y a pas trop le choix, il est là depuis le début, le virer des stacks est maintenant quasiment impossible.
ça s’était pour la qualité à proprement parler.
Le vrai problème c’est plutot pourquoi faire des apps JS quand un site “plat” ferait largement l’affaire ?
Concernant la diversité, je suis pour, mais avec de la qualité !
@+
Ce serait intéressant d’essayer de replacer l’état actuel de JS dans l’histoire de l’informatique.
Combien de machines bizarre, mal fichues et incapable de se parler entre elles ont été inventées avant d’en arriver à la norme POSIX ?
Combien de langages bizarres et mal fichu avant d’en arriver au C (qui n’est peut-être pas si bien fichu que ça, mais c’est pas grave, on a appris à faire avec).
C’est un réflexe qu’on n’a pas encore suffisamment en informatique : analyser l’histoire. Tout simplement parce que l’informatique est encore relativement récente, et donc son histoire est peu fournie.
Et lorsqu’on en sera à analyser le bordel actuel dans la programmation mobile, ce sera là aussi utile de se plonger dans le peu d’histoire qu’on a.
Et le futur/actuel bordel de l’internet des objets aussi.
Moi je fais du C++ comme ça je suis pas emmerdé.
ET encore ET encore !
Vous avez oublie de parler de la conso sur le client final : A titre d’exemple facebook mange a peu pres 5% de mon CPU en permanence a cause de tous les appels js fais pour raffraichir cette interface ( qui etait plus rapide a afficher du temps ou c’etait du statique ) ….
Je pense surtout que faire des frontend full JS c’set clairement un truc de hipster pour faire monter les salaires comme l’ont dit certains plus haut…pour ma part j ai prefere monter en competence sur du framework stable et evolutif (sf) et juste une couche JS un peu evolue avec jQuery, je fais 99% de ce qu on fait les autres angulas js…. SANS DEPENDANCE.
Ce XKCD qui vient de sortir résume bien l’esprit actuel.
Vu que j’utilise aussi NoScript, je me rend bien compte que Javascript n’est pas toujours nécessaire. En développant, j’essaye ou j’aimerais pouvoir rendre Javascript optionnel. De plus, le vanilla Javascript n’est pas si pauvre que ça, on utilise surtout DOM et XHR au final. Pas besoin de JQuery ou autre pour faire ça. Par contre, un framework modulaire qui ajoute des fonctionnalités réellement manquantes, comme par exemple les fonctions pour encoder ou décoder base64 ou JSON dans les anciens navigateurs, là je suis d’accord. Il ne faut pas avoir de fonctions inutiles qui prennent de la place, ou de variables “non libérées” qui s’accumulent (cause probable des ralentissements sur les ordinateurs bas de gamme).
Il y a des choses qui sont confondues allégrement dans ces discussions qui mènent à un dialogue de sourd. Dommage, parce que ce serait l’occasion d’avoir des échanges productifs.
1) Oui, la communauté js est dynamique et innovante, js est un langage cool, qui évolue vite et disponible partout, et ça mène à une certaine effervescence qui peut être déroutante d’entrée de jeu mais que nul développeur qui se respecte ne devrait remettre en cause (sinon il faut retourner faire du Cobol).
2) Mais ce foisonnement est aussi du à une certaine immaturité de la communauté js qui fait qu’on assiste à pas mal de pratiques néfastes :
je ne comprends pas les principes fondamentaux du web, alors je dis que c’est cassé et j’écris une lib à la place ;
je ne comprends pas bien un framework / outil / lib existant, alors je dis que c’est cassé et je publie ma version ;
je m’amuse à écrire une lib pour le fun, et je la publie sur npm juste parce que je peux ;
plutôt que de contribuer à une base de code existant, je vais m’amuser à publier un nouveau truc ;
« ah bon, un projet web peut s’étaler sur plus de trois mois ? »…
On a ça dans toutes les communautés, mais c’est particulièrement marqué dans js, parce que c’est le langage mainstream aujourd’hui (même effet que php il y a quelques années).
Se plaindre du foisonnement de code et d’outils js en faisant fi du premier point, dire que « js ça pue » sans chercher à comprendre le langage, ce n’est pas digne d’un·e dev digne de ce nom, et ce n’est guère productif.
Mais ignorer le second point et prétendre que « de toutes façons, le bordel c’est cool », c’est aussi se voiler la face en niant l’existance de réels problèmes dans l’écosystème. Ce sont des erreurs qui ont été commises par d’autres communautés, n’est-il pas dommage de se priver de cette source d’expérience ?
J’ai arrêté de troller sur developpez.com parce que les discussions étaient pas constructives, mais ici c’est assez pareil mais y’a plus de fun :) alors allons-y.
@bsadacheng Tu n’as jamais lu de code Windows, j’en suis sûr, car il est fermé. Moi, si. Et c’est bien pire que du code Linux, crois moi. Je sais de quoi je parle, moi. ;)
@Louis j’ai juste l’impression que le bordel c’est comme les relations patrons-employés : il faut une “balance”, pas trop d’un côté, pas trop de l’autre. Avant tout était pour les employés, aujourd’hui la balance part dans l’autre sens jour après jour et devient de plus en plus uniquement pour les patrons. Mais je m’éloigne. On parlait du bordel : je suis entièrement d’accord, il en faut. Merci les fork github pour mon ergodox. Mais quand la balance n’est plus équitable, et qu’il y a trop de bordel, cela devient problématique. Sans un Linus Torvalds pour intégrer les sources, en s’assurant que la balance tombe pas trop du côté du bordel, Linux crève. Et JavaScript est très largement tombé dans ce côté bordélique. Reprocher à une communauté d’être bordélique, c’est bête. Expliquer qu’on en a marre d’un gros putain de bordel qui est devenu immense et ingérable sur le plan professionnel, ça n’est pas bête.
@jules : regarde bien ma question ici. Le type répond “voici une solution partielle pour résoudre ton problème.”. Yep. Here’s an alternate partial solution that uses just that approach. Lis bien son code : clair, précis, documenté. 269 lignes pour quelque chose qui est impossible à maintenir sur des gros projets. Juste impossible. Et c’est qu’un début, de l’aveux de l’auteur qui est excellent en JavaScript. Même chose codée en Python ? 20 lignes (sisi je ne blague pas). Mais bon, on veut être à la mode.
Je pense que si l’auteur de ce post est comme moi, il déteste quand tout le monde essaie de suivre une mouvance alors que c’est d’une connerie qui n’a pas de limite. “Allez jetons nous du premier étage sur du bitume c’est super rigolo”. Moi je n’y vais pas. “Ah t’y vas pas ? Qu’est-ce que t’es con alors !”. Voilà ce que je ressens quand tout le monde dit “JavaScript c’est la solution à la vie, l’univers et le reste”.
@anon je suis d’accord avec toi : les gens qui maîtrisent une ou deux “stack” en JavaScript peuvent se vendre des fortunes, vu la vitesse à laquelle tout évolue. D’ailleurs j’ai refusé d’apprendre Angular v1 pour en faire des formations parce que je savais que la v1 est tellement moisie que la v2 n’est pas compatible ! T’imagine tous ceux qui ont sorti des dizaines de milliers d’euros pour faire un site Angular v1 et qui voient que c’est dépassé, et même plus compatible, qu’ils doivent ressortir à nouveau des dizaines de milliers d’euros pour la moindre évolution ? C’est horrible ! Mais pour un expert Angular v1 c’est la poule aux oeufs d’or, t’as entièrement raison.
@lui : T’as trop raison : la plupart des newbies Php arrivent pour traîner leur bordel ingérable dans le monde JS.
@Nicolas Chambrier : pour terminer tout ça, j’espère qu’une seule et unique chose : que Unity puisse effectivement, avec le temps, remplacer tout ce bordel ambiant. Je prie pour que cela arrive.
@Olivier Pons : pour ta question sur StackOverflow, c’est juste que dans ce cas tu utilises mal l’asynchrone. Ça peut se régler assez facilement avec un compteur de reste-à-faire pour “attendre” la fin des opérations et donc que ton “ret” soit correctement peuplé (et en bien moins de 200 lignes), ou en 20 lignes aussi avec un outil du genre de “async”, ou encore moins avec les Promise tout simplement.
Sinon pour Unity, ça n’a juste rien à voir avec la choucroute :o et il est illusoire d’imaginer qu’on revienne un jour sur un système nécessitant un plugin à la Java/Flash. Cette vision est périmée.
sudo npm uninstall npm -gLes gens ne lisent plus Hugo mais lisent Closer,
Les gens ne regardent plus Audiard mais Friends et toutes ces séries américaines à la con,
Les gens n’achètent plus Armor Lux mais H&M,
Les gens ne cuisinent plus mais vont au Mac Do,
Alors la populace, par flemme intellectuelle, programme de la merde car ce qui l’attire c’est la facilité et la médiocrité à l’image de notre société et de nos hommes politiques : on touille tous dans notre caca.
La règle dans notre société : “Fais de la merde, fais là vite et bien et surtout facture au max”.
Les langages de merde, le management et la gestion projet ne sont que des outils permettant d’aller vite comme les circuits économiques auxquels nous obéissons : la rentabilité à court terme implique une gestion projet agile et donc des langages adaptés à ce même rythme.
Un vision industrielle n’est plus adaptée à notre style économique, la meilleure preuve est que l’industrie française est morte.
Les analyses purement informatiques sont fausses, il faut regarder à plus grande échelle.
100% d’accord, c’est énervant. Je pense que pour mes futur projets je ferais du front JS sous prozac, ça changera que dalle mais au moins j’en aurais rien à foutre.
Pour les bidouilleurs Javascript, une méthodologie adaptée à votre style : http://www.la-rache.com/index.html
Ce post rejoint un peu le post “Retour sur la pénurie de devs”.
Sans vouloir simplifier ou schématiser, il y a 2 catégories de dèvs :
– ceux qui en ont rien à foutre du long terme, utilisent la dernière techno à la mode, pondent leur appli en 3 semaines, se font payer dans la foulée et passent à autre chose. Ils s’éclatent un max, rajoutent une ligne sur leur cv / mois. Ils sont en mode YOLO.
– ceux qui passent derrière pour nettoyer ce merdier car par un grand miracle, la durée de vie de l’appli dépasse 3 mois.
D’après mon expérience, la proportion est de 90% pour les 1ers et 10% pour les 2nds.
Pourquoi ?
Parce que tout le monde sait qu’il y a une chance sur 100 que l’appli existe encore dans 3 mois.
Donc faut faire de la merde, ce qui est à la portée de tout le monde. Les problèmes arrivent quand par miracle l’appli trouve son marché et rapporte de l’argent, la, faut faire les choses proprement sinon ça met en péril les rentrées d’argent et ça intéresse pas du tout les YOLO car pourquoi faire les choses proprement si ils trouvent toujours des clients qui les paient à faire de la merde ? Il reste les 10% qui acceptent de nettoyer le merdier et construisent une appli pérenne.
Une techno est forcément associée à un contexte économique et social.
Personnellement, je fais parti de la 2nd catégorie, les nettoyeurs de merde qu’on appelle en urgence parce que ça plante. Mais je m’en fous, mes tarifs sont au moins le double des YOLO.
Choisis ton camp camarade développeur.
Merci de ne pas ranger Meteor dans la case framework front-end, c’est trop réducteur.
Le front-end de Meteor c’est Blaze par defaut (un fork de handlebar) et ça peut etre remplacé par Angular ou React.
Meteor c’est bien plus qu’un framework.
Ils ont l’ambition de devenir la plateforme JS avec le frontend et le backend, la gestion de packages et le déploiement tout en un.
Apres oui je suis un fanboy de Meteor, j’avoue mais je pense que c’est pour les bonne raisons… voir une de mes prez au sujet de Meteor
et la video du co-fondateur de Meteor qui me confirme mes espoirs (a mon sens) désolé c’est un peu long (48m)
ou celle la en plus court mais moins sexy
Sinon j’étais dev PHP/SQL pendant plus de 10 ans et maintenant ça fais presque 2 ans que je ne fais plus que du Meteor et … je kiffe ^_^
Certes, je tire mon chapeau à l’équipe de Météor qui sont des gens qui essayent vraiment une approche new gen.
Merci Sam pour l’article et à tous ceux qui ont commenté. Je trouve les commentaires aussi intéressants à lire que l’article (je suspecte d’ailleurs Sam d’avoir ce but en trollant JS, en plus de s’amuser !). N’étant pas un développeur, j’apprécie l’échange. Notamment ce troll majesteux de Louis, s’il en est. Il a l’avantage de trancher avec l’avis de Sam et de le faire réagir sur sa position. Comme Thibault l’a très bien écrit dans son commentaire, il ya du vrai dans les deux discours (pour ce que je sais de l’open-source). La diversité ne fait pas la qualité, etc…
D’ailleurs, est-ce que le concept de “standard” au sens de la stabilité va à l’encontre de l’esprit open-source ?
@Louis
Comme beaucoup de Linuxien typiques, tu vois uniquement en binaire : Windows/OpenSource. Mal / Bien.
Il y a des juste milieux dans la vie.
On peut avoir moins de bazar sans tomber dans le microsoft like.
Les standards, ça fait qu’en RSS et Atom t’as plein de namespaces (xmlns) en plus pour rajouter de l’inutile, parce que soi-disant non présents dans les standards (parce que c’est inutile).
Moi ça me faire rire de lire des commentaires disant que 2 ans plus tard et après une mise à jour des bibliothèques plus rien ne fonctionne… En fait c’est un peu la base du développement par dépendances. Il me semble que les mecs qui font du C++ (oui cela existe encore) ou des paquets Debian ont exactement le même problème lorsque des paquets dont leur logiciel dépend sont mis à jour.
Certes c’est le bordel dans l’environnement JS actuellement, mais c’est un processus de créativité normal. Globalement ce phénomène suit une courbe de Gauss : néant (ou très peu de diversité) – explosion (gros bazar) – selection naturelle des meilleurs outils (état stable).
JS est sorti du néant (l’âge d’or de jQuery et un peu avant) pour entre dans l’étape d’explosion, tout cela va s’épurer naturellement et se stabiliser.
C’est mon avis et c’est observable dans beaucoup d’autres domaines (cf. la courbe de développement d’un produit).
Perso, je développe principalement avec jQuery car besoin compatibilité IE8 (que j’espère bien voir disparaitre une bonne fois pour toutes cette année), je n’ai pas de besoins ultra-avancés en JS. C’est pas hype, mais c’est plutôt robuste. Certes cette effervescence est déroutante quand on n’est pas à fond là-dessus et qu’on y regarde de l’extérieur.
Je reconnais que la venue d’ES6 est vraiment intéressante, dans le sens ou l’on parie sur un langage et pas un framework (qui lui peut facilement décéder), et Babel permet quand même d’avoir la compat’ avec des navigateurs pas au top du support d’ES6.
Nicolas Chambrier a bien résumé ma pensée : quand on n’est pas à fond là-dedans, on a envie de regarder encore pendant 1 an et voir ce qui va rester. Je reconnais que je mange beaucoup de popcorn à regarder
Tu trolles beaucoup toi dis donc. Tu proposes quoi pour solutionner les problèmes que tu souleves ? vas-y on t’écoute.
@glup : vu le ton tu n’es pas du tout ouvert à des solutions. On ne peut pas conseiller quelqu’un si il ne voit pas qu’il y a un problème. Donc je passe.
J’ai du mal à comprendre pourquoi ça embête tant que ça les gens que l’écosystème JS soit hyper dynamique. Personne ne vous oblige à mettre à la poubelle votre stack actuelle pour tout remplacer par le dernier truc à la mode. Si vous avez déjà un framework avec lequel vous êtes confiant et efficace, pourquoi changer ? On peut rester curieux et se renseigner sur les nouveautés sans pour autant se sentir obligés de les utiliser sur son prochain projet.
Et puis, ce n’est un secret pour personne que lorsque les navigateurs supporteront nativement ES6, HTTP/2 et WebAssembly, la plupart des technos qui ont été mentionné dans l’article perdront tout leur intérêt. Est-ce que c’est une raison pour cracher dessus ? Ben non, ce sont des solutions au court-termisme assumé et elles fonctionnent très bien en l’état. Ce n’est pas une “machine à créer de la dette technique”, la dette technique elle vient de choix humains ! Si vous décidez de baser votre prochain projet de 3000 jours-homme sur un framework expérimental v0.4-beta tenu par deux étudiants à SF, ce ne sera pas la faute au framework si vous vous plantez… ça fait aussi partie du job de savoir faire des choix techniques posés et réfléchis, et non pas se dire “on verra bien, ça a l’air cool”.
Pour ma part, je suis ravi de voir toute cette agitation dans le monde du JS. J’ai l’impression que l’écosystème JS est un gigantesque incubateur, qu’on a mis une culture de bactéries sous rayons radioactifs et qu’elles mutent dans tous les sens. On voit des trucs inattendus, d’autres trucs vraiment horribles, beaucoup meurent ou se font bouffer, mais au final il en ressort quelques super-bactéries ultra-balèzes qu’on aurait même pas imaginé au début de l’expérience. JavaScript a une histoire complètement chaotique mais quand on prend du recul, on a quand même eu de grands progrès grâce à ce chaos. Il a fallu 15 implémentations différentes des Promise avant de se mettre d’accord sur un standard en ES6. Il a fallu des centaines de bibliothèques simplifiant la gestion des requêtes AJAX avant qu’on ait l’API fetch. Les standards du Web ont toujours évolué comme ça : on observe chacun expérimenter dans son coin, puis on essaie d’en retirer le meilleur ; la seule chose qui a changé, c’est l’échelle. Car oui JS est ultra-populaire. Ce qui n’est pas pour me déplaire, vu que c’est en faisant du JS que je gagne ma vie.
Enfin, si vous ne voulez pas vous prendre la tête à apprendre et installer un million de bidules, mais que vous êtes quand même tentés par la nouveauté, il y a des setups tout faits de solutions faciles à mettre en place et à apprivoiser. Je pense à [vue-loader] notamment, ou encore RiotJS qui a déjà été cité dans un autre commentaire (nb: je maintiens la traduction française de la doc de RiotJS).
Et si tout ça vous sort par les trous de nez et que vous avez envie d’écrire un rant post avec des gifs animés bien trollesques, ben vous pouvez aussi choisir de faire quelque-chose de réellement utile et qui vous mette de meilleure humeur. Comme vous servir un chocolat chaud, regarder un film ou aller faire une promenade. Vous verrez, c’est sympa ;)
Hello très bonne article le mois dernier je me suis fight pour faire marcher React.
Juste pour que mon environnement puisse marcher j ai passé 1 semaine entre Gulp que j ai abandonné pour WebPack + Babel + ES6 + ES7. C’est de la folie j ai même pris peur lorsque j ai regardé du côté de flux et ses dérives. ( vraiment furieux les mecs )
Pour ceux qui se pose la question de savoir que choisir je leur conseille pour un projet (FullJS) -> MeteorJS, il fait des merveilles.
Pour le Front Pure je pense qu’il faut oublier Ember Angular and co trop lourd et surtout trop de contrainte et pas assez de liberté un simple Mediator/Facade + React pour de la webApp ou sinon du jQuery pour des petites manip seront largement tip top.
Pour ceux qui cherche une alternative a …flux, j utilise baobab -> ( un peu comme dans meteor avec minimongo/session );
Je me souviens qu a l epoque jquery n etait pas seul il y avait scriptaculous, yahooUI, dojo etc..
conclusion ? chaos puis harmonie : calme avant la tempete ;
la question c est de comprendre pkoi jquery en 2016 ne suffit plus ?
Et bien entre temps il y a u l arrivé ou le succé rapide des smartphones et des tablette qui ont apporté de nouvelle pratique ou dérive : on charge une fois le gros du gros puis on affiche ( one page scroll ect… )
mais comment apporter un rafraichissement rapide et transparent de ce dernier sans rafraichir le navigateur.
Pour reussir cette promesse sans jeu de mot on oublit jquery pour du vanillaJS et malheuresement pour les debutants c est la loose du coup sont arrivé une chier de framework ( backbones, ember, angular ) qui vont encore plus foutre la merde et pire encore lorsqu on souhaite echanger avec le serveur. Et oui le plus simple serait de pouvoir poursuivre la communication en js d ou le succes de node et mieux encore ecrire et lire en js ( json ) mongo bien evidement.
Le soucis c est que cette approche ( one page + api ) est tt nouvelle ce qui explique l explosion de la communauté js qui est en plein mouvement et des pepites commence a voir le jour comme Meteor et sa compensation de latence.
Pour ceux qui ne comprendrai pas imaginé Deezer a l epoque si il aurait ete codé en jquery, plus d un navigateur aurait planté.
Je crois qu’il n’y avait pas assez de troll sur cette page, je vais donc y ajouter ma petite patte…
@Louis : Quand tu dis “Cela vient du fait que j’ai lu ça : https://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar” je suis ravi de savoir que tu lis des pages Wikipedia mais, quand on veut être troll arrogant, peut-être pourrait il être utile de lire le livre à laquelle elle se réfère, non ?
Car si tu avais lu “La Cathédrale et le Bazar”, il ne t’aurait pas échappé que le terme “Cathédrale” d’Eric Raymond fait en partie référence à la manière dont Richard Stallman gérait ses projets (Emacs en l’occurrence), à savoir (en gros) privilégier la publication de versions stables, contrairement à Linus avec Linux qui encourageait à en poster le plus possible.
Je ne dis pas qu’il faut préférer la Cathédrale au Bazar, mais que tes petites phrases péremptoires du genre “Dans le monde du logiciel libre, le bordel règne en maître” je pense que tu peux te les carrer délicatement dans le… le derrière (désolé pour l’image, je me plie à la thématique principale du site).
Mais peut-être que ta culture générale te laisse croire que Richard Stallman a écrit MS-DOS…
Voire que les mondes du Libre et de l’Open Source se confondent…
Aux plaisirs…
(J’ai essayé de faire le plus poilu possible. J’espère que c’est suffisant.)
Il ne faut pas oublier que ces nouveaux outils sont faits pour construire des IHM Web complexes, de plus en plus proche de ce que l’on peut faire dans les applications natives.
Alors oui, ces outils sont infiniments plus difficiles à mettre en oeuvre que jQuery, mais ils nous permettent aussi de faire des applications beaucoup plus abouties.
En ce moment j’utilise Angular ou React, selon mes besoins. Angular pour les IHM avec pleins de formulaires et React pour le reste.
Je n’utilise pas de surcouche JS comme Coffescript, ou Typescript car cela me semble trop risqué sur le long terme, et cela rend le debug plus délicat.
Concernant React, je n’utilise pas Flux, Redux…, le fonctionnement de base me suffit largement.
En revanche j’utilise ES6 avec babel. Ca complexifie légerment le build, mais ce n’est pas de la dette technique, car un jour les navigateurs le feront nativement.
Pour le build j’utilise selon les cas : npm scripts (on trouve vite les limites), gulp (la notion de flux rend parfois des choses simples compliqués), webpack (le pire! mais indispensable pour le build incrémental avec React sur les gros projets).
Aucune de ces solutions n’est vraiment satisfaisantes… Je pense qu’il reste une place à prendre pour un Nieme outil de build, qui mettrait tout le monde d’accord :)
Tous ces problèmes sont connus au niveau du W3C. Il y a comme qui dirait un village d’irréductibles gaulois qui luttent pour que le Web devienne sémantique, analysable par des machines, et non plus livré aux marketeurs qui veulent des bords ronds et des pubs animées toujours fluides. L’abandon de XHTML a été un tournant, la faute aux faiseurs de navigateurs, et Javascript est devenu indispensable : http://homepages.cwi.nl/~steven/Talks/2015/11-06-xml-amsterdam/
Sam,
not sure if this will make you change your mind about JavaScript: http://www.infoq.com/articles/no-more-mvc-frameworks
Frameworks and libraries are just too easy to come by with JS, but at the core, it is because some of the key assumptions behind code factoring are broken. Trying add the nth framework to fix the way we factor code is not a good way to solve the problem. The SAM pattern should help people return to the basics. At least it did it form me.
JJ-
Hi.
I disliked the article:
Bottom line: the article was still very interesting. But it could have been way shorter, way less pedantic, and not pretending to invent something. You can just say “look, we have these problems, we have some existing tools that are good at it, use them together. Here is an example”. This would have been 50 lines.
fair enough, it looks like my point was not made clear in the article, thank you for your feedback. In the end, you can’t be reactive and interactive at the same time, just a small detail, and the whole point of the pattern is to eliminate data binding, that’s why it is not there… databinding is the problem not the solution.
@jean-jacques dubray: BTW, despite the tone in my comment, I did find the article interesting. I just dislike the form, and the dismissal of the interest of framework as a tool to federate community in favor of a custom but isolated solution.
Je suis moi aussi désespéré par la panoplie de nouveaux frameworks. Aujourd’hui, j’ai laissé tomber tout ça pour me concentrer sur l’essentiel : JS. Je développe en JS orienté-objet, je pense “components” et j’utilise PubSub pour la communication inter-components. Composition est une autre clé. jQuery pour l’Ajax et la sélection/modification de DOM. Connaitre JS, c’est connaitre l’essentiel. Quelques patterns JS pour orchestrer tout ça, et les choses roulent. Lorsque je démarre un nouveau développement, mes estimations sont toujours correctes, et c’est dans l’intérêt d’absolument tout le monde. Le reste, c’est de la propagande marketing.
Il existe des algorithmes qui évaluent la complexité d’un code ; il devrait y avoir le même type d’algorithme pour déterminer la complexité de l’environnent technologique. 3-4 technologies/frameworks pour faire du développement front-end, c’est too much. Je suis lassé de perdre mon temps à étudier une API/framework que d’autres ont faits.
J’espère que cette frénésie cessera. Dieu que ce sera bon de ne plus se tirer les cheveux avec les derniers gadgets à la mode.
Il me semble cependant que ce qui arrive au JS est un phénomène naturel: quand le langage ou l’éco n’est pas mûr, il donne naissance à des tonnes d’outils.
PHP, même Java en son début et bien d’autres y sont passé. Une seule constante: le temps fait office de nettoyage.
Dans le web frontend, que se passe-t-il ?:
– l’utilisateur attend une expérience quasi native dans son navigateur;
– JS traîne un manque de fonctions auquel on palie via ES6, mais entretemps X frameworks et patterns sont nés
– l’innovation se fait aujourd’hui beaucoup plus sur le web que dans des technos dites desktop only; le dev web est quasi roi
Forcément ca donne lieu à une ruée vers l’or.
Je trouve ca fascinant et effrayant. Effrayant car les recruteurs mal avisés vont demander des connaissances trop pointues et éphémères. Fascinant car il en découlera un web meilleur une fois le menage ayant été fait.
En résumé: je suis 100% d’accord avec l’article, mais le phénomène n’est pas l’apanage de JS. Tu aurais écris le même article il y a xxx années sur d’autres langages.
C’est purement cyclique et en aucun cas un phénomène nouveau. La seule nouveauté est l’ubiquité du web, et donc un sentiment qu’il faut tout voir et tout apprendre. Et ca perso, j’ai choisi mon camp: apprendre, ok, mais on ne peut pas tout sinon: dépression. Nous ne sommes pas des machines, laissons le cycle naturel faire son effet. Un dev n’est pas un surhomme.
Et si la solution c’était de faire tout à la main? A l’ancienne! Retrouver le plaisir des choses simples et instantanées?
Visiblement, les gars de FapFapJS ont bien compris le truc : http://www.fapfajs.io
Un truc propre alors.
Bonjour à toutes et à tous,
un vieux dinosaure comme moi reste perplexe face à toutes ces gesticulations.
Quoique je pense avoir eu les miennes en mon temps.
Un peu d’histoire :
Sorti de Fac avec un DEA d’informatique (à la fin des années 80),
on travaillait en cours sur les bases de données, les réseaux de neurones (eh oui dèjà),
la théorie de la programmation et on conversait sur des machines UNIX en telnet avec
des correspondants japonais et parfois américains (bon j’abrège).
Donc sorti de fac on connait 3,4 langages, surtout le C (unix oblige),
le Pascal, un peu de Lisp et SQL. Puis arrive Java et surout l’avènement
internet. Voilà, voilà j’y arrive !! Il est vrai qu’au début je n’y aie pas trop cru.
Surement influencé par Microsoft qui croquait le monde informatique à pleine dent
(vu que le PC venait de naitre) et qui ne croyait pas non plus vraiment à l’internet(normal c’était LE concurent).
Mais Javascript était déjà de la partie (oui Javascript est sortit en 95, 96 si mes souvenirs sont bons = 20 ans !!!!!!)
et comme Netscape était bien vu (par pleins de gens et d’organismes…), cela a obligé Microsoft à réagir (jscript = javascript ersatz).
Mais Javascript (fortement inspiré par d’autres langages à l’époque, java, python etc…) ne devait qu’enrichir HTML,
être simple d’utilisation et manipuler les objets du DOM.
Mon avis :
Javascript a bien évolué, le WEB aussi, mais le WEB reste le WEB !!!
Javascript n’est qu’un langage, mais le seul aujourd’hui éxécuté par les navigateurs !!!!
Donc quoique l’on fasse en bout de ligne c’est (il faut) du Javascript.
C’est pourquoi je comprends les différents avis face à pléthore de Framework et outils en tous genres
pour faire le JOB sur le WEB. Car le dev WEB permet d’être à peu près la seule solution “universelle”
pour une application multi-plateforme. Le monde Javascript est devenu une vraie jungle, c’est vrai !!
Et c’est très dur d’y voir clair et de commencer par le bon bout !!!
J’en sais quelque chose, j’ai mis 2 semaines à comprendre comment cela fonctionnait (à peu près) tellement il y a de concepts
qui disent que… et qui font que… et puis je suis un peu vieux aussi.
Mais je pense que l’on essaye de plier le Javascript et son technosystem, à ce qui existe déjà sur le desktop (ça a le même goût, mais ça s’appelle différement).
Mais pour retrouver une expérience quasi desktop sur le WEB, c’est pas aussi simple que cela !!
Vu que ça n’a jamais été conçu pour faire cela, on essaye tant bien que mal de se rapprocher du graal mais c’est pas encore parfait.
Alors comme un vieux singe j’attends et je suis sur que l’on va revenir à des choses plus terre à terre, d’ici quelques années.
Soit s’apercevoir que le WEB avec HTML et CSS et Javascript, il y en a un ou deux de trop dans l’histoire.
Et que tout va se faire directement en Javascript et pourquoi pas directement à partir du terminal client.
Les tuyaux vont forcement grossir (5G, la fibre) et donc le volume d’info qui passe par le tube sera un détail.
Soit Google va sortir un plugIns (plus jamais ça !) de son sac magique Google et tout le monde va l’adopter (si, si !!).
Soit le WEB/HTML et consort va disparaitre petit à petit pour être directement intégré (interprété) dans un OS, ou une VM (.NET ?) ???
Seul le temps nous le dira !!!
j’ai peut-être écrit beaucoup pour pas dire grand chose, mais bon ça me grattait, alors voilà…
Bonne journée à toutes et à tous.
PS :
J’ai une appli CRUD (avec une belle IHM) qui doit durer au moins 5 ans à faire sur le WEB (multiplateform oblige et sans installation client desktop).
Je suis d’abord parti sur Java + Vaadin + Spring + Hibernate, vu le nombre de techno et TRUCS à mettre en place pour sorti qq chose, j’ai eu peur !!!
Je me suis penché alors sur Javascript directement, mais aujourd’hui après avoir survolé Angular 1, je me suis aperçu que le 2 arrivait donc j’ai recommencé
mais à voir effectivement tous les outils (en command line) à utiliser pour faire un minimum j’ai dis pfuuiiiiii. J’ai commençé mais il faut beaucoup
de courage pour persévérer. Je n’ai ni trouvé quelqu’un, ni un blog, ni une techno qui m’a convaincu, mais je cherche encore !!!
Je vais essayer JHipster, Aurelia et Meteor, j’ai bien dis essayer.
En attendant je suis preneur de tout les conseils et avis avisé et d’un stagiaire également.
Nous sommes petite structure (2 dev = copains de fac) sur la region parisienne au pied du Métro ligne 1.
“Cela donne des trolls low level tout juste bon à se moquer de PHP et de JavaScript sans comprendre pourquoi ces deux langages lead le monde des applis web OpenSource.”
Pourquoi ils sont leaders..? J’ai ma petite idée, qui ne te plaira pas :
– déjà parce qu’ils sont simples à apprendre, ça fait un gros avantage, n’importe qui avec un minimum de cerveau arrivera à afficher une page web avec eux (alors que vouloir se lancer en ASP.Net ou JAVA Struts, Spring ou JEE est un peu galère)
– puis simple à mettre en place (merci Apache puis Wamp pour avoir démocratisé et simplifié le php local – et ouais ça date surement mais j’en fais plus du tout depuis plusieurs années)
– léger (enfin à la base, s’il faut se trimballer 2Go de plugins et lib maintenant, c’est juste ridicule)
– et javascript, y’a hélas aucune alternative pour faire du dév un peu dynamique sur le client, en tous cas portable sur les différentes plateformes/browsers
Mais ce n’est pas pour leur subjective beauté, puissance relative ou éco-système fourre-tout.
Il est vrai que la montée en puissance de node ces trois dernières années a crée un bazar monstre.
Mais je vous vois parler de stack plutôt hétérogène et je me demande pourquoi. Pourquoi vous vous cassez le cul ?
Tu veux un truc stable :
– évites les libs sorti de on ne sais où avec un ou deux dev. c’est pas des solutions pérènnes
– évites les dépendences dont tu n’as pas besoin
– choisis bien ton langage. Ne prends pas node js parce que c’est à la mode !
si tu as beaucoup de templating à faire côté client, tu devrais peut-être éviter nodejs. Perso, je l’utilise pour des app web ou des api, voir pour générer des pages static en suite servie par un truc genre nginx. Node + express et hop ça marche très bien.
Ensuite, pour le côté client, pareil, il faut rester simple, sans compté les besoin très spécifique (de la carto avec leaflet, des graph ave chart js, des stat avec D3 …) il faut se limité à un framework/lib pour générer ses templates ou gérer ses pages.
Donc contraire à Sam, je dis que faire des choses propres en js, c’est plus simple qu’avant. Mais la première fois, il faut se poser et observer. Prendre le temps de voir ce qui est stable.
Quand à la question angular 1 et 2, pour le moi, le 1 gagne haut la main car il est éprouvé, pas mort, stable et surtout il ne cède pas aux sirènes des transpileur comme dart ou typescript qui apportent avant tout des incompatibilités et des config pas possibles. Le 2 je le jète à la poubelle x)
Je suis sur un projet pro d’un an et demi, pour le migrer à node 6, on aura que peu de changement à faire. On a jamais eu trop de problème de ce côté là.
Un article qui reprend l’idée générale que je me fais sur tous ces frameworks de développement web “à tout faire” qu’on voit apparaître et disparaître au fil du temps.
Durant mes études, que ce soit en IUT ou même en école d’ingénieur, j’ai toujours fonctionné en suivant une équation très simple : un langage = un domaine d’application (jusque là, rien de choquant – SQL pour de la base de données, C pour des applications “clients lourds”, Java/PHP pour des traitements serveurs, …). Mes premières expériences professionnelles ont d’ailleurs très bien confirmé cela et c’est à cette époque que j’ai véritablement compris le fonctionnement du modèle MVC (peu vu malheureusement pendant mes études).
Et depuis maintenant plusieurs années, je vois de plus en plus des outils qui décident de mélanger les couches : du code Java qui génère du JS pour GWT, du code Javascript qui génère de l’HTML pour ExtJS, … Au nom de quoi ? De la simplité de programmation ? De la maintenabilité ? Non seulement je ne vois aucun gain de temps d’un point de vue développeur à utiliser ces outils censés nous faciliter la vie, mais surtout on se confronte à des problématiques que l’on n’avait pas jusqu’à présent :
– souci d’installation des frameworks avec des messages d’erreurs pas du tout standards (quand il y en a),
– logiques qui sont propres aux librairies et qui fait qu’on est fatalement amené un jour à soulever le capot pour comprendre pourquoi ça ne réagit pas comme on voudrait (s’il y en a que ça amuse d’aller regarder le contenu du librairie pour en comprendre le fonctionnement, pas moi),
– le temps passé à se former sur la librairie (certes, certaines librairies ont une courbe d’apprentissage très rapide mais il n’empêche que le jour où elles deviennent obsolètes, on est reparti pour un tour),
– des pages web de plus en plus lourdes à afficher alors qu’on a des ordis de plus en plus puissants (cherchez l’erreur sachant qu’en plus, l’ergonomie tend vers toujours plus de simplicités ces dernières années),
– …
Au final, mes préférences restent sur des choses basiques : des pages HTML avec du CSS pour la forme, du JQuery pour y intégrer ce qui est dynamique (et éventuellement rajouter des effets “designs”), et un langage un peu plus lourd pour ce qui est côté serveur. Vivement que cette mode du tout-JS passe…
Entièrement d’accord avec cet article.
Ce qui me chagrine le plus est cette surenchère des solutions à base de js qui vendent de la révolution notement en terme de solutions backend alors que leur doc est obsolète et que les issues ne sont pas corrigé sur des points critique.
Côté front heureusement que angularjs est arrivé pour apporter à mon sens un réel atout en dev front.
Hello,
Me concernant, je trouve la stack JS plutôt simple (j’ai essayer de migrer vers le language GO, suite au succès de Docker, mais suis revenu à une stack JS (front/back web).
Il suffit de suivre l’evolution du language JS (le language évolue vite et dans le bon sens avec l’aide de Typescript comme phase de beta test en quelques sorte par rapport aux nouveaux concepts) pour comprendre les outils à utiliser.
C’est à dire ceux suivis et construits par des équipes pérénnent .
Par exemple ma stack :
NodeJS 6 (bientôt en LTS) – API grace au framework HapiJS (Wellmart) – et Angular 2 ou ReactJS en Front
concernat les outils de build webpack (qui à remplacer les autres car plus performant et plus simple)
Rien de compliqué !
JS avant était mis à jour que très rarement, maintenant l’organisme de certification à changer la donne depuis 2015 (MS et Google vont pousser de nouvelle techno/amélioration dans le language chaque années) c’est pourquoi les tecnhos/Framework sont en plein effervessence (JS version 2016 à redistribuer les cartes des possibilitées …)
Angular 2 et ReactJS sont l’exemple même de tout ça remeetre tout à plats pour pouvoir bénéficier des futurs evolution du language …
Et lorsque tu veux apprendre le développement web et que t’es plongé dans cette m**** autant dire que t’as qu’une envie, c’est de fuir…
@Sebastien oui oui c’est simple, sauf que webpack c’est déjà hasBeen : http://javascriptplayground.com/blog/2016/10/moving-to-webpack-2/
Une fois la phase vieu aigri passé, il restera plus qu’à ce mettre à jour. Bonne chance !
Et maintenant que tu as fini de gueuler, tu t’es tourné vers quoi ? :)
Je suis en pleine lecture. Merci pour ce type d’article et d’échanges riches en enseignement pour un newbie en frontend.
Louis, bien que je sois moi-même principalement dev JS et PHP (donc deux langages aux communautés vivaces mais bordéliques), et presque “acquis à la cause”, quelques remarques :
Tu prends effectivement, comme l’ont fait remarquer certains, un ton condescendant des plus pénibles, et ça dessert ton propos… parce que ni toi, ni moi, ni l’auteur de cet article ne détenons la Vérité Ultime™.
J’approuve totalement Sam quand il dit, en réponse à ton argument que “le bordel c’est bien”, qu’avec JS ça atteint un degré jamais vu ailleurs. Non ce n’est pas “bien” d’en arriver à un tel niveau de bordel. Ce n’est enviable en aucune façon, quoi que tu puisses te dire pour essayer de t’en convaincre toi-même.
Bah désolé vieux, mais “que les choses se tassent”, j’ai une mauvaise nouvelle pour toi : ça ne va jamais arriver tel que c’est parti. Mon 1er framework front a été Ember.js. Que j’aime beaucoup par ailleurs, mais que je délaisse parce que contribuant à l’indécente obésité des pages et applis web (btw comme quelqu’un l’a dit, riotjs is the way to go!). J’avais commencé un projet perso avant qu’Ember et Ember Data ne se stabilisent en 1.0, puis j’ai suivi l’évolution pendant un temps, jusqu’à 1.5 environ (c’était il y a longtemps !). Je reste 6 mois sans toucher au projet, je me dis “tiens passons à la 1.7”, et ça me pète littéralement tout. Des heures pour adapter mon appli au nouveau modèle. Les gens qui ont investi dans Angular 1.x ont la même déconvenue avec l’arrivée du 2. Et ça c’est pour ne parler que d’un framework. Là on en a littéralement qui dégueulent de partout, ça continue, chaque putain de jour, quelqu’un de par le monde pond un nouveau framework JS en se disant “tiens, y en a aucun autre qui fait ce que je veux”.
L’argument comme quoi ce “dynamisme” de la communauté (“hystérie” serait-il un terme approprié, je vous laisse juger) serait payant à long terme est à mon avis,
douteuxtotalement démenti par la réalité. On a probablement tous espéré qu’un jour Linux botterait le cul de Windows. Et ça n’arrivera jamais. J’en rêvais quand j’ai découvert Linux (en 97 pour ma part). Et certes les choses ont progressé, même une distro un peu “geek friendly” comme Debian a un installeur graphique. Mais la dispersion des efforts fait que c’est mort, absolument mort, pour espérer concurrencer Windows ou OS X pour le grand public. Qu’en a-t-on à foutre d’avoir le choix entre 10 environnement desktops ? Si tu en as un qui marche bien tu vas le choisir, non ? Le pire c’est que les raisons qui motivent les moults forks et autres sont le plus souvent douteuses et motivées par des raisons dont le quidam moyen – voire le geek moyen – se fout éperdument (comme Devuan le fork de Debian motivé par le passage de celle-ci à systemd).En conclusion, je veux bien défendre JS parce que j’aime ce langage, mais parfois il faut arriver à avoir un minimum d’examen critique honnête sur nos pratiques. Moi-même je plaide coupable pour m’être créé mon propre petit “boilerplate/framework à mon goût” pour node, et je me dis que si on en est arrivé à un tel bordel, c’est parce que tout le monde fait pareil dans son coin. Et ce n’est pas la direction à prendre à mon avis.
Je suis d’accord, ceci dit javascript n’a jamais été aussi génial et innovant !
un bon stack:
serveur: node + babel + di-ninja + express + graphql
navigateur: webpack + babel + di-ninja + react + relay + redux
C’est vrai qu’il faut compter un sacré temps d’apprentissage et d’expérimentation pour mettre en place ne serait-ce que le socle,
mais au final c’est très gratifiant, je recommande !
@takion : Je me suis mis à ReactJS (front uniquement, pas de NodeJS chez moi !) il y a 15 jours. Le tutoriel officiel montre comment faire d’une ligne de JS pure 15 lignes de React JS + JSX… Autant dire que ça met un coup.
Puis je lis ton post, et je vois qu’au bas mot pour faire un truc qui serait un “bon stack” il faut au mini 11 systèmes à apprendre :O
Ben je me dit : ReactJS je fini le tuto parce que c’est la mode et que comme Angular ça fleuri sur les offres d’emploi…
Mais pour coder ce que je vois au quotidien sur les sites, pas besoin d’une usine à gaz ! Au pire une lib maison de JS pure, ou un aggrégat de libJS sans dépendances pour des choses basiques. Mais pas 1Mo de JS pour gérer des event de click en JS !
@Valentin
Je comprends que tu puisse penser ça car j’ai déjà eu le même genre de raisonnement lorsque j’avais moins d’expérience.
En fait ce qu’il faut comprendre c’est que les bénéfices de React par rapport à du pure JS se révèlent sur le long terme,
sur des projets complexes et dont le code se doit d’être évolutif.
Certe, ce qu’avant on pouvais faire en 1 ligne, il nous en faut maintenant 15,
mais lorsque qu’on est sur un projet qui comporte 50 000 lignes de code JS rien que côté navigateur, là où on aurait dû patcher de partout et rajouter 500 lignes de code en se rapprochant toujours un peu plus d’une impasse totale à certaines nouvelles fonctionalités futures, avec React, on va pouvoir résoudre ça proprement et en 5 lignes de code seulement.
Et je ne parle même pas de la ré-usabilité des composants développés, car ce pourrait être le sujet de plusieurs articles.
Il est vrai qu’il n’est pas évident d’utiliser React sans avoir l’impression qu’il complique pour beaucoup des problématiques simples, sans avoir eu auparavant affaire aux problématiques qu’il résout de manière magistrale.
Et c’est d’ailleurs pareil pour n’importe quel outil un peu complexe.
Pour avoir codé pendant 10 ans avec jQuery et avec du JS pure (de plus en plus à mesure que les problèmes de cross-compat et de rétro-compat s’amenuisaient), je peut te dire que depuis que je suis passé à React, je m’émerveille tous les jours de la flexibilité et de la simplicité de résolutions de certains problèmes qui auparavant m’auraient fait m’arracher les cheveux.
L’expérience de nombreux cauchemards durant plusieurs années en développement web me permet d’apprécier correctement la valeur d’une approche déclarative par rapport à une approche impérative.
Bien sure cela est particulièrement pertinent sur des interfaces entièrement générées en javascript, le serveur ne retournant que de la data pure (en général du json).
Il est certain que si on parle d’ajouter trois events à un plugin wordpress, il n’y a aucun intérêt à utiliser React.
En revanche lorsque l’on développe un CRM complet sur mesures pour un client, le temps et la performance gagnés sont quasi-infini!
@Nicolas Chambrier Pour information, je ne fais que des sites Web Django/Python, et tout s’oriente presque vers des “serveurs” Django/Python = serveurs REST / JSON (pour faire simple) avec un client Unity + échanges REST / JSON.
Deux ans après ce post, je viens de faire ce qui suit 3 trois fois, sur trois projets totalement différents :
– développement d’un serveur Web Django/Python
– développement d’un échange REST / JSON
– une boîte à côté a fait l’application mobile (une fois Cordova une fois Ionic une fois React)
– j’ai refait à côté pour voir si j’arrivais, la solution Unity
Le constat est sans appel :
Cordova / Ionic / React :
– 5 jours pour développement
– à chaque nouvelle évolution, minimum une journée (facturée) pour les implémenter + déployer
– certaines évolutions on coûté 3 jours voire plus (car c’étaient juste des plugins installés, et il fallait les analyser pour les faire évoluer selon le besoin du client)
– esthétique : laide
– problèmes sous-jacents : énormes : selon les mobiles, problèmes de CSS. A tel point qu’ils ont décidé d’embarquer le navigateur dans le livrable (de 6Mo l’appli tu passe à 23Mo)
Unity :
– 20 jours pour développement (oui, 4 fois plus !)
– à chaque nouvelle évolution, durée entre 2 et 10 fois MOINS que les solutions Cordova / Ionic / React (oui, une évolution m’a pris moins d’une heure à être implémentée contre une journée sur React)
– je n’ai jamais eu de problème des responsive. Jamais. Sur tous les mobiles sur lesquels j’ai installé l’appli, sans aucune exception. J.a.m.a.i.s.
– aucun problème sous-jacent. Pas un ou deux : aucun.
Et je n’ai pas du tout parlé du monde incroyable qui s’ouvre en plus de mon appli qui n’est qu’en 2D avec des UI basiques : la 3D.
Bref, si, mon post ici avait tout son sens, et question pérennité, une application mobile sur deux est développée en Unity aujourd’hui.
La solution pérenne pour moi = l’opposé de créer la dette technique, est :
– côté serveur : Django / Python
– côté client : pas de JavaScript du tout, mais du Unity / C# (sachant que, notez bien, la courbe d’apprentissage est très longue et fastidieuse, mais rien, absolument rien dans le monde professionnel, ne vaut le plaisir de voir la mâchoire du client qui tombe par terre lorsqu’on présente l’application Unity juste après qu’il ait vue l’application en Cordova / Ionic / React).