Quand tu développes une application (par opposition à une simple page
web), tu a vite fait - en tous cas si tu codes tout à la mano - de
dépasser les 25ko,
Vu sous cet angle : OK.Prototype, tout un tas de monde s'en sert, donc normalement il
devrait être en cache,
ce serait l'idéal, non ?
Non.
Pourquoi ?
(hors incongruité de la ressource en un lieu non maitrisé)Je m'en doute bien et ça va bien dans mon sens : charger je ne sais
combien de ko de biblis pour ... finalement ... zapper la page qui
daigne enfin s'afficher ...
Avec une machine qui n'a rien d'une bête de course (athlon XP1800) et
une connection adsl minimum, c'est tout à fait indolore.
Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
mais je suis en ADSL 512
Tu as un peu raison, j'ai l'impression que dans le cas de JS lourds (2 à
300ko) je n'ai pas plus de lenteur que pour recevoir une page de 30 ko
toute mouillée en RTC.
Et c'est donc relativement indolore.
C'est juste une question de principe : je connais certains qui n'ont pas
l'ADSL.
En outre les JS n'ont pas été chargés pour rien, probablement ils vont
agiter un tas de choses comme de faire charger d'autres sources (ce qui
ne va pas accélérer l'affichage final).
non merci.
Tu n'a pas l'air de comprendre.
Non, tu me comprends mal : "non merci le truc *exclusif* JS"
Dans le cas le plus courant, la ressource "/url/de/protoype.js" sera
la même pour tout un domaine.
oui, mais j'aimerais n'avoir à ne la charger qu'après l'accueil et même
qu'après le menu. (ce serait sympa pour celui qui débarque et s'aperçoit
qu'il n'a rien à faire ici).
Car en général, la bibli n'est pas seule requise.
Quand tu développes une application (par opposition à une simple page
web), tu a vite fait - en tous cas si tu codes tout à la mano - de
dépasser les 25ko,
Vu sous cet angle : OK.
Prototype, tout un tas de monde s'en sert, donc normalement il
devrait être en cache,
ce serait l'idéal, non ?
Non.
Pourquoi ?
(hors incongruité de la ressource en un lieu non maitrisé)
Je m'en doute bien et ça va bien dans mon sens : charger je ne sais
combien de ko de biblis pour ... finalement ... zapper la page qui
daigne enfin s'afficher ...
Avec une machine qui n'a rien d'une bête de course (athlon XP1800) et
une connection adsl minimum, c'est tout à fait indolore.
Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
mais je suis en ADSL 512
Tu as un peu raison, j'ai l'impression que dans le cas de JS lourds (2 à
300ko) je n'ai pas plus de lenteur que pour recevoir une page de 30 ko
toute mouillée en RTC.
Et c'est donc relativement indolore.
C'est juste une question de principe : je connais certains qui n'ont pas
l'ADSL.
En outre les JS n'ont pas été chargés pour rien, probablement ils vont
agiter un tas de choses comme de faire charger d'autres sources (ce qui
ne va pas accélérer l'affichage final).
non merci.
Tu n'a pas l'air de comprendre.
Non, tu me comprends mal : "non merci le truc *exclusif* JS"
Dans le cas le plus courant, la ressource "/url/de/protoype.js" sera
la même pour tout un domaine.
oui, mais j'aimerais n'avoir à ne la charger qu'après l'accueil et même
qu'après le menu. (ce serait sympa pour celui qui débarque et s'aperçoit
qu'il n'a rien à faire ici).
Car en général, la bibli n'est pas seule requise.
Quand tu développes une application (par opposition à une simple page
web), tu a vite fait - en tous cas si tu codes tout à la mano - de
dépasser les 25ko,
Vu sous cet angle : OK.Prototype, tout un tas de monde s'en sert, donc normalement il
devrait être en cache,
ce serait l'idéal, non ?
Non.
Pourquoi ?
(hors incongruité de la ressource en un lieu non maitrisé)Je m'en doute bien et ça va bien dans mon sens : charger je ne sais
combien de ko de biblis pour ... finalement ... zapper la page qui
daigne enfin s'afficher ...
Avec une machine qui n'a rien d'une bête de course (athlon XP1800) et
une connection adsl minimum, c'est tout à fait indolore.
Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
mais je suis en ADSL 512
Tu as un peu raison, j'ai l'impression que dans le cas de JS lourds (2 à
300ko) je n'ai pas plus de lenteur que pour recevoir une page de 30 ko
toute mouillée en RTC.
Et c'est donc relativement indolore.
C'est juste une question de principe : je connais certains qui n'ont pas
l'ADSL.
En outre les JS n'ont pas été chargés pour rien, probablement ils vont
agiter un tas de choses comme de faire charger d'autres sources (ce qui
ne va pas accélérer l'affichage final).
non merci.
Tu n'a pas l'air de comprendre.
Non, tu me comprends mal : "non merci le truc *exclusif* JS"
Dans le cas le plus courant, la ressource "/url/de/protoype.js" sera
la même pour tout un domaine.
oui, mais j'aimerais n'avoir à ne la charger qu'après l'accueil et même
qu'après le menu. (ce serait sympa pour celui qui débarque et s'aperçoit
qu'il n'a rien à faire ici).
Car en général, la bibli n'est pas seule requise.
Heu ... si on n'y comprend pas trop en JS, je me demande comment
on va se dépatouiller d'usines à gaz ...
[...]Mais quelle est la raison qui justifie, dans une page formulaire,
l'ajout de code HTML à la suite d'un textarea ?
Par exemple, transformer un textarea en éditeur wyswyg sans toucher
au source HTML ?
Ha oui ! le truc z'indispensable dans un formulaire ! :-)
(qui, quoiqu'on fasse, marchotera +/-)
Outre le fait que certains de ces éditeurs fonctionnent assez
correctement,
Ha ! tu l'admets ! "assez" ...
j'aimerais te signaler qu'en ce qui me concerne j'ai des clients qui
paient assez cher pour imposer l'emploi de ce genre de choses - alors
ton avis sur le côté indispensable ou non de la chose, si tu veux,
c'est un peu HS. A ce jeu là, ni JS ni les CMS n'ont rien
d'indispensable.
Damned ! je me suis trahi ! :-)
Nota :
je ne vois pas en quoi l'usage d'une bibli permet mieux que du code
maison de faire du html propre ?
Nota : je ne vois pas le rapport entre ton 'nota' et le post auquel tu
réponds.
Nota : il y a longtemps qu'on n'est plus en train de répondre au post
initial
Pour info : je réponds àPar exemple, transformer un textarea en éditeur wyswyg sans toucher
au source HTML ?
Alors tu n'a pas compris le "sans toucher au source HTML". Quand tu dois
Heu ... si on n'y comprend pas trop en JS, je me demande comment
on va se dépatouiller d'usines à gaz ...
[...]
Mais quelle est la raison qui justifie, dans une page formulaire,
l'ajout de code HTML à la suite d'un textarea ?
Par exemple, transformer un textarea en éditeur wyswyg sans toucher
au source HTML ?
Ha oui ! le truc z'indispensable dans un formulaire ! :-)
(qui, quoiqu'on fasse, marchotera +/-)
Outre le fait que certains de ces éditeurs fonctionnent assez
correctement,
Ha ! tu l'admets ! "assez" ...
j'aimerais te signaler qu'en ce qui me concerne j'ai des clients qui
paient assez cher pour imposer l'emploi de ce genre de choses - alors
ton avis sur le côté indispensable ou non de la chose, si tu veux,
c'est un peu HS. A ce jeu là, ni JS ni les CMS n'ont rien
d'indispensable.
Damned ! je me suis trahi ! :-)
Nota :
je ne vois pas en quoi l'usage d'une bibli permet mieux que du code
maison de faire du html propre ?
Nota : je ne vois pas le rapport entre ton 'nota' et le post auquel tu
réponds.
Nota : il y a longtemps qu'on n'est plus en train de répondre au post
initial
Pour info : je réponds à
Par exemple, transformer un textarea en éditeur wyswyg sans toucher
au source HTML ?
Alors tu n'a pas compris le "sans toucher au source HTML". Quand tu dois
Heu ... si on n'y comprend pas trop en JS, je me demande comment
on va se dépatouiller d'usines à gaz ...
[...]Mais quelle est la raison qui justifie, dans une page formulaire,
l'ajout de code HTML à la suite d'un textarea ?
Par exemple, transformer un textarea en éditeur wyswyg sans toucher
au source HTML ?
Ha oui ! le truc z'indispensable dans un formulaire ! :-)
(qui, quoiqu'on fasse, marchotera +/-)
Outre le fait que certains de ces éditeurs fonctionnent assez
correctement,
Ha ! tu l'admets ! "assez" ...
j'aimerais te signaler qu'en ce qui me concerne j'ai des clients qui
paient assez cher pour imposer l'emploi de ce genre de choses - alors
ton avis sur le côté indispensable ou non de la chose, si tu veux,
c'est un peu HS. A ce jeu là, ni JS ni les CMS n'ont rien
d'indispensable.
Damned ! je me suis trahi ! :-)
Nota :
je ne vois pas en quoi l'usage d'une bibli permet mieux que du code
maison de faire du html propre ?
Nota : je ne vois pas le rapport entre ton 'nota' et le post auquel tu
réponds.
Nota : il y a longtemps qu'on n'est plus en train de répondre au post
initial
Pour info : je réponds àPar exemple, transformer un textarea en éditeur wyswyg sans toucher
au source HTML ?
Alors tu n'a pas compris le "sans toucher au source HTML". Quand tu dois
ma préférence va pour le moment à prototype (entre autres parce que
c'est la plus couramment utilisée, ce qui m'évite de devoir en
apprendre une demi-douzaines par ailleurs sensiblement équivalentes en
termes de qualité et de fonctionnalité).
vu.Qui a dit que le questionneur était "développeur" ?
(au sens où tu sembles l'entendre : professionnel)
Le sens où je l'entends, c'est "compétent".
Oui, bon, on est d'accord sur le sens général.javascript est un langage de programmation, c'est donc un outil pour
développeur.
...ce n'est certainement pas le langage le plus accessible à un débutant.
En tous cas il semble l'être de moins en moins.
Oui et non, tout dépend du niveau d'exigences final du site.
"Ça marche chez moi, c'est OK" ou "Pas de retour négatif"
Le "niveau d'exigeance final" du client,
Je n'ai pas parlé de client(s).
et j'espère qu'on leur en laisse le moyen (temps de production).
Qu'on nous "laisse le temps" ? Tu rêves, là ou quoi ? Tu veux couler
la boite ???
:-)
ma préférence va pour le moment à prototype (entre autres parce que
c'est la plus couramment utilisée, ce qui m'évite de devoir en
apprendre une demi-douzaines par ailleurs sensiblement équivalentes en
termes de qualité et de fonctionnalité).
vu.
Qui a dit que le questionneur était "développeur" ?
(au sens où tu sembles l'entendre : professionnel)
Le sens où je l'entends, c'est "compétent".
Oui, bon, on est d'accord sur le sens général.
javascript est un langage de programmation, c'est donc un outil pour
développeur.
...
ce n'est certainement pas le langage le plus accessible à un débutant.
En tous cas il semble l'être de moins en moins.
Oui et non, tout dépend du niveau d'exigences final du site.
"Ça marche chez moi, c'est OK" ou "Pas de retour négatif"
Le "niveau d'exigeance final" du client,
Je n'ai pas parlé de client(s).
et j'espère qu'on leur en laisse le moyen (temps de production).
Qu'on nous "laisse le temps" ? Tu rêves, là ou quoi ? Tu veux couler
la boite ???
:-)
ma préférence va pour le moment à prototype (entre autres parce que
c'est la plus couramment utilisée, ce qui m'évite de devoir en
apprendre une demi-douzaines par ailleurs sensiblement équivalentes en
termes de qualité et de fonctionnalité).
vu.Qui a dit que le questionneur était "développeur" ?
(au sens où tu sembles l'entendre : professionnel)
Le sens où je l'entends, c'est "compétent".
Oui, bon, on est d'accord sur le sens général.javascript est un langage de programmation, c'est donc un outil pour
développeur.
...ce n'est certainement pas le langage le plus accessible à un débutant.
En tous cas il semble l'être de moins en moins.
Oui et non, tout dépend du niveau d'exigences final du site.
"Ça marche chez moi, c'est OK" ou "Pas de retour négatif"
Le "niveau d'exigeance final" du client,
Je n'ai pas parlé de client(s).
et j'espère qu'on leur en laisse le moyen (temps de production).
Qu'on nous "laisse le temps" ? Tu rêves, là ou quoi ? Tu veux couler
la boite ???
:-)
Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
Un processeur AMD 32 bits cadencé à =~ 1550 Mhz,
C'est juste une question de principe : je connais certains qui n'ont
pas l'ADSL.
J'en connais aussi qui ont encore un vieux mac sous Os8 ou Os9, avec IE5
mac.
Je suis d'accord avec toi sur le fait que la généralisation de l'adsl
n'est pas une raison pour charger la mule, mais sur pas mal de sites, il
serait possible de gagner pas mal de poids (et de traitement côté
navigateur) sur d'autres éléments, à moindre coût...
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
En outre les JS n'ont pas été chargés pour rien, probablement ils vont
agiter un tas de choses comme de faire charger d'autres sources (ce
qui ne va pas accélérer l'affichage final).
Ah bon ?
Tu sais, en général, quand on utilise ajax pour "charger d'autres
sources", on le fait *après* que la page ait été chargée.
Tu veux dire : le truc qui ne fonctionne pas sans js ? C'est une autre
question.
Car en général, la bibli n'est pas seule requise.
Non - il y a aussi toutes les images, les feuilles de style etc. Et puis
le html lui-même, of course !-)
Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
Un processeur AMD 32 bits cadencé à =~ 1550 Mhz,
C'est juste une question de principe : je connais certains qui n'ont
pas l'ADSL.
J'en connais aussi qui ont encore un vieux mac sous Os8 ou Os9, avec IE5
mac.
Je suis d'accord avec toi sur le fait que la généralisation de l'adsl
n'est pas une raison pour charger la mule, mais sur pas mal de sites, il
serait possible de gagner pas mal de poids (et de traitement côté
navigateur) sur d'autres éléments, à moindre coût...
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
En outre les JS n'ont pas été chargés pour rien, probablement ils vont
agiter un tas de choses comme de faire charger d'autres sources (ce
qui ne va pas accélérer l'affichage final).
Ah bon ?
Tu sais, en général, quand on utilise ajax pour "charger d'autres
sources", on le fait *après* que la page ait été chargée.
Tu veux dire : le truc qui ne fonctionne pas sans js ? C'est une autre
question.
Car en général, la bibli n'est pas seule requise.
Non - il y a aussi toutes les images, les feuilles de style etc. Et puis
le html lui-même, of course !-)
Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
Un processeur AMD 32 bits cadencé à =~ 1550 Mhz,
C'est juste une question de principe : je connais certains qui n'ont
pas l'ADSL.
J'en connais aussi qui ont encore un vieux mac sous Os8 ou Os9, avec IE5
mac.
Je suis d'accord avec toi sur le fait que la généralisation de l'adsl
n'est pas une raison pour charger la mule, mais sur pas mal de sites, il
serait possible de gagner pas mal de poids (et de traitement côté
navigateur) sur d'autres éléments, à moindre coût...
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
En outre les JS n'ont pas été chargés pour rien, probablement ils vont
agiter un tas de choses comme de faire charger d'autres sources (ce
qui ne va pas accélérer l'affichage final).
Ah bon ?
Tu sais, en général, quand on utilise ajax pour "charger d'autres
sources", on le fait *après* que la page ait été chargée.
Tu veux dire : le truc qui ne fonctionne pas sans js ? C'est une autre
question.
Car en général, la bibli n'est pas seule requise.
Non - il y a aussi toutes les images, les feuilles de style etc. Et puis
le html lui-même, of course !-)
Damned ! je me suis trahi ! :-)
Oui, je vois. Un partisan du retour à l'age de pierre...
Alors tu n'a pas compris le "sans toucher au source HTML".
Quand tu dois
intégrer un composant genre éditeur wyswig dans un CMS (ou autre appli
un tant soit peu complexe), tu ne veux pas avoir à retoucher à la main
tout les endoits où il y a un textarea
Damned ! je me suis trahi ! :-)
Oui, je vois. Un partisan du retour à l'age de pierre...
Alors tu n'a pas compris le "sans toucher au source HTML".
Quand tu dois
intégrer un composant genre éditeur wyswig dans un CMS (ou autre appli
un tant soit peu complexe), tu ne veux pas avoir à retoucher à la main
tout les endoits où il y a un textarea
Damned ! je me suis trahi ! :-)
Oui, je vois. Un partisan du retour à l'age de pierre...
Alors tu n'a pas compris le "sans toucher au source HTML".
Quand tu dois
intégrer un composant genre éditeur wyswig dans un CMS (ou autre appli
un tant soit peu complexe), tu ne veux pas avoir à retoucher à la main
tout les endoits où il y a un textarea
ce n'est certainement pas le langage le plus accessible à un débutant.
En tous cas il semble l'être de moins en moins.
Il ne l'a jamais été AMHA.
Ceci étant, même si j'avais du temps devant moi, je ne l'utiliserais pas
à coder à la main tout le boilerplate qu'une bonne bibliothèque peut
prendre en charge pour moi - je me préocupperais plutôt de contribuer à
améliorer cette bibliothèque (par exemple pour la rendre modulaire...).
ce n'est certainement pas le langage le plus accessible à un débutant.
En tous cas il semble l'être de moins en moins.
Il ne l'a jamais été AMHA.
Ceci étant, même si j'avais du temps devant moi, je ne l'utiliserais pas
à coder à la main tout le boilerplate qu'une bonne bibliothèque peut
prendre en charge pour moi - je me préocupperais plutôt de contribuer à
améliorer cette bibliothèque (par exemple pour la rendre modulaire...).
ce n'est certainement pas le langage le plus accessible à un débutant.
En tous cas il semble l'être de moins en moins.
Il ne l'a jamais été AMHA.
Ceci étant, même si j'avais du temps devant moi, je ne l'utiliserais pas
à coder à la main tout le boilerplate qu'une bonne bibliothèque peut
prendre en charge pour moi - je me préocupperais plutôt de contribuer à
améliorer cette bibliothèque (par exemple pour la rendre modulaire...).
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
Un processeur AMD 32 bits cadencé à =~ 1550 Mhz,
ha ben tu m'aurais dit un AMD32/1550 j'aurais compris :-)
Ça doit être aussi bien sinon mieux qu'un G4/400,
ou bien est-ce au
niveau d'un G3/266 ?
C'est juste une question de principe : je connais certains qui n'ont
pas l'ADSL.
J'en connais aussi qui ont encore un vieux mac sous Os8 ou Os9, avec
IE5 mac.
oui, aussi.
Et sur PC AMD K6II/500 Win95 ...
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
En outre les JS n'ont pas été chargés pour rien, probablement ils
vont agiter un tas de choses comme de faire charger d'autres sources
(ce qui ne va pas accélérer l'affichage final).
Ah bon ?
Il y en a qui font écrire des pages complètes via JS (y compris les
insertions d'images, vidéos, étoussa).
Coldfusion ? ou je ne sais plus trop quoi ni lesquels (prototype?).
Tu sais, en général, quand on utilise ajax pour "charger d'autres
sources", on le fait *après* que la page ait été chargée.
... ça dépend ... on peut avoir le skin/mise-en-page en "normal" et tout
le(s) contenu(s) en Ajax.
mais ce n'est pas grave : une roue de secours a été habilement prévue :-)
mais le poids de la page d'entrée n'est pas réduit totomatiquement parce
qu'on ajaxionne,
Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
Un processeur AMD 32 bits cadencé à =~ 1550 Mhz,
ha ben tu m'aurais dit un AMD32/1550 j'aurais compris :-)
Ça doit être aussi bien sinon mieux qu'un G4/400,
ou bien est-ce au
niveau d'un G3/266 ?
C'est juste une question de principe : je connais certains qui n'ont
pas l'ADSL.
J'en connais aussi qui ont encore un vieux mac sous Os8 ou Os9, avec
IE5 mac.
oui, aussi.
Et sur PC AMD K6II/500 Win95 ...
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
En outre les JS n'ont pas été chargés pour rien, probablement ils
vont agiter un tas de choses comme de faire charger d'autres sources
(ce qui ne va pas accélérer l'affichage final).
Ah bon ?
Il y en a qui font écrire des pages complètes via JS (y compris les
insertions d'images, vidéos, étoussa).
Coldfusion ? ou je ne sais plus trop quoi ni lesquels (prototype?).
Tu sais, en général, quand on utilise ajax pour "charger d'autres
sources", on le fait *après* que la page ait été chargée.
... ça dépend ... on peut avoir le skin/mise-en-page en "normal" et tout
le(s) contenu(s) en Ajax.
mais ce n'est pas grave : une roue de secours a été habilement prévue :-)
mais le poids de la page d'entrée n'est pas réduit totomatiquement parce
qu'on ajaxionne,
Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
Un processeur AMD 32 bits cadencé à =~ 1550 Mhz,
ha ben tu m'aurais dit un AMD32/1550 j'aurais compris :-)
Ça doit être aussi bien sinon mieux qu'un G4/400,
ou bien est-ce au
niveau d'un G3/266 ?
C'est juste une question de principe : je connais certains qui n'ont
pas l'ADSL.
J'en connais aussi qui ont encore un vieux mac sous Os8 ou Os9, avec
IE5 mac.
oui, aussi.
Et sur PC AMD K6II/500 Win95 ...
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
En outre les JS n'ont pas été chargés pour rien, probablement ils
vont agiter un tas de choses comme de faire charger d'autres sources
(ce qui ne va pas accélérer l'affichage final).
Ah bon ?
Il y en a qui font écrire des pages complètes via JS (y compris les
insertions d'images, vidéos, étoussa).
Coldfusion ? ou je ne sais plus trop quoi ni lesquels (prototype?).
Tu sais, en général, quand on utilise ajax pour "charger d'autres
sources", on le fait *après* que la page ait été chargée.
... ça dépend ... on peut avoir le skin/mise-en-page en "normal" et tout
le(s) contenu(s) en Ajax.
mais ce n'est pas grave : une roue de secours a été habilement prévue :-)
mais le poids de la page d'entrée n'est pas réduit totomatiquement parce
qu'on ajaxionne,
Et sur PC AMD K6II/500 Win95 ...
Ca par contre je connais pas.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
Si tu additionne le code nécessaire pour chaque requête plus le code
pour traiter le résultat de chaque requête, t'a vite fait d'avoir un
paquet de lignes de code.
Coldfusion ? ou je ne sais plus trop quoi ni lesquels (prototype?).
Coldfusion est une techno serveur propriétaire... je ne vois pas le
rapport avec js...
le poids de la page d'entrée n'est pas réduit totomatiquement
parce qu'on ajaxionne,
Non, mais ça évite quand même de recharger toute la page quand on veut
juste mettre à jour un petit fragment.
Et sur PC AMD K6II/500 Win95 ...
Ca par contre je connais pas.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
Si tu additionne le code nécessaire pour chaque requête plus le code
pour traiter le résultat de chaque requête, t'a vite fait d'avoir un
paquet de lignes de code.
Coldfusion ? ou je ne sais plus trop quoi ni lesquels (prototype?).
Coldfusion est une techno serveur propriétaire... je ne vois pas le
rapport avec js...
le poids de la page d'entrée n'est pas réduit totomatiquement
parce qu'on ajaxionne,
Non, mais ça évite quand même de recharger toute la page quand on veut
juste mettre à jour un petit fragment.
Et sur PC AMD K6II/500 Win95 ...
Ca par contre je connais pas.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
Si tu additionne le code nécessaire pour chaque requête plus le code
pour traiter le résultat de chaque requête, t'a vite fait d'avoir un
paquet de lignes de code.
Coldfusion ? ou je ne sais plus trop quoi ni lesquels (prototype?).
Coldfusion est une techno serveur propriétaire... je ne vois pas le
rapport avec js...
le poids de la page d'entrée n'est pas réduit totomatiquement
parce qu'on ajaxionne,
Non, mais ça évite quand même de recharger toute la page quand on veut
juste mettre à jour un petit fragment.
Le 25/06/2007 13:49, ASM répondait à Bruno Desthuilliers :D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
C'est quoi, les 10 ou 20 ko dont tu parles ?
Je n'ai en fait jamais compris la différence qu'il y a entre XHR et
Ajax,
Le 25/06/2007 13:49, ASM répondait à Bruno Desthuilliers :
D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
C'est quoi, les 10 ou 20 ko dont tu parles ?
Je n'ai en fait jamais compris la différence qu'il y a entre XHR et
Ajax,
Le 25/06/2007 13:49, ASM répondait à Bruno Desthuilliers :D'autre part, le recours à Ajax permet d'éviter des rechargements
*complets* de la page, et donc, une fois la bibliothèque montée en
cache, un net gain de perfs *particulièrement* pour ceux qui ont un
faible débit.
Oui.
Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
... me semble-ce.
C'est quoi, les 10 ou 20 ko dont tu parles ?
Je n'ai en fait jamais compris la différence qu'il y a entre XHR et
Ajax,
