Forum » Programiranje » JS frameworks: knockoutJS, angularJS, react, ...
JS frameworks: knockoutJS, angularJS, react, ...
kuall ::
Kle je ratala mau zbrka z vsemi temi frameworki.
V bistvu je skupno vsem tem knjižnicam instantno komuniciranje s serverjem in instant osveževanje podatkov v clientu, brez da se počasi osveži cela stran, kot je bilo na tradicionalen način.
Ampak je en problem:
Te JS knjižnice so tako narejene, da narediš request, dobiš podatke iz serverja in potem spremeniš html z javascriptom (s funkcijami od frameworka), da uporabniku posodobiš podatke.
Ampak tu ko osvežiš podatke v html kontroli pride do podvajanja kode na klientu in serverju, kar je zelo slabo za programiranje: ko stran prvič naložiš moraš isto podatke bindat na html kontrole iz serverja, potem pa celoten html cele strani pošlješ klientu.
Da se izognijo temu podvajanju tako vidiš strani, ki naložijo vsako html kontrolo posebej s temi JS knjižnicami, za vsako kontrolo naredijo request iz JS kode. Kar pa spet upočasni stran po moje, če moraš čakat za vsak element, da se naloži. Po moje preveč requestov upočasni stran. Pa tudi pretiravanje z JS zna upočasnit stran.
Zdej me pa zanima, ali obstaja nek framework, ki ta problem reši?
Idealna rešitev bi bila, da bi imel nek framework, ki bi imel skupno kodo in jezik za client in server data binding. Pol pa če bi hotel bindat celo stran ob prvem obisku bi klical funkcije iz serverja, če bi pa hotel bindat samo en element pa bi klical te funckije iz klienta.
Ena rešitev je, da z javascriptom kličeš server funkcijo, ki vrne že zgeneriran html od kontrole. S tem je samo ta problem, da prenašaš nepotreben html iz serverja, namesto da bi prenašal samo podatke, ki so se spremenili, kar malenkost upočasni stvar. To bi ta framework rešil: pač imel bi funkcijo bindControl(controlId), ki jo je možno klicat iz klienta ali serverja. Če bi jo klical iz klienta bi prenesla samo podatke in potem osvežila html kontrolo, če pa iz serverja pa bi zgenerirala html od kontrole in to dodala k htmlju cele strani.
Če kaj takega še ne obstaja bi bilo nujno naredit po moje.
V bistvu je skupno vsem tem knjižnicam instantno komuniciranje s serverjem in instant osveževanje podatkov v clientu, brez da se počasi osveži cela stran, kot je bilo na tradicionalen način.
Ampak je en problem:
Te JS knjižnice so tako narejene, da narediš request, dobiš podatke iz serverja in potem spremeniš html z javascriptom (s funkcijami od frameworka), da uporabniku posodobiš podatke.
Ampak tu ko osvežiš podatke v html kontroli pride do podvajanja kode na klientu in serverju, kar je zelo slabo za programiranje: ko stran prvič naložiš moraš isto podatke bindat na html kontrole iz serverja, potem pa celoten html cele strani pošlješ klientu.
Da se izognijo temu podvajanju tako vidiš strani, ki naložijo vsako html kontrolo posebej s temi JS knjižnicami, za vsako kontrolo naredijo request iz JS kode. Kar pa spet upočasni stran po moje, če moraš čakat za vsak element, da se naloži. Po moje preveč requestov upočasni stran. Pa tudi pretiravanje z JS zna upočasnit stran.
Zdej me pa zanima, ali obstaja nek framework, ki ta problem reši?
Idealna rešitev bi bila, da bi imel nek framework, ki bi imel skupno kodo in jezik za client in server data binding. Pol pa če bi hotel bindat celo stran ob prvem obisku bi klical funkcije iz serverja, če bi pa hotel bindat samo en element pa bi klical te funckije iz klienta.
Ena rešitev je, da z javascriptom kličeš server funkcijo, ki vrne že zgeneriran html od kontrole. S tem je samo ta problem, da prenašaš nepotreben html iz serverja, namesto da bi prenašal samo podatke, ki so se spremenili, kar malenkost upočasni stvar. To bi ta framework rešil: pač imel bi funkcijo bindControl(controlId), ki jo je možno klicat iz klienta ali serverja. Če bi jo klical iz klienta bi prenesla samo podatke in potem osvežila html kontrolo, če pa iz serverja pa bi zgenerirala html od kontrole in to dodala k htmlju cele strani.
Če kaj takega še ne obstaja bi bilo nujno naredit po moje.
mchaber ::
Preberi si SSR (server side rendering) implementacije React, Vue, Angular.
Marsikje se da pospesit(seveda zelo odvisno od primera) z uporabo websocketov.
Kar opisuješ bi lahko bil mogoče meteor.js link
Marsikje se da pospesit(seveda zelo odvisno od primera) z uporabo websocketov.
Kar opisuješ bi lahko bil mogoče meteor.js link
.
McAjvar ::
Te JS knjižnice so tako narejene, da narediš request, dobiš podatke iz serverja in potem spremeniš html z javascriptom (s funkcijami od frameworka), da uporabniku posodobiš podatke.
Ampak tu ko osvežiš podatke v html kontroli pride do podvajanja kode na klientu in serverju, kar je zelo slabo za programiranje: ko stran prvič naložiš moraš isto podatke bindat na html kontrole iz serverja, potem pa celoten html cele strani pošlješ klientu.
Da se izognijo temu podvajanju tako vidiš strani, ki naložijo vsako html kontrolo posebej s temi JS knjižnicami, za vsako kontrolo naredijo request iz JS kode. Kar pa spet upočasni stran po moje, če moraš čakat za vsak element, da se naloži. Po moje preveč requestov upočasni stran. Pa tudi pretiravanje z JS zna upočasnit stran.
Hm. Glede odebeljenega dela - malce se igračkam z Angularjem in Aurelio recimo, pa še nisem nikjer potreboval takšnega postopka, kot ga opisuješ. Strežnik načeloma skrbi za dostavo, obdelavo in shranjevanje podatkov, odjemalec (aplikacija v brskalniku) pa za prikaz in delo z njimi. Se pravi, če imaš dva spustna menija, boš strežnik pobaral zgolj za podatke, kako pa jih boš nato prikazal, je strežniku popolnoma vseeno.
Glede preveč requestov so pa tu zadeve, kot so minifikacija kode, konkatenacija več datotek v eno samo in tako dalje.
Bi rekel, da ni problem v ogrodjih, ki jih omenjaš, pač pa v opisanem načinu uporabe.
"[...] the advance of civilization is nothing
but an exercise in the limiting of privacy."
- Isaac Asimov
but an exercise in the limiting of privacy."
- Isaac Asimov
kuall ::
Saj tisto kar sem opisal ni nič posebnega, najbrž si narobe razumel. Server zgenerira html in ga pošlje klientu. To je klasičen način. Zdej pa so ti novi načini osveževanja podatkov z ajax z Javascriptom, da osvežiš instantno samo del strani s podatki iz serverja in od tod ta zmeda, ker moraš 2x napisat isto kodo za filat podatke v html: v js in v server jeziku.
Drgač jaz uporabljam ASP.NET Web Forms in C#. Je pa najbrž res prihodnost v Javascriptu (node.js), ko se bodo stvari mau normalizirale, ker takole menjavat med jeziki je precej potratno, najbolj kvalitetno se programira, če ni treba menjavat. Javascript ima to veliko prednost, da teče v vseh brskalnikih, te prednosti nima noben drug jezik, zato se bo širil v uporabi, ker se ljudem ne da menjavat med jeziki niti ni učinkovito.
Teoretično pa bi se po moje dalo tako naredit, da imaš skupno funkcijo bindControl (controlId, data), ki deluje na serverju in na klientu.
Ker zdej je v mojem primeru tako, da na serverju bindam takole:
ctl.Text = dataReader["field"];
v klientu pa približno takole:
ctl.innerHtml = json ["field"];
Podvajanje kode.
Jaz sem se podvajanju kode tako ognil, da mi web servis vrne zgeneriran html in potem ga z javascriptom vstavim v stran. Mau potratno prenašat še html namest da bi samo podatke ampak dela še zmeraj hitro.
En dober način za učenje je ta, da se spomniš kako bi stvar teoretično morala delat, pol pa iščeš, če kaj takega že obstaja, velika verjetnost je, da je kdo že to ustvaril, če pa ni pa je priložnost, da sam narediš to novo uporabno stvar.
Je pa zanimiv tale meteorJS, bom moral enkrat to vse bolje pregledat, naredit kakšen testni web app.
Drgač jaz uporabljam ASP.NET Web Forms in C#. Je pa najbrž res prihodnost v Javascriptu (node.js), ko se bodo stvari mau normalizirale, ker takole menjavat med jeziki je precej potratno, najbolj kvalitetno se programira, če ni treba menjavat. Javascript ima to veliko prednost, da teče v vseh brskalnikih, te prednosti nima noben drug jezik, zato se bo širil v uporabi, ker se ljudem ne da menjavat med jeziki niti ni učinkovito.
Teoretično pa bi se po moje dalo tako naredit, da imaš skupno funkcijo bindControl (controlId, data), ki deluje na serverju in na klientu.
Ker zdej je v mojem primeru tako, da na serverju bindam takole:
ctl.Text = dataReader["field"];
v klientu pa približno takole:
ctl.innerHtml = json ["field"];
Podvajanje kode.
Jaz sem se podvajanju kode tako ognil, da mi web servis vrne zgeneriran html in potem ga z javascriptom vstavim v stran. Mau potratno prenašat še html namest da bi samo podatke ampak dela še zmeraj hitro.
En dober način za učenje je ta, da se spomniš kako bi stvar teoretično morala delat, pol pa iščeš, če kaj takega že obstaja, velika verjetnost je, da je kdo že to ustvaril, če pa ni pa je priložnost, da sam narediš to novo uporabno stvar.
Je pa zanimiv tale meteorJS, bom moral enkrat to vse bolje pregledat, naredit kakšen testni web app.
Greg91 ::
Kot prvo, to niso ravno novi načini (ajax ipd.) Kot drugo pa, zakaj bi server sploh moral kakršenkoli html dokument generirati (google: REST API)? Naj ti raje servis vrne json, pol pa ti predstavi na klientu podatke kakorkoli želiš. Pa se boš izognil tudi podvajanju kode.
win64 ::
Je pa potrebno opozorit, da je tak način nalaganja(MVVC) primeren za spletne aplikacije, medtem pa za dobro spletno stran nujno potrebuješ tudi server rendering.
Najbolj pomemben argument je, da uporabniku ni potrebno čakati, da se naložijo vse skripte preden lahko pride do vsebine.
Drugače pa imaš recimo že star sistem v ASP.NET, ki ti ponuja ajax renderiranje posameznih delov strani. V osnovi potrebuješ zelo malo dodatno kode(definicije) v primerjavi z ne AJAX renderiranjem. Se pa vse renderira na strežniku(ni pa nujno). Če te zanima več glej za UpdatePanel.
Najbolj pomemben argument je, da uporabniku ni potrebno čakati, da se naložijo vse skripte preden lahko pride do vsebine.
Drugače pa imaš recimo že star sistem v ASP.NET, ki ti ponuja ajax renderiranje posameznih delov strani. V osnovi potrebuješ zelo malo dodatno kode(definicije) v primerjavi z ne AJAX renderiranjem. Se pa vse renderira na strežniku(ni pa nujno). Če te zanima več glej za UpdatePanel.
krho ::
Kot drugo pa, zakaj bi server sploh moral kakršenkoli html dokument generirati
Zato, ker drugače traja pol ure, da se ves javscript naloži, ter potem še podatki prenesejo. Vmes pa buljiš prazen zaslon.
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net
kuall ::
Naj ti raje servis vrne json, pol pa ti predstavi na klientu podatke kakorkoli želiš. Pa se boš izognil tudi podvajanju kode.
To je za moje pojme pretiravanje z Javascript kodo, ker upočasni stran. Nimam rad takih strani, sem jih pa že videl.
Ajax je še vedno nova tehnologija zato, ker se še vedno lovijo s temi js frameworki, kako to naredit prijazno programerju. Vse te nejasnosti pa pridejo iz komuniciranja klienta s serverjem, ker je bil internet na začetku tako narejen, da je kazal samo statične html strani.
Pa tudi teoretično gledano je jasno, da je to počasnejši način kot pa če server renderira html. Ker najpočasnejši del je še vedno komunikacija. Če ti server vse naredi in vrne v 1 koraku sigurno ne najdeš hitrejšega načina kot to, hitrost pa je pri straneh najbolj važna stvar, ker noben noče čakat na počasne strani.
UpdatePanel poznam in ga na veliko uporabljam. Ampak se mi spet ne zdi preveč v redu. Ker spet ni jasno na serverju, katere podatke je treba prebrat, ponavadi se prebere podatke od cele strani. Pa tudi ni tako hiter način to kot Ajax. Imaš pa še tisti neumni viewstate.
McAjvar ::
Si izmeril? Kakšne pa so razlike? Ali hočeš reči, da je kakršnakoli uporaba JSONa za prenos podatkov pretiravanje? Če ja, prosim utemelji. Sicer me zanima, kako to, da se je recimo Google odločil tudi za takšen pristop, pa je zelo znan po tem, da strašno radi optimizirajo vse možno, dokler jih prinese prednosti za uporabnike oziroma prihranke pri delovanju. Gledajo na skoraj vsak prenešen byte, pa vendar uporabljajo Javascript in JSON.
Katere strani daš lahko kot primer, kjer pretiravajo z Javascriptom in jih nimaš rad? In katere se ti dopadejo?
AJAX je že precej stara reč. Kaj razni frameworki počnejo in kako poskušajo razvijalcem olajšati ali "olajšati" zadevo, je ločen problem. Lahko jih tudi ignoriraš in neposredno uporabljaš XMLHttpRequest.
Seveda je vse skupaj odvisno od tega, kaj potrebuješ in kakšne imaš omejitve, vendar bi rekel, da v neki spletni strani, ki uporablja knjižnice, ki so v široki uporabi ter jih vključuje preko kakega CDN. To pri dosti uporabnikih lahko pomeni, da imajo vse podatke že cachirane, tako da ni nobenega novega prenosa, le nekaj milisekund traja, da se npr. jQuery naloži, potem pa lahko narediš klic na svoj strežnik, ki ti namesto nekaj 100KB HTMLja posreduje le nekaj 10KB velik JSON, ki ga z Javascriptom nato pretvoriš v kakršnokoli obliko želiš. Časi tu za samo obdelavo ter prikaz se merijo v milisekundah, zato me res zanima tvoj način uporabe, da imaš takšne težave. Dodatna prednost je lahko tudi, da strežniku posreduješ le nek minimum podatkov, ki so se v danem trenutku ali obrazcu spremenili in od strežnika dobiš tudi le set sprememb. Če prikazuješ nekaj tisoč vrstic podatkov in vsakokrat prejmeš le spremembe, ki jih uporabniku lahko sproti prikazuješ, je to precej hitreje oziroma odzivneje in z manj prenosa podatkov, kot vsakokratna priprava HTMLja na strežniku, prenos in vsakokratni ponovni prikaz.
Hočem rečt, Javascript je, če ga znaš uporabiti, zelo močno orodje in nič kaj opazno ne upočasni strani. Če ga prav uporabiš, pripomore k boljši uporabniški izkušnji (ne šteje namreč le hitrost), tudi sami hitrosti prikazovanja podatkov, zmanjšanju količine prenešenih podatkov do klienta, itd.
Katere strani daš lahko kot primer, kjer pretiravajo z Javascriptom in jih nimaš rad? In katere se ti dopadejo?
AJAX je že precej stara reč. Kaj razni frameworki počnejo in kako poskušajo razvijalcem olajšati ali "olajšati" zadevo, je ločen problem. Lahko jih tudi ignoriraš in neposredno uporabljaš XMLHttpRequest.
Seveda je vse skupaj odvisno od tega, kaj potrebuješ in kakšne imaš omejitve, vendar bi rekel, da v neki spletni strani, ki uporablja knjižnice, ki so v široki uporabi ter jih vključuje preko kakega CDN. To pri dosti uporabnikih lahko pomeni, da imajo vse podatke že cachirane, tako da ni nobenega novega prenosa, le nekaj milisekund traja, da se npr. jQuery naloži, potem pa lahko narediš klic na svoj strežnik, ki ti namesto nekaj 100KB HTMLja posreduje le nekaj 10KB velik JSON, ki ga z Javascriptom nato pretvoriš v kakršnokoli obliko želiš. Časi tu za samo obdelavo ter prikaz se merijo v milisekundah, zato me res zanima tvoj način uporabe, da imaš takšne težave. Dodatna prednost je lahko tudi, da strežniku posreduješ le nek minimum podatkov, ki so se v danem trenutku ali obrazcu spremenili in od strežnika dobiš tudi le set sprememb. Če prikazuješ nekaj tisoč vrstic podatkov in vsakokrat prejmeš le spremembe, ki jih uporabniku lahko sproti prikazuješ, je to precej hitreje oziroma odzivneje in z manj prenosa podatkov, kot vsakokratna priprava HTMLja na strežniku, prenos in vsakokratni ponovni prikaz.
Hočem rečt, Javascript je, če ga znaš uporabiti, zelo močno orodje in nič kaj opazno ne upočasni strani. Če ga prav uporabiš, pripomore k boljši uporabniški izkušnji (ne šteje namreč le hitrost), tudi sami hitrosti prikazovanja podatkov, zmanjšanju količine prenešenih podatkov do klienta, itd.
"[...] the advance of civilization is nothing
but an exercise in the limiting of privacy."
- Isaac Asimov
but an exercise in the limiting of privacy."
- Isaac Asimov
BigWhale ::
Kot prvo, to niso ravno novi naÄini (ajax ipd.) Kot drugo pa, zakaj bi server sploh moral kakrĹĄenkoli html dokument generirati (google: REST API)? Naj ti raje servis vrne json, pol pa ti predstavi na klientu podatke kakorkoli ĹželiĹĄ. Pa se boĹĄ izognil tudi podvajanju kode.
Vse je odvisno kaj delas, za koga in za koliko ljudi. To kar se zadnje casa dogaja v JavaScript svetu je ze na robu blaznosti. :>
Kaj ti pomaga se tako dober REST API, ce mora potem client narediti 20 requestov samo zato, da dobi podatke za rendering potem pa se nadaljnih 20 na X razlicnih CDNjev, kjer dobi se ves ostali content? User pa medtem zeha in bulji v kak progress bar in caka, da se mu totally awesome single page app nalozi.
Problem JS frameworkov je ta, da dostikrat stvari zakomplicirajo po nepotrebnem. Ponavadi v projekt prinesejo se en milijon dependencijev. React boilerplate hello world je 120MB! :> To je insanity.
BigWhale ::
Hočem rečt, Javascript je, če ga znaš uporabiti, zelo močno orodje in nič kaj opazno ne upočasni strani. Če ga prav uporabiš, pripomore k boljši uporabniški izkušnji (ne šteje namreč le hitrost), tudi sami hitrosti prikazovanja podatkov, zmanjšanju količine prenešenih podatkov do klienta, itd.
Seveda, ampak Greg se zgoraj sprasuje zakaj bi sever sploh kakrsenkoli HTML posiljal clientu. To je ena skrajnost, ki ni vedno hitrejsa, vsaj ne za clienta.
Slo-Tech vrne pretezno HTML in strani se odpirajo v vecini prej kot v eni sekundi. Enr equest je 10 in nekaj KB html, ostane se nekaj CSSja, ostalo so images in nekaj vrstic JavaScripta. Sem not tlacit REST API in stvari komplicirat s kaksnim drugim pristopom je brez veze.
Pisanje sporocil pa brez zadrzkov uporablja AJAX in deluje povsem ok.
Da bi pa kr cel web obesil na REST APIje je pa norost. :)
McAjvar ::
@BigWhale: Vsekakor se strinjam, da je obešanje prav vsega na Javascript norost. Upam, da nisem napisal ničesar, kar bi dajalo vtis, da mislim kako drugače. Prav tako pa je tlačenje popolnoma vsega v HTML. Neko zdravo razmerje obojega je dobro najti.
Morda kualla le narobe razumem, ampak glede na prebrano se mi zdi, da Javascripta tam, kjer bi lahko pripomogel k večji hitrosti, ne uporablja tako, da bi lahko izkoristil razpoložljiv potencial, zato ima namesto delitve dela podvajanje.
Morda kualla le narobe razumem, ampak glede na prebrano se mi zdi, da Javascripta tam, kjer bi lahko pripomogel k večji hitrosti, ne uporablja tako, da bi lahko izkoristil razpoložljiv potencial, zato ima namesto delitve dela podvajanje.
"[...] the advance of civilization is nothing
but an exercise in the limiting of privacy."
- Isaac Asimov
but an exercise in the limiting of privacy."
- Isaac Asimov
BigWhale ::
Ce vsebina ni prevec interaktivna, potem ni prav nobene potrebe po JavaScriptu (za nalaganje same vsebine) in motoviljenju z AJAX klici in miljoni frameworkov.
Looooooka ::
Prvo se vprasaj kaj je sploh cilj. Ce je cilj samo ena spletna strannpotem upostevaj to kar je napisal BigWhale.
Ko gledas spletne strani, kjer je v zgodbi REST service in spletna stran z javascriptom(angular je tle zelo popularen) je razlog verjetno v tem, da hocejo imeti povsod uporabo istega vira. REST servisa. Tega lahko ponucajo ne samo za spletno stran ampak tudi za desktop aplikacijo in mobilno aplikacijo. Vecino angular kode lahko ponucas tudi za pisanje nativne aplikacije za ios, android in mislim da tudi windows phone s primernim frameworkom, ki zna te zadeve spravit v pravilno obliko(npr nativescript.org).
Torej si lahko vsi ti razvijalci tudi delijo kodo med tem, ko vsak razvija svoj del vsi pa uporabljajo isti REST service in se s samimi podatki in avtentikacijo ne rabijo ukvarjat.
Ti frameworki majo svoje mesto ampak za eno navadno spletno stran, ki nima nobenega namena biti nic drugega so pax nepotrebni.
Jamranje glede ajaxa in rendeneriranja je na mestu SAMO v tem primeru.
Ko gledas spletne strani, kjer je v zgodbi REST service in spletna stran z javascriptom(angular je tle zelo popularen) je razlog verjetno v tem, da hocejo imeti povsod uporabo istega vira. REST servisa. Tega lahko ponucajo ne samo za spletno stran ampak tudi za desktop aplikacijo in mobilno aplikacijo. Vecino angular kode lahko ponucas tudi za pisanje nativne aplikacije za ios, android in mislim da tudi windows phone s primernim frameworkom, ki zna te zadeve spravit v pravilno obliko(npr nativescript.org).
Torej si lahko vsi ti razvijalci tudi delijo kodo med tem, ko vsak razvija svoj del vsi pa uporabljajo isti REST service in se s samimi podatki in avtentikacijo ne rabijo ukvarjat.
Ti frameworki majo svoje mesto ampak za eno navadno spletno stran, ki nima nobenega namena biti nic drugega so pax nepotrebni.
Jamranje glede ajaxa in rendeneriranja je na mestu SAMO v tem primeru.
Gandalfar ::
Ember.js fastboot zna to kar išče OP. Na server side zrendra html, hkrati pa v zna v 'shoebox' (inline javascript tag) porinit podatke, da jih ni treba še enkrat fetchat.
Zaenkrat sicer še pride do switchanja pre-rendered DOM-a s tistim, ki se zgradi ko se JS inicializira, vendar bo tudi ta problem rešen, ko dodajo 'rehydration'.
Zaenkrat sicer še pride do switchanja pre-rendered DOM-a s tistim, ki se zgradi ko se JS inicializira, vendar bo tudi ta problem rešen, ko dodajo 'rehydration'.
MH0 ::
Če gre za web aplikacijo in ni potrebe po SEO, ne vidim potrebe po generiranju html-a na serverju.
Html template in javascript nalagaš v odvisnosti od routinga.
Sam html template sicer zaradi uporabniških pravic na strežniku res sprocesiram, z js pa se niti ne trudim kajti zaradi varnosti itak moraš tudi na strežniku vedno čekirati input in pravice.
Jquery in bootstrap pa že ni tako hudo naložit. Sploh pa, če se lahko poslužiš CDN-a.
Za ta namen še vedno furam klasične asmx-e v GW aplikaciji v DMZ in ti gredo potem na WCF v LAN.
Html template in javascript nalagaš v odvisnosti od routinga.
Sam html template sicer zaradi uporabniških pravic na strežniku res sprocesiram, z js pa se niti ne trudim kajti zaradi varnosti itak moraš tudi na strežniku vedno čekirati input in pravice.
Jquery in bootstrap pa že ni tako hudo naložit. Sploh pa, če se lahko poslužiš CDN-a.
Za ta namen še vedno furam klasične asmx-e v GW aplikaciji v DMZ in ti gredo potem na WCF v LAN.
MH0 ::
Ker najbrž ne poznamo vsi te enostavne poti, ki jo omenjaš. Povej nam kaj več.
Pri meni je asp.net že pred leti odpadel. S temi postbacki stvar pač ni konkurenčna desktop UX.
Tisti njihov atlas/ajax poskus pa se mi ni obnesel.
Z veseljem v bodoče kaj poenostavim tako, da poslušam....
Pri meni je asp.net že pred leti odpadel. S temi postbacki stvar pač ni konkurenčna desktop UX.
Tisti njihov atlas/ajax poskus pa se mi ni obnesel.
Z veseljem v bodoče kaj poenostavim tako, da poslušam....
sebastjan28 ::
Jaz še vedno ne razumem, zakaj ne enostavno ne uporabite najbolj enostavno rešitev za takšne naloge: MVC applikacijo (npr ASP.NET MVC)
Controler je v tem primeru odgovoren za pripravo payloada(za branje podatkov je zelo dobro uporabiti Repository, ki bere podatke s pomočjo ORM). View nato poskrbi za binding payloada in vsebuje java script/Jquery,... za asinhrone operacije. Hkrati služi Controler tudi kot WebService za prej omenjene klice. Dodate že DI framework and et voila: imate hitro razvito in enostavno za vzdrževanje applikacijo.
Controler je v tem primeru odgovoren za pripravo payloada(za branje podatkov je zelo dobro uporabiti Repository, ki bere podatke s pomočjo ORM). View nato poskrbi za binding payloada in vsebuje java script/Jquery,... za asinhrone operacije. Hkrati služi Controler tudi kot WebService za prej omenjene klice. Dodate že DI framework and et voila: imate hitro razvito in enostavno za vzdrževanje applikacijo.
Spura ::
sebastjan28 je izjavil:
Jaz še vedno ne razumem, zakaj ne enostavno ne uporabite najbolj enostavno rešitev za takšne naloge: MVC applikacijo (npr ASP.NET MVC)
Ali pa JSF.
BigWhale ::
Ker najbrž ne poznamo vsi te enostavne poti, ki jo omenjaš. Povej nam kaj več.
Pri meni je asp.net že pred leti odpadel. S temi postbacki stvar pač ni konkurenčna desktop UX.
Tisti njihov atlas/ajax poskus pa se mi ni obnesel.
Z veseljem v bodoče kaj poenostavim tako, da poslušam....
Nevem kaj delas, ne morem ti svetovati. :)
Ce delas 'one page' aplikacijo, potem rabis nek 'framework' in si lahko privoscis generirat HTML v brskalniku. Se moras pa prej vprasat, ce je one page aplikacija res to kar potrebujes.
Ce delas nek 'novicarski portal' potem je best bet, da HTML ustvari server in ga spravi v nek cache in potem to serviras uporabnikom kot staticne strani.
Ce delas kaj tretjega, potem potrebujes nekaj tretjega.
MH0 ::
sebastjan28 je izjavil:
Jaz še vedno ne razumem, zakaj ne enostavno ne uporabite najbolj enostavno rešitev za takšne naloge: MVC applikacijo (npr ASP.NET MVC)
Moje zahteve so takšne, da na strežnikih kamor se dostopa z browserji oz. kjer se hostajo web servisi ne sme biti nobenih sledi o podatkovnih bazah. Priznam pa, da mi asp.net mvc nikoli ni zadišal. Pač vsak ima verjetno svoje kaprice. :-)
Zgodovina sprememb…
- spremenilo: MH0 ()
MH0 ::
Ker najbrž ne poznamo vsi te enostavne poti, ki jo omenjaš. Povej nam kaj več.
Pri meni je asp.net že pred leti odpadel. S temi postbacki stvar pač ni konkurenčna desktop UX.
Tisti njihov atlas/ajax poskus pa se mi ni obnesel.
Z veseljem v bodoče kaj poenostavim tako, da poslušam....
Nevem kaj delas, ne morem ti svetovati. :)
Ce delas 'one page' aplikacijo, potem rabis nek 'framework' in si lahko privoscis generirat HTML v brskalniku. Se moras pa prej vprasat, ce je one page aplikacija res to kar potrebujes.
Ce delas nek 'novicarski portal' potem je best bet, da HTML ustvari server in ga spravi v nek cache in potem to serviras uporabnikom kot staticne strani.
Ce delas kaj tretjega, potem potrebujes nekaj tretjega.
Za ERP npr.?
BigWhale ::
Kot sem ze prej povedal, je vse odvisno od tega kaj bi rad pocel, potem se pa odlocas kako bi rad to pocel. Ce res rabis one page in imas na eni strani samo API in nic drugega, potem ti ne preostane drugega, kot nek moderen JS framework. Ce nimas samo APIja in ce delas tudi komplet backend, se lahko odlocas za neko hibridno verzijo.
Z generiranjem HTMLja na server strani ni prav nic narobe in generalno rect, da je to slabo je neumnost.
Z generiranjem HTMLja na server strani ni prav nic narobe in generalno rect, da je to slabo je neumnost.
MH0 ::
In kako potem pašeta tvoja zadnja posta k tvojemu komentarju "Ja, zakaj bi stvari delal enostavne, ce jih lahko zakompliciras. :>"?
technolog ::
HTML je treba generirat ali na serverju ali na clientu. Torej nekje bo treba porabit nekaj ekstra CPU časa.
Argument je, da je to dosti bolje počet na clientu, ker ceno decentralizirano plača uporabnik, pa še prej dobi odgovor na zahtevek.
HTML je verjetno tudi kakih 10% večji (po gzipu) in že samo ta dodaten čas ki se ga porabi na networkingu odtehta vse CPU prihranke.
Argument je, da je to dosti bolje počet na clientu, ker ceno decentralizirano plača uporabnik, pa še prej dobi odgovor na zahtevek.
HTML je verjetno tudi kakih 10% večji (po gzipu) in že samo ta dodaten čas ki se ga porabi na networkingu odtehta vse CPU prihranke.
Zgodovina sprememb…
- spremenil: technolog ()
illion ::
HTML je treba generirat ali na serverju ali na clientu. Torej nekje bo treba porabit nekaj ekstra CPU časa.
Jz html generiram kar on-the-fly na ruterjih in switchih, vsak od njih opravi doloceno delo, ki ga racumam z Hn * Pi, kjer je Hn stevilo hopov na trenutni povezavi, Pi pa procentualni delez skupne CPU moci hopov za i-ti hop.
BigWhale ::
In kako potem pašeta tvoja zadnja posta k tvojemu komentarju "Ja, zakaj bi stvari delal enostavne, ce jih lahko zakompliciras. :>"?
Ker je OP spraseval nekaj, dobil je pa miljon odgovorov, vsak je pa trdil nekaj svojega in kompleksnost je kr narascala. :)
Over-engineering je kr problem.
Looooooka ::
Trenutno probavam Angular 4 v .NET core v navezi z token avtentikacijo (jwt) pa vse tri zadeve met v svojem projektu.
Moram priznati, da so zakompliciral življenje v tri krasne.
Tole si mel včasih po branju dokumentacije v par dnevih z lastno kodo in uporabo json.neta spacan v par dnevih.
S tem angularjem je pa tok navlake, da ne omenim velikost same knjižnice, da se počasi sprašujem če se res sploh splača :)
Mislim, ko bo vse delalo bom mogoče rekel, da je sploh oh in sploh odlično ampak z vsemi preskoki iz angular na angular2 (4) in tri tisoč različnimi navodili kako je najbolje narediti zadevo(vsak s svojo verzijo knjižnic in pluginov) te kar mine živet.
Right now I could not agree more :D
Moram priznati, da so zakompliciral življenje v tri krasne.
Tole si mel včasih po branju dokumentacije v par dnevih z lastno kodo in uporabo json.neta spacan v par dnevih.
S tem angularjem je pa tok navlake, da ne omenim velikost same knjižnice, da se počasi sprašujem če se res sploh splača :)
Mislim, ko bo vse delalo bom mogoče rekel, da je sploh oh in sploh odlično ampak z vsemi preskoki iz angular na angular2 (4) in tri tisoč različnimi navodili kako je najbolje narediti zadevo(vsak s svojo verzijo knjižnic in pluginov) te kar mine živet.
Over-engineering je kr problem.
Right now I could not agree more :D
trstenjak ::
Spomnim se, ko sem začel s programiranjem Win32 v c-ju. Vse lepo definirano, laufa kot urica, nobenih sprememb api-ja. Danes 20 CDNov, da sploh lahko kaj zaženeš, po pol leta nova verzija knjižnic. Polovica pluginov ni kompatibilna, obstoječi program moraš nadgraditi. Včasih se sprašujem, če ni to vse z namenom, da upočasnijo male skupine in posameznike. Eh, to je samo teorija zarote.
Looooooka ::
Spomnim se, ko sem začel s programiranjem Win32 v c-ju. Vse lepo definirano, laufa kot urica, nobenih sprememb api-ja. Danes 20 CDNov, da sploh lahko kaj zaženeš, po pol leta nova verzija knjižnic. Polovica pluginov ni kompatibilna, obstoječi program moraš nadgraditi. Včasih se sprašujem, če ni to vse z namenom, da upočasnijo male skupine in posameznike. Eh, to je samo teorija zarote.
Poglej si javaskript knjižnice. Za par vrstic kode, ki bi jih moral vsak bebec znat spisat, naredijo plugin/knjižnico, ki je potem dependency v 300 projektih. Obup.
Zgodovina sprememb…
- spremenilo: Looooooka ()
trstenjak ::
Spomnim se, ko sem začel s programiranjem Win32 v c-ju. Vse lepo definirano, laufa kot urica, nobenih sprememb api-ja. Danes 20 CDNov, da sploh lahko kaj zaženeš, po pol leta nova verzija knjižnic. Polovica pluginov ni kompatibilna, obstoječi program moraš nadgraditi. Včasih se sprašujem, če ni to vse z namenom, da upočasnijo male skupine in posameznike. Eh, to je samo teorija zarote.
Poglej si javaskript knjižnice. Za par vrstic kode, ki bi jih moral vsak bebec znat spisat, naredijo plugin/knjižnico, ki je potem dependency v 300 projektih. Obup.
Za v CV referenca je super. :)
Zgodovina sprememb…
- spremenil: trstenjak ()
BigWhale ::
Za par vrstic kode, ki bi jih moral vsak bebec znat spisat, naredijo plugin/knjižnico, ki je potem dependency v 300 projektih. Obup.
Zato bomo se dolgo govorili o left-pad incidentu leta 2016 ...
http://www.haneycodes.net/npm-left-pad-...
kuall ::
Tisti problem, o katerem sem spraševal v tej temi:
"kako ne bindat stvari 2x, na serverju in klientu, obenem pa tudi ne poslat polno ajax requestov?"
je čist enoatavno rešljiv:
ko se stran naloži pošlješ vse podatke v obliki json v obliki neke js spremenljivke na klienta. bindaš jih s htmljem s klient knjižnico.
potem pa ko uporabnik kaj klika in rabiš osvežene podatke s serverja vežeš (bindaš) podatke s klient knjižnico.
če rabiš osvežit celo stran pošlješ ajax zahtevek, ki ti vrne celoten json.
če želiš osvežiti samo del strani pa pošlješ drug ajax zahtevek, ki ti vrne samo del teh podatkov.
zelo čisto, nobenega podvajanja kode, stran deluje zelo hitro.
človek spet dobi veselje za web programiranje.
priporočam knockoutjs. naredi job, obenem pa je enostaven za uporabo.
"kako ne bindat stvari 2x, na serverju in klientu, obenem pa tudi ne poslat polno ajax requestov?"
je čist enoatavno rešljiv:
ko se stran naloži pošlješ vse podatke v obliki json v obliki neke js spremenljivke na klienta. bindaš jih s htmljem s klient knjižnico.
potem pa ko uporabnik kaj klika in rabiš osvežene podatke s serverja vežeš (bindaš) podatke s klient knjižnico.
če rabiš osvežit celo stran pošlješ ajax zahtevek, ki ti vrne celoten json.
če želiš osvežiti samo del strani pa pošlješ drug ajax zahtevek, ki ti vrne samo del teh podatkov.
zelo čisto, nobenega podvajanja kode, stran deluje zelo hitro.
človek spet dobi veselje za web programiranje.
priporočam knockoutjs. naredi job, obenem pa je enostaven za uporabo.
Zgodovina sprememb…
- spremenilo: kuall ()
kuall ::
Moderator je temo zavil v offtopic smer. Zato pa je forum tam kjer je.
Delaš zaradi uživanja. S tem, da bo hitro narejeno se obremenjujejo samo idioti, ki so brez občutka za stvari. Take so moje izkušnje.
Delaš zaradi uživanja. S tem, da bo hitro narejeno se obremenjujejo samo idioti, ki so brez občutka za stvari. Take so moje izkušnje.
BigWhale ::
Ne, mene resno zanima koliko casa je trajal razvoj.
Zaradi uzivanja se pa delajo hobi projekti, neke komercialne resitve pa so prakticno vedno pogojene dolocenim casovnim omejitvam in z njimi se ne obremenjujejo samo idioti. Noben pametne ne mece denarja za razvoj v pec in gleda kako gori.
Zaradi uzivanja se pa delajo hobi projekti, neke komercialne resitve pa so prakticno vedno pogojene dolocenim casovnim omejitvam in z njimi se ne obremenjujejo samo idioti. Noben pametne ne mece denarja za razvoj v pec in gleda kako gori.
kuall ::
Se nisem dotaknil tega 1 leto in pol, takrat sem se samo malo učil, ker sem imel občutek, da mi bo kdaj prav prišlo. Zdej mi je pa res prav prišlo, sem spacal v parih tednih. Projekt je mix med hobi in pro.
Danes me je jebalo to, ko sem observable spremenljivki določil vrednost preden je bil html select napolnjen, s katerim je bila spremenljivka povezana. In ga je nastavilo avtomatično nazaj na undefined. Sem moral potegnit dol debug verzijo knockoutjs in debuggirat v chromu, step in itd, da sem razumel, kaj se dogaja. Pa je šlo par ur v nič. Takrat, ko je vrstni red važen, ko na prvi pogled ne izgleda, da ima kaj veze, postane zajebano programirat.
Aja pa nad javascriptom nisem navdušen. Bolj en gnoj od jezika je vidim. C# svetlobna leta boljši.
Danes me je jebalo to, ko sem observable spremenljivki določil vrednost preden je bil html select napolnjen, s katerim je bila spremenljivka povezana. In ga je nastavilo avtomatično nazaj na undefined. Sem moral potegnit dol debug verzijo knockoutjs in debuggirat v chromu, step in itd, da sem razumel, kaj se dogaja. Pa je šlo par ur v nič. Takrat, ko je vrstni red važen, ko na prvi pogled ne izgleda, da ima kaj veze, postane zajebano programirat.
Aja pa nad javascriptom nisem navdušen. Bolj en gnoj od jezika je vidim. C# svetlobna leta boljši.
Zgodovina sprememb…
- spremenilo: kuall ()
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Učenje programiranja (Front-end) (strani: 1 2 )Oddelek: Programiranje | 12845 (9941) | matjash |
| » | MVC vs. AngularOddelek: Izdelava spletišč | 2468 (2058) | kod |
| » | Vsebina tretje spletne straniOddelek: Izdelava spletišč | 1363 (1146) | alexa-lol |
| » | Kaj prvo PHP ali Javascript (strani: 1 2 )Oddelek: Izdelava spletišč | 9389 (7997) | HardFu |
| » | Nasvet pred izdelavoOddelek: Programiranje | 2810 (2154) | Gandalfar |