city:angular

En gros ils se tirent une balle dans le pied non ? Plus globalement je ne comprends pas cette volonté de transformer Javascript en « java like » (cf cet AtScript ou Typescript) avec cette notion de typage fort (ou au moins explicite) et de classes au lieu du prototypage, comme si on persistait à faire croire qu’on peut faire du Javascript sans le connaître.

J’aime bien Angular (je parle de la version 1) parce que c’est finalement assez simple (même pour faire des choses très complexes, je n’ai jamais trouvé ça très difficile, reste le problème des performances). Du coup cette version 2 ne me dit rien, vers quel framework faudrait-il se tourner ? React vaut-il le coup ?

En gros ils se tirent une balle dans le pied non ? Plus globalement je ne comprends pas cette volonté de transformer Javascript en « java like »

La communauté JS est très variée, et ce n’est pas la seule tendance. L’apparition des classes dans ES6 est très critiquée (voir par exemple : ▻http://seenthis.net/messages/332237)

De mon coté, je n’aime pas du tout Angular (avis perso), mais c’est une solution qui reste très adaptée à certains contextes. Le problème est que, du fait sa popularité, beaucoup de gens l’ont utilisé pour tout et n’importe quoi.

Du coup cette version 2 ne me dit rien, vers quel framework faudrait-il se tourner ? React vaut-il le coup ?

Une des tendances qui a l’air de se dessiner c’est la fin des trucs monolithiques :

▻https://andywalpole.me/#!/blog/142134/2015-the-end-the-monolithic-javascript-framework

React est tout « petit » par rapport à Angular, il faut lui ajouter d’autres choses pour arriver aux même fonctionnalités. J’aime bien React (mais j’ai pas encore fait grand chose avec).

Je comprends ce désir d’utiliser plusieurs modules plutôt qu’un gros framework qui fait tout mais ces derniers temps j’ai ressenti un certain besoin de simplicité, notamment pour mes développements perso (car professionnellement on a plus ou moins le temps d’approfondir la connaissance des outils utilisés) et cette profusion de modules et de frameworks m’apparaît comme une vraie plaie pour la maintenance et le déploiement de l’application, surtout quand on fait du développement sporadique (parfois je mets mon développement en veille pendant quelques mois), sans compter qu’on ne sait jamais où donner de la tête (tel micro-framework remplace avantageusement un autre qui était pourtant hyper hype il y a 2 mois puis finalement un autre module fait bien mieux le taf pourvu qu’on appelle une autre dépendance etc.). Au moins avec Angular on peut tout faire (y compris n’importe quoi, j’en conviens).

Ceci dit je vais regarder du côté de knockout, ça me semble pas mal et plus léger.

Ah carrément, je partage ton constat.

sans compter qu’on ne sait jamais où donner de la tête (tel micro-framework remplace avantageusement un autre qui était pourtant hyper hype il y a 2 mois puis finalement un autre module fait bien mieux le taf pourvu qu’on appelle une autre dépendance etc.).

C’est tout à fait ça : à chaque nouvelle fracassante du dernier outil « hypeJS », un bébé phoque meurt en moi. Vivement que l’écosystème se stabilise un peu.

En tout cas Knockout c’est plutôt sympa (super docs de prise en main), mais pas aussi « puissant » que Angular.

De mon coté, on utilise surtout nodeJS pour automatiser du webdesign et de l’intégration web (encore un domaine où la hype n’a pas arrêté l’année dernière, avec la sortie d’un nouvel outil toutes les 2 semaines quasiment...). Et bien, actuellement on utilise surtout Grunt, et de plus en plus « rien du tout » : de petits scripts persos appelés en ligne de commande via les champs « script » du package.json (▻http://substack.net/task_automation_with_npm_run).

C’est quasi aussi rapide à faire et on est pas obligé de se plier à un outil, d’essayer de le tordre, voir debugguer le code (debugguer du JS... :-S ).

J’ai remarqué cette pattern chez les gens qui m’influencent en JS :
– le moins de dépendances possible,
– toujours regarder s’il y a pas un module plus bas niveau qui peut faire le travail
– se méfier des outils rutilants et qui en font trop
– Faire de petits modules, les plus standards possible.

J’avoue que pour le moment, en ce qui concerne JS côté serveur, je me suis aussi contenté d’utiliser nodejs pour ce genre de tâches que tu décris (qui incluent aussi des choses du genre sass -> css, coffeescript -> js etc., dernièrement avec gulp plutôt que grunt mais ça ne change pas grand chose je pense). Cette profusion de librairies, cette instabilité en somme, ne me pousse pas à réellement faire des projets avec nodejs (mais peut-être bien que ça ne me serait même pas utile pour ce que je fais en fait).

Bof, c’est clairement de mauvaise foi sur le coup du « Hello world » qui nécessiterait 10000 trucs. Angular est à la fois simple et complexe, on peut faire des trucs tout bête sans se prendre la tête et en même temps on peut fabriquer des machineries incroyables et plutôt efficaces à condition de bien maîtriser la bête. Que trouve tu de mieux dans reactJS car au premier abord ça me branche beaucoup moins qu’Angularjs ?

Bof, c’est clairement de mauvaise foi sur le coup du « Hello world » qui nécessiterait 10000 trucs.

Oui, carrément caricatural :) Mais il n’a pas tort sur certains aspect « sur-ingéniérés ». Il se fait aussi bien remettre à sa place dans le premier commentaire (Nathan).

J’ai posté le lien car ça m’intéresse, j’aime avoir la propagande et la critique. Je « n’achète pas tout » dans l’article et l’auteur a des opinions très tranchées (mais pas inintéressantes).

Très vite (pas le tps de tout détailler) :

Ce que je reproche à Angular :
– Courbe d’apprentissage très plate puis ’falaise’ : c’est magique pour faire très très vite un POC, mais dès qu’il faut factoriser, généraliser, et faire des choses un peu avancées, il faut mettre les mains dans la machine et en comprendre une bonne part des tréfonds (la façon dont sont gérés les scopes, le binding, le dirty-checking, etc...). C’est pas progressif du tout.
– Très mauvaise documentation et exemples (cf plus haut)
– Coté UI, on se retrouve avec un HTML très sale, très pénible à travailler, surtout si les précédents développeurs se sont « amusés » avec les directives. (disclaimer, je suis « webdesigner/dev front » plutôt que « dev back qui s’est mis au front »)
– On y retrouve beaucoup d’idiomes et de patterns issus de JAVA, je ne vois pas l’intérêt en JS, et ça me file des boutons, désolé :)

Ce qui m’attire dans ReactJS :
– Périmètre très restreint : ça gère des composants, c’est tout. Contrairement à Angular où on a : vues + routeur + binding + composants + contrôleurs + services + tests.
– Fait pour la performance.
– ça ne pousse pas un modèle d’architecture ou d’organisation en particulier (défaut ou avantage ? ça dépend des contextes, plutôt avantage pour moi).
– je suis plus dubitatif sur le JSX, mais c’est à tester.

Je n’ai pas encore ’vraiment’ testé React (les tuto du web ça compte pas ^^). Je suis impatient, mais là où il faudra bosser, je pense, c’est dans l’organisation du code et des vues lorsque le projet grossira.

Bref, je pense que Angular est très adapté à certaines situations et projets, mais j’avoue que sur certains point j’ai été assez déçu.

Ce qui m’énerve également, c’est la tendance à vouloir en mettre partout, sans comprendre ce que c’est et pourquoi c’est fait ; comme c’est un peu la mode actuellement (javascript = AngularJS pour certains).

Sinon il y en a qui font ça : angular + react :

▻http://www.williambrownstreet.net/blog/2014/04/faster-angularjs-rendering-angularjs-and-reactjs

▻http://davidandsuzi.com/ngreact-react-components-in-angular

est-ce que ça vous brancherait d’écrire la future page d’accueil de seenthis en react.js ?

Que faciliterait react ? Qu’est ce que vous voudriez décliner en composants ?

Actuellement on charge tout en html : le formulaire principal, les 25 messages, leurs formulaires de réponse, les boutons « modifier, supprimer », etc. Ça fait circuler beaucoup de code inutilement, et puis ça ne permet pas de gérer facilement l’ajout d’un commentaire, le temps réel et tout ça.