Pourquoi est-ce que vous voulez réécrire tous le code actuel dès qu'un nouveau framework sort ?
En fait, on ne veux pas forcément tout réécrire dès qu'un nouveau framework sort, mais plutôt que dès que l'on veux implémenter une nouvelle fonctionnalité (par exemple l'export en PDF), il s'avère que nos framework sont obsolètes, que ce que l'on veut faire va alors dépendre d'une bibliothèque JS qui n'est plus mise à jour, donc qu'il vaudrait mieux commencer par porter notre application vers les frameworks actuels avant d'ajouter la fonctionnalité en question. Et comme faire du javascript n'est pas le cœur de notre métier (pour parler en manager) et que nous ne demandons de nouvelles fonctionnalités que de façon irrégulière (en fait, quand nous trouvons un peu d'argent pour cela, donc au plus une fois par an), nous utilisons toujours un framework obsolète...
Peut-être un mot sur notre application: nous sommes un institut de recherche sur la neige et les avalanches (www.slf.ch) et nous avons fait développer une application de visualisation des profiles de neige (structure stratigraphique du manteau neigeux, sous forme de couches ayant diverses propriété: densité, forme et taille des grains, température, dureté, etc). Cette application est aussi bien utilisée pour visualiser des résultats de simulation numérique que des mesures sur le terrain et permet maintenant d'entrer des données mesurées sur le terrain. Afin que tous puissent en bénéficier, nous nous basons sur des standards internationaux (représentation graphique standardisée, format XML standardisé) et nous avons choisis de faire cette application en javascript qui tourne entièrement dans le navigateur (le serveur ne fait que servir le JS, donc ceux qui utilisent notre serveur ne risquent pas de le surcharger!) et tout en Open Source (AGPL). L'application et sa forge se trouvent d’ailleurs sur https://niviz.org/.
En C++ nous aurions moins ce problème, mais comme il s'agit d'un application qui tourne entièrement dans le navigateur (et pas du tout sur le serveur), ce n'est pas possible... Mais je dois bien avouer que depuis que je vois un peu mieux comment l'écosystème JS fonctionne, je me demande si nous n'aurions pas mieux fait de faire une application lourde... (en même temps, avec la version web il suffit aux utilisateurs d'aller sur https://run.niviz.org pour travailler avec leurs données ou entrer de nouveaux profils, sans rien à installer, ce qui est très confortable).
[^] # Re: L'écosystème JavaScript était trop simple
Posté par Mathias Bavay (site web personnel) . En réponse à la dépêche Sortie de Deno 1.0. Évalué à 9.
En fait, on ne veux pas forcément tout réécrire dès qu'un nouveau framework sort, mais plutôt que dès que l'on veux implémenter une nouvelle fonctionnalité (par exemple l'export en PDF), il s'avère que nos framework sont obsolètes, que ce que l'on veut faire va alors dépendre d'une bibliothèque JS qui n'est plus mise à jour, donc qu'il vaudrait mieux commencer par porter notre application vers les frameworks actuels avant d'ajouter la fonctionnalité en question. Et comme faire du javascript n'est pas le cœur de notre métier (pour parler en manager) et que nous ne demandons de nouvelles fonctionnalités que de façon irrégulière (en fait, quand nous trouvons un peu d'argent pour cela, donc au plus une fois par an), nous utilisons toujours un framework obsolète...
Peut-être un mot sur notre application: nous sommes un institut de recherche sur la neige et les avalanches (www.slf.ch) et nous avons fait développer une application de visualisation des profiles de neige (structure stratigraphique du manteau neigeux, sous forme de couches ayant diverses propriété: densité, forme et taille des grains, température, dureté, etc). Cette application est aussi bien utilisée pour visualiser des résultats de simulation numérique que des mesures sur le terrain et permet maintenant d'entrer des données mesurées sur le terrain. Afin que tous puissent en bénéficier, nous nous basons sur des standards internationaux (représentation graphique standardisée, format XML standardisé) et nous avons choisis de faire cette application en javascript qui tourne entièrement dans le navigateur (le serveur ne fait que servir le JS, donc ceux qui utilisent notre serveur ne risquent pas de le surcharger!) et tout en Open Source (AGPL). L'application et sa forge se trouvent d’ailleurs sur https://niviz.org/.
En C++ nous aurions moins ce problème, mais comme il s'agit d'un application qui tourne entièrement dans le navigateur (et pas du tout sur le serveur), ce n'est pas possible... Mais je dois bien avouer que depuis que je vois un peu mieux comment l'écosystème JS fonctionne, je me demande si nous n'aurions pas mieux fait de faire une application lourde... (en même temps, avec la version web il suffit aux utilisateurs d'aller sur https://run.niviz.org pour travailler avec leurs données ou entrer de nouveaux profils, sans rien à installer, ce qui est très confortable).
Mathias