Bruno Desthuilliers a écrit :
> ASM a écrit :
>> Bruno Desthuilliers a écrit :
>
> 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 ???

:-)


--
Stephane Moriaux et son (moins) vieux Mac

Bruno Desthuilliers a écrit :
> ASM a écrit :
>> Bruno Desthuilliers a écrit :
>
> 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 ???

:-)


--
Stephane Moriaux et son (moins) vieux Mac

Bruno Desthuilliers a écrit :
> ASM a écrit :
>> Bruno Desthuilliers a écrit :
>>> Guy a écrit :
>>>> Bruno Desthuilliers a écrit :
>>>>> ASM a écrit :
>>>>>
>>>>>> 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 ?



--
Stephane Moriaux et son (moins) vieux Mac

Bruno Desthuilliers a écrit :
> ASM a écrit :
>> Bruno Desthuilliers a écrit :
>>> Guy a écrit :
>>>> Bruno Desthuilliers a écrit :
>>>>> ASM a écrit :
>>>>>
>>>>>> 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 ?



--
Stephane Moriaux et son (moins) vieux Mac

ASM a écrit :
> Bruno Desthuilliers a écrit :
>>
>> 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)

Un processeur AMD 32 bits cadencé à =~ 1550 Mhz, et qui date déjà d'il y
a quelques années. Bref, plus du tout up to date, voire limite obsolète.
En d'autres termes : ma bécane est *loin* d'être une bête de course.
Plutôt un bousin vieillissant.

> 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.

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.

>>> non merci.
>>
>> Tu n'a pas l'air de comprendre.
>
> Non, tu me comprends mal : "non merci le truc *exclusif* JS"

Tu veux dire : le truc qui ne fonctionne pas sans js ? C'est une autre
question. Sur les pages d'un site public, effectivement, il est
largement préférable de faire en sorte que ça fonctionne sans. Pour une
application, c'est autre chose (et ça reste une discussion ouverte...).

>> 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.

Non - il y a aussi toutes les images, les feuilles de style etc. Et puis
le html lui-même, of course !-)

ASM a écrit :
> Bruno Desthuilliers a écrit :
>>
>> 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)

Un processeur AMD 32 bits cadencé à =~ 1550 Mhz, et qui date déjà d'il y
a quelques années. Bref, plus du tout up to date, voire limite obsolète.
En d'autres termes : ma bécane est *loin* d'être une bête de course.
Plutôt un bousin vieillissant.

> 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.

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.

>>> non merci.
>>
>> Tu n'a pas l'air de comprendre.
>
> Non, tu me comprends mal : "non merci le truc *exclusif* JS"

Tu veux dire : le truc qui ne fonctionne pas sans js ? C'est une autre
question. Sur les pages d'un site public, effectivement, il est
largement préférable de faire en sorte que ça fonctionne sans. Pour une
application, c'est autre chose (et ça reste une discussion ouverte...).

>> 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.

Non - il y a aussi toutes les images, les feuilles de style etc. Et puis
le html lui-même, of course !-)

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> Guy a écrit :
>>>>> Bruno Desthuilliers a écrit :
>>>>>> ASM a écrit :
>>>>>>
>>>>>>> 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" ...

Ai-je jamais prétendu que ça fonctionnait de manière impeccable dans
tous les contextes et sur toutes les plateformes ?

Honnêtement, quand tu vois le boulot que ça représente de développer un
composant de ce genre, et le support totalement hasardeux des divers
navigateurs tant pour js que pour le dom et les css, tu peux te dire que
l'existant relève déjà du tour de force.

>> 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 ! :-)

Oui, je vois. Un partisan du retour à l'age de pierre...

>>> 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
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 - cauchemar de maintenance et
énorme perte de temps en perspective. Encore plus si tu tiens à ce que
ton appli continue à fonctionner correctement sans javascript.

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> Guy a écrit :
>>>>> Bruno Desthuilliers a écrit :
>>>>>> ASM a écrit :
>>>>>>
>>>>>>> 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" ...

Ai-je jamais prétendu que ça fonctionnait de manière impeccable dans
tous les contextes et sur toutes les plateformes ?

Honnêtement, quand tu vois le boulot que ça représente de développer un
composant de ce genre, et le support totalement hasardeux des divers
navigateurs tant pour js que pour le dom et les css, tu peux te dire que
l'existant relève déjà du tour de force.

>> 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 ! :-)

Oui, je vois. Un partisan du retour à l'age de pierre...

>>> 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
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 - cauchemar de maintenance et
énorme perte de temps en perspective. Encore plus si tu tiens à ce que
ton appli continue à fonctionner correctement sans javascript.

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>> Bruno Desthuilliers a écrit :
>>
>> 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.

Il ne l'a jamais été AMHA.

>
>>> 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).

Ah bin c'est sûr que si tu n'a pas de clients - pas de deadline ni de
budget ni de cahier des charges ni aucune de ces contraintes - c'est un
autre problème...

>>> 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 ???
>
> :-)

Non, c'est pas drôle.

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...).

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>> Bruno Desthuilliers a écrit :
>>
>> 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.

Il ne l'a jamais été AMHA.

>
>>> 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).

Ah bin c'est sûr que si tu n'a pas de clients - pas de deadline ni de
budget ni de cahier des charges ni aucune de ces contraintes - c'est un
autre problème...

>>> 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 ???
>
> :-)

Non, c'est pas drôle.

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...).

Bruno Desthuilliers a écrit :
> ASM a écrit :
>>
>> 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 ...
Bien sûr : tous ces malheureux sont en RTC :-(

> 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...

et ce n'est rien de le dire :-)
(tous ces sites marchands qui profusionnent quasi en pure perte)

> 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, faut un peu le prévoir :-)

> Tu veux dire : le truc qui ne fonctionne pas sans js ? C'est une autre
> question.

mais ça m'interpelle.

>> 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 !-)

Non ? Comme je suis déçu ! :-)


--
Stephane Moriaux et son (moins) vieux Mac

Bruno Desthuilliers a écrit :
> ASM a écrit :
>>
>> 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 ...
Bien sûr : tous ces malheureux sont en RTC :-(

> 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...

et ce n'est rien de le dire :-)
(tous ces sites marchands qui profusionnent quasi en pure perte)

> 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, faut un peu le prévoir :-)

> Tu veux dire : le truc qui ne fonctionne pas sans js ? C'est une autre
> question.

mais ça m'interpelle.

>> 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 !-)

Non ? Comme je suis déçu ! :-)


--
Stephane Moriaux et son (moins) vieux Mac

Bruno Desthuilliers a écrit :
> ASM a écrit :
>>
>> Damned ! je me suis trahi ! :-)
>
> Oui, je vois. Un partisan du retour à l'age de pierre...

C'est mon travers.

> Alors tu n'a pas compris le "sans toucher au source HTML".

Disons que je me limite à son sous-entendu : "HTML propre".

> 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

J'imagine !
et n'en disconviens pas.




--
Stephane Moriaux et son vieux Mac

Bruno Desthuilliers a écrit :
> ASM a écrit :
>>
>> Damned ! je me suis trahi ! :-)
>
> Oui, je vois. Un partisan du retour à l'age de pierre...

C'est mon travers.

> Alors tu n'a pas compris le "sans toucher au source HTML".

Disons que je me limite à son sous-entendu : "HTML propre".

> 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

J'imagine !
et n'en disconviens pas.




--
Stephane Moriaux et son vieux Mac

Bruno Desthuilliers a écrit :
> ASM a écrit :
>> Bruno Desthuilliers a écrit :
>>> 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.

ce qui ne l'empêche pas de complexifier :-)

> 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...).

C'est une très bonne intention.

--
Stephane Moriaux et son (moins) vieux Mac

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 ? La taille supplémentaire
de l'interpréteur JavaScript pour qu'il reconnaisse XMLHttpRequest ?
La taille d'un code JavaScript à télécharger pour que l'on puisse
vraiment parler d'« Ajax » au lieu de « XMLHttpRequest » ?

Je n'ai en fait jamais compris la différence qu'il y a entre XHR et
Ajax, si ce n'est que celui-ci a un nom plus facile à retenir que
celui-là (et plus rapide à taper si on veut l'écrire en entier).

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 ? La taille supplémentaire
de l'interpréteur JavaScript pour qu'il reconnaisse XMLHttpRequest ?
La taille d'un code JavaScript à télécharger pour que l'on puisse
vraiment parler d'« Ajax » au lieu de « XMLHttpRequest » ?

Je n'ai en fait jamais compris la différence qu'il y a entre XHR et
Ajax, si ce n'est que celui-ci a un nom plus facile à retenir que
celui-là (et plus rapide à taper si on veut l'écrire en entier).

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>>
>>> 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,

Pas assez d'éxpérience du G4 pour te dire

> ou bien est-ce au
> niveau d'un G3/266 ?

S'il te plait... J'ai dit "bousin vieillissant", pas "ossement de
dinosaure" !->

>>> 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 ...

Ca par contre je connais pas.

>> 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.

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. Même si le poids total de ce code reste
inférieur à celui de la biblio + le code spécifique appelant la biblio,
ça n'empêche que tu a tout ce code à écrire *et* à maintenir. Au prix de
la journée de développeur, ce n'est pas économiquement envisageable.
Particulièrement quand tes clients sont assez informés pour connaître
eux-mêmes ces bibliothèques, ce qui est le cas dès que tu a un service
informatique en face de toi.

>>> 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).

Il y a des andouilles partout, suffit de lire le daily WTF pour s'en
convaincre.

> 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...

>> 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.

personnellement, j'ai plutôt des templates distinct pour tous les
composants "ajaxifiables", et un template principal qui rappelle ces
composant, directement au chargement de la page complète, via ajax (si
js activé) après.

> 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,

Non, mais ça évite quand même de recharger toute la page quand on veut
juste mettre à jour un petit fragment.

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>>
>>> 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,

Pas assez d'éxpérience du G4 pour te dire

> ou bien est-ce au
> niveau d'un G3/266 ?

S'il te plait... J'ai dit "bousin vieillissant", pas "ossement de
dinosaure" !->

>>> 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 ...

Ca par contre je connais pas.

>> 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.

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. Même si le poids total de ce code reste
inférieur à celui de la biblio + le code spécifique appelant la biblio,
ça n'empêche que tu a tout ce code à écrire *et* à maintenir. Au prix de
la journée de développeur, ce n'est pas économiquement envisageable.
Particulièrement quand tes clients sont assez informés pour connaître
eux-mêmes ces bibliothèques, ce qui est le cas dès que tu a un service
informatique en face de toi.

>>> 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).

Il y a des andouilles partout, suffit de lire le daily WTF pour s'en
convaincre.

> 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...

>> 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.

personnellement, j'ai plutôt des templates distinct pour tous les
composants "ajaxifiables", et un template principal qui rappelle ces
composant, directement au chargement de la page complète, via ajax (si
js activé) après.

> 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,

Non, mais ça évite quand même de recharger toute la page quand on veut
juste mettre à jour un petit fragment.

Bruno Desthuilliers a écrit :
> ASM a écrit :
>> Bruno Desthuilliers a écrit :
>>> ASM a écrit :
>>>>
>> Et sur PC AMD K6II/500 Win95 ...
>
> Ca par contre je connais pas.

Ben moi oui et je t'assure que ça vaut le jus !
Vu que le K6II est incompatible avec Win95 ... !
(les grandes joies du DOS + patches étoussa) :-)

>> 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.

On ne doit certainement pas parler de la même chose, je parle de
l'include à la volée via JS de documents ou fragments (documents qui
peuvent être éventuellement triturés à la requette par le serveur)

Le XRH se limite à 2, 3 fonctions réutilisables.

>> 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...

je l'ai dis : je sais plus quoi (je dois faire un blocage là).

>> 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.

Bien sûr.
(ça a été inventé pour ça me semble-ce)

C'est assez génial ce qu'on arrive à en faire (pas légèrement !)
et j'ai été absolument bluffé par ce truc :
http://orangoo.com/labs/GoogieSpell/

--
Stephane Moriaux et son (moins) vieux Mac