logi sisse meist KKK

Tahaks teiste arvamust teemal - kas panna HTML kokku JS poolel või koostada see serveris ning see kasutajale ette sööta. Eelkõige puudutab see siis AJAXi reponse - ilus oleks nagu korralik JSON saata ning selle põhjal renderdada, samas kohati tundub aga mõistlikum siiski serveri poolel see kokku panna ja hiljem lihtsalt DOMi lükata.

stackoverflow.com lehelt leidsin vastuseks, et soovitatakse serveri pool siiski kokku panna:

Please, don't use Javascript to layout your pages. Only use it where it is needed.

Despite recent enhancements and standardizations, Javascript is still typically slow, difficult to be completely compatible (think old IE and others), and not so compatible with some screen readers and scrapers/search engines.

Miinus on muidugi asjal see, et JS poolel oleks veel erinev syntax lisaks. Millised on teie kogemused/arvamused?

küsitud Oct 24 '11 at 17:44

Kaspar%20Kalve's gravatar image

Kaspar Kalve
133118


Nagu enamiku tarkvaraarenduse probleemide puhul tuleks siingi lähtuda DRY printsiibist: ära korda ennast.

Kui sedasama HTML-i on tarvis toota nii AJAXi läbi lehte uuendades kui lehe staatilise versiooni jaoks, siis on tark hoida selleks vajalikku loogikat vaid ühes kohas. Selleks näen ma kahte varianti:

  • HTML tehakse serveri poolel.
  • HTML-i koostamise loogika on eraldi moodulis, mida nii brauseri kui serveri pool kasutada saavad. Seda on lihtne rakendada kui serveri pool on samuti JavaScriptis, a'la NodeJS.

Enamik veebilehti peaks olema kättesaadavad ka ilma JavaScripti abita, sest sa ju soovid et Google su lehte indekseeriks. Samas JavaScripti-mahuka veebirakenduse puhul, mille staatiline versioon ei omaks erilist mõtet (a'la Google Mapsi peale ehitatud visuaalne tööriist), võid piirduda HTML-i genereerimisega üksnes JavaScripti poolel.

Kiiruse argument on, nagu enamasti ikka, teisejärguline - selleks tuleks mõõta kas sinu konkreetsel juhul üks või teine moodus annab kiiruses võitu või mitte.

link

vastatud Oct 25 '11 at 00:49

Rene%20Saarsoo's gravatar image

Rene Saarsoo ♦♦
1.1k101121

Olenemata kas tegu on "klassikalise" veebi või rakendusega võib need andmed, mida kuvatakse sisseloginud kasutajale (ning mis seetõttu on ka kõige mittestaatilisemad, sest kuvatakse kõikidele kasutajatele eraldi) brauseri poole peal kokku panna - ükski robot neid indekseerima ei pea.

(Nov 09 '11 at 12:13) Andris

Klassikalises veebis tuleks üldse võimalikult vähe javascripti kasutada (klassikaline tähendab tavalise sisu näitamist nagu kodulehtedel, foorumid, blogid jms). Juba kasvõi otsingumootorite pärast.

Mitteklassikalises veebis (veebiprogrammid, siseveebid, erirakendused jms) on mu meelest just õigem kasutada lähenemist, kus server annab json objekti ja edasi töötleb seda brauser. Satun alatihti olukordadesse, kus tuleb näidata mingit infot näiteks nimekirjas ja kui kasutaja klikkab võib hiirega üle läheb objektist, siis tuleb näidata rohkem infot kui esialgu näha oli. Sellisel juhul tundub ainuõige võtta see täiendav info saadud JSON objektist ning jooksvalt html kokku laduda.

link

vastatud Oct 25 '11 at 14:42

Kaiko%20Kaur's gravatar image

Kaiko Kaur
2307712

Kas poleks võimalik neid kaht lähenemist niimoodi ühendada, et pritsida serverist välja HTML (või XML+XSLT), kus lisainfo on kohe olemas, aga nähtamatu (siis on vähemalt põhitekst saadav kätte ka JS-vaeguritele, sealhulgas otsimootoritele) ja vajadusel kasutatakse JS selle nähtavaks tegemiseks ja taas peitmiseks?

Aga ma olen veebiprogrammeerimisega väga vähe tegelenud, nii et see võib olla ka mingi jube häkk, mille puudusi ma väheste kogemuste tõttu lihtsalt näha ei oska.

(Oct 26 '11 at 11:04) Ahto Truu ♦♦

Saab küll neid ühendada. Nii on tehtud ka pinu avalehel.

Ma proovisin leida mõtteid, et miks ma nii tahaksin pigem json-i tõmmata ja seda kasutada, aga liiga hästi ei suuda seda argumenteerida.

(Nov 03 '11 at 10:48) Kaiko Kaur

Põhjus, miks ma pigem json-it eelistan ja html-i ei taha vastuseks kasutada on ilmselt välja kujunenud mõttemall, et server on server ja brauser on klient. Server peaks pakkuma API-t ja hoidma vajalikke faile kliendi jaoks. Server ei peaks olema liiga spetsiifiline kliendi jaoks.

(Nov 04 '11 at 10:37) Kaiko Kaur

Kui plaanid AJAXit kasutada osaliste leheuuenduste (partial page update) jaoks, siis tagastades AJAXi päringu vastusena HTMLi saad taaskasutada seda koodi, mis sul algse lehe genereeris. Minu meelest piisav argument, et igal võimalusel kasutada AJAXi asemel AJAHi (Asynchronous JavaScript And HTML). Ma oletan ka, et HTMLi parsimine brauseri poolt on kiirem, kui JSONi parsimine Javascripti parseri poolt + Javascriptis DOM manipuleerimine.

link

vastatud Oct 24 '11 at 20:31

Tambet%20Matiisen's gravatar image

Tambet Matiisen ♦♦
77791125

edited Oct 25 '11 at 10:49

Ainukese juhusena võib välja tuua olukorra, kus üritad browseri põhist programmi võimalikult reaktiivse ning kiirena hoida. Ehk hoiad ühte WebSocketit lahti ning kannad selle kaudu kiiresti json andmeid + template üle ning paned siis browseri poolel kokku.

link

vastatud Oct 24 '11 at 21:59

egon's gravatar image

egon ♦♦
771239

Sinu vastus
lülita eelvaade

Jälgi seda küsimust

By Email:

Pärast sisselogimist saad tellida muudatuse teavitusi siit

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *kaldkiri* või __kaldkiri__
  • **paks kiri** või __paks kiri__
  • link:[tekst](http://url.com/ "pealkiri")
  • pilt?![alt tekst](/path/img.jpg "pealkiri")
  • nummerdatud nimekiri: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • põhilised HTML märgendid on samuti toetatud

Pinu tööpakkumised

kõik pakkumised »

Küsimuse sildid:

×18
×6
×6
×1

küsitud: Oct 24 '11 at 17:44

nähtud: 3,525 korda

viimati uuendatud: Nov 09 '11 at 12:13

Litsents: Creative Commons Attribution License | Kontakt: info@pinu.ee