---

Hej NG,

Jeg har efter adskillelige forsøg prøvet at bruge
document.getElementsByClassName med de udvidelser jeg finder rundt omkring
heriblandt http://javascript.about.com/library/bldom08.htm som bare
gennemløber alle tags og tjekker om de har den givne klasse dog uden held.
Hvordan får man det til at virke?

Mvh Anders

---

Anders Mikkelsen skrev:
> Hej NG,
>
> Jeg har efter adskillelige forsøg prøvet at bruge
> document.getElementsByClassName med de udvidelser jeg finder rundt
> omkring heriblandt http://javascript.about.com/library/bldom08.htm som
> bare gennemløber alle tags og tjekker om de har den givne klasse dog
> uden held. Hvordan får man det til at virke?

Jeg havde for nogen tid siden brug for det samme til
artiklen
http://webdesign101.dk/javascript/eksempel_3.php
og fandt noget kode i Googles kodebibliotek,
som jeg kunne bruge. Link til denne kode
i artiklen.
--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

"Jørgen Farum Jensen" <jfjenzen@yahoo.dk> skrev i meddelelsen
news:4b87e02b$0$36581$edfadb0f@dtext01.news.tele.dk...
> Anders Mikkelsen skrev:
>> Hej NG,
>>
>> Jeg har efter adskillelige forsøg prøvet at bruge
>> document.getElementsByClassName med de udvidelser jeg finder rundt
>> omkring heriblandt http://javascript.about.com/library/bldom08.htm som
>> bare gennemløber alle tags og tjekker om de har den givne klasse dog uden
>> held. Hvordan får man det til at virke?
>
> Jeg havde for nogen tid siden brug for det samme til
> artiklen
> http://webdesign101.dk/javascript/eksempel_3.php
> og fandt noget kode i Googles kodebibliotek,
> som jeg kunne bruge. Link til denne kode
> i artiklen.
> --

Tror du har vedhæftet det forkert link thi linket her fører til noget med at
sortere efter dato..

Mvh Anders..

---

Anders Mikkelsen skrev:

>>> Jeg har efter adskillelige forsøg prøvet at bruge
>>> document.getElementsByClassName med de udvidelser jeg finder rundt
>>> omkring heriblandt http://javascript.about.com/library/bldom08.htm
>>> som bare gennemløber alle tags og tjekker om de har den givne klasse
>>> dog uden held. Hvordan får man det til at virke?
>>
>> Jeg havde for nogen tid siden brug for det samme til
>> artiklen
>> http://webdesign101.dk/javascript/eksempel_3.php
>> og fandt noget kode i Googles kodebibliotek,
>> som jeg kunne bruge. Link til denne kode
>> i artiklen.
>> --
>
> Tror du har vedhæftet det forkert link thi linket her fører til noget
> med at sortere efter dato..

Linket er rigtig nok og artiklen indeholder et
svar på dit spørgsmål, nemlig hvordan kan jeg
lave et array som
var newsArray = getElementsByClassName("note");
når browseren nu ikke understøtter
getElementByClassName.

At bruger det til nogle datobestemte ting har
vel ikke noget med sagen at gøre? Eller har
jeg helt misforstået dit spørgsmål?
--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Anders Mikkelsen:
> Hej NG,
>
> Jeg har efter adskillelige forsøg prøvet at bruge
> document.getElementsByClassName med de udvidelser jeg finder rundt omkring
> heriblandt http://javascript.about.com/library/bldom08.htm som bare
> gennemløber alle tags og tjekker om de har den givne klasse dog uden held.
> Hvordan får man det til at virke?
>
> Mvh Anders

Den efterspurgte funktion findes i FF - ved ikke med de andre...
(Og den er ikke som skrevet står en javascript funktion, men et
funktion i objekterne i DOM - men det er måske en gammel artikel, der
gives ingen dato.)
Ud over det, forstår jeg ikke spørgsmålet.
Der findes vist ingen andre muligheder, end at gennemgå alle
elementerne, hvis man vil finde elementer med en given egenskab, og i
DOM (eller der på anden vis) ikke allerede findes funktioner til det.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

"Birger Sørensen" <sdc@bbsorensen.com> skrev i meddelelsen
news:4b87fa64$0$286$14726298@news.sunsite.dk...
> Anders Mikkelsen:
>> Hej NG,
>>
>> Jeg har efter adskillelige forsøg prøvet at bruge
>> document.getElementsByClassName med de udvidelser jeg finder rundt
>> omkring heriblandt http://javascript.about.com/library/bldom08.htm som
>> bare gennemløber alle tags og tjekker om de har den givne klasse dog uden
>> held. Hvordan får man det til at virke?
>>
>> Mvh Anders
>
> Den efterspurgte funktion findes i FF - ved ikke med de andre...
> (Og den er ikke som skrevet står en javascript funktion, men et funktion i
> objekterne i DOM - men det er måske en gammel artikel, der gives ingen
> dato.)

Ja den findes i FF, men problembarnet, IE, har den ikke..

> Ud over det, forstår jeg ikke spørgsmålet.
> Der findes vist ingen andre muligheder, end at gennemgå alle elementerne,
> hvis man vil finde elementer med en given egenskab, og i DOM (eller der på
> anden vis) ikke allerede findes funktioner til det.
>
> Birger


Jeg tænker på en funktion i retning af getElementsByTag hvor man jo kan
finde alle elementer med et givent tag. I stedet for tags vil jeg så finde
alle elementer med en given klasse..

---

Anders Mikkelsen kom med følgende:
>
> "Birger Sørensen" <sdc@bbsorensen.com> skrev i meddelelsen
> news:4b87fa64$0$286$14726298@news.sunsite.dk...
>> Anders Mikkelsen:
>>> Hej NG,
>>>
>>> Jeg har efter adskillelige forsøg prøvet at bruge
>>> document.getElementsByClassName med de udvidelser jeg finder rundt omkring
>>> heriblandt http://javascript.about.com/library/bldom08.htm som bare
>>> gennemløber alle tags og tjekker om de har den givne klasse dog uden held.
>>> Hvordan får man det til at virke?
>>>
>>> Mvh Anders
>>
>> Den efterspurgte funktion findes i FF - ved ikke med de andre...
>> (Og den er ikke som skrevet står en javascript funktion, men et funktion i
>> objekterne i DOM - men det er måske en gammel artikel, der gives ingen
>> dato.)
>
> Ja den findes i FF, men problembarnet, IE, har den ikke..
>
>> Ud over det, forstår jeg ikke spørgsmålet.
>> Der findes vist ingen andre muligheder, end at gennemgå alle elementerne,
>> hvis man vil finde elementer med en given egenskab, og i DOM (eller der på
>> anden vis) ikke allerede findes funktioner til det.
>>
>> Birger
>
>
> Jeg tænker på en funktion i retning af getElementsByTag hvor man jo kan finde
> alle elementer med et givent tag. I stedet for tags vil jeg så finde alle
> elementer med en given klasse..

Så meget forstod jeg.
Og der er en opskrift på hvordan man gør i det link du selv postede.
Hvad er det du ikke kan finde ud af, eller hvad er det der går galt?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Anders Mikkelsen wrote:

> Jeg har efter adskillelige forsøg prøvet at bruge
> document.getElementsByClassName med de udvidelser jeg finder rundt
> omkring heriblandt http://javascript.about.com/library/bldom08.htm som
> bare gennemløber alle tags og tjekker om de har den givne klasse dog
> uden held. Hvordan får man det til at virke?

Jeg kender godt det link (har selv brugt det). Hvad mener du med at du
ikke kan få den til at virke?

Du skriver bare fx : els = document.getElementsByClassName("myclass") og
får så et array med de matchende elementer.

Du kan se flere implementeringer her: http://ejohn.org/blog/tags/xpath

Og apropos John Resig, så kunne du overveje jQuery. Hvis
getElementsByClassName er det eneste du har brug for overhovedet, er det
måske overkill, men hold da op hvor bliver det hele meget lettere når
man bruger jQuery. Ikke mindst hvad angår browserkompatibitet.

Fordelen med jQuery er også at du bruger en css-lignende syntax til at
finde dine elementer, fx efter classname. Lad os sige du vil finde alle
TD'er med klassen "total" inden i en tabel der hedder "udgifter", og
gøre teksten rød:

$("#udgifter td.total).css("color","red");

Hilsen
Martin

---

"Martin Larsen" <martin+spamfree+larsen@bigfoot.com> skrev i meddelelsen
news:4b88f614$0$280$14726298@news.sunsite.dk...
> Anders Mikkelsen wrote:
>
>> Jeg har efter adskillelige forsøg prøvet at bruge
>> document.getElementsByClassName med de udvidelser jeg finder rundt
>> omkring heriblandt http://javascript.about.com/library/bldom08.htm som
>> bare gennemløber alle tags og tjekker om de har den givne klasse dog
>> uden held. Hvordan får man det til at virke?
>
> Jeg kender godt det link (har selv brugt det). Hvad mener du med at du
> ikke kan få den til at virke?
>
> Du skriver bare fx : els = document.getElementsByClassName("myclass") og
> får så et array med de matchende elementer.

Tak, jeg har bare været utrolig dum og skrevet
document.getElementsByClassName("myclass").innerHTML = 'ads'; . Jeg er meget
grøn i javascript hvilket også er grunden til at jeg ikke vil bruge jquery
som det primære framework. Jeg har sat mig for at lære javascript grundigt
og det gør jeg ved selv at udvikle alt..

> Du kan se flere implementeringer her: http://ejohn.org/blog/tags/xpath
>
> Og apropos John Resig, så kunne du overveje jQuery. Hvis
> getElementsByClassName er det eneste du har brug for overhovedet, er det
> måske overkill, men hold da op hvor bliver det hele meget lettere når man
> bruger jQuery. Ikke mindst hvad angår browserkompatibitet.
>
> Fordelen med jQuery er også at du bruger en css-lignende syntax til at
> finde dine elementer, fx efter classname. Lad os sige du vil finde alle
> TD'er med klassen "total" inden i en tabel der hedder "udgifter", og gøre
> teksten rød:
>
> $("#udgifter td.total).css("color","red");
>
> Hilsen
> Martin

Tak

Mvh Anders

---

Anders Mikkelsen tastede følgende:
> "Martin Larsen" <martin+spamfree+larsen@bigfoot.com> skrev i meddelelsen
> news:4b88f614$0$280$14726298@news.sunsite.dk...
>> Anders Mikkelsen wrote:
>>
>>> Jeg har efter adskillelige forsøg prøvet at bruge
>>> document.getElementsByClassName med de udvidelser jeg finder rundt
>>> omkring heriblandt http://javascript.about.com/library/bldom08.htm som
>>> bare gennemløber alle tags og tjekker om de har den givne klasse dog
>>> uden held. Hvordan får man det til at virke?
>>
>> Jeg kender godt det link (har selv brugt det). Hvad mener du med at du ikke
>> kan få den til at virke?
>>
>> Du skriver bare fx : els = document.getElementsByClassName("myclass") og
>> får så et array med de matchende elementer.
>
> Tak, jeg har bare været utrolig dum og skrevet
> document.getElementsByClassName("myclass").innerHTML = 'ads'; . Jeg er meget
> grøn i javascript hvilket også er grunden til at jeg ikke vil bruge jquery
> som det primære framework. Jeg har sat mig for at lære javascript grundigt og
> det gør jeg ved selv at udvikle alt..
>
>> Du kan se flere implementeringer her: http://ejohn.org/blog/tags/xpath
>>
>> Og apropos John Resig, så kunne du overveje jQuery. Hvis
>> getElementsByClassName er det eneste du har brug for overhovedet, er det
>> måske overkill, men hold da op hvor bliver det hele meget lettere når man
>> bruger jQuery. Ikke mindst hvad angår browserkompatibitet.
>>
>> Fordelen med jQuery er også at du bruger en css-lignende syntax til at
>> finde dine elementer, fx efter classname. Lad os sige du vil finde alle
>> TD'er med klassen "total" inden i en tabel der hedder "udgifter", og gøre
>> teksten rød:
>>
>> $("#udgifter td.total).css("color","red");
>>
>> Hilsen
>> Martin
>
> Tak
>
> Mvh Anders

Hvis der kun er tale om et enkelt element, er det nemmere at bruge id
og getElementById - det returnerer kun et enkelt element (et id skal
være unikt), og kan bruges direkte i sammenhænge som du beskriver -
hvilket dog ikke skal anbefales, da det vil give fejl, hvis elementet
af en eller anden årsag ikke kan findes.
Den foreslåede funktion getElementsByClassName() returnerer et array
(ligesom f.eks. getElementsByName()), og resultatet kan ikke anvendes
direkte - du er nødt til først at vælge hvliket element i arrayet, du
vil sætte innerHTML for.
Tilstedeværelsen af det lille s efter "Element" i disse funktioners
navne, fortæller om en meget stor forskel

Der er adskillige gode grunde til at gå uden om JQuery og andre
framework.
Ønsket om at lære selv, er en vældig god grund.
Læsbar kode er en anden.
Og så er det lidt som at bruge Word, til en simpel tekstfil : man får
fjorten gange så meget med, som man ikke har brug for, som den lille
del man har brug for.

Dermed ikke sagt, at der ikke er tilfælde hvor det kan være en fordel
at bruge framework.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:
> Der er adskillige gode grunde til at gå uden om JQuery og andre framework.
> Ønsket om at lære selv, er en vældig god grund.

Enig.

> Læsbar kode er en anden.

Uenig.

Mit eksempel synes jeg fx er uhyre læsbart:

$("#udgifter td.total).css("color","red");

Hvad enten man er vant til jQuery, eller blot CCS, er det ganske
tydeligt hvad der sker. Er man ikke hjemme i nogle af delene, men kun
javascript, er det naturligvis ikke så læsbart, men sådan er det jo med
alting.

jQuery understøtter chaining, og så kan man rigtignok lave nogle meget
lange sammensætninger der ikke just er læsbare, men det er man heldigvis
selv herre over.

Martin

---

Den 27-02-2010, skrev Martin Larsen:
> Birger Sørensen wrote:
>> Der er adskillige gode grunde til at gå uden om JQuery og andre framework.
>> Ønsket om at lære selv, er en vældig god grund.
>
> Enig.
>
>> Læsbar kode er en anden.
>
> Uenig.
>
> Mit eksempel synes jeg fx er uhyre læsbart:
>
>
> Hvad enten man er vant til jQuery, eller blot CCS, er det ganske tydeligt
> hvad der sker. Er man ikke hjemme i nogle af delene, men kun javascript, er
> det naturligvis ikke så læsbart, men sådan er det jo med alting.
>
> jQuery understøtter chaining, og så kan man rigtignok lave nogle meget lange
> sammensætninger der ikke just er læsbare, men det er man heldigvis selv herre
> over.
>
> Martin

Jeg har programmeret javascript, stort set siden de fandt på at kunne
gøre HTML dynamisk ad den vej.
Jeg er rimeligt godt inde i css - i hvert fald 2.1.

$("#udgifter td.total).css("color","red");

er volapyk, der hverken er js eller css.
Det nærmeste man kommer noget man kender, er vel $tegnet, som er
variable i PHP og # som er id-selector i css. css( etpar strenge) er en
funktion, i andre sprog - hvis der skal være analogi, må $(..) også
være en funktion, og den skal returnere et object, der definerer en
funktion med navnet css().

Så jeg vil til enhver tid påstå, det ikke er læseligt - specielt for
folk der spørger om js.


Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Så jeg vil til enhver tid påstå, det ikke er læseligt - specielt for
> folk der spørger om js.

Prøv så at lave den samme kode i standard JS. Så kan vi se hvad der er
lettest at læse

Men i øvrigt må kravet for enhver kode være at det er let at læse for
dem som er inde i det pågældende sprog/miljø. C++ er fx ikke læseligt
for mig fordi jeg aldrig har programmeret i det.

Martin

---

Martin Larsen wrote:

> Men i øvrigt må kravet for enhver kode være at det er let at læse for
> dem som er inde i det pågældende sprog/miljø. C++ er fx ikke læseligt
> for mig fordi jeg aldrig har programmeret i det.

Altså mere præcist: Pågældende eksempel er uhyre forståeligt for enhver
som er blot en smule ind i jQuery. Og efter min mening langt hurtigere
at tyde end de tilsvarende (væsentligt flere) linjer lavet i standard JS.

Martin

---

Martin Larsen kom med denne ide:
> Birger Sørensen wrote:
>
>> Så jeg vil til enhver tid påstå, det ikke er læseligt - specielt for
>> folk der spørger om js.
>
> Prøv så at lave den samme kode i standard JS. Så kan vi se hvad der er
> lettest at læse
>
> Men i øvrigt må kravet for enhver kode være at det er let at læse for dem som
> er inde i det pågældende sprog/miljø. C++ er fx ikke læseligt for mig fordi
> jeg aldrig har programmeret i det.
>
> Martin

Nu ved jeg ikke, hvad det er man ønsker at gøre med den aktuelle JQuery
dims.
Men hvis jeg nogensinde skulle få brug for noget der kan det samme, vil
jeg helt utvivlsomt programmere det selv, for at undgå alt det i
JQueri, jeg ikke har brug for, og for selv at have muligheden for at
vide hvad der foregår.
Og i sidste ende, er det det samme der foregår - enten det foregår i
min kode eller i JQueri. Min kode er bare lettere tilgængelig, nemmere
at rette i og indeholder kun det jeg har brug for.

Og nej. En fornuftig kode, skal også kunne forstås af andre end dig
selv.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Men hvis jeg nogensinde skulle få brug for noget der kan det samme, vil
> jeg helt utvivlsomt programmere det selv, for at undgå alt det i JQueri,
> jeg ikke har brug for, og for selv at have muligheden for at vide hvad
> der foregår.
> Og i sidste ende, er det det samme der foregår - enten det foregår i min
> kode eller i JQueri.

Helt fair betragtning.

> Og nej. En fornuftig kode, skal også kunne forstås af andre end dig selv.

Nu lægger du altså noget i munden på mig som jeg ikke sagde! Jeg nævnte
intet om mig selv, men derimod at det var forståeligt for andre som er
inde i det pågældende sprog/miljø/framework.

Martin

---

Efter mange tanker skrev Martin Larsen:
> Birger Sørensen wrote:
>> Og nej. En fornuftig kode, skal også kunne forstås af andre end dig selv.
>
> Nu lægger du altså noget i munden på mig som jeg ikke sagde! Jeg nævnte intet
> om mig selv, men derimod at det var forståeligt for andre som er inde i det
> pågældende sprog/miljø/framework.
>
> Martin

Beklager. Det var ikke jeg mente det.

I enhver form for projekt, er det vigtigt at dokumentere, så evt.
efterfølgere kan forstå den tankegang, der ligger bag.
Hvis en anden skal overtage dine opgaver, lægger det ekstra
(unødvendige) begrænsninger på hvem der kan. Eller ekstra arbejde til
dem der udpeges.
Når jeg f.eks. designer en hjemmeside, der skal fungere som slægtsbog,
stamtræ og billedarkiv, er det vigtigt at de generationer der følger
efter, kan vedligeholde og videreudvikle.

Browserne kan forventes at udvikle sig. Js kan forventes at udvikle
sig. JQueri?

Det er fint med "framewors". Men lav dine egne funktioner (eller kopier
de smarte), og organiser det, så du kun medtager det der skal bruges.
Det andet er en uskik, der spilder en hulens masse bånbredde, og gør
koderne uoverskuelige og mere eller mindre umulige at vedligeholde, for
andre end indforskrevne, der ikke kan eller vil kode selv.

Jeg kender ikke JQeri, og kommer formentlig heller aldrig til. Men hvad
er det, det kan, som ikke kan kodes i js - ud over at spare dig for
besværet, og gøre vedligeholdelsen mere kompliceret end nødvendigt?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Jeg kender ikke JQeri, og kommer formentlig heller aldrig til. Men hvad
> er det, det kan, som ikke kan kodes i js - ud over at spare dig for
> besværet, og gøre vedligeholdelsen mere kompliceret end nødvendigt?

Interessant spørgsmål som jeg glæder mig til at svare på, men lige nu
har vi gæster til fødselsdag

Martin

---

Martin Larsen frembragte:
> Birger Sørensen wrote:
>
>> Jeg kender ikke JQeri, og kommer formentlig heller aldrig til. Men hvad
>> er det, det kan, som ikke kan kodes i js - ud over at spare dig for
>> besværet, og gøre vedligeholdelsen mere kompliceret end nødvendigt?
>
> Interessant spørgsmål som jeg glæder mig til at svare på, men lige nu har vi
> gæster til fødselsdag
>
> Martin

Tillykke til hvem det nu er

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Martin Larsen frembragte:
>> Birger Sørensen wrote:
>>
>>> Jeg kender ikke JQeri, og kommer formentlig heller aldrig til. Men hvad
>>> er det, det kan, som ikke kan kodes i js - ud over at spare dig for
>>> besværet, og gøre vedligeholdelsen mere kompliceret end nødvendigt?
>>
>> Interessant spørgsmål som jeg glæder mig til at svare på, men lige nu har
>> vi gæster til fødselsdag
>>
>> Martin
>
> Tillykke til hvem det nu er

Også tillykke til Martin herfra, og venter også spændt på et svar.

Specifikt kunne jeg godt tænke mig at høre om hvorfor Martin ikke hjalp
Danjel videre i tråden 'sammentælling' d. 26/1, samt hvordan han kunne
forestille sig en _løsning_ vha. jquery.

Jeg har ikke noget imod disse frameworks, ligesom jeg heller ikke havde
noget mod disse 4GL's i '80-erne, men:
"It takes you _this_ far, but _no_ further".

Hvis man ikke kan, eller vil, lære at kode selv, sætter det nogle
begrænsninger.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Specifikt kunne jeg godt tænke mig at høre om hvorfor Martin ikke hjalp
> Danjel videre i tråden 'sammentælling' d. 26/1

Det kan du godt få et svar på allerede nu : mangel på tid! Intet andet.
Har haft travlt med bl.a. jQuery Desuden så jeg at Danjel havde fået
et tilfredsstillende svar (fra dig så vidt jeg husker?) så jeg tænkte at
det kunne godt vente. Jeg skal nok komme med et bud på det om ikke så længe.

> Hvis man ikke kan, eller vil, lære at kode selv, sætter det nogle
> begrænsninger.

Har kodet javascript professionelt siden 1997 og har først taget jQuery
op for godt et år siden, så ....

I øvrigt er jeg ikke til frameworks, jQuery er faktisk det eneste jeg
benytter rent undtagelsesvist, bl.a. pga. nogle de ting der har været
fremme i denne tråd. Men det har vist sig så effektivt at jeg har måtte
bøje mig.

Forklaringen på hvorfor jeg synes jQuery er så genialt får jeg nok først
lavet på tirsdag, for jeg skal lave moms i morgen.

Martin

---

Martin Larsen wrote:

> Det kan du godt få et svar på allerede nu : mangel på tid! Intet andet.
> Har haft travlt med bl.a. jQuery Desuden så jeg at Danjel havde fået
> et tilfredsstillende svar (fra dig så vidt jeg husker?) så jeg tænkte at
> det kunne godt vente. Jeg skal nok komme med et bud på det om ikke så
> længe.

Du skal ikke bruge tid på det for min skyld, det var blot et hint om at
denne problemstilling var langt lettere at løse uden jquery.

>> Hvis man ikke kan, eller vil, lære at kode selv, sætter det nogle
>> begrænsninger.
>
> Har kodet javascript professionelt siden 1997 og har først taget jQuery
> op for godt et år siden, så ....

Det var ikke en kritik, men et hint om, at disse 'frameworks' (og 4GL's)
sætter nogle begrænsninger.

Har kodet adskillige sprog professionelt siden '80, så du får grumme svært
ved at transformere mig over i jquery m.v, da jeg har dårlige erfaringer
med disse.

Afhænig af synsvinklen - selvfølgelig.
Hvis synsvinklen er, at det skal være nemt og hurtigt for en _selv_, og ikke
for brugerne, er det en fordel.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Du skal ikke bruge tid på det for min skyld, det var blot et hint om at
> denne problemstilling var langt lettere at løse uden jquery.

Måske, måske ikke. Jeg har ikke haft tid til at sætte mig ind i
problemstillingen (sammentællingen) eller at kigge på din løsning, og
det kan meget vel være at konklusionen er at der ikke er nogen grund til
at blande jQuery ind i det. Det er jo ikke noget man religiøst skal
benytte sig af, kun dér hvor det er en fordel. Og her er der naturligvis
forskel i erfaring og præferencer, altså hvornår man synes det er en fordel.

> Har kodet adskillige sprog professionelt siden '80, så du får grumme svært
> ved at transformere mig over i jquery m.v, da jeg har dårlige erfaringer
> med disse.

Det har jeg heller ikke noget specielt ønske om, men jeg vil meget gerne
fortælle hvorfor *jeg* synes det er værd at sætte sig ind i. Om et par
dage, når tiden til det.

> Afhænig af synsvinklen - selvfølgelig.
> Hvis synsvinklen er, at det skal være nemt og hurtigt for en _selv_, og ikke
> for brugerne, er det en fordel.

Jeg er ikke helt med her. Brugerne, mener du slutbrugerne på
hjemmesiden? I så fald er de vel græsk-katolske med hvad du har kodet
hjemmesiden i, bare det virker. Og her er der jo heldigvis ikke noget
facit - det der virker for dig som udvikler og samtidigt giver et godt
slutresultat uden at være browserafhængigt, langsomt eller tungt at
loade, det må være det rigtige i en given situation. Hvad enten man
sværger til det ene eller det andet. Et par af de nævnte kriterier
udelukker flere af de frameworks jeg har kigget på, men ikke jQuery.

Martin

---

Martin Larsen wrote:

> Jeg er ikke helt med her. Brugerne, mener du slutbrugerne på
> hjemmesiden?

Det er fordi vi har forskellige synsvinkler.
Mit metiér er større (interne) systemer, hvor ROI afgøres af
effektivitetsbesparelser hos den samlede brugermasse.

Om man kan opgøre den samme ROI på en 'offentlig' side skal jeg lade være
usagt, da man ikke kender adfærd 'med' eller 'uden' "fancy" ting.

Noget er smart, og noget er måske ikke smart.

Her tænker jeg på Jørgens indlæg om 'Smart galleri' af 27.2.
Jo - det er smart i forhold til de "unge og smarte", men hvem er målgruppen?

Jeg har svært ved at forestille mig, at målgruppen er de unge med sidste nye
grej....(?)

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> Her tænker jeg på Jørgens indlæg om 'Smart galleri' af 27.2.
> Jo - det er smart i forhold til de "unge og smarte", men hvem er målgruppen?
>
> Jeg har svært ved at forestille mig, at målgruppen er de unge med sidste nye
> grej....(?)
>

Det ved jeg ikke noget om. Grunden til at jeg nævnte det
var at /jeg/ synes det var /elegant/ som jeg skrev i
meddelelsen, var kombinationen billede og tekst der
fangede øjet på en god kontrapunktisk måde - i forhold
til det måske lidt tørre øvrige indhold - og på
en god måde gav hints om hvad de øvrige museer i
Odense har at byde på.

Og det kan overhovedet skyldes at jeg er en mådeligt
ivrig museumsbesøgende. Og jeg kan overhovedet ikke
se hvad en læsers grej har med webkommunikation at
gøre. Og så har i øvrigt ingen indsigt i hvor populære
museer i bred almindelighed er blandt ungdommen.

Og endnu mere offtopic: Det er vel nnæppe meningen at
et museum skal konkurrere med det sidste nye rockband,
det sidste nye computerspil eller "Twilight". Det er
helt forskellige slags oplevelser, og heldigvis for det!

--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Birger Sørensen wrote:

> Tillykke til hvem det nu er

Min datter som nu er 2 år gammel

Martin

---

Martin Larsen forklarede den 28-02-2010:
> Birger Sørensen wrote:
>
>> Tillykke til hvem det nu er
>
> Min datter som nu er 2 år gammel
>
> Martin


Hvordan har du tid at være her så?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Hvordan har du tid at være her så?

Jamen, det har jeg heller ikke! Det er derfor jeg endnu efter en måned
ikke har lavet det jQuery-eksempel som Stig efterlyste

Martin

---

On 28-02-2010 17:22, Birger Sørensen wrote:
> Efter mange tanker skrev Martin Larsen:
>> Birger Sørensen wrote:
>>> Og nej. En fornuftig kode, skal også kunne forstås af andre end dig
>>> selv.
>>
>> Nu lægger du altså noget i munden på mig som jeg ikke sagde! Jeg
>> nævnte intet om mig selv, men derimod at det var forståeligt for andre
>> som er inde i det pågældende sprog/miljø/framework.
>>
>> Martin
>
> Beklager. Det var ikke jeg mente det.
>
> I enhver form for projekt, er det vigtigt at dokumentere, så evt.
> efterfølgere kan forstå den tankegang, der ligger bag.

og her er frameworks da også langt bedre end hvis man alene sidder med
et projekt.

1000 mennesker der sidder og skriver en dokumentation + 10 mennesker der
strukturer den, kan da kun være bedre end hvis man alene skal sidde og
skrive hele dynen selv, og her gælder 1 linjers dokumentation i koden
ikke - eksempler er en vigtig del :)

http://docs.jquery.com/Main_Page

> Hvis en anden skal overtage dine opgaver, lægger det ekstra
> (unødvendige) begrænsninger på hvem der kan. Eller ekstra arbejde til
> dem der udpeges.

Kan man javascript/css, så tager det ikke 10 min. at sætte sig ind i
tankegangen bagved fx. jquery

> Når jeg f.eks. designer en hjemmeside, der skal fungere som slægtsbog,
> stamtræ og billedarkiv, er det vigtigt at de generationer der følger
> efter, kan vedligeholde og videreudvikle.

Det er måske lige at tage spaden i den lange arm (eller hvad man nu siger)

Hvordan var HTML (og nå ja javascript) for 20 år siden?
Hvordan mon det ser ud om 20 år? - Mon teknologien stiger ligeså
kraftigt (nu hvor MS endelig har fået bugt med IE6 og allerede har
planer om IE9... wauv!) som den har gjort de sidste 20 år?

20 år siden.. var det ikke dengang med 28.8k modem som noget af det
ypperste og nettet var mest af alt nyhedsgrupper/bulletinsboard? - nja
måske vi lige skal 25 år tilbage i tiden for det, men håber du fik
pointen :)

Nå jeg udvikler (især ved databaser) og en kunde siger, "jamen vi skal
jo kun have 5 sider" - hvad mon ikke den samme kunde siger om 5 år,
enten 0 eller 20 sider (ellers går det sku ikk særlig godt for den
kunde, hehe)

Så jeg arbejder altid udfra enten 0 eller undelig antal fx. kategorier
(gælder også ved HTML/CSS/Javascript menuer, her kan jeg dog godt ofte
begrænse til 4 sublevels, css mæssigt, men muligt at smide flere ind
henadvejen)

> Browserne kan forventes at udvikle sig. Js kan forventes at udvikle sig.
> JQueri?

jQuery har skam også forandret sig, vi er jo helt oppe i version 1.4.2
nu - og det går forrygende...

Kilde: [1]
We know of an estimated 279,601[2] websites that are using JQuery.

[1]
http://trends.builtwith.com/javascript/JQuery

[2]
This is an estimated figure based on sites within the top ten thousand
we found using this technology.

> Det er fint med "framewors". Men lav dine egne funktioner (eller kopier
> de smarte), og organiser det, så du kun medtager det der skal bruges.

Helt enig!
Funktioner/klasser er lækkert - lige til at kopier fra det ene projekt
til det andet.

Men dejligt at man ikke skal tænke på core'en.

Fx. bare ajax kald, det er da et gedemarked uden et framework (om det så
er jquery, eller bare et rent ajax library, eller noget man selv har lavet)

new ajax(url, {
method: 'get',
params: { foo: 'bar', baz: id },
beforeCall: function() {
// Do something before ajax is fired, fx. add a loader
},
onsuccess: function(request) {
// We got a response header 200 - wuhuu
// request can be anything from xml, json, html, text
},
onfailure: function(response) {
// Whoops, we didnt get a response header 200...
switch(response.header) {
case '404': alert('page was not found!');
case '403': alert('whops you didnt have access');
// and so on
}
}
});

Alt andet hvad der ligger bagved klassen ajax er fuldstændig
ligegyldigt, bare det virker :)
Om det så er en klasse man selv har lavet, eller brugt fra et library.

> Det andet er en uskik, der spilder en hulens masse bånbredde, og gør
> koderne uoverskuelige og mere eller mindre umulige at vedligeholde, for
> andre end indforskrevne, der ikke kan eller vil kode selv.

Jeg kan en hel del javascript på bunden, men jeg er bare træt af så
virker det ene ikke i den ene browser og det andet ikke i den anden, og
her hjælper frameworks perfekt, især når man er timelønnet

og tro mig når jeg siger, kunderne er sku egentlig ligeglad med om det
er det ene eller andet, bare det virker - så er der selvfølgelig nogle
FÅ som lige tygger det igennem og spørger til det, så sætter man prisen
for hvis det skal laves med det ene, eller det andet, så får de helt
selv lov til at bestemme.

>
> Jeg kender ikke JQeri, og kommer formentlig heller aldrig til. Men hvad
> er det, det kan, som ikke kan kodes i js - ud over at spare dig for
> besværet, og gøre vedligeholdelsen mere kompliceret end nødvendigt?

Vedligholdesen er da uhyre simpel...
Fjern den gamle og indsæt den nye ene 24kb javascript fil...

Eller endnu nemmere hente den fra googles server (som selvfølgelig kører
med de rigtige "modified" headers) og ja, så behøver man aldrig tænke på
at opgradere jquery, det gør google for dig.

<script type="text/javascript" src="http://www.google.com/jsapi">
<script>
google.load("jquery");
</script>

og ja, hvis der er så er ændringer i jquery så den ikke er
bagudkombitabel mere, så skal der selvfølgelig ændres, hvis man har
brugt en af de funktioner. - Men det kunne ligeså godt ske med en
browser/javascript version som også lige synes er blevet for oldnordisk.

document.layer, document.all (eller hvordan det nu lige var) er vel et
godt eksempel :)
Fra dengang med Netscape 4 og IE 4/5 tiden

Du skal aldrig tænke på om der bliver ændret i javascript motoren på de
gængse browsere, det er der bug-reporters til, og fixen bliver lavet.
Så kan du evt. vente på en officiel udgivelse, eller hente sourcen
direkte via subversion

Unødig båndbredde, hvorfor ikke bruge det når det nu er til rådighed?
I danmark har vi jo en masse, nu hvor vi ikke kan streame film (opråb
til politikerne/koda !!)

Desuden så henter du også kun javascript filen 1 gang, så ligger den jo
i din cache resten af tiden, og brugte alle google løsningen, ja så
skulle den "aldrig" hentes :)

24kb - tjaa mon ikke jeg sagtens kunne ændre 3-4 jpg billeder fra 95%
kvalitet til 90% kvalitet og finde de 24kb.

Men jo, 1 ting ser jeg som ville være en nice feature, at kunne vælge
hvilke dele af jquery man vil have med. (som man kan med mange andre
javascript libraries)

Nå ordentlig smøre

---

Martin skrev:
> On 28-02-2010 17:22, Birger Sørensen wrote:
8X
>> I enhver form for projekt, er det vigtigt at dokumentere, så evt.
>> efterfølgere kan forstå den tankegang, der ligger bag.
>
> og her er frameworks da også langt bedre end hvis man alene sidder med et
> projekt.
>
> 1000 mennesker der sidder og skriver en dokumentation + 10 mennesker der
> strukturer den, kan da kun være bedre end hvis man alene skal sidde og skrive
> hele dynen selv, og her gælder 1 linjers dokumentation i koden ikke -
> eksempler er en vigtig del :)
>
> http://docs.jquery.com/Main_Page

1000 mennesker er inde i tankegangen bag dine projekter?

>> Hvis en anden skal overtage dine opgaver, lægger det ekstra
>> (unødvendige) begrænsninger på hvem der kan. Eller ekstra arbejde til
>> dem der udpeges.
>
> Kan man javascript/css, så tager det ikke 10 min. at sætte sig ind i
> tankegangen bagved fx. jquery

Og uden JQery, behøver man overhovedet ikke spekulere på det.
Ud med de 1000, så der kun er dem der er brug for. *Det* er
rationalisering!

>> Når jeg f.eks. designer en hjemmeside, der skal fungere som slægtsbog,
>> stamtræ og billedarkiv, er det vigtigt at de generationer der følger
>> efter, kan vedligeholde og videreudvikle.
>
> Det er måske lige at tage spaden i den lange arm (eller hvad man nu siger)
>
> Hvordan var HTML (og nå ja javascript) for 20 år siden?
> Hvordan mon det ser ud om 20 år? - Mon teknologien stiger ligeså kraftigt (nu
> hvor MS endelig har fået bugt med IE6 og allerede har planer om IE9... wauv!)
> som den har gjort de sidste 20 år?
>
> 20 år siden.. var det ikke dengang med 28.8k modem som noget af det ypperste
> og nettet var mest af alt nyhedsgrupper/bulletinsboard? - nja måske vi lige
> skal 25 år tilbage i tiden for det, men håber du fik pointen :)

Jo - men du fik ikke min!

8X
>> Browserne kan forventes at udvikle sig. Js kan forventes at udvikle sig.
>> JQueri?
>
> jQuery har skam også forandret sig, vi er jo helt oppe i version 1.4.2 nu -
> og det går forrygende...

W3C til HTML og CSS ECMA til js.
JQuery?

> Kilde: [1]
> We know of an estimated 279,601[2] websites that are using JQuery.
>
> [1]
> http://trends.builtwith.com/javascript/JQuery
>
> [2]
> This is an estimated figure based on sites within the top ten thousand we
> found using this technology.

Ikke forstået. Der er 279.601 af de mest besøgte 10.000 der bruger
JQuery?
Måske skal jeg så have skolepengene tilbage.
Og selv hvis det var muligt, er de fleste så bare de fleste, eller gør
det dem også klogere?

>> Det er fint med "framewors". Men lav dine egne funktioner (eller kopier
>> de smarte), og organiser det, så du kun medtager det der skal bruges.
>
> Helt enig!
> Funktioner/klasser er lækkert - lige til at kopier fra det ene projekt til
> det andet.
>
> Men dejligt at man ikke skal tænke på core'en.

"coren" er emca-262
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
og den er der vist ikke mange der er tvivl om, eller stiller
spørgsmåltegn ved.
JQuery er en overbygning på "coren".

> Fx. bare ajax kald, det er da et gedemarked uden et framework (om det så er
> jquery, eller bare et rent ajax library, eller noget man selv har lavet)
>
> new ajax(url, {
> method: 'get',
> params: { foo: 'bar', baz: id },
> beforeCall: function() {
> // Do something before ajax is fired, fx. add a loader
> },
> onsuccess: function(request) {
> // We got a response header 200 - wuhuu
> // request can be anything from xml, json, html, text
> },
> onfailure: function(response) {
> // Whoops, we didnt get a response header 200...
> switch(response.header) {
> case '404': alert('page was not found!');
> case '403': alert('whops you didnt have access');
> // and so on
> }
> }
> });

ajax?
XMLHTTPrequest, er et object (ActiveX i ældre udgaver) i browseren.
http://bbsorensen.dk/?men=Software/AJAX
Du bruger en overbygning af et object fra en overbygning af js.
Ligner lidt noget, der ellers er forbeholdt M$. For at spare tid og
arbejde for dig, skal vi allesammen have 3 gange så meget RAM og midst
4 gange så meget fart på CPU'erne...

> Alt andet hvad der ligger bagved klassen ajax er fuldstændig ligegyldigt,
> bare det virker :)
> Om det så er en klasse man selv har lavet, eller brugt fra et library.
>
>> Det andet er en uskik, der spilder en hulens masse bånbredde, og gør
>> koderne uoverskuelige og mere eller mindre umulige at vedligeholde, for
>> andre end indforskrevne, der ikke kan eller vil kode selv.
>
> Jeg kan en hel del javascript på bunden, men jeg er bare træt af så virker
> det ene ikke i den ene browser og det andet ikke i den anden, og her hjælper
> frameworks perfekt, især når man er timelønnet
>
> og tro mig når jeg siger, kunderne er sku egentlig ligeglad med om det er det
> ene eller andet, bare det virker - så er der selvfølgelig nogle FÅ som lige
> tygger det igennem og spørger til det, så sætter man prisen for hvis det skal
> laves med det ene, eller det andet, så får de helt selv lov til at bestemme.

Klart. Jeg er også ligeglad med hvofor bilen kører - bare den gør det,
når jeg har brug for det, og kan stoppes igen.
Resultatet af dit arbejde er dine kunders værktøj.

>> Jeg kender ikke JQeri, og kommer formentlig heller aldrig til. Men hvad
>> er det, det kan, som ikke kan kodes i js - ud over at spare dig for
>> besværet, og gøre vedligeholdelsen mere kompliceret end nødvendigt?
>
> Vedligholdesen er da uhyre simpel...
> Fjern den gamle og indsæt den nye ene 24kb javascript fil...
>
> Eller endnu nemmere hente den fra googles server (som selvfølgelig kører med
> de rigtige "modified" headers) og ja, så behøver man aldrig tænke på at
> opgradere jquery, det gør google for dig.
>
> <script type="text/javascript" src="http://www.google.com/jsapi">
> <script>
> google.load("jquery");
> </script>
>
> og ja, hvis der er så er ændringer i jquery så den ikke er bagudkombitabel
> mere, så skal der selvfølgelig ændres, hvis man har brugt en af de
> funktioner. - Men det kunne ligeså godt ske med en browser/javascript version
> som også lige synes er blevet for oldnordisk.

Her tænker vi så ikke på ozonlaget, og hvad der kunne spares af trafik.
Browserne har indbygget js fortolker, der ikke skal checke for
opdateringer hver gang en ny side skal vises.

> document.layer, document.all (eller hvordan det nu lige var) er vel et godt
> eksempel :)
> Fra dengang med Netscape 4 og IE 4/5 tiden
>
> Du skal aldrig tænke på om der bliver ændret i javascript motoren på de
> gængse browsere, det er der bug-reporters til, og fixen bliver lavet.
> Så kan du evt. vente på en officiel udgivelse, eller hente sourcen direkte
> via subversion
>
> Unødig båndbredde, hvorfor ikke bruge det når det nu er til rådighed?
> I danmark har vi jo en masse, nu hvor vi ikke kan streame film (opråb til
> politikerne/koda !!)

Godt - så lad os da bruge den til at hente 24Kb til alle sider, i
stedet for den ene der er brug for...

> Desuden så henter du også kun javascript filen 1 gang, så ligger den jo i din
> cache resten af tiden, og brugte alle google løsningen, ja så skulle den
> "aldrig" hentes :)
>
> 24kb - tjaa mon ikke jeg sagtens kunne ændre 3-4 jpg billeder fra 95%
> kvalitet til 90% kvalitet og finde de 24kb.

Javel. Vi går også på kompromis med kvaliteten for at spare arbejde.

> Men jo, 1 ting ser jeg som ville være en nice feature, at kunne vælge hvilke
> dele af jquery man vil have med. (som man kan med mange andre javascript
> libraries)
>
> Nå ordentlig smøre

Jeps - og den svarede ikke på spørgsmålet om hvad det er JQuery kan,
som ikke kan gøres med helt almindelig js...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 02-03-2010 13:58, Birger Sørensen wrote:
> Martin skrev:
>> On 28-02-2010 17:22, Birger Sørensen wrote:
>> http://docs.jquery.com/Main_Page
>
> 1000 mennesker er inde i tankegangen bag dine projekter?

Nej, de er bare en hjælp til at huske...

> Og uden JQery, behøver man overhovedet ikke spekulere på det.
> Ud med de 1000, så der kun er dem der er brug for. *Det* er
> rationalisering!

og ud med computer, de er da også kun nice-to-have, og vi ville sagtens
kunne leve uden dem.

>>> Når jeg f.eks. designer en hjemmeside, der skal fungere som slægtsbog,
>>> stamtræ og billedarkiv, er det vigtigt at de generationer der følger
>>> efter, kan vedligeholde og videreudvikle.
>>
>> Det er måske lige at tage spaden i den lange arm (eller hvad man nu
>> siger)
>>
>> Hvordan var HTML (og nå ja javascript) for 20 år siden?
>> Hvordan mon det ser ud om 20 år? - Mon teknologien stiger ligeså
>> kraftigt (nu hvor MS endelig har fået bugt med IE6 og allerede har
>> planer om IE9... wauv!) som den har gjort de sidste 20 år?
>>
>> 20 år siden.. var det ikke dengang med 28.8k modem som noget af det
>> ypperste og nettet var mest af alt nyhedsgrupper/bulletinsboard? - nja
>> måske vi lige skal 25 år tilbage i tiden for det, men håber du fik
>> pointen :)
>
> Jo - men du fik ikke min!

Sikkert ikke...

Har du prøvet at sidde at arbejde på samme projekt uden strukturering
imellem flere end 1 person? subversion fx.

Ja, det har du helt sikkert (gætter jeg på..)
Så ved du sikkert også at det er lækkert at have library så man ikke
skal lave de samme ting til igen og igen.

Om librariet så hedder BS eller "eksternt library" er vel i for sig det
samme - den eneste forskel er at BS librariet skal bugfixes in-house,
mens det andet ikke skal.

>
> 8X
>>> Browserne kan forventes at udvikle sig. Js kan forventes at udvikle sig.
>>> JQueri?
>>
>> jQuery har skam også forandret sig, vi er jo helt oppe i version 1.4.2
>> nu - og det går forrygende...
>
> W3C til HTML og CSS ECMA til js.
> JQuery?
>
>> Kilde: [1]
>> We know of an estimated 279,601[2] websites that are using JQuery.
>>
>> [1]
>> http://trends.builtwith.com/javascript/JQuery
>>
>> [2]
>> This is an estimated figure based on sites within the top ten thousand
>> we found using this technology.
>
> Ikke forstået. Der er 279.601 af de mest besøgte 10.000 der bruger JQuery?
> Måske skal jeg så have skolepengene tilbage.

På dansk...
Der bliver målt på 10.000 af de største sites, og udfra % af dette
nupper man så de resten...

> Og selv hvis det var muligt, er de fleste så bare de fleste, eller gør
> det dem også klogere?

Det skal jeg så ikke kunne sige - men måske de ved lidt om flere ting,
og det lidt om alt er perfekt nok til at gøre kunderne glade?

>
>>> Det er fint med "framewors". Men lav dine egne funktioner (eller kopier
>>> de smarte), og organiser det, så du kun medtager det der skal bruges.
>>
>> Helt enig!
>> Funktioner/klasser er lækkert - lige til at kopier fra det ene projekt
>> til det andet.
>>
>> Men dejligt at man ikke skal tænke på core'en.
>
> "coren" er emca-262

Med sine små spisfindigheder til hver sin engine.

> http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
> og den er der vist ikke mange der er tvivl om, eller stiller
> spørgsmåltegn ved.

Nej da - har jeg vist aldrig heller sagt.

> Du bruger en overbygning af et object fra en overbygning af js.
> Ligner lidt noget, der ellers er forbeholdt M$. For at spare tid og
> arbejde for dig, skal vi allesammen have 3 gange så meget RAM og midst 4
> gange så meget fart på CPU'erne...

Ja, og det har vi, vi kører jo ikke med 512kb ram mere og 686'ere (måske
et par enkelte, men så er det da kun for gensynets glæder/sorger)

>
>> Alt andet hvad der ligger bagved klassen ajax er fuldstændig
>> ligegyldigt, bare det virker :)
>> Om det så er en klasse man selv har lavet, eller brugt fra et library.
>>
>>> Det andet er en uskik, der spilder en hulens masse bånbredde, og gør
>>> koderne uoverskuelige og mere eller mindre umulige at vedligeholde, for
>>> andre end indforskrevne, der ikke kan eller vil kode selv.

Det går da helt an på hvor godt man har dokumenteret sin kode.
Et lille eksempel (undskyld Stig..)
http://w-o-p-r.dk/javascript/callxmlhttprequest.js

Hvis man ikke er indforstået med den kode, så ville du da ALDRIG
nogensinde ane hvad den gør - og med den dokumentation der er beskrevet,
så skal man da også lige pudse glassene for ikke at misse en enkelt fejl.

>> Jeg kan en hel del javascript på bunden, men jeg er bare træt af så
>> virker det ene ikke i den ene browser og det andet ikke i den anden,
>> og her hjælper frameworks perfekt, især når man er timelønnet
>>
>> og tro mig når jeg siger, kunderne er sku egentlig ligeglad med om det
>> er det ene eller andet, bare det virker - så er der selvfølgelig nogle
>> FÅ som lige tygger det igennem og spørger til det, så sætter man
>> prisen for hvis det skal laves med det ene, eller det andet, så får de
>> helt selv lov til at bestemme.
>
> Klart. Jeg er også ligeglad med hvofor bilen kører - bare den gør det,
> når jeg har brug for det, og kan stoppes igen.

Godt eksempel, og hvis den ikke virker, så er det retur på skolebænken.

> Resultatet af dit arbejde er dine kunders værktøj.

Jeps, hvad skal de kigge på når de lige har lagt X antal bananer for at
deres idéer er blevet til virkelig.

> Godt - så lad os da bruge den til at hente 24Kb til alle sider, i stedet
> for den ene der er brug for...

Nemlig!

>
>> Desuden så henter du også kun javascript filen 1 gang, så ligger den
>> jo i din cache resten af tiden, og brugte alle google løsningen, ja så
>> skulle den "aldrig" hentes :)
>>
>> 24kb - tjaa mon ikke jeg sagtens kunne ændre 3-4 jpg billeder fra 95%
>> kvalitet til 90% kvalitet og finde de 24kb.
>
> Javel. Vi går også på kompromis med kvaliteten for at spare arbejde.

Nææ, det ville jeg nu aldrig gøre - de 24kb var for din skyld

> Jeps - og den svarede ikke på spørgsmålet om hvad det er JQuery kan, som
> ikke kan gøres med helt almindelig js...

Ingenting, men måske jeg kunne lave 10 ting hvor du måske nåede 4 ting?
Så har jeg 6 ting hvor jeg kan prøve nye metoder, afprøve nyt lir til
øjenene, eller lave ingenting.

---

Martin wrote:

[snip en masse]

> document.layer, document.all (eller hvordan det nu lige var) er vel et
> godt eksempel :)
> Fra dengang med Netscape 4 og IE 4/5 tiden

Hvordan er det lige du skelner mellem IE8 og andre p.t?

> Desuden så henter du også kun javascript filen 1 gang, så ligger den jo
> i din cache resten af tiden, og brugte alle google løsningen, ja så
> skulle den "aldrig" hentes :)

Her bør du sætte dig ind i hvordan browsere, og deres cache, fungerer.

> Nå ordentlig smøre

Ja, og jeg har snippet en del, men din holdning/budskab skinner klart
igennem.

HVIS man arbejder på fast pris (og ikke timeløn, som du skriver), er det en
fordel at skrue noget sammen hurtigst, og lettest muligt, men det er ikke
det samme som BEDST muligt.

Du skriver lidt om browsere og kompatibilitet, men hvilke
kompatibilitetsproblemer ser du i fremtiden, ud over dem der er i dag?

Hvis man forholder sig til 'standard' javascript, og tager hensyn til de
særegne ting IE nu engang har, ser jeg ikke de voldsomme problemer, hverken
nu eller i fremtiden.

Du fremhæver selv Ajax, og her vil jeg henvise til mit eget 'library':
<http://w-o-p-r.dk/javascript/callxmlhttprequest.js>

Det kan det det skal, med en enkelt linies kald, og kræver ikke xx KB for
den smule funktionalitet.

Dog kræver det et andet 'library', hvis man vil have ISO-8859-1 data på
'wiren' - hvordan gør du det i jquery?

Iso-8859-1 er trods alt standard på HTML fronten, og rimeligt udbredt i
'western europe'.

Alt i alt, så afspejler dit indlæg tydeligt den suboptimering, der er
trenden af i dag - at gøre det let for een selv, uden hensyntagen til
brugere.

Det er fint nok ud fra visse betrgtninger, men hvis succes'en afhænger af
ROI, så er det en ikke ubetydelig faktor hvordan brugere oplever sin
hverdag, herunder performance.

Hvordan du får blandet databaser sammen men javascript fatter jeg i øvrigt
ikke en meter af - det må vist være en tankeprut.

--
Med venlig hilsen
Stig Johansen

---

On 02-03-2010 14:08, Stig Johansen wrote:
> Martin wrote:
>
> [snip en masse]
>
>> document.layer, document.all (eller hvordan det nu lige var) er vel et
>> godt eksempel :)
>> Fra dengang med Netscape 4 og IE 4/5 tiden
>
> Hvordan er det lige du skelner mellem IE8 og andre p.t?

Lige PT er der ikke de helt store gevaldige problemer med browserne -
heldigvis er IE6 snart fortid, men den lever stadig (desværre) temmelig
kraftigt.

var x = {
z = function() {
},
}

Her ville IE7 fejle, er dog ikke sikker på IE8 jeg har lært og fjerne
det sidste komma

Kan godt være det står specifikt i standarden at det sidste komma ikke
må være der og at det er forkert osv - men det er pænt træls hvis man
lige smider det på til sidst (eller fjerner den sidste funktion og lige
glemmer kommaet)

En anden ting jeg oplevede...

var flag = true;
function newsletteronunload() {
if (flag == true) {
// Do something
}
}

Her ville jeg gerne have flag === true ind istedet, ja jeg kan godt lide
at type test også (og selvfølgelig fuldstændig ligegyldig i denne
sammenhæng, men sådan er jeg høhø), men så virkede det ikke i IE7/8
Selvom jeg ved at === virker fint i IE

Selvom med
alert(typeof flag);
alert(typeof true);
fik jeg PRÆCIST de samme typer retur


> Ja, og jeg har snippet en del, men din holdning/budskab skinner klart
> igennem.

Tak

>
> HVIS man arbejder på fast pris (og ikke timeløn, som du skriver), er det en
> fordel at skrue noget sammen hurtigst, og lettest muligt, men det er ikke
> det samme som BEDST muligt.

Kunden der sidder foran koden og kigger på hjemmesiden/programmet etc.
er i de allerfleste tilfælde rimelig ligeglad med hvad der egentlig
ligger bagved. (og mange forstår heller ikke en dyt af det)

Selvfølgelig er frameworks ikke lavet til små simple ting, jeg ville da
aldrig bruge et serverside framework hvis jeg skulle lave 4-5 skabeloner.

Men hvis jeg skulle lave 20, og hver af de 20 skulle have 2-3
forskellige content sider, så vi ender i noget af retningen af 40-60
forskellige sider, så ville et framework virkelig være skønt.

På et enkelt side har jeg fx. følgende
<select> bokse med et design som ikke ville kunne laves i ren css (runde
hjørner er jo ikke med i IE7-8, virker lækkert i firefox og safari, dog
med deres egne versioner af CSS3 -moz-border-radius og
-webkit-border-radius osv.)

Et galleri med lidt bløde effekter, og ikke "stenhårde" popups

Radiobuttons/checkbokse med fuldstændig anderledes design end de sædvanlige

ajax-kald af en masse

og ellers diverse andre ting som gør et website lækkert at se på, men
tungt - HELT ENIG!

og Ja, nogle kunder vil ikke gå på kompromis med deres design, selv er
der nogle der vil have flyttet en boks en halv pixel op....

>
> Du skriver lidt om browsere og kompatibilitet, men hvilke
> kompatibilitetsproblemer ser du i fremtiden, ud over dem der er i dag?

Nu er det jo ret svært at spå om fremtiden, men hvis man bare kigger
lidt over vandet til CSS, så er kompatibiliteten pænt forskellig, og med
den største udbyder (som endelig er begyndt at komme frem i skoene) som
værende den mest irriterende, hvis man kan sige det

og med HTML5 som allerede er lettere begyndt sit togt frem, så vil der
også klart blive noget ballade her.

Så med 4 forskellige større javascript motorer (V8, SquirrelFish,
JScript og TraceMonkey) og hvis de så også begynder at udvikle sig til
andet end at vil bruge ECMA-262'3rd (fra 2000!!) så bliver der da også
lidt sjov og ballade her. (hvilket de 2 allerede er hoppet videre fra)

og det ses vil tydeligt i spørgerens spørgsmål -
document.getElementsByClassName som ikke er understøttet i ECMA-262, men
først i en senere version af javascript (dog ved jeg ikke hvilken, så
meget er jeg heller ikke inde i de forskellige versioner).

JSON er også en lille forhindring, og (svjv!) ikke native understøttet i
ECMA-262, og JSON har vel efterhånden overtaget istedet for ren XML, for
at spare båndbredde/hastighed... Birger

> Hvis man forholder sig til 'standard' javascript, og tager hensyn til de
> særegne ting IE nu engang har, ser jeg ikke de voldsomme problemer, hverken
> nu eller i fremtiden.

Nemlig de særegne, så skal man lave en ekstra funktion til dit og dat -
og vupti, så er man også oppe i meget mere ekstra kode end man egentlig
ville have, og så har man sit eget library.

Findes der iøvrigt en funktion ala
(taget fra PHP)

if (! function_exists('foobar')) {
function foobar() {
// Gør det samme som i den "rigtige" foobar
}
}

>
> Du fremhæver selv Ajax, og her vil jeg henvise til mit eget 'library':
> <http://w-o-p-r.dk/javascript/callxmlhttprequest.js>
>
> Det kan det det skal, med en enkelt linies kald, og kræver ikke xx KB for
> den smule funktionalitet.

Nu er ajax i jQuery jo også en lillebitte del af jQuery librariet (10%
tror jeg, uden lige at have målt)
og som jeg har sagt før, så ønsker jeg også at man kunne nøjes med dele
af jquery istedet for hele møllen.

> Dog kræver det et andet 'library', hvis man vil have ISO-8859-1 data på
> 'wiren' - hvordan gør du det i jquery?

Serveren skal naturligvis outputte det korrekte format for den fil man
henter, ellers så skal det overrides direkte i filen - i PHP ville man
gøre således

<?php
header('Content-type: text/json; charset=iso-8859-1');
?>
men det har jo intet med ajax kaldet af gøre, da det jo er serveren der
så outputter i forkert format.

Ellers så ville jeg bare sende scriptCharset med i mit kald.

$.ajax({
url: 'ajax.php',
data: {foo: bar}
scriptCharset: 'iso-8859-1',
success: doSuccess
});

Det kan også sættes som default med

$.ajaxSetup({
scriptCharset: 'iso-8859-1'
});

Så vil alle ajax kald bruge denne
også kan vi nøjes med at skrive

$.get('ajax.php', {foo: bar}, doSuccess);

Eller hvis hele resultatet alligevel skal ind i en div, så kan man lade
vær med at hive callback funktionen med.

$('div').load('ajax.php', {foo: bar});

> Alt i alt, så afspejler dit indlæg tydeligt den suboptimering, der er
> trenden af i dag - at gøre det let for een selv, uden hensyntagen til
> brugere.

Selv på iPhone glider jQuery hamrende let over...
Så det er ihvertfald ikke kræfterne på maskinen man skal kigge på.

> Det er fint nok ud fra visse betrgtninger, men hvis succes'en afhænger af
> ROI, så er det en ikke ubetydelig faktor hvordan brugere oplever sin
> hverdag, herunder performance.

Nej da, helt sikkert - men for hulen hvor ville nettet da være noget så
skræmmende at kigge på hvis alt stod på sort og hvidt - effekter er nu
altså både en del af trenden og lir til øjenene.

Hvordan mon salget ville være i en webshop hvor der ikke var billeder,
men ren tekst :)

Om effekten så er javascript, css, flash eller lign. er egentlig ret
ligegyldigt.

Et sødt eksempel jeg lige kan komme på er mainframes (her tænker jeg
lidt på en tid i Aspect/4 fra EDBgruppen, sort i grønt, tænk hvis det
var en kunde der så en webshop som det... og heller ikke særlig
indbydende for medarbejdere at skulle tænke på.

> Hvordan du får blandet databaser sammen men javascript fatter jeg i øvrigt
> ikke en meter af - det må vist være en tankeprut.

Tjaa, tjoo kl. var pænt meget

---

8X

FYI
JSon *er* understøtttet af EMCA262 og
getElement(s)... er ikke javascript, men defineret i DOM (), og derfor
EMCA262 helt uvedkommende - selvom de selvfølgelig kan anvendes fra js.
getElementsByClassName findes i FF - ikke i IE.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Dette er en af de bedste workarounds for dette jeg har set.
http://www.netlobo.com/javascript_getelementsbyclassname.html

Regards Jens Peter Karlsen.

On Wed, 03 Mar 2010 01:44:04 +0100, Birger Sørensen
<sdc@bbsorensen.com> wrote:

>getElementsByClassName findes i FF - ikke i IE.

---

Birger Sørensen wrote:

> Jeg kender ikke JQeri, og kommer formentlig heller aldrig til. Men hvad
> er det, det kan, som ikke kan kodes i js - ud over at spare dig for
> besværet, og gøre vedligeholdelsen mere kompliceret end nødvendigt?

Så fik jeg lidt tid nu min datter er lagt i seng

Jeg har tænkt en del over dit spørgsmål og fundet ud af at jeg kunne
skrive en hel lærebog om jQuery, så meget har jeg arbejdet med det. Det
skal jeg dog nok spare jer for, så det bliver bare nogle tanker og
smagsprøver.

Først: man kan IKKE lavet noget i jQuery som man ikke kan lave i
standard JS da det jo er kodet i JS. Men til gengæld er der mange ting
som bliver overordentligt meget lettere. Dels på grund af jQuerys efter
min mening geniale CSS-lignende syntax, dens funktionsammenkædning samt
den indbyggede browserkompatibilitet.

Inden jeg giver et egentligt svar på spørgsmålet, vil jeg komme med
nogle indledende betragtninger som jeg finder betydningsfulde. Hvis det
bliver for kedeligt, så spol bare ned til eksemplerne

<kedelig>

jQuery fylder ikke meget, ca. 24k. Man kan altid argumentere for at det
er meget hvis fx alt man skal bruge er trådens getElementsByClassName,
men i praksis, på en typisk hjemmeside, er det ikke meget. Desuden
bliver den cached, så hvis man browser rundt på sitet skal det kun
loades én gang.

jQuery er hurtigt. Meget hurtigt. Naturligvis ikke hurtigere end det kan
laves i native JS - og dog! I praksis kan man nemlig godt komme ud for
at jQuery er hurtigere end ens native kode af to årsager: For det første
er der tænkt længe over algoritmerne i jQuery (og de bliver forbedret
løbende), så det kan hænde at de er bedre end ens egen algoritme. For
det andet bruger jQuery i visse tilfælde forskellige implementeringer
afhængig af browseren, således at der bruges metode A på fx Gecko og
metode B på IE fordi metode A her er for langsom. Så for at matche
hastigheden med native kode skulle man altså i disse tilfælde
implementere to (eller flere) forskellige løsninger på samme problem.
Retfærdigvis skal det dog siges at de fleste funktioner er implementeret
på samme måde for alle browsere.

Kompabiliteten er vigtig for jQuery. Den er indbygget i kernen og en
vigtig del af hele ideen. Selv hvis en browser ikke har en bestemt
funktion, som fx netop getElementsByClassName for IE's vedkommende, så
tager jQuery hånd om denne situation for dig. Prøv at forestille dig at
du har lavet en ganske kompleks hjemmeside med masser af DHTML osv. Og
fået det til at virke i alle moderne browsere. Så kommer IE9 og i den
virker skidtet ikke. Eller der kommer en helt ny browser. Er du heldig,
kan du måske ret let modificere koden, men med jQuery opdaterer du bare
til nyeste version. (Der er jo ingen garantier, men jQuery har indtil nu
været hurtig til at komme med den slags opdateringer). Eller du laver et
plugin der løser problemet - se næste afsnit.

jQuery har en smart og enkel pluginarkitektur. Det betyder at du kan
udvide kernen med alle mulige funktioner som du måtte have brug for. Der
findes på nettet en masse plugins, eller du kan lave dem selv. Plugins
fylder typisk et par hundrede bytes, men kan også være store og komplekse.

Mange af disse færdige plugins er kalendere, draggables og droppables,
popups, auto-suggestions og andre UI-ting. For mange er disse grafiske
brugerflader den vigtigste fordel ved jQuery, især designere og andre
som egentligt ikke kan/gider kode, men bare vil have noget let og
hurtigt. For mig er det vigtigste dog alt det jeg selv kan gøre med
frameworket.

Endelig har det en syntax som gør det utroligt koncist. Frameworket
lever op til mottoet "Write less, do more". Samtidigt er det virkeligt
let at læse og skrive *** når man har vænnet sig til syntaxen ***.
Sidstnævnt bemærkning er vigtig, for det KAN ligne nonsens for de
uindviede! (Heldigvis er der efterhånden mange indviede). Men det er
meget hurtigt at lære hvis man kender til JS og CSS i forvejen.

</kedelig>

Nu må jeg hellere komme til sagen: Hvad kan man bruge jQuery til? Næsten
alt, så jeg omformulerer: Hvad vil man normalt bruge det til?

Svar: Til at finde og manipulere DOM-elementer. Hvis ens kode ikke eller
kun i ringe grad involverer DOM, er der næppe nogen grund til at rode
jQuery ind i billedet. Men har man til gengæld brug for i væsentlig grad
at manipulere DOM-elementerne, er der i høj grad noget at komme efter.

I praksis kan jQuery og native JS med fordel blandes: For mig består en
typisk side af masser af native JS krydret med jQuery til at håndtere DOM.

EKSEMPEL 1:

Jeg programmerer lidt i Python for Symbian (mobiltelefoner) og finder
denne wiki meget nyttig:

http://wiki.forum.nokia.com/index.php/Most_Viewed_Python_Articles

Men det er svært at overskue siden med de mange uordnede eksempler. Hvad
hvis jeg nu er interesseret i eksempler på kode der bruger telefonens
SMS-funktion?

Let!

Prøv at indsætte følgende i browserens adresselinje på førnævnte url.
Jeg håber I gider gøre dette, eksemplet er ret slående!

javascript:$("#wikiContent
li").hide().filter(":contains('SMS')").show();void(0);

(Det skal kun være én linje, i tilfælde af at newsreaderen deler den)

Vupti: Nu ser du kun de wiki-links der handler om SMS. Prøv så at gå op
i adresselinjen og erstat "SMS" med fx "call" og tryk enter...

Altså kun én linje i jQuery:

$("#wikiContent li").hide().filter(":contains('SMS')").show();

Læses sådan: Find alle li-elementer under elementet med id=wikiContent,
skjul dem alle, filtrer så dem der indeholder teksten SMS, og vis disse.

Når det kan lade sig gøre blot at paste kodestumpen ind i adresselinjen,
er det fordi siden allerede benytter jQuery. Ellers kan man bruge
følgende bookmarklet der "jquerifyer" alle sider:

http://www.learningjquery.com/2006/12/jquerify-bookmarklet


EKSEMPEL 2:

Jeg er ret ny i Linux og benytter derfor følgende forum flittigt:

http://www.linuxin.dk/node/15465

Men jeg synes det er mere logisk at nyeste indlæg er først. Så jeg
bruger følgende kodestump sammen med Greasemonkey til at vende
rækkefølgen om:

elems = $(".forum-comment")
var arr = $.makeArray(elems).reverse();
$(arr).insertAfter("h1.title")

Herefter kommer nyeste indlæg øverst. Mit greasemonkey-script er lidt
mere komplekst idet det også gør andre ting, men disse tre linjer er nok
til at sortere i omvendt orden.


EKSEMPEL 3 (plugin):

I det første eksempel filterede jeg en wiki efter nøgleord. Problemet er
dog at filteret :contains er case-sensitivt. Så en filtrering på "SMS"
finder fx ikke "sms".

Men så bruger jeg bare dette plugin:

jQuery.expr[':'].Contains = function(a,i,m){
return jQuery(a).text().toUpperCase().indexOf(m[3].toUpperCase())>=0;
};

Herefter kan det bruges præcis som den indbyggede funktion, blot staves
contains med stort C:

filter(":Contains('SMS')")


EKSEMPEL 4:

Mine eksempler har været simple for at formidle ideen, men alligevel
meget nyttige (for mig i hvert fald). Men naturligvis kan man også lave
væsentligt mere sofistikerede ting med jQuery.

Mit sidste eksempel har jeg ikke lavet selv, men det er et udmærket
eksempel på hvad man kan med jQuery - og så er det lidt "rekursivt" idet
det faktisk handler om jQuery!

http://visualjquery.com/

Prøv at indtaste noget i filteret, fx "ajax". Og klik så videre på de
blå felter. Eller prøv med det føromtalte "contains".


Puha, sikken en omgang!

Jeg håber det lykkedes mig at svare nogenlunde fyldestgørende på Birgers
spørgsmål. Og at vise at jQuery kan være rigtigt smart til at manipulere
DOM med. Der er andre JS frameworks derude, men jQuery er i stor vækst
og har en meget lovende fremtid.

Om man så vil benytte jQuery eller et andet framework, eller sin egen
gode gamle JS-kode er op til den enkelte. Der er ikke noget facit her.

Hilsen
Martin

---

Den 03-03-2010 22:34, Martin Larsen skrev:

> Jeg har tænkt en del over dit spørgsmål og fundet ud af at jeg kunne
> skrive en hel lærebog om jQuery, så meget har jeg arbejdet med det. Det
> skal jeg dog nok spare jer for, så det bliver bare nogle tanker og
> smagsprøver.
>
> Først: man kan IKKE lavet noget i jQuery som man ikke kan lave i
> standard JS da det jo er kodet i JS. Men til gengæld er der mange ting
> som bliver overordentligt meget lettere. Dels på grund af jQuerys efter
> min mening geniale CSS-lignende syntax, dens funktionsammenkædning samt
> den indbyggede browserkompatibilitet.
>
> Inden jeg giver et egentligt svar på spørgsmålet, vil jeg komme med
> nogle indledende betragtninger som jeg finder betydningsfulde. Hvis det
> bliver for kedeligt, så spol bare ned til eksemplerne
>
> <kedelig>

<SNIP: JQuery forklaring>

Jeres diskussion minder mig om en helt anden situation, men det kommer
stadig af det samme, nemlig udvikling, og kravet om, at tingene skal gå
hurtigere som gør, at automatisering er nødvendig.

Situationen:

Jeg kan huske i 80erne, hvor jeg skulle skrive ansøgninger, og dette
foregik i hånden. Det var simpelthen et krav, hvilket jeg sådan set godt
forstod.

Imidlertid, så gør udviklingen, at man i dag sender sin ansøgning via
firmaets hjemmeside i PDF-format... man skriver heller ikke breve
(højest postkort) i hånden mere, her mailer eller SMSer man. Det er helt
fuldautomatiseret.

Jeg har selv været og er stadig fortaler for denne automatik, men den
har også gjort, jeg har en ganske elendig håndskrift i dag (den HAR
engang været ret pæn). Jeg bruger i dag håndskrift til indkøbssedler og
til at skrive noter på arbejdet til den næste om hvad der er sket. Alt
andet foregår for så vidt elektronisk.

Min anke imod frameworks er de samme som for automatiseringen af
skrif-kommunikationen, at man riskerer at glemme det helt grundlæggende,
og HVIS den situation opstår, hvor man ikke har den automatik til
rådighed, så kan det ikke nytte noget, det man skriver i hånden ikke kan
læses. Eller at man glemmer hvordan man staver, fordi man er vant til
SMS-sprog.

Derfor er jeg sådan set i to lejre. Jeg kan se udviklingen, den går imod
frameworks og automatisering hele vejen rundt, og den kan ikke standses,
men samtidig er jeg inderlig modstander af, at man mister overblikket
over det helt grundlæggende - idt. at man lærer frameworks uden at kende
til JS - lidt som at designe i Frontpage/WYSIWYG uden at kunne HTML og
CSS og de grundlæggende regler for semantik og webdesign iøvrigt.

Det er fint nok i nu hver især beskriver indbyrdes fordele ved hver
jeres metode set udfra eget perspektiv, men kan man mon blive enige om
nogle (generelle?) situationer, hvor frameworks kan have sin ret, og de
situationer, hvor ren JS er det bedste. Jeg mener, her må i kunne blive
enige om nogle tommelfingerregler ell. lign. ? Jeg er som sagt selv på
begge banehalvdele her--

Iøvrigt, så holder jeg fast ved, at det ville være en klar fordel at
have en undergruppe, som hedder frameworks til clientside. Jeg bruger
slet ikke selv så store scripts, så JQuery vil for mig være at skyde
gråsprve med missiler, og min interesse er foreløbig udelukkende i
indbygget sprog, som jeg gerne vil lære først. Det skulle gerne være
sådan, at går man i clientside, så får man diskussioner om indbygget
sprog, men man kan ikke undgå diskussioner om frameworks og brugen af
disse, og skal heller ikke undgå det, derfor forslag om undergruppe.

Det svarer lidt til, man har en PHP og ASP undergruppe under
serverside-gruppen.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Derfor er jeg sådan set i to lejre. Jeg kan se udviklingen, den går imod
> frameworks og automatisering hele vejen rundt, og den kan ikke standses,
> men samtidig er jeg inderlig modstander af, at man mister overblikket
> over det helt grundlæggende - idt. at man lærer frameworks uden at kende
> til JS - lidt som at designe i Frontpage/WYSIWYG uden at kunne HTML og
> CSS og de grundlæggende regler for semantik og webdesign iøvrigt.

Det er vi rørende enige om. Jeg er da også glad for at jeg har et godt
kendskab til JS efter at have arbejdet med det siden omkring '97. jQuery
har jeg brugt et års tid. Uden godt kendskab til JS vil man også kun
være *bruger* af jQuery og vil fx ikke være i stand til at lave plugins.

> Det er fint nok i nu hver især beskriver indbyrdes fordele ved hver
> jeres metode set udfra eget perspektiv, men kan man mon blive enige om
> nogle (generelle?) situationer, hvor frameworks kan have sin ret, og de
> situationer, hvor ren JS er det bedste. Jeg mener, her må i kunne blive
> enige om nogle tommelfingerregler ell. lign. ?

Det har jeg berørt i mit lange indlæg. Høj grad af DOM-manipulation:
jQuery, ellers native JS. Altså som tommelfingerregel.

Men det gælder for mig, det er ikke den evige sandhed.

Allerede i mit først svar til denne tråds OP skrev jeg at jQuery ville
være overkill hvis han blot skulle bruge getElementsByClassName. Jeg har
altså ikke en religiøs indstilling til frameworket (ikke at du på nogen
måde har antydet det, jeg nævner det bare lige).

> Det svarer lidt til, man har en PHP og ASP undergruppe under serverside-gruppen.

Jeg synes det er en god ide med en undergruppe. Det skal dog ikke være
sådan at frameworks er tabu i hovedgruppen. En spørger har måske slet
ikke kendskab til at der findes frameworks, så derfor kan det være på
sin plads at nævne muligheden og måske komme med et eksempel. Og ellers
henvise til undergruppen for uddybende forklaringer.

Martin

---

Martin Larsen kom med følgende:
> Rune Jensen wrote:
>
>> Derfor er jeg sådan set i to lejre. Jeg kan se udviklingen, den går imod
>> frameworks og automatisering hele vejen rundt, og den kan ikke standses,
>> men samtidig er jeg inderlig modstander af, at man mister overblikket
>> over det helt grundlæggende - idt. at man lærer frameworks uden at kende
>> til JS - lidt som at designe i Frontpage/WYSIWYG uden at kunne HTML og
>> CSS og de grundlæggende regler for semantik og webdesign iøvrigt.
>
> Det er vi rørende enige om. Jeg er da også glad for at jeg har et godt
> kendskab til JS efter at have arbejdet med det siden omkring '97. jQuery har
> jeg brugt et års tid. Uden godt kendskab til JS vil man også kun være
> *bruger* af jQuery og vil fx ikke være i stand til at lave plugins.
>
>> Det er fint nok i nu hver især beskriver indbyrdes fordele ved hver
>> jeres metode set udfra eget perspektiv, men kan man mon blive enige om
>> nogle (generelle?) situationer, hvor frameworks kan have sin ret, og de
>> situationer, hvor ren JS er det bedste. Jeg mener, her må i kunne blive
>> enige om nogle tommelfingerregler ell. lign. ?
>
> Det har jeg berørt i mit lange indlæg. Høj grad af DOM-manipulation: jQuery,
> ellers native JS. Altså som tommelfingerregel.
>
> Men det gælder for mig, det er ikke den evige sandhed.
>
> Allerede i mit først svar til denne tråds OP skrev jeg at jQuery ville være
> overkill hvis han blot skulle bruge getElementsByClassName. Jeg har altså
> ikke en religiøs indstilling til frameworket (ikke at du på nogen måde har
> antydet det, jeg nævner det bare lige).
>
>> Det svarer lidt til, man har en PHP og ASP undergruppe under
>> serverside-gruppen.
>
> Jeg synes det er en god ide med en undergruppe. Det skal dog ikke være sådan
> at frameworks er tabu i hovedgruppen. En spørger har måske slet ikke kendskab
> til at der findes frameworks, så derfor kan det være på sin plads at nævne
> muligheden og måske komme med et eksempel. Og ellers henvise til undergruppen
> for uddybende forklaringer.
>
> Martin

Der er slet ingen tvivl om, at JQuery har sin berettigelse.

Men den ligger ikke i at man skal bruge en enkelt funktion som
getElementsByClassName().
Og den ligger heller ikke i "hold da op hvor bliver det hele meget
lettere når man bruger jQuery" - så ender man med at hente 24Kb, hver
gang der skal bruges 6 linier.
For mig må det være en afvejning af, hvor mange af *brugerens*
resourcer, der spildes på ting der ikke er brug for. Ikke en opgørelse
af, hvor mange reourcer man selv sparer ved at bruge det.

Og faren er de mange derude, der har en masse gode ideer, men ikke er i
stand til selv at programmere løsninger til de problemstillinger de
møder.
Og i at når nogen spørger efter getElementsByClassName(), så bliver der
svaret "hold da op hvor bliver det hele meget lettere når man bruger
jQuery".
Og det kan da godt være at det bliver lettere. I de fleste af de
tilfælde, der kommer op her i NG, vil det være overkill - og Rune har
en pointe i, at JQuery er en vej udenom at lære at gøre tingene
"rigtigt".

Det er da en god ide at have "frameworks". Men det bør være sådan, at
der er mulighed for at vælge det fra, der ikke skal bruges. Det vil i
praksis sige, enten skal man programmere det selv, eller det skal
"leveres" på en måde, at man kan udvælge den eller de
funktioner/objekter man har brug for.
Det bør vel også være sådan, at /hvis/ man vælger at bruge JQuery, så
er det noget man bevidst gør fra starten af sit projekt. Ellers er der
mange ting man risikerer at få dobbelt - hvilket også er
uhensigtsmæssigt spild af *brugerens* resourcer. Man inkluderer ikke
JQuery midt i projektet (med mindre man også redesigner fra bunden, for
at bruge de tilføjede muligheder optimalt).
Og derfor (og fordi JQuery ikke lærer nogen noget om js) kan "JQuery"
ikke være svaret på spørgsmål om js.

Netop derfor, vil det være en god ide, med en gruppe til frameworks.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Der er slet ingen tvivl om, at JQuery har sin berettigelse.
> Men den ligger ikke i at man skal bruge en enkelt funktion som
> getElementsByClassName().

Enig - det har jeg også pointeret.

> Og den ligger heller ikke i "hold da op hvor bliver det hele meget
> lettere når man bruger jQuery" - så ender man med at hente 24Kb, hver
> gang der skal bruges 6 linier.

For så vidt også enig. Men som jeg skrev, var de små eksempler blot for
at tydeliggøre ideen. Normalt vil det være ganske komplekse sider der
arbejdes på.

> For mig må det være en afvejning af, hvor mange af *brugerens*
> resourcer, der spildes på ting der ikke er brug for. Ikke en opgørelse
> af, hvor mange reourcer man selv sparer ved at bruge det.

I princippet enig, det er en afvejning. Men hvis du mener at 24k er er
problem for brugerens resourcer, så er jeg meget uenig. Det er langt
vigtigere at siden er kompatibel i (helst) alle browsere. Du skal sidde
på en overordentlig langsom forbindelse for at finde download af 24k et
problem.

> Og faren er de mange derude, der har en masse gode ideer, men ikke er i
> stand til selv at programmere løsninger til de problemstillinger de møder

Ja.

> Og i at når nogen spørger efter getElementsByClassName(), så bliver der
> svaret "hold da op hvor bliver det hele meget lettere når man bruger
> jQuery".

Ja, hvis det står alene. Men jeg skrev jo netop at det var overkill hvis
han blot havde brug for getElementsByClassName. Jeg benyttede blot
lejligheden til at fortælle om jQuery.

> Og det kan da godt være at det bliver lettere. I de fleste af de
> tilfælde, der kommer op her i NG, vil det være overkill - og Rune har en
> pointe i, at JQuery er en vej udenom at lære at gøre tingene "rigtigt".

Også enig.

> Det bør vel også være sådan, at /hvis/ man vælger at bruge JQuery, så er
> det noget man bevidst gør fra starten af sit projekt.

Ja, naturligvis.

> Man inkluderer ikke
> JQuery midt i projektet (med mindre man også redesigner fra bunden, for
> at bruge de tilføjede muligheder optimalt).

Ja, jeg har haft gjort netop dette, redesignet et eksisterende projekt
for at udnytte fordelene.

> Og derfor (og fordi JQuery ikke lærer nogen noget om js) kan "JQuery"
> ikke være svaret på spørgsmål om js.

Nej, det er der vist heller ikke nogen der har påstået

> Netop derfor, vil det være en god ide, med en gruppe til frameworks.

Jep.

Martin

---

Martin Larsen:
> Birger Sørensen wrote:
8X
>> Og den ligger heller ikke i "hold da op hvor bliver det hele meget
>> lettere når man bruger jQuery" - så ender man med at hente 24Kb, hver
>> gang der skal bruges 6 linier.
>
> For så vidt også enig. Men som jeg skrev, var de små eksempler blot for at
> tydeliggøre ideen. Normalt vil det være ganske komplekse sider der arbejdes
> på.

Måske noget med holdninger. Jeg mener langt de fleste "hjemmesider" -
og i hvert flad dem der spørges om her i NG - er for små til at det kan
betale sig at bruge JQuery.

>> For mig må det være en afvejning af, hvor mange af *brugerens*
>> resourcer, der spildes på ting der ikke er brug for. Ikke en opgørelse
>> af, hvor mange reourcer man selv sparer ved at bruge det.
>
> I princippet enig, det er en afvejning. Men hvis du mener at 24k er er
> problem for brugerens resourcer, så er jeg meget uenig. Det er langt
> vigtigere at siden er kompatibel i (helst) alle browsere. Du skal sidde på en
> overordentlig langsom forbindelse for at finde download af 24k et problem.

Det er ikke kun et spørgsmål om at hente 24K. Det er et spørgsmål om
versionscheck med google, måske hentning af ny version, udpakning,
oprettelse af threads til afvikling (af funktionalitet der ikke er brug
for), osv.
Min kæreste har ofte 8-10 tabs åbne. De bør alle have separate tråde
til det der forgår i dem. Så snakker vi om 10x spild af min. 24Kb
resourcer, i værste fald.
Så din JQuery, hvor der ikke er brug for den, kan sagtens være med til
at gøre afviklingen af alt muligt andet langsommere end den egentlig
behøver at være. Alt for at du kan spare lidt tid og samtidig gøre dine
projekter billige for din arbejdsgiver.
Hvor er det du sparer, og hvem betaler for den besparelse?

8X
>> Og derfor (og fordi JQuery ikke lærer nogen noget om js) kan "JQuery"
>> ikke være svaret på spørgsmål om js.
>
> Nej, det er der vist heller ikke nogen der har påstået

Men du skulle lige bemærke, at JQuery kan ordne getElementByClassName()
i et snuptav...
Så er der een til der kan spilde resourcer, og gøre browsing på nettet
unødvendigt langsommere...


8X

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Måske noget med holdninger. Jeg mener langt de fleste "hjemmesider" - og
> i hvert flad dem der spørges om her i NG - er for små til at det kan
> betale sig at bruge JQuery.

Det tror jeg at du langt hen ad vejen har ret i.

> Alt for at du kan spare lidt tid og samtidig gøre dine projekter billige for din arbejdsgiver.
> Hvor er det du sparer, og hvem betaler for den besparelse?

Faktisk rammer du meget godt, bortset fra at jeg vil mene at jeg sparer
mere end *lidt* tid. Men ja, udviklingen bliver billigere, og det er
vigtigt for kunderne. Brugt rigtigt har det ingen negativ effekt for
brugerne. Brugt forkert, så kan det sagtens have en negativ effekt.
Præcis som dårligt hjemmestrikket JS kan have det.

Jeg arbejder som selvstændig men er også tilknyttet et konsulentfirma.
Her har jeg konstateret en stigende efterspørgsel på jQuery, så også ud
fra et jobmæssigt synspunkt har det været udbytterigt.

> Men du skulle lige bemærke, at JQuery kan ordne getElementByClassName() i et snuptav...
> Så er der een til der kan spilde resourcer, og gøre browsing på nettet unødvendigt langsommere...

Jeg har selv været meget glad for lære jQuery at kende, så jeg mente det
kunne være en hjælp. Afhængigt af brugerens mål. Det kan kun brugeren
selv vide. Sidenhen har han udtrykt ønske om at lære JS fra bunden, og
det bifalder jeg absolut. Men det kunne jeg ikke vide da jeg skrev mit
første indlæg.

---

Den 04-03-2010 17:08, Martin Larsen skrev:
> Birger Sørensen wrote:

>> Men du skulle lige bemærke, at JQuery kan ordne
>> getElementByClassName() i et snuptav...
>> Så er der een til der kan spilde resourcer, og gøre browsing på nettet
>> unødvendigt langsommere...
>
> Jeg har selv været meget glad for lære jQuery at kende, så jeg mente det
> kunne være en hjælp. Afhængigt af brugerens mål. Det kan kun brugeren
> selv vide. Sidenhen har han udtrykt ønske om at lære JS fra bunden, og
> det bifalder jeg absolut. Men det kunne jeg ikke vide da jeg skrev mit
> første indlæg.

Lige en enkelt kommentar som "uindviet", så skal jeg nok holde ;)

Jeg synes stadig det lader lidt til, at man - fra begge sider - ikke
rigtigt accepterer den anden teknik. Jeg tror, det forvirrer en evt.
spørger, at der ikke er nogle grundlæggende ting, man er enige om, eller
i hvert fald ikke er uenige om.

Jeg foregriber formodentlig beguvenhedernes gang, for JQuery er vel
forholdsvist nyt i nyhedsgrupperne, så egentlig burde man først kunne
udtale sig, når der har været tilstrækkelige Real Life "cases", som kan
danne baggrund for en slags konklusion. Sådan man ved nogenlunde, hvor
hvad er bedst.

Men det første står stadig, synes jeg. Der mangler, man accepterer, der
er to teknikker, og de er kommet for at blive begge. Og at begge har
berettigelse, bare ikke nødvendigvis i samme situationer. Teknikkerne
skal vel ikke sammenlignes imod hinanden udfra en "skal kunne
alt"-situation, men samlet op imod hver specifikke "case". Kræver det,
man sluger kameler?

PS: Nu svarede jeg lige på din, fordi det var den sidste i "rækken".
Mine synspunkter er ret generelle - selv om jeg dog også har ændret mig
lidt henad vejen.


MVH
Rune Jensen

---

Rune Jensen forklarede:
> Den 04-03-2010 17:08, Martin Larsen skrev:
>> Birger Sørensen wrote:
>
>>> Men du skulle lige bemærke, at JQuery kan ordne
>>> getElementByClassName() i et snuptav...
>>> Så er der een til der kan spilde resourcer, og gøre browsing på nettet
>>> unødvendigt langsommere...
>>
>> Jeg har selv været meget glad for lære jQuery at kende, så jeg mente det
>> kunne være en hjælp. Afhængigt af brugerens mål. Det kan kun brugeren
>> selv vide. Sidenhen har han udtrykt ønske om at lære JS fra bunden, og
>> det bifalder jeg absolut. Men det kunne jeg ikke vide da jeg skrev mit
>> første indlæg.
>
> Lige en enkelt kommentar som "uindviet", så skal jeg nok holde ;)
>
> Jeg synes stadig det lader lidt til, at man - fra begge sider - ikke rigtigt
> accepterer den anden teknik. Jeg tror, det forvirrer en evt. spørger, at der
> ikke er nogle grundlæggende ting, man er enige om, eller i hvert fald ikke er
> uenige om.
>
> Jeg foregriber formodentlig beguvenhedernes gang, for JQuery er vel
> forholdsvist nyt i nyhedsgrupperne, så egentlig burde man først kunne udtale
> sig, når der har været tilstrækkelige Real Life "cases", som kan danne
> baggrund for en slags konklusion. Sådan man ved nogenlunde, hvor hvad er
> bedst.
>
> Men det første står stadig, synes jeg. Der mangler, man accepterer, der er to
> teknikker, og de er kommet for at blive begge. Og at begge har berettigelse,
> bare ikke nødvendigvis i samme situationer. Teknikkerne skal vel ikke
> sammenlignes imod hinanden udfra en "skal kunne alt"-situation, men samlet op
> imod hver specifikke "case". Kræver det, man sluger kameler?
>
> PS: Nu svarede jeg lige på din, fordi det var den sidste i "rækken". Mine
> synspunkter er ret generelle - selv om jeg dog også har ændret mig lidt henad
> vejen.
>
>
> MVH
> Rune Jensen

Jeg syntes ikke umiddelbart, man kan tale om to forskellige teknikker.
JQuery er en overbygning til js - uden js kan det ikke noget. Så det er
samme teknik, men en anderledes semantik. Der er bare nogen der har
gjort alt det vanskelige for programmøren. Og det har en absolut
svaghed ved, at man ikke kan vælge det ud, der skal bruges.

Som jeg ser det, så er JQuery, en slags "bibliotek", med en farlig
masse funktionalitet, du kan hente ind og bruge på din side, så du
slipper for at programmere selv.
Og det er helt fint.
Det kan spare an masse arbejde - hvis man virkelig har brug for alt det
det kan. Har man ikke det, spilder man en masse af brugernes (de
mennesker, der besøger de sider der anvender det) resourcer.

Så brugt rigtigt og fuldt, er det helt fint.
Til småopgaver er det uanvendeligt.

Du kan ikke gøre mere, ved at anvende JQuery, men du kan gøre det
nemmere.

Jeg tror ikke der skal sluges kameler, for vi er enige langt hen ad
vejen.
Den største forskel er vel, at Martin finder det OK, at introducere
JQuery for folk der ikke har brug for det, hvor jeg mener det er
forkert at tilbyde folk genveje, der koster en masse unødige resourcer
- ikke for programmøren, men for resultatets brugere.
Ikke at jeg mener, de ikke må kende til det. Men de skal være i stand
til at vudere, om de nu også har brug for det først, og om det ekstra
resourceforbrug, er besparelsen i arbejde (og erfaring og indlæring)
værd.

Birger.

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Jeg tror ikke der skal sluges kameler, for vi er enige langt hen ad vejen.

Ja, faktisk stort set hele vejen igennem, tror jeg.

Det eneste punkt hvor vi nok ikke bliver enige er at man spilder
brugernes resourcer ved at downloade 24k. Jeg tror ikke på de kan mærke
det i praksis. Jeg skriver i praksis, for du kan da godt se i Firebug
hvor mange ekstra millisekunder det tager, men det generer næppe ret mange.

Som *princip* er jeg enig. Fx kan jeg mærke på min bærbare hvordan
flash-bannere og andet unødvendigt indhold sætter blæseren igang og
tærer på batteriet, og gør den ubehageligt varm at have på skødet!

Det er altså et spørgsmål om at vi har foreskellige grænser, og her tror
jeg som sagt ikke vi bliver enige.

Men hvad, det behøver vi jo heller ikke. Hele tråden har været sober, og
det har glædet mig. Jeg har set alt for mange tråde i nyhedsgrupperne
hvor uenighed fører til personangreb og mudderkastning.

Hilsen
Martin

---

Den 04-03-2010 19:35, Martin Larsen skrev:
> Birger Sørensen wrote:
>
>> Jeg tror ikke der skal sluges kameler, for vi er enige langt hen ad
>> vejen.
>
> Ja, faktisk stort set hele vejen igennem, tror jeg.
>
> Det eneste punkt hvor vi nok ikke bliver enige er at man spilder
> brugernes resourcer ved at downloade 24k. Jeg tror ikke på de kan mærke
> det i praksis. Jeg skriver i praksis, for du kan da godt se i Firebug
> hvor mange ekstra millisekunder det tager, men det generer næppe ret mange.
>
> Som *princip* er jeg enig. Fx kan jeg mærke på min bærbare hvordan
> flash-bannere og andet unødvendigt indhold sætter blæseren igang og
> tærer på batteriet, og gør den ubehageligt varm at have på skødet!
>
> Det er altså et spørgsmål om at vi har foreskellige grænser, og her tror
> jeg som sagt ikke vi bliver enige.

Næh, men man kan måske nærme sig hinanden... henad vejen ;)

> Men hvad, det behøver vi jo heller ikke. Hele tråden har været sober, og
> det har glædet mig. Jeg har set alt for mange tråde i nyhedsgrupperne
> hvor uenighed fører til personangreb og mudderkastning.

Jeg vil prøve at holde det lidt generelt, hvor muligt..

Jeg tror, det er farligt, at afvise en metode eller teknologi, fordi den
ikke er "korrekt". Det kan i sidste ende gøre, man mister lysten i det
hele taget, hvis det f.eks. er en begynder (jeg tænker her på andre
teknologier igennem tiden). Jeg skriver ikke dette som "indviet", men af
egne fejltagelser i forbindelse med vejledning.

Det helt store problem med de frameworks (set fra min side), det er, at
de ikke har fundet en plads endnu. Det er stadig en slags konkurrent på
en eller anden måde til "ren javascript".

Det kommer formentlig af, at det stadig er så nyt, så folk ved endnu
ikke helt, hvor det er nyttigt og ikke nyttigt at bruge det, bare at det
er nemt. Det gør, at selv professionelle sider henter libraries ind en
masse, jeg har set en side, som havde tre forskellige frameworks - plus
plugins, og det giver selvfølgelig frameworks et dårligt ry blandt dem,
som så ved, hvad det er "korrekt".

Det svarer lidt til, at brugen af frameworks er på samme niveau nu, som
den første hjemmeside, man laver. Min var plastret til med
JAVA-applets-effekter og Flash-memuer, Javascript-follow-the-mouse,
aniGIFfer (dog mest i begyndelsen), frames, og så var designet i
tabeller (og i Frontpage 98).

Ingen af de metoder i sig selv er for så vidt forkerte, det var brugen
af dem i den konkrete situation, som var det, men det vidste jeg jo
ikke, jeg var bare nysgerrig,

I dag, så er JAVA-applets nyttige til login i banken, Flash bruges til
reklamer (nåhja, og bliver blocked af AdBlockFF ;) ), frames har faktisk
også sin berettigelse - har jeg fundet ud af - det er ellers stadig lidt
tabu i webdesigngrupperne som metode, ligesom tabeldesign godt kan
forsvares i visse tilfælde (f.eks. avancerede forme, hvor det er
vigtigt, at alt står korrekt). Så man kan ikke afvise dem pga. de er
"ukorrekte" i sig selv, men man skal kende fordele og ulemper udfra
formålet, og foretage sit valg udfra det.

Men indtil man så finder ud af, hvad de frameworks kan bruges til, så
vil diskussionerne nok gå, og det er vel naturligt nok.. som "uindviet"
kan jeg bare ikke give nogen "løsning", andet end tid...

Optimalt, så spørger man vel oplægsstilleren hvad det skal bruges til,
måske også dennes viden, så man har noget at gå efter, og så kan man
give fordele og ulemper ved valgt metode, så kan folk selv bestemme.

Dette gælder så ikke kun specifikt frameworks - det er sådan jeg
forsøger at vejlede om f.eks. Flash. Når folk har fået oplyst fordele og
ulemper, kan man ikke gøre mere. Så har brugeren de nødvendige data at
foretage et valg udfra, i stedet for at "vælge i blinde".

Men når metoden så er valgt, så tager man den derfra, så er teknologien
i sig selv ikke til diskussion mere. Jeg synes selv, det er sjældent når
jeg bliver spurgt, at jeg afviser en valgt metode, hvis der er grundlag
for den (hvis spørgeren kan argumentere for den som bedst til formålet).
En godt argumenteret metode i situationen, er efter min mening den
rigtige metode.


MVH
Rune Jensen

---

Den 04-03-2010 19:35, Martin Larsen skrev:
> Birger Sørensen wrote:
>
>> Jeg tror ikke der skal sluges kameler, for vi er enige langt hen ad
>> vejen.
>
> Ja, faktisk stort set hele vejen igennem, tror jeg.
>
> Det eneste punkt hvor vi nok ikke bliver enige er at man spilder
> brugernes resourcer ved at downloade 24k. Jeg tror ikke på de kan mærke
> det i praksis. Jeg skriver i praksis, for du kan da godt se i Firebug
> hvor mange ekstra millisekunder det tager, men det generer næppe ret mange.

Hmmm... en generel betragtning: Hvis tid er et spørgsmål, så vil jeg
kigge på dette parameter med "størrelse", og så er det ikke helt uvigtigt.

Jeg er ikke helt sikker på, hvornår og hvornår ikke det ellers er
vigtigt, men er det en salgsside, så er tid for mig et sådant parameter
i større eller mindre grad.

Her ville jeg så, hvis det var en færdig side, tage det oppefra, og
optimere, hvor der er mest at hente og nedefter. GZIPping bør kunne tage
en del. Optimering af billeder også, måske. Database og serverside også.
Måske når man så til Javascripten, måske ikke. Men jeg vil ikke sige, at
tid - downloadtid og den "response"-tid som går imellem brugeren
forespørger, til der kommer resultat er uvigtig. Specielt ikke, hvis det
er en applikationsside (AJAX), så forventer brugerne absolut umiddelbar
respons, og så er koden hypervigtig.

Men nok ville jeg i stedet kigge på inden, jeg implementerer kode i det
hele taget, hvad der er mest optimalt.

24kb her og 24kb der, kan godt give en del. Ikke fordi jeg er modstander
af frameworks af denne grund, og 24kb skal ikke være afgørende slet
ikke, hvis de ikke er vigtige i situationen. Men jeg mener i det samlede
billede, i forhold til formålet, og det iøvrigt det at "følge best
practise", når du skriver "kan ikke mærke det i praksis". Følger man
best practise ét sted fra start, hentes måske 2-3 millisekunder. Gør man
det alle steder, hentes måske et sekund?

Yahoo har lavet nogle research-resultater, som viste mærkbar nedgang i
besøgende, med en ekstra downloadtid på ét sekund - tror, det var på
både eBay og Yahoo selv, det blev testet.

Jeg ville også nøje overveje teknologien til en mobilside. Hvilken glæde
har jeg af, min hjemmeside går ned, fordi den æder batteriet op af
dårlig kodning/forkert anvendelse af teknologien?

Men på en alm. familieside, f.eks. næh, der har det nok ikke nogen
betydning, og her ville jeg nok ikke overveje den del som specielt
vigtig i forhold til indholdet og opsætningen af siden, som jeg ville
finde vigtigere at bruge tid på.

Jeg synes stadig, man skal kigge på det udfra anvendelse og formål, ikke
udfra teknologien selv, og det er det, jeg har forsøgt at fortælle med
mine indlæg ;)


MVH
Rune Jensen

---

Rune Jensen wrote:

> Jeg synes stadig, man skal kigge på det udfra anvendelse og formål, ikke
> udfra teknologien selv, og det er det, jeg har forsøgt at fortælle med
> mine indlæg ;)

Og jeg er sådan set enig hele vejen igennem, så i stedet for specifikt
at kommentere de mange ting du kommer ind på, vil blot takke for dit
bidrag

Hvis jeg dog skal trække en enkelt ting frem, så er det helt rigtigt at
man i hvert tilfælde skal overveje om der skal benyttes et framework, og
i givet fald hvilket, så man undgår disse hjernedøde blandinger af tre
frameworks - det er jeg også stødt på!

Martin

---

Martin Larsen skrev:

>
> Mit eksempel synes jeg fx er uhyre læsbart:
>
> $("#udgifter td.total).css("color","red");
>
Skal der være et ulige antal anførselstegn?

Det generer mig...


--
Jeg foretrækker min the tilberedt efter BS6008

---

Leif Neland wrote:

> Skal der være et ulige antal anførselstegn?

Nej det er en tyrkfjel. Det skal være

$("#udgifter td.total").css("color","red");