Stabilité javascript ? besoin avis d'expert

Sur la capture que l'on voit, le contenu de chaque fenetre est en ajax ou dans des iframes ?

Avoir accès à la mémoire, non, ça tu ne peux pas. Tu peux libérer des events tout au mieux, éventuellement bien vidé tes variables (même si chrome est sensé savoir le faire). Et à défaut, mettre des console.log un peu partout, notamment dans les events (sourtout lié à la souris/scroll, et chose du genre) qui peuvent vite devenir l'enfer, en particulier si on oublie de les désactiver à chaque nouveau chargement.

Théoriquement, si c'est en iframe, tu ne devrais pas avoir de soucis particulier, même avec 100 fenetres, si c'est en ajax et qu'il y a du javascript de partout, là ... faut vraiment que l'appli soit dev au petit oignon pour limiter le lag, et encore.

Salut,
Ce sont des div chargées avec ajax.
Pour information, je fais bien des .off pour libérer les évenements.
Mais le problème ne vient pas de là, puisque j'ouvre des fenêtres, les .off, c'est à la fermeture de cette même fenêtre.
le problème survient à l'accumulation d'ouverture de fenêtres, même sans en fermer une seule.

Et pour le console.log, comme je le disais au dans mon post, il ne fonctionne pas.
Javascript semble s'arrêter de fonctionner pendant quelques minutes.

@plus.
Pierre

Oué, 100 fenetres chargés en ajax avec chacun leur petite sauce d'interaction en JS, oué ... ça me parait pas fou que ça lag à fond.
Dans l'absolu, le JS hyper hyper maitrisé en désactivant les intéractions avec les fenetres non focus, et de réactivé les évenements quand la fenetre reprend le focus pourrait potentiellement faire l'affaire, mais ça demande beaucoup beaucoup de taff. Les fenetres dialoguent directement entre elle pour que tu aies besoin que ce soit en ajax ?

Enfin là, c'est une étude complete du code qu'il faudrait faire, ça s'improvise pas. Il existe des moyens de voir les fuites de mémoire avec les outils de google chrome, mais perso, j'y ai jamais rien compris. T'as du tuto qui essai d'expliquer (en english, j'ai jamais trouvé en FR), mais je trouve les données hyper complexe à analyser pour en sortir un point précis à revoir.

Salut,
Oui, les fenêtres commnuniquent entre elles.
Pour info, ça ne lague pas du tout, c'est même très rapide.
C'est une application one page, jamais il n'y a rechargement le la page principale.
Déactiver les évenements si la fenêtre qui n'a plus le focus n'est pas envisageable, because, je fais énormément de trigger pour actualiser les fenêtres en arrière plan.

@plus.
Pierre

Je l'ai expliqué au dessus

Salut,
J'ai trouvé :D
Certains objets n'étaient pas détruit : voir
Par contre, ce que je ne comprend pas, c'est que je détruisais la div parent !!!!.
Pas grave, vé le faire à la mano :D

@plus

Pierre

D'un point de vue UX c'est une totale aberration. Si l'app n'est destinée qu'à toi, pourquoi pas, sinon à ta place, je repenserai l'UX. Ce genre de chose (ouvrir X fenêtres dans une App) n'existe pas. Source de confusion et impression de bordel pour l'utilisateur (voire d'application d' il y a 20/30ans. Une app moderne gère ça en mode navigation (page-sous-page-boutons de retour, boite modal, etc...).

Sinon pour "structurer ton code", je te conseille vivement de coder comme tous les frameworks modernes, par "Web Components".
1/ Ca règle le problème de structure, de maintenance et d'évolutivité du code.

2/ Ca règle un autre de tes problèmes => les Web Components sont par défaut "étanches" MAIS tu peux les faire communiquer entre eux. Tu vois bien l'avantage : rendre indépendants et sans conflit possible chacune de tes "fenêtres" puisqu'elles encapusleront chacune LEURS variables et LEURS méthodes, et si tu as envie, tu peux faire passer données d'un component à l'autre. Ton histoire de construction et destruction d'objet est automatique sur Angular par exemple quand tu charges un component.

Par frameworks front moderne, j'entends : Angular, React, VueJS... Et très clairement si tu te diriges vers de l'APPLICATION web, c'est aujourd'hui ce qu'il faut.

Je plussoie :)

Salut,
@Entrepreneo.fr, je vais te répondre poing par poing :D
1 ) "D'un point de vue UX c'est une totale aberration. Si l'app n'est destinée qu'à toi, pourquoi pas, sinon à ta place, je repenserai l'UX. Ce genre de chose (ouvrir X fenêtres dans une App) n'existe pas. Source de confusion et impression de bordel pour l'utilisateur."
L'app n'est pas destinée qu'a moi, environ 150 personnes l'utilisent.
D'une part, j'avais cette contrainte de multi fenêtrage, parce que, la version 1 (client lourd que j'ai ecrit en 1996) était en mode MDI.
Ouvrir X fenêtres dans une App n'existe pas ??, ha bon !!!! ?? :D

C'est la présentation de Microsoft Excel, c'est vrai que c'est une totale aberration :D
Microsoft n'y connais rien :/ .
D'ailleur, je n'ai rien inventé :
voir ici .
et ici .
Source de confusion et impression de bordel pour l'utilisateur ??
C'est pas l'avis des utilisateurs, dont certains passent s'une interface SDI à MDI, bien au contraire.
Voir plusieurs factures, plusieurs commandes enfin plusieurs documents simultanément n'a rien d'aberrant,
surtout si l'on fait du glisser/poser entre les documents.
De plus, l'environnement avec lequel travail ces utilisateurs es MDI (Windows).
2)"Sinon pour "structurer ton code", je te conseille vivement de coder comme tous les frameworks modernes, par "Web Components".
Ca règle le problème de structure, de maintenance et d'évolutivité du code.
J'ai commencer à coder cette App en 2009, et les framworks front (réact, angular et consort) n'existaient pas je crois, donc, j'ai fais avec les moyens du bord.
"à ta place, je repenserai l'UX" , merci d'avoir pensé que j'avais au moins pensé :D :D
Je n'ai pas en permanence le cerveau en bouillonement, mais il m'arrive de faire fonctionner (de temps en temps) cet organe :D
Dernier point :

"Et très clairement si tu te diriges vers de l'APPLICATION web, c'est aujourd'hui ce qu'il faut."
100% d'accord avec toi, c'est ce que je ferais.D

Pour conclure, ce que je trouve aberrant, c'est cette fermeture (j'ai pas dis d'esprit :D) et ce ton catégorique !!!!!
Ce choix fait à l'époque était argumenté par le client, il avait des fonctionnalitées qu'il ne voulait pas perdre.
Si j'avais eu ce choix, j'aurais eu plusieurs méthodes de réflection :
1 mode fénéant : SDI.
2 mode "relevage" de défi technique : MDI.
Le client a fait ce choix pour moi :D

@plus.

Pierre

PS : @Kenor : n'en met pas partout :D :D

Je suis d'accord avec un toi sur un point que tu répètes beacoup dans ton explication : "A l'époque" ;)
Je note aussi 1996. Et je comprends parfaitement la problèmatique des "vieux projets" qu'il est impossible de remettre au goût du jour "sans tout refaire à partir de zéro".

En revanche, non on ne peut pas comparer "un tableur excel" et une app web. Pour preuves, de multiples app web "modernes" naissent du même besoin : présenter des datas, un tableau de bord, du CRUD, et pourtant ... avec un UX totalement différent, moderne, beau, intuitif, "justement" pour présenter autre chose qu'un tableur... j'ai envie de dire, si l'ambition est de faire un excel bis aujourd'hui... autant utiliser excel ;)

Maintenant j'entends : la problématique est de faire survivre et évoluer un produit de 1996 (qui date de 20 ans donc). Tant que le Client est content tout va bien :) Ca répond sûrement à son besoin. Mais via un vieil UX et une interface façon années 80 :) Oui je suis radical, ou réaliste au choix :)

Au delà de ce qui semble t'avoir froissé (l'aspect UX), ma réponse était surtout sur le côté "maintenable" du code JS... et on le sait tous : accumuler du jQuery pour faire du front, c'est clairement pas ce qu'il y a de mieux aujourd'hui côté maintenabilité et scalabilité... repenser l'app à travers une API+framework front oui c'est clairement mieux. Refaire une app de 1996, c'est une contrainte et pas des moindres ? Oui totalement d'accord. Mais personne ne pouvait deviner tes contraintes client ni que ton app datais de plus de 20ans.

Si ce que tu disais était parole d'évangile... les boites feraient encore tous leurs factures, leur compta et leur envois d'email sur des interfaces comme excel ? non il y a des apps comme SalesForce qui sont nées... entre autre ;) Pour la présentation des data on aussi Beam qui fait des tableaux de bord au top, à partir de data de toute provenance... le "tableau" pour moi est juste là pour stocker des data et les présenter de façon très sommaire et peu pertinente.

Bon courage ;)

Salut,
@FactureHero.com , d'abord, en aucun cas je n'ais été froissé :D :D
Je suis quelqu'un qui accepte et me nourris la critique (malgrés que je sois parfait :D ), si elle est argumentée, ce qui n'est pas le cas.
Je m'aperçois que tu as très mal lus mon post :D
1) "Je suis d'accord avec un toi sur un point que tu répètes beacoup dans ton explication : "A l'époque" ;)
Je note aussi 1996. Et je comprends parfaitement la problèmatique des "vieux projets" qu'il est impossible de remettre au goût du jour "sans tout refaire à partir de zéro"."
J'étais quand même obligé de repartir de zéro, "(client lourd que j'ai ecrit en 1996) ", je passe quand même à un client légé, ce qui n'a rien à voir au niveau programation.
2)"Maintenant j'entend : la problématique est de faire survivre et évoluer un produit de 1996 et je ici c'est donc le cas. Tant que le Client est content tout va bien :) Ca répond sûrement à son besoin. Mais via un vieil UX et une interface façon années 80 :) Oui je suis radical, ou réaliste au choix :)"
j'utilise quotidiennement ce genre d'interface des années 80 :D :D
Pourtant, ce genre d'interface (MDI) existe encore et est remise à jour continuellement.


De toutes façons, c'est pas grave, je suis un vieux qui utilise des veilles choses :D :D.
A partir d'un certain âge, voir d'un âge certain, on ne change plus, crois en mon expérience ;) (je parle de toi là )
Je suis prêt à changer si tu argumentes correctement, pas avec des affirmations gratuites qui ne sont que ton propre avis.
Le mien n'est pas opposé mais certainement plus modéré.
Le preuve tous mes prochains projets seront écris avec VueJS en front et Slim en back.
Tu vois, malgrés mon âge certain, je change :D :D
D'ailleurs, en parlant d'UX, j'ai la mienne et celle de beaucoup de retour d'utilisateurs.
Pour info, je dévellope depuis le début des années 80, donc, je peux parler d'eXpérience.
Bon, sur ce, j'ai du taf :D :D

@plus.

Pierre

C'est certain que si tu compares un OS avec un application web ... on ne va pas s'en sortir :) Compare ce qui est comparable.
Au risque de me répéter... check les applications modernes utilisées AUJOURD'HUI par les entreprises qui ont les moyens du changement... et le multi-fenêtrage n'existe pas ... une app d'entreprise, c'est pas un windows... ou alors question de point de vue... ;)

Les web app et les mobile-app se rejoignet de plus en plus côté interface et utilisation. expériences unifiées d'une part, mais surtout expérience plus agréable... Perso une app qui ouvre pleins de fenêtre, moi je n'utilise pas :) Focus sur une fenêtre, un jeu de data et UNE action me paraît bien plus agréable. Le côté "y en a partout" oui c'est bien sur excel, oui sur un OS... mais une application de gestion... ouch :) Le mal de crâne à la fin de la journée pour les users :)

On a pu échanger les points de vue. J'admet volontiers que je suis radical côté UX, loin de tout connaître mais farouchement POUR les interface les plus light possibles, SURTOUT sur les applications professionnelles de gestion. Mais là aussi , question de point de vue :)

La tendance me semble tout de même à l'allègement visuel et à la navigation rapide et intuitive. Beaucoup de lectures et d'études intéressantes sur le sujet.

Ca me rappelle une citation d'un mec qui pondait l'UX d'interfaces de gestion pro : "C'est pas parce que c'est pour des professionnels de l'industrie que ça doit être moche et austère" :)

Blague à part, comment tu expliques que des solutions capables de gérer du très lourd (en volume de data, et en nb de fonctionnalités), parviennent à créer des interfaces SANS multi-fenêtrage, et être très prisées et demandées (SalesForce et les autres par exemple...). C'est bien qu'il y avait matière à "faire mieux" pour les utilisateurs non ???

Que ta solution convienne à ton client qui l'utilise, j'en doute pas. C'est une des forces commerciales de ces solutions : créer l'habitude :) Changer d'outil devient même "une épreuve" pour le client, même si l'outil est plus moderne.

Sinon pour tes choix de technos à suivre : très bien :) Je n'utilise pas mais je n'en pense que du bien. Slim : rapide, vueJs ça le fait.

Tu as du en voir passer des technos depuis les années 80 :) As-tu encore des collègues survivants de cette période ? :) Je dev depuis 10ans... et déjà je trouve que tout va très très vite :) Bravo.

Bonne continuation pour la suite ;)

alors je viens mettre mon grain de sel dedans la conversation et je rejoins donc l'avis de @Pierrot01, j'utilise au quotidien dynamics CRM, le CRM de Microsoft couplé à NAV ou AX les 2 gros ERP de Microsoft aussi, les tous associés à office 365. bens j'ai de l'ouverture d'Ifra, de tous les côtés et pour peux que je travaille sûr de la personnalisation et du de dessus, j'ai aux minimums 4 fenêtres ouvertes pour pouvoir interagir avec les formulaires, les ressources web ou encore les tableaus de bord.

@defy : Oui les products microsoft... pas le cas sur d'autres CRM ultra-pointus, donc question de point de vue :)

Si tu peux mettre aussi ton grain de sel sur ta propre question sur Angular sur l'autre post, ce serait cool :) Je t'ai fait 2 réponses avec un bout de code. Je ne pourrai te répondre davantage que si tu me confirmes bien ton problème ;)

Salut,
@FactureHero.com ,
Je pense que nous ne tomberons pas d'accord :D :D
Mais j'ai noté ton expression : "farouchement POUR" , opposé, fermé ????

"Le côté "y en a partout" oui c'est bien sur excel, oui sur un OS... mais une application de gestion... ouch "
Quelques écran (pour exemple) de sage online qui est, c'est bien connu, un OS très en vogue, et aussi très vendu d'ailleurs.

De plus, mes exemples antécédants n'étaient pas que des OS.

UX veux dire : Utilisateur eXperience.
C'est pas parce qu'il n'y a pas de "s" à utilisateur que ça veux dire factUrehero.com eXperience.(c'est évidement à prendre au second degrés ;) )

J'ai de très bonnes remontées d'utilisateurs qui était avant sur un CRM en mode SDI.
En aucun cas ils ne se plaignent de maux de crâne.
Arrête de penser que ton avis est l'universalité, il y a des gens autour de toi, moi, entre autre :D :D
On va pas jouer à FactureHero.comADit :D :D.

Si un jour tu as une demande de ce genre, j'espere que tu n'essayeras pas de convaincre ton client de passer au SDI, mais par contre, que tu lui feras la remarque que c'est bien plus complexe niveau développement et que cette complexité a un coût.
Bien sûr, tu utiliseras les bon framworks ;)
Fais moi le plaisir de lire mes "post" en totalité :D :D

@plus

Pierre

Mon dieu que c'est laid ! :)

Entre ce que tu me présentes là et une Interface à la SalesForce... Chacun appréciera... pour moi il n'y a pas photo. L'app web "MODERNE", n'est pas née par hasard... mais bien sur le constat qu'il y avait LARGEMENT MIEUX A FAIRE côté interface utilisateur...

Maintenant chacun est libre de penser ce qu'il/elle veut et/ou rester sur de vieux acquis qui fonctionnent "bon gré mal gré" tant que le Client n'explore pas la concurrence :)

Un seul exemple sur SalesForce suffit :

Sinon je te remercie de te soucier de mon activité :) J'en ai 3 en fait : développeur / formateur / entrepreneur
Côté dev et côté formateur, je réponds à la demande des clients, et ô sacrilège oui j'ose les conseiller :)
Côté entrepreneur, tout comme je préfère consommer des app Saas selon mes besoins, je préfère également produire de l'app Saas plutôt que d'aller chercher le client 1 par 1 au besoin ...

Le Saas, c'est une "proposition", une vision de son/ses fondateurs, et si ça convient les clients payent/mois, à l'opposé donc de créer une solution sur mesure un jour pour un client ... et la laisser vieillir 30 ans ;) Ici aussi, on pourrait parler modernité des usages qui sont nettement en train de changer... l'application de gestion en interne pour le client est de moins en moins une solution, pour de raisons, de coûts, de mobilité, d'évolutivité du produit. Ce qui arrive ici à ton client (son app qui vieillit avec lui :) ), n'arrive pas avec du Saas. Les clients de SalesForce dans 20a auront une "app moderne" dans les mains. ;)

Bonne journée :)

Sinon Pierrot, hors UX :) je te conseille vivement de te mettre à Angular par exemple :

Quand je lis tes problématiques, les réponses y sont évidentes.

• Multiples fenetres qui seraient à la fois "étanches" tout en pouvant communiquer entre elles : le web Component règle ce problème
• Des triggers partout pour mettre à jour tes fenêtes : RxJS, de base dans angular règle ton problème avec la programmation réactiv
• Globalement une telle app (ou les suivantes, j'ai bien compris : ) ) mériteraient un passage aux frameworks modernes

Ca règlerai beaucoup de tes soucis, et c'est même pour ça qu'ils sont nés :)

Salut,
"Mon dieu que c'est laid... :) "
je rejoint ton avis :D :D
Mais je n'aprécie pas beaucoup plus l'interface de salesforce :D: D

"Sinon Pierrot, hors UX :) je te conseille vivement de te mettre à Angular par exemple :"
Je supploie :D :D
Mais comme je t'ai dis, j'ai commencer à coder cette app en 2009.
Ce serai à refaire, bien évidement que je prendrais un framework front digne de cce nom :D
Mais là, tu vois, j'ai pas le budget pour tout refaire ;)
Entre php javacript et sql, y a plus de 50000 lignes de code :D
Mais pour info, mes problèmes sont réglés ;)

@plus

Pierre

Salut, C'est quoi ta solution si tous tes problemes sont réglés ?

Il avait des souci d'objects non détruits, donc de la mémoire occupée. En même temps @Pierrot01 a poussé la machine avec des centaines de fenêtre ouvertes :) Cas improbable mais bonne pratique qui permet de déceler des problèmes mémoire.

Salut
Mais comme je l'ai dit au debut du topic, j'ai une config plutôt costaude .
Core I7, 32 go Ram 510mo SDD et 3 téra HD.
Avec une config de base, les problèmes doivent arriver bien avant ;)
@plus
Pierre