Blog relating the daily life of web agencies developers

@james perso j’ai bien aimé ►https://medium.com/javascript-and-opinions/state-of-the-art-javascript-in-2016-ab67fc68eb0b c’est partial mais ça te donne des idées

– npm « va de paire » avec node
– amha tu peux oublier bower maintenant
– perso je suis passé de jshint à eslint :
▻https://github.com/shramov/leaflet-plugins/commit/526bee1f670dbceb5480e212c8c536a5cfb253ad
voici la conf minimale que j’utilise :
▻https://github.com/shramov/leaflet-plugins/blob/master/.eslintrc

▻http://eslint.org donc.

et du coup, me rappelant de l’excellent ►http://www.phptherightway.com, je tombe sur ▻http://jstherightway.org

un peu de lecture en perspective :-)

Je n’ai pas de guide (ça fait trop longtemps...) mais ceci dit j’ai remarqué que dans JavaScript Weekly (▻http://javascriptweekly.com) et Node Weekly (▻http://nodeweekly.com) il y avait souvent des liens vers des tutoriels de qualité.

Dans ta liste, je te conseillerais d’oublier bower (je n’utilise que npm, que ce soit pour du client ou du serveur), grunt et gulp (je fais tout mes build scripts aussi dans npm, avec de l’Unix et du JS ; quelques exemples simples : ▻https://github.com/scienceai/crossref/blob/master/package.json#L6), et JSHInt qui comme d’autres l’ont dit est dépassé par ESLint.

J’utilise ▻https://github.com/scienceai/eslint-config-scienceai comme config, mais c’est un compromis, à toi de voir s’il correspond.

De façon générale, JS c’est comme Unix : il y a plein de petits outils, mais il ne faut surtout pas partir sur l’impression que tu as besoin de tout connaître pour bien t’en servir. Il faut juste trouver ce dont tu as besoin pour commencer, puis progressivement améliorer les choses en rajoutant telle ou telle brique à ta boîte à outils (enfin tu vois quoi).

Si c’est pour faire du client, je te conseille de regarder rapidement du coté de la transpilation browserify+babel+uglify+watchify parce que c’est un peu touffu et abscons la première fois mais par contre une fois que ça roule ça devient difficile de revenir à une longue liste d’éléments script et à ES5.

Et pose des questions !

#bande_de_geeks :-*

Bisous aussi @suske

Merci à tous ! Vraiment :-)

Et oui je risque fort de revenir avec des questions ;)

Coté task-runners grunt est clairement en perte de vitesse. Npm scripts est une solution très élégante (plus légère et moins de dépendances), par contre pas toujours simple à mettre en place sur des gros projets. Dans ce cas, j’utilise Gulp (mais toujours en combinaison avec npm-scripts). Pour ajouter un lien aux excellents postés par les autres : ▻http://naholyr.fr/2015/11/ecrire-des-scripts-npm-multi-plateforme
Il y a aussi webpack, d’ailleurs qui est un « builder/packer » (plutôt qu’un task-runner utilisé pour faire du build... à la différence de Gulp/Grunt), capable de gérer aussi les CSS, les images, etc...

Coté « packers », je privilégie browserify et l’écosystème autour, mais il faut avouer que webpack a certains avantages (et dès que l’on fait du #React sur des projets moyens à gros, on le rencontre souvent).

Coté « data-binding », #React est plus que populaire... mais n’est pas toujours le plus simple ou le plus élégant (franchement il y a tout et n’importe quoi dans son écosystème). Pour des projets petits à moyen, j’aime beaucoup VueJS que je trouve largement sous-estimé (le technical-marketing-driven development de la communauté JS est... fatiguant :-S)

Enfin, si tu veux être un « hipster » (et avoir peut être un cran d’avance), regarde du coté de :
– Elm (un dialecte de Haskell compilant vers du JS) – surprenant de simplicité et très intéressant, bien plus propre et simple que du React+Redux (il a servi d’inspiration aux auteurs de Redux)
– Cycle.js, pour faire du « Functionnal Reactive Programming » (pas encore suffisament testé, mais les concepts sont intéressants).

►http://elm-lang.org (la version 0.17 vient juste de sortir et est encore plus simple)
▻http://cycle.js.org

Si je puis exprimer quelques légères différences d’opinion avec @0gust1... :)

Personnellement, je bosse au quotidien sur un gros projet JS et je n’ai pas rencontré de situation où les npm scripts n’étaient pas suffisants. Il est vrai qu’on n’a pas de collaborateur sous Windows, du coup la portabilité est plus simple. YMMV !

Pour WebPack, je m’en méfie comme de la peste. J’ai tenté le coup il y a six mois pour un nouveau projet, et au départ ça avait l’air génial, presque magique. Et puis j’ai voulu configurer un truc pas tout à fait comme tout le monde... catastrophe. Au moins browserify ça ne fait qu’un truc mais ça le fait bien, et quand tu veux autre chose il suffit d’aller voir ailleurs :)

C’est vrai que la qualité de l’écosystème React est inégale, mais il y a quand même des choses très bonnes (comme react-motion, ou les linters de JSX). Personnellement je ne suis pas fan de Redux, je pense qu’il y a une place à prendre. À l’usage React même c’est quand même top.

J’espère que les gars de Cycle vont nous sortir quelque chose de bien ; ils semblent avoir bien compris les problèmes de RxJS (IMHO inutilisable même si le concept est top) avec xstream. À suivre, mais bon c’est très, très hipster pour commencer :)

Je lis cela comme de la prose ésotérique. Presque je pourrais entrer en transe si j’allumais des bougies.
:D

@rastapopoulos c’est pour toi :p

http://www.commitstrip.com/wp-content/uploads/2016/05/Strip-Pepperidge-farm-650-final.jpg

Haha, ouais, c’est un peu ça. #vieux_con

J’ai la même impression que pour la cartoon. Avant tu voulais coder, tu codais. Maintenant faut investir beaucoup de temps pour comprendre l’environnement avant de comprendre comment coder.

(et puis jquery, c’est super récent hé :p ) #dhtml

@robin pas vraiment de désaccord :) c’est vrai que ces dernières années j’ai bossé dans des environnements assez hétérogènes (l’outillage devait marcher sous Win, OSX et Linux).

Pour webpack, j’ai eu exactement les mêmes sentiments...

Sinon, je m’aperçois que j’ai oublié de mettre le lien vers #vueJS : ►http://vuejs.org Pour des projets pas énormes, je trouve ça beaucoup plus rapide/efficace que React.

Désolé pour les liens de « hipster » (c’est vrai que je ne commencerais pas par là ;-) ). Je trouve Elm néanmoins très intéressant, j’ai été très surpris en essayant. Il n’est pas encore assez intégré avec les APIs des navigateurs à mon goût : poster un form « à l’ancienne » n’est pas vraiment simple, utiliser le localStorage non plus (les trucs que j’ai constaté).

Sinon, pour @rastapopoulos , @nicolasm , je ressens ça assez fort. On a beaucoup parlé de #javascript_fatigue ces derniers temps. De mon coté, j’ai eu de sacrées prises de bec avec de jeunes devs zélotes des derniers trucs à la mode, aux avis dichotomiques, ne sachant pas faire la part des choses entre le marketing des équipes techniques des GAFAM et la réalité du code, des besoins. On peut encore écrire de très bonnes choses avec jQuery si l’on organise son code avec soin. Je suis devenu un vieux con aussi, je crois.

Il y a des niveaux dans le #vieux_con :)

Perso je ne songe même plus à la #js_fatigue, juste je passe mes journées un peu à coté du torrent de trucs qui sortent, je sirote ma bière, et de temps en temps quand il y a un bon outil qui passe je l’attrape. Il fait frais, la vue est belle.

En ce qui concerne SPIP, les codeurs initiaux parlaient anglais sans grosse difficulté. On n’a pas vraiment choisi de coder en français en fait ; c’est surtout qu’on n’avait pas spécialement réfléchi à cette question quand on s’est lancés, le projet n’avait d’ailleurs pas d’ambition démesurée à l’époque : on faisait les choses comme elles venaient, en mélangeant écriture “naturelle” et code.

Au final ce n’était sans doute pas l’approche la plus efficace dans la concurrence mondiale. Mais il faut aussi se rendre compte que ça a eu le mérite d’ouvrir certaines portes, comme par exemple l’arrivée de participants codeurs qui, eux, ne parlaient pas anglais.

Parfois tout de même c’est rageant de voir que sur github le moindre bout de code qui fait un truc à moitié mal torché a des zillions de stars, alors que SPIP, qui possède déjà des fonctions pour faire pareil depuis 10 ou 15 ans, n’est pas repris. Mais c’est aussi (surtout ?) dû, je pense, à la faiblesse de la modularité des fonctions internes de SPIP.

C’est marrant, @fil ou pas. J’ai jamais été investi dans le code de #SPIP, mais je l’ai utilisé pas mal de fois. Hé bin ça faisait plaisir que ce soit codé en français. Ça nous faisait des vacances. Je veux dire par là qu’à fonctionnalités « égales », c’est plus cool de taper des lignes de code dans sa langue maternelle qu’en anglais. Même si l’anglais n’est pas un problème. Donc, merci pour ça, pour ce plaisir.

#mouais

Ici en Bolivie, il y a de très bons codeurs et codeuses, mais la majorité n’est pas à l’aise avec l’anglais, et du coup les variables en anglais sont écrites « yaer » au lieu de « year » ou des trucs dans le genre. De même, la documentation doit être en espagnol, sinon c’est incompréhensible.

Du coup, on a défini des normes de codage où tout est en espagnol, c’est à dire exactement ce que décrit la BD, sans l’ironie :)

▻https://gitlab.geo.gob.bo/bolivia-libre/bolivia-libre/blob/master/doc/politicas-desarrollo.md

Je précise que c’est pour des systèmes utilisés par l’État Bolivien, et qui ne seront sûrement pas utilisés ou développés par des anglophones.

Ça vous paraît une mauvaise idée ? Qu’est-ce que vous conseillez ?

En ce qui me concerne je conseille exactement ça pour les collectivités (petites et grosses) ou les PME locales, franco-françaises, avec lesquelles je travaille, @severo.

Quand le client est francophone, et que si un jour il ne veut plus de nous comme presta et que le prochain presta est à 99,9% francophone aussi, ça n’a strictement aucun sens de livrer des développements en anglais.

Le pire même, j’en connais qui mettent même tous les logs de commits en anglais dans le dépôt propre au projet (pas dans un dépôt d’un truc libre public quoi). Alors qu’ensuite c’est gardé par le client français et lu par les prochains intervenants français…

C’est vraiment pour se la péter, et ça ne fait que ralentir la compréhension des intervenants suivants.

La BD part du principe que tout est une organisation capitaliste mondialisée présente dans X pays… Out of reality (mais ces gens là voudraient bien que ce soit la réalité).

Merci @rastapopoulos, je suis d’accord avec tes arguments.

Le lien semble en erreur, et je ne parviens pas à trouver l’article sur le site.

Le lien ne fonctionne pas, mais adblock+ fonctionne très bien ;)

on dirait bien que l’article est venu et est repartu…
mais j’en ai retrouvé une copie sur ▻http://www.leparisien.fr/flash-actualite-high-tech/face-aux-logiciels-anti-publicite-google-et-les-editeurs-contre-attaquent

(...)
En attendant une éventuelle action en justice, actuellement à l’étude en France contre les bloqueurs de publicité, les réponses des sites hexagonaux aux internautes allergiques à la pub sont disparates.
(...)
« Le secteur de la publicité veut abattre Adblock comme l’industrie musicale a traité Napster », résume à l’AFP Sean Blanchfield, le PDG de PageFair, à propos du populaire service de partage de musique, lancé en 1999 avant d’être fermé sur injonction de tribunaux en 2001.

Curieux de découvrir l’angle d’attaque... si une telle action doit avoir lieu !

Adblock : la tension monte, le procès en ligne de mire
▻http://pro.clubic.com/webmarketing/publicite-en-ligne/actualite-742731-adblock-tension-proces-ligne-mire.html

Les bloqueurs de publicités provoquent la colère des éditeurs en ligne. L’IAB France et le Geste, deux organismes représentant sites et annonceurs réfléchissent à l’idée d’attaquer en justice ces « adblockers », en particulier la société Adblock Plus.

Les représentants des annonceurs et des éditeurs français montrent les dents. Ils pourraient prochainement agir en justice à l’encontre des systèmes permettant de bloquer certaines publicités en ligne (adblockers). Le comportement de certains bloqueurs, comme la société Eyeo, éditrice d’Adblock Plus, aurait conduit les professionnels du secteur à franchir le pas.

Mais merde ! On a bien le droit de mettre un autocollant « pas de publicité » sur sa boîte aux lettres ! On ne veut pas de pub, point barre ! Commence à faire c... c’t’équipe !

Ils confirment tous, d’une certaine façon que leurs publications sont sur abonnement. Et quand on n’est pas abonné, on n’y va pas. Et donc voilà. Ils ne veulent pas qu’on les lise... Tant mieux. Leurs messages sont toxiques... et si de ce fait plus de monde pouvait éviter de les lire, ça ne serait pas plus mal...