Reprise du message précédent :
"Ember: think of it as doing Cobol in the banking industry"
 
comme accroche.

C'était en général, après être tombé sur un projet en GWT je me suis dis plus jamais

C’est dommage de se dire intéresser par les changements et d’être aussi fermé par la suite. J’avoue que toute personne ayant testé Ember avant 2.0 peut avoir souffert et ne pas se rendre compte de l’évolution.
 
Mais bon, je ne tiens pas à dire React c’est de la merde (même si personnellement ne pas contribuer à l’essor de Facebook me plait).
 
Suis tu l’évolution d’autres librairies/frameworks JS ou uniquement React ?

Mouais

 
Tu ne te rends pas compte du gain de productivité pour les grosses équipes sur les gros projets  

Je ne suis pas fermé, je n'en ai simplement pas l'utilité ou l'envie pour le moment

Gain de productivité par rapport à quoi ?
Si tu prends l'exemple d'une archi micro services avec React + lamdbas avec du JS partout, la productivité est quand meme excellente, et une rapidité de déploiement / pivot adaptée avec des environnements qui bougent souvent (topic web je rappelle ). Après c'est sur que si tu bosses dans des banques c'est pas la même (bien qu'ici les grosses banques commencent à migrer).

De toutes façons il n'y a pas de "meilleur" framework/language, simplement le plus adapté à l'usage dont on a besoin

 
Les conventions font qu’il est très facile de naviguer une grosse codebase. Ça permet de structurer sans que chacun invente sa sauce. Pas de build customisé pour chaque projet. Un écosystème qui supporte beaucoup de problèmes de base.
Etc..

 
Je sais surtout que c’est un argument plus que bancal que de dire « si tel ou tel gros l’utilise, c’est que c’est pas de la merde ». Y’a plein de grosses équipes et de gros projets qui retropedalent en terme de techno aussi

Pour etre productif à long court/moyen/long terme faut :
- pouvoir recruter facilement
- avoir une techno sur laquelle la montée en competence est facile/digeste
- avoir une grosse communauté (stackoverflow, plugins)
 
Donc bon Ember ... voila quoi ...
Surtout que tout le reste (angular / react / vue) est tout aussi rapide en prise en main et production, sinon plus.
Un projet doit pouvoir avoir 50% de ses lignes de codes qui proviennent de SO

Pas nécessairement, tu peux avoir une techno plus niche mais avec des gens meilleurs et/ou plus motivés (cf Python Paradox). Et faut pas non plus confondre nombre de personnes avec la techno sur leur CV & facilité à recruter.

Pas nécessairement non plus, ça va dépendre de ta problématique. Tu veux pas mettre des batons dans les roues, mais tu veux pas non plus nécessairement prendre VBA parce qu'on en a vite fait le tour.

Avoir une communauté motivée et amicale (communautaire) semble plus utile qu'une grosse communauté.

 
Ce nivellement par le bas

 
Tout a fait, après on s'arrete pas à ce qu'il y a écrit sur le CV pour recruter .. mais au moins des dev angular/react ca se trouve rapidement, suffit de filtrer derrière.
 

En quoi la grosseur d'une communauté influe sur la qualité / motivation ? Ok les posts/issues/articles interessants sont plus dilués dans le "vrac" mais perso quand je sais ce que je cherche je trouve (moteur de recherche toussa)
 

 
Redface was red

C'est l'avantage et l'inconvénient de Boring Techno. Moi ça me va parce qu'il y a de la maturité et du sérieux dans les release, et qu'on se sent pas obliger de tout changer pour faire plaisir aux cool kids. Le problème c'est que lesdits cool kids sont partis ailleurs, ne restent que les rares qui se sont spécialisés. C'est confortable quand tu es un LinkedIn ou Captain Train et que tu peux réserver une part significative du marché (voir l'entretenir), moins quand tu n'es pas un gros.

 
 
   
 
Ces grosses boites ont le choix : Netflix utilise aussi React, LinkedIn a payé 2 équipes pendant 1 an pour faire le même projet en Ember/Glimmer et PReact pour comparer les performances.

 
 
C’est clairement un problème    
 
Mais j’ai l’impression que choisir React ne facilite pas plus l’embauche de dev avec véritable expérience. Ça reste un pool restraint, les autres se contentant de sauter de techno en techno sans jamais approfondir quoi que ce soit.

J'ai pas spécialement besoin d'un dev d'expérience si je ne suis pas un "gros", je fais juste de la SPA sans énormes contraintes de perf ni de scalabilité.
Juste besoin d'un dev bien câblé, connaissant les bases récentes du FW. Le reste, ça s'apprend sur le tas si la codebase et les collègues sont pas trop à la ramasse.
Sous Ember c'est rare (le dev bien câblé avec des notions du FW), sous React/Vue/Whatever nettement moins.
 

Je suis content d'avoir lancé ce débat
Bien que je ne participe pas, je lurke, et c'est très intéressant !

 
Malgré mon intérêt pour Ember, je ne suis pas sur que je prendrais ça quelque soit la boite et le projet sur lequel je bosse
 
Je bossais dans une boite avec 1 énorme SPA et plus de 10 autres applications, une centaine d'ingénieurs. Il y avait une vraie plus value. De la même manière quand j'aidais les boites, ca permettait de se concentrer sur des choses plus importantes car il était facile de naviguer le code.

Puisqu'on parle de framework JS, the Ember.js project se lance dans le marketing, "Ember.js: The Documentary"
 
https://thenextweb.com/dd/2019/02/2 [...] ally-good/

Perso je suis sur VueJS depuis plus d'un an, je bouge plus depuis... Je crois avoir trouvé le framework frontend qui me va

 
J'aime beaucoup aussi. Et j'attend la V3 en natif TS avec impatience aussi

Idem. C'est pas demain la veille que je vais refaire du react.

Pour quelle raison ?

VueJS    
Je vois pas pourquoi j'irais m'emmerder avec cette techno tordue alors qu'il y'a une solution bien mieux pensée à côté

Je n'irai pas dire que React est mal pensé, mais oui je partage le fait que le flow de VueJS est ultra propre, et meme si globalement en terme de fonctionnalités React et Vue se valent (de ce que je lis, React serait un poil devant), n'empeche que l'envie de réouvrir un vieux project Vue est la, alors que chez React...

 
Quel type de sites fais tu et dans quel environnement pro/taille d’équipe ?
 
Peux tu détailler ta pensée ?

Si on va par là faut pas utiliser le JS pour du vdom, c'est juste pas adapté et il y a des solutions mieux pensées à côté.

J'ai pas dit que React était mal pensé. Je pense juste que React n'était pas pensé pour ce qu'on en fait aujourd'hui et en conjonction avec Redux c'est bien pire.

Je ne fais plus de web.
 

Stadire?

 
J’ai du mal à comprendre comment tu émets ce jugement du coup.

Il en a fait suffisamment, jusqu'à peu pour avoir un avis credible

Du coup il peut détailler ce qui lui fait dire ca et repondre aux querstions que j'ai posées

J'ai fait 5 gros projets avec React, taille d'équipe entre 5 et 20 personnes. Que des SPA ce qui est une connerie, en tout cas implémentée à coup de ReactDOM.render(body, ...), et toutes avec du Redux. J'ai fait deux interventions en tant que senior dev et le reste en tant qu'architecte ou CTO.  
 
Le constat de base c'est que ça scale très mal quand on veut absolument absolument détourner la techno pour en faire un framework applicatif. Quand j'ai commencé y'avait des choses assez risibles comme le fait que les modals présentaient une difficulté particulière, ce que vise entre autre à résoudre React.portal, et ça ne choquait personne.
 
Après avoir constaté ça, j'ai essayé d'autres choses comme ne pas avoir un seul point de montage et une application monobloc, mais plutôt plusieurs points d'entrée: un par zone dynamique.
 
Du coup j'ai arrêté ce genre de mission car trop peu d'intêret.

Merci  
 
Quel est la dernière version de React que tu as utilisé dans ce contexte ?

16.x

J'aime bien l'arrivée des providers, ainsi que de suspense. Les hook, c'est bien, mais pour moi ,c'est du sucre syntaxique.

je n'ai jamais aimé redux, trop verbeux, trop de bordel. Je prefere mobx, mais attention à la magie noire, des fois c'est pénible

Pour les modals, dans mon dernier projet , j'ai fait comme ça :

.backdrop{
              pointer-events: auto;
              position: fixed;
              bottom: 0;
              left: 0;
              right: 0;
              top: 0;
              background-color: rgba(0,0,0,0.2);
              z-index: 1000
}

export class Modal extends Component {
  escFunction = event => {
    if (event.keyCode === 27) {
      this.props.close && this.props.close();
    }
  };
  componentDidMount() {
    document && document.addEventListener('keydown', this.escFunction, false);
  }
  componentWillUnmount() {
    document && document.removeEventListener('keydown', this.escFunction, false);
  }
  render() {
    const { isOpen } = this.props;
 
    let height = this.props.height || '33%';
    return (
      <div
        style={{
          pointerEvents: 'none'
        }}
      >
        {isOpen && (
          <div
            className="backdrop"
            onClick={e => {
              this.props.close && this.props.close();
              e.preventDefault();
            }}
          />
        )}
        <CSSTransitionGroup
          transitionName="slideInFromBottom"
          transitionEnterTimeout={500}
          transitionLeaveTimeout={500}
        >
          {isOpen && (
            <div
              key="father"
              style={{
                pointerEvents: 'auto',
                position: 'fixed',
                bottom: '0',
                left: '0',
                right: '0',
                height: height,
                backgroundColor: 'white',
                overflowX: 'scroll',
                padding: '1em',
                zIndex: '1001'
              }}
            >
              {this.props.children}
            </div>
          )}
        </CSSTransitionGroup>
      </div>
    );
  }
}

Il manque juste du SQL et on est de retour aux années 90

oui, et non

il y a un mélange de pas mal de chose, mais chaque composant est autonome. Donc au sein du même groupe de fichier, on a l'intégralité d'un bout de la logique, c'est testable, c'est maintenable, et le contrat avec l'extérieur est propre (les props sont le moyen principal + eventuellement les accès aux storesredux/mobx/provider)

Les refacto sont indolores si il n'y a que les props, gérable si il y a des accès au stores.

edit : dans certains composants, j'ai aussi l'accès à l'api, comme ça on est complet
edit2 : pour clarifier, je compte l'api comme un store (asynchrone)

Le HTML dans le code JS, ca me fait toujours mal aux yeux. Je me demande ce que pensent les designers qui veulent modifier le visuel du site.

 
Pour moi, ce genre de framework est intéressant pour les Apps qui justement embarquent entièrement leur code HTML parce qu'elles ont par exemple un mode offline efficace. Concrêtement, cela se justifie pleinement pour les Apps pour les appareils mobiles.
Le problème, c'est que cette logique maintenant a débordé un peu partout et qu'on se retrouve avec plein de sites où l'emploi de ce genre de méthode ne se justifie absolument pas et où c'est même fortement contre productif.

J’ai du mal à saisir la justification de la présence de HTML dans du JS pour un mode offiline.  

 
Je me suis mal exprimé. Tu peux parfaitement séparer et avoir ton HTML dans des templates front ends. Je parlais d'avoir tout le code embedded pour des sites ou des applications qui n'en ont aucunement besoin.