Hei,
Kysyn nyt sellaista kysymystä, joka varmaan jakaa mielipiteet. Eli lataanko jQueryn head osassa vai juuri ennen sulkeutuvaa body elementtiä?
Käsittääkseni ns. best practise on ladata jQuery juuri ennen sulkeutuvaa body elementtiä, tämä vaikuttaa mm. sivuston suorituskykyyn jne.
Minulla ei ole kokemusta jQuerystä, mutta maalaisjärjellä voin sanoa että skriptit pitäisi ladata head-osassa. Jos joku muu skripti koittaa käyttää jQueryä sivun latautuessa, niin skripti ei toimi.
En kyllä tajua että miten skriptin lataamisajankohta vaikuttaa sivuston suorituskykyyn.
Juuri tätä kysyn koska se vaikuttaa.
Lisäksi jos jQuerya kutsutaan ennen bodyn sulkemista ei tarvitse käyttää document ready funktiota lainkaan.
late: jQueryn ready-funtiota kannattaa käyttää aina.
reino: javascriptin lataaminen headissä estää sivun "piirtämisen", jos tiedoston lataamisessa kestääkin kauan (esim. ladattaessa cdn-palvelimelta, joka jostain syystä ei vastaakaan nopeasti).
Voitko lebe80 perustella tuon sanomasi?
Lisäys: ..siis "jQueryn ready-funtiota kannattaa käyttää aina."
Säästetään molempien aikaa, ja käännetään se näin päin:
Voitko itse tehdä esimerkin jQueryllä, jossa et käytä readyä (ja sitä vastaavia tapoja).
Heh, onko tämä nyt joku vitsi.. sinä lauot näitä totuuksia täällä foorumilla miten asiat ovat tai eivät ole?
Eli toisin sanoen kukaan täällä ei osaa vastata / perustella tätä kysymystä? Väitän edelleen että kaikista paras tapa tällaisessa perus saitissa (ei siis framework) on kutsua jQuerya ennen bodyn sulkemista, lisäksi ei tarvitse käyttää lainkaan document ready funktiota. Mikä kohta tässä menee yli?
Olen nyt tullut siihen käsitykseen että putkassakin on rajansa ja osalla aivan kummallisia käsityksiä ohjelmoinnista / koodaamisesta. Täällähän piti olla pelkkää pro jengiä.. varmaan tuo DOM liittyy tähän koko jupakkaan oleellisesti.
Tässä ajassa sä olisit kerinnyt jo testaamaan sen.
Et tule saamaan minulta ilmaista koodia ikinä Lebe, olen pitänyt putkaa jonkin sortin paikkana jossa aina tiedetään lopulta oikea vastaus kysymyksiin mutta ei täälläkään voi olla joka asiasta ihan kaikista oikeellisinta tietoa.
Toivon että kysymykseeni löytyisi perusteluita.. edes tuo CDN juttu ei ole ihan 100% syy.. jQuery voi olla omalla palvelimella.
Mitä sanotte siitä että DOM osaisi asetella esim. kuvat sinne omaan rakenteeseensa ja tämä mm. nopeuttaisia asioita..
No mitä haittaa siitä readystä on?
Ja miksi teet tästä asiasta näin suuren numeron?
edit:
Ja olethan nyt ymmärtänyt oikein, että aika paljon sinun pitääkin asioita testata ihan itse ja jättää se teoria puoli vähän vähemmälle.
Tiedätkö sä mikä on DOM?
..heh
meinasin ihan asiallisen postauksen laittaa, mutta antaapa olla. Joo mikäköhän vittu se DOM on.
ok, latella on taas tämmönen päivä.
Kai sä tajuat, että mä olin se viimeinen henkilö, joka edes yritti vastata sulle asiallisesti.
Heh.
Niin siis jqueryn ready-eventhän on wrapperi natiiville js:n onload-eventille ja sen callback kutsutaan silloin, kun sivun DOM on latautunut. Mikään muu ei ole perusteltu paikka laittaa oikeastaan kaikkea mahdollista js:sään liittyvää kuin head-elementti. Body nimensä mukaisesta on sivun runkoa/vartaloa varten ja head sisältää otsikkotiedot tai itse sivun rakenteen kannalta metatiedon. On myös täysin naurettavaa tehdä tästä joku suoritustehoon liittyvä ongelma, kun sillä ei ole selaajan kannalta paskaakaan väliä, että missä kohtaa sivua se jquery ladataan, sillä vaikutus on millisekunti sinne tai tänne ja samaa vaihtelua voi aiheuttaa verkon latenssi. Olennaisempaa on miettiä mitä kaikkea sinne muistiin ladataan ja mitä siellä säilytetään.
Tuossa on hieman tietoa:
http://learn.jquery.com/using-jquery-core/document-ready/
Suomeksi mä nyt vaan sanoisin, että jos et tarkista document.readyllä että onko sivut latautunut, homma kusee helposti monessa asiassa. Eli kannattaa käyttää sitä, niin yksi huoli vähemmän.
Ja itse laitan jqueryn sinne <head> -osioon, koska oon aina tehnyt niin ja ymmärtänyt että se nimenomaan on paikka kaikille javascripteille. En oikeasti tajua mitenkään ihmeellisesti näitä asioita mutta homma toimii ja peitto heiluu.
Mielestäni tästä on turha ruveta kinastelemaan ja jumiutua jauhamaan tästä.
Tässä on tapa jota käytän eli body osassa lataan jQueryn ja sen jälkeen oman jQuery tiedoston.
<body>
<!-- Tekstiboksi -->
<p class="warning">
<span>It's A Trap!</span>
</p>
<!-- Kuva -->
<div class="image">
<img src="img/ackbar.gif" />
</div>
<!-- Toiminnallisuus -->
<script src="//code.jquery.com/jquery-1.11.0.min.js"></script>
<script src="js/app.js" type="text/javascript" charset="utf-8"></script>
</body>Nyt sitten tuossa omassa app.js tiedoston alussa ei tarvita lainkaan mitään tyhjää funktiota tai document ready funktioita jne.
$(".warning").hide().show("slow");Tämä kaikki on oppimani mukaan ns. Best Practice. Samoin tavoin kuin monet avaavat vain <?php tagin mutta eivät välttämättä sulje. (riippuen tilanteesta).
Lisäys:
Pohdintaa englanniksi...
"It's not that the images would load before jQuery. They would be inserted into the Document Object Model (DOM) which is like a tree with each branch having relationships to the other elements. For instance, a div with a paragraph tag inside would be viewed by the browser as a parent to child relationship. By allowing everything to load first you prevent jQuery from trying to perform an action on an element that has not yet been loaded into the DOM. Placing jQuery on the bottom acts the same as $(document).ready();" If you wanted to hide an image before the page is displayed, you can still do this when the DOM has been created. It doesn't have to do with the display to the user, just the browser's creation of the hierarchy of elements."
Lisäys:
Niin eli..
Kuvat latautuvat tällä tekniikalla ennen JavaScript tiedostoja. Käyttäjän kannalta tämä on hyvä tapa koska se on document ready verrattuna nopeampi. Toisaalta jos puhutaan koodin ylläpidettävyydestä ja muutenkin järjestyksestä niin olisi mukava että jQuery on head osassa.
mm. Modernizr pitää olla siellä joka tapauksessa, niin kaiketi se olisi fiksua että kaikki JS samassa paikassa. Olisin nyt vain halunnut kuulla, kun täällä ammattilaisia, niin mielipiteen mikä on tänä päivänä oikein tapa lisätä jQuery. Esim. CDN on myös hyvää käytäntöä näistä suorituskykyyn liittyvistä syistä.
Ymmärrän kyllä että projektit ja frameworkit ovat erilaisia, mutta tällaisessa perus web-sivusto / web-app jutussa, mikä onkaan oikea tapa!
Jos lataat scriptin sivun lopussa, myös toiminnallisuudet mihin sitä käytät, toimivat vasta kun sivu on kokonaisuudessaan ladattu. eli kun käytät jqueryä esimerkiksi asettamaan kaikki luokan .warning spanit punaiseksi, jos arvo > 10, niin käyttäjälle rendataan ensin teksti normaalin värisenä, ja jquery scriptin latauduttua vaihdetaan väri. eli käyttäjä näkee värin vaihdoksen. jos taas jquery olisi ladattu head:ssä, ja alustus document readyssä, väri olisi vaihdettu ennenkuin rendattu dokumentti näytetään käyttäjälle (koska se suoritetaan ennen window.load:ia).
scriptin lataaminen sivun lopussa on rinnastettu best practiseen, kuten myös document ready:kin. riippuen siitä kuinka suuri DOM -puu on, ja kauanko sen lataamiseen menee, voi jonkinlaisen riskiarvion laskea, ja päätellä pitääkö esim eventit ja alustukset ladata document readyssä (jos toinen mahdollisuus on että käyttäjä ehtii klikkailemaan elementtejä, jotka eivät sitten tee vielä mitään koska eventtejä ei ole vielä ehditty asettaa => DOM puun lataus kesken)
Okei, kiitän groovyb.
Luulen että käytän jatkossa tuota head osaa se tuntuu jotenkin oikeammalta paikalta jQuerylle . . . . . enkä muutenkaan halua ajatella niin että DOM on rakennettu siinä vaiheessa valmiiksi kun päästään jQueryn kohdalle.
Vertaan tätä asiaa siihen kun PDO PHP jutuissa käytetään hakulauseissa ? -merkkejä minusta ne ovat pahin keksintö ikinä. Eli pyrin käyttämään sarakkeiden nimiä. Tämä on juuri useamman koodarin kannalta mielekkäämpää ja varsinkin silloin kun pitää palata takasin koodin pariin tauon jälkeen.
---
Offtopic, tällä hetkellä käyn läpi jQuerya ja tarkoitus olisi vielä ennen kesää saada lisättyä erilaista toiminnalisuutta omille kotisivuille. Olen käsittänyt että kun haetaan web-kehittäjää esim. työharjoitteluun niin perus vaatimuksina usein ovat:
- HTML
- CSS
- JavaScript
..en sitten täysin tiedä mitä tuo JS kohta tarkoittaa eli riittääkö esim. että osaa jonkin verran esim. jQuerya. Tarkoitus tämän jälkeen käydä läpi pelkkää "JavaScriptiä".
Ei se mikään web-kehittäjä ole, jos siltä ei vaadita palvelinpuolen osaamista. :D
http://fns.fi/ajankohtaista/fns-etsii-tuotekehityksesta-kiinnostunutta-web-ohjelmoijaa:
Toivomme sinulta:
- Hyvää HTML-, CSS- ja JavaScript-osaamista
- Hyvää PHP-osaamista
- Hyvää tietokantaosaamista
- Kokemusta sovelluskehysten käytöstä (esimerkiksi CakePHP)
- Kokemusta versionhallintatyökaluista
- Kokemusta Linux-palvelimista
Tuo nyt on yksi käytännön esimerkki. En ole tutkinut näitä paljon tarkemmin.
Jotenkin osasin taas odottaa tällaista... eli varmaankin tarvitaan myös muunlaista osaamista, mutta monessa tuo kova kolmikko: html, css, js.
Lisäksi vaikka hakisi Front End tehtäviin niin usein toivotaan tuota osaamista / ymmärrystä Back End puolesta mikä hyvä asia. Mitä pidemmälle olen näissä web jutuissa päässyt niin sitä paremmin tajuan kuinka eri tekniikat ovat kuitenkin lähellä toisiaan ja niistä löytyy paljon samankaltaisuutta. Esim. jQueryn kanssa tehdessä .. funktioitahan siellä tulee rakennettua.
Tänä päivänä jopa jQuery alkaa olla vanhentunutta tapaa tehdä js:ssää. Nykyään olla kiinnostuneita osaajista, jotka ymmärtää erilaisten JavaScript MVC- tai MVVM- frameworkien päälle. jQuerya käytetään lähinnä yksittäisten widgettien tekoo, joiden tarvitsee pystyä muokkaamaan dom-puuta, mutta itse sovelluslogiikka ja backendin yhdistäminen front endiin tehdään juuri näillä frameworkeillä. Yhtään isommissa käyttöliittymäprojekteissa on aivan käsittämättömän suuri duuni, tehdä käsin dom-puun päivittelyä, kun on keksitty termi data-binding, joka hoitaa sen itsestään.
Data binding on vain yksi kikka yhteen asiaan, ei se vielä itsessään tee toisesta kirjastosta jQueryä kehittyneempää. Se nyt vaan niin, että on tyhmää lähteä tekemään web-järjestelmiä ilman mitään sovelluskehystä, olipa käytössä sitten php, js tai jokin muu kieli.
En väittänytkään, että se olisi ainoa hyöty. Se on kuitenkin jo itsessää hyvin merkittävä hyöty, kun ei tarvitse koodata event-handlereitä käsin ja pitää huolta, että tietomallin tieto päivittyy käyttöliittymää ja käyttöliittymässä tehdyt muutokset tietomalliin. Muita hyötyjä on mainitsemani RestFul-tyyppisten pyyntöjen tekeminen palvelin softaan. Tietenkin myös yksin keskeisimmistä frameworkkien hyödyistä on ohjelman rakenteen hahmottaminen fiksusta.
Muistan kuinka aikoinani hehkutin WordPressiä ja sen tuomia mahdollisuuksia. WP ei ehkä ole 100% hyvä mutta on se jo todella kova framework.
late kirjoitti:
Muistan kuinka aikoinani hehkutin WordPressiä ja sen tuomia mahdollisuuksia. WP ei ehkä ole 100% hyvä mutta on se jo todella kova framework.
Ei pure enään Laten provot meihin.
Paitsi, ettei WordPressiä voi ohjelmistokehykseksi edes kutsua, sillä se on paljon ennemmin julkaisujärjestelmä. Ei oikeassa bisnesmaailmassa olla lainkaan kiinnostuneita mistään WordPressistä. Meidän firman sivutkin kun uusittiin, niin se ostettiin, pilkkahintaa, palveluna ulkopuoliselta, kun ei ketään kiinnostanut alkaa vääntää minkään Joomlan tai muun kanssa, sillä se touhu on kauheeta shittiä ja on sitä tärkeämpiäkin hommia. Web-sivujen vääntäminen on niin kuollut bisnes, että on hullua edes yrittää työllistää ittensä sillä. Voin kertoa - ei onnistu. Raha liikkuu isoissa tai keskisuurissa järjestelmissä, kuten erilaisissa ERP:iessä, joita mekin asiakkaillemme teemme.
Kuten Triton ja kumppanit hyvin tietävät niin WordPressiä käytetään laajasti myös Suomessa.
late: Sun yksi suurimmista ongelmista on se, että teet hirveän ison numeron jostain käytettävästä välineestä. Puuseppä käyttää sahaa ja vasaraa yms... ja ne on sille väleineitä. Ohjelmistokehittäjälle joku kirjasto tai framework on välinä siinä missä puusepälle on nyt vaikka se saha. Tuntuu, että sun täyty pistää hitosti paukkuja siihen, että opit yhtä työkalua käyttämään. Tosiasia on se, että it-alalla mennään koko aika eteenpäin ja joudutaan jatkuvasti arvioimaan, että mitä välineitä käytetään ja pitää olla valmis ottamaan hetkessä uusia työkaluja haltuun. Miten kuvittelet pärjääväsi tässä nopeasti muuttavassa maailmassa? Voi olla, että joskus kukaan ei enää käytä WordPressiä vaan jotain ihan muuta.
Toiseksi. Web-sivujen kehitys oli hyvää bisnestä 2000-luvun alkupuolella (tai näin isot pojat ovat minulle kertoneet, kun itse olin vielä ala-asteella), mutta tänäpäivänä se ei kyllä kannata. Valmiita layoutteja on valmiina pilvin pimein ja nämä kotisivukone-tyyppiset ratkaisut houkuttelevat hintansa puolesta asiakkaita mielettömästi. WordPress rajaa kumminkin aika tiukasti sen, että minkätyyppisiä asioita sillä voidaan tehdä ja nämä projektit ovat yleensä melko pieniä. Muutenkaan PHP ei ole kovin hyvä kieli yhtään isompiin projekteihin, sillä siitä loppuu teho aika äkkiä kesken + sen koodaaminen, debuggaaminen sekä ylläpitäminen on aikamoinen tuskien taival. Näitä WordPress-kilkkeitä tekevät firmat on varsin normaalisti pieniä mainostoimistoja, jotka tekee siinä sivussa muutakin graafista suunnittelua. Tuo sinun linkkaamasi sivu sisälsi juuri näitä pieniä firmoja, jotka yhteensä työllistää jonkun 100 - 150 ihmistä eli ei hirveästi vakuuttanut tuo sinun "WordPressin laajastikäyttäminen Suomessa".
Triton kirjoitti:
Paitsi, ettei WordPressiä voi ohjelmistokehykseksi edes kutsua, sillä se on paljon ennemmin julkaisujärjestelmä.
Julkaisujärjestelmähän se on mutta ei se mitään haittaa. Sen päälle voi rakentaa tietynlaisia sivuja ja se voi jopa onnistua kätevämmin kuin "vain" frameworkin päälle tehdessä. WordPress-taidoilla ei kuitenkaan vielä kovin pitkälle pääse. Jos vaikka osaisi Zendiä, Symfonya tai Yii'tä, niin niiden kahden muunkin oppiminen olisi paljon helpompaa kuin WP-taustalla. WordPress on julkaisujärjestelmäksikin todella antiikkinen tekniseltä arkkitehtuuriltaan, joten jos tyytyy (hyytyy) sen kanssa puljaamaan, niin ei ole mahdollisuuksia kehittyä kovin hyväksi koodariksi.
lainaus:
Web-sivujen vääntäminen on niin kuollut bisnes, että on hullua edes yrittää työllistää ittensä sillä. Voin kertoa - ei onnistu.
Kovin ontto väite, kun juuri edellisessä virkkeessä totesit, että teidänkin firmanne osti sivut muualta, koska niiden tekeminen itse ei ollut toimiva vaihtoehto.
Juuri se tekeekin pelkästi web-sivujen tekemisestä kuollutta bisnestä, kun osaajia on paljon ja kilpailu on niin kova, että hinnat painuu täysin pohjalle. Täytyy tehdä hirveästi työtä, että pääsee edes kohtuulliselle ansioille. Java-kehityksestä kun nyt voi laskuttaa tilanteesta riippuen 75 - 100 euroa tunti, niin jo 300 tunnin projektista nettoaa ihan kivasti.
Jopas on jänniä väitteitä. Hassua miten täydellisesti ne ovat ristiriidassa oman kokemukseni ja käsitykseni kanssa. Toisaalta olen itse lopettanut web-kehittäjän hommat, ehkä koko ala on mullistunut vastikään?
Ainakin vielä vuosi pari sitten tilanne oli sellainen, että fronttitöitä riittää niin paljon kun haluaa tehdä. Laskutettava tuntihinta ei kieltämättä aina mahdu antamaasi haarukkaan, mutta se ei välttämättä ole alaraja joka tulee vastaan.
Itse nyt lähinnä tarkoitin näitä, jotka rakentavat firmoille nettisivuja WordPressin tai Joomlan päälle. Kyllä varmasti front-end hommaa riittää, mutta silloin tehdäänkin käyttöliittymiä osaksi isompia softia.
Eihän tuo web -kehitys ole vähentynyt yhtään, päinvastoin! Isommat yritykset siirtävät yhä enemmän ja enemmän vanhoja desktop, Lotus Notes ja Access softiaan verkkotoimisiksi joko paikalliseen intranettiin tai pilveen. Pienyrittäjien verkkosivuja ei ole moneen vuoteen enää tarvinnut edes ajatella tekevänsä, eikä edes kannattaisi. Ei kukaan täyspäinen edes ajattelisi kilpailevansa valmiita verkkosivutemplategeneraattoreita vastaan tuntihinnallaan. Tuli tässä eräskin verkkosivukehittäjä vastaan, joka oli voittanut tarjouskilpailun verkkokaupasta 1000:lla eurolla, parilla sataa halvemmalla kuin hävinnyt tarjoaja. Eipä siinä paljon käteen jää verojen jälkeen viikon työstä. Ehkäpä tuosta syystä tuo pk -sektori ei ole koskaan minua kiinnostanutkaan. Isojen firmojen projekteissa kun on kuukausiksi töitä kerrallaan, ja ei tähän päivään asti ole ainakaan tarvinnut kattoon syljeskellä.
Luulisi että web-kehitys olisi erittäin tärkeää nykyään, koska kaikki siirtyy verkkoon ja erilaiset responsiiviset sivut kasvattavat tarpeellisuuttaan.
Luultavasti en ole osannut ilmaista itseäni tarpeasti selkeästi ja se lienee johtuneen käyttämieni termien kuormituksesta.
Web-kehitys itsessään ei tietenkään ole vähentynyt vaan hyvin paljon desktop-sovelluksia muutetaan pilvipalveluiksi. Nyt kuitenkin on syytä erottaa kaksi asiaa toisistaan: web-kehitys ja WordPress. WordPressiä käytetään nettisivustojen ja joidenkin verkkokauppojen pohjalla, mutta se ei tosiaan ole sama asia kuin koko web-kehitys. WordPress-markkinat tai nettisivumarkkinat ei takuulla tänä päivänä ole enää sellaiset, että niihin kannattaisi lähteä hirveästi kilpailemaan. Voi sieltä joitakin satasia saada, mutta sillä ei vielä elä. Ihan eri asia on tehdä web-kehitystä ja kehittää jotain uudenlaisia verkkopalveluita tai SAAS-tyyppisiä ERP-ratkaisuja.
Wordpress-markkinat tosiaan taitaa olla näitä, joissa hinnat liikkuu Tritonin mainitsemissa satasissa.
Tästä syystä javascriptin ääretön optimointi ja Wordpress-samassa lauseessa tuntuu niin perverssiltä ajatukselta, että en käsitä miksi tätä kukaan jaksaa edes miettiä.
Itse antaisin jQueryn latautua siellä, missä wp:n tekijät ovat sen asettaneet latautumaan. Jos se taas ei oletuksena tule mukana, niin tuolloin se kannattaa laittaa sinne, mihin sen laittamiseen kuluu vähiten aikaa.
Nähtävästi nämä noin 50 "yritystä" sitten vievät yhdessä kaikki nämä sataset Suomessa. WordPressin suurin ongelma ainakin täällä Suomessa on ollut se että sitä aliarvioidaan jatkuvasti. Kyllä WP taipuu vaikka mihin, mutta se ei ehkä ole 100% puhtainta koodia. Sen sijaan asiakkaan näkökulmasta se on luotettava ja helppokäyttöinen sekä sitä voi muokata jatkossa melko pienellä vaivalla jos asiakas haluu jonkun uuden ominaisuuden.
Nyt esim. putka kysyy mitä koodaat? Ja on erotettu web-sivustot ja web-palvelut toisistaan.. mielestäni tulevaisuudessa ja ellei jo nyt nämä kaksi asiaa ovat sama isompi kokonaisuus.
Voisiko jopa olla niin että lopulta ei tehdä enään sovelluksia lainkaan vaan yksi koodi taipuu joka laitteelle iPhonesta Androidiin.
late kirjoitti:
Nähtävästi nämä noin 50 "yritystä" sitten vievät yhdessä kaikki nämä sataset Suomessa. WordPressin suurin ongelma ainakin täällä Suomessa on ollut se että sitä aliarvioidaan jatkuvasti. Kyllä WP taipuu vaikka mihin, mutta se ei ehkä ole 100% puhtainta koodia. Sen sijaan asiakkaan näkökulmasta se on luotettava ja helppokäyttöinen sekä sitä voi muokata jatkossa melko pienellä vaivalla jos asiakas haluu jonkun uuden ominaisuuden.
Totta kai se taipuu, mikä tahansa julkkari taipuu mihin tahansa, mutta pointti onkin se, kannattaako siihen taipumiseen käyttää ylimääräistä aikaa, kun jokin toinen julkkari tekee sen selvästi järkevämmin. Ihan yhtälailla voisit sanoa, ettei mitään julkkaria kannata käyttää, kun kaiken voi koodata itse.
Ja melko pienellä vaivalla on melko suhteellinen käsite, kun puhutaan isommista projekteista, joissa Wp voi oikeasti olla täysin väärä alusta.
WP:stä en sano muuta, kuin että se on WP-asiakkaiden mielestä ehkä juuri mainitsemasi tapainen. Omasta mielestä se on hyvinkin rajoittunut (tosin olen tehnyt ammatikseni nettisivuja vasta kymmenen vuotta), artikkelipohjainen järjestelmä, johon vähääkään artikkelipohjaisista sivuista eroavat sivustot on lähes mahdoton toteuttaa niin, että niitä voi ylläpitää järkevästi.
Blogisivustoihin ja pieniin kamppissaitteihin se on ihan ok.
ps.
50 yrityksen joukosta puuttui mm. meidän yritys (tai itseasiassa koko kaupunki, jossa yritykseni sijaitsee), joten en yhtään ihmettelisi, vaikka 50 sijaan Suomessa olisi +400 "wp-yritystä".
Omien kokemusten perusteella myös monet toiminimet ovat keskittyneet Wordpressiin, koska sillä saa perussivuston nopeasti aikaiseksi.
late kirjoitti:
Voisiko jopa olla niin että lopulta ei tehdä enään sovelluksia lainkaan vaan yksi koodi taipuu joka laitteelle iPhonesta Androidiin.
No voihan se olla jo nyt, mutta kuten tässäkin, onko selaimella pyöriteltävä alusta se kaikkein optimaalisin ratkaisu. Tuolloin tietynlaisten (esim. erittäin graafisten) sovellusten tekeminen voi olla täysin mahdotonta toteuttaa (lue pelit).
Late ymmärrätkö, ettei softabisnes ole sama asia kuin WordPress? Kerro minulle, että kuinka WordPress taipuu nyt vaikka lentokentän lentojenohjausjärjestelmäksi tai vaikka paperitehtaan tuotannonohjausjärjestelmäksi? Näissä molemmissa käyttöliittymää voi hyvinkin olla web-pohjainen, mutta taustalla jyllää joku paljon jämerämpi java tai c++ -sovellus.
Mä en itse ole kovin suuri julkaisualustojen fani muutenkaan. Niissä vaikuttaa olevan järjestelmällisesti ongelmia päivitysten kanssa. Erityisesti Drupalin henkeen kuuluu se, että sivustoa pykätessä käytetään kaikenlaisia epämääräisiä kolmannen osapuolen moduuleita, koska koodin tekeminen itse on mukamas syöpä. Sitten nämä moduulit (tai itse tehdyt ad hoc -kustomoinnit) hajoilevat milloin mitenkin päivitysten yhteydessä.
Jos tehdään sivuja yksittäiselle asiakkaalle, joka tarvitsee sivut nimenomaan sisällön julkaisemiseen netissä, niin silloin voisin käyttää julkaisujärjestelmää. Mutta heti kun vaatimuksissa mainitaan monimutkaisemmat admin-työkalut tai jotain muuta ei-julkiseen webbiin tarkoitettua sälää, niin pudottautuisin yhtä tasoa alemmas ja vääntäisin kokonaan kustomoidun järjestelmän puhtaan kehysympäristön päälle.
late kirjoitti:
Nyt esim. putka kysyy mitä koodaat? Ja on erotettu web-sivustot ja web-palvelut toisistaan.. mielestäni tulevaisuudessa ja ellei jo nyt nämä kaksi asiaa ovat sama isompi kokonaisuus.
Web-sivustot ja web-palvelut todellakin ovat ja tulevat aina olemaan aivan eri asioita. En puhuisi sivuista kun käytän web-serviceä, enkä myöskään palvelusta, kun luen staattista rfc-dokumenttia tai yleensä jotakin dokumentaatiota.
vesikuusi: Toivottavasti et nyt puhu Web-palvelusta kun tarkoitat Web Serviceä (esim. SOAPia)? Itse olen puhunut web-palvelusta tarkoittaen nyt vaikka verkkopankkia tai jotain vastaavaa jonkin instanssin tarjoamaan verkkopohjaista palvelua. Web Servicet ovat taas tavalla tai toiselle menetelmiä esim. järjestelmäintegraatioita tehtäessä.
late kirjoitti:
Nyt esim. putka kysyy mitä koodaat? Ja on erotettu web-sivustot ja web-palvelut toisistaan.. mielestäni tulevaisuudessa ja ellei jo nyt nämä kaksi asiaa ovat sama isompi kokonaisuus.
Mielestäni on aivan selvää, että esimerkiksi nettipankki on palvelu ja laurihasko.com on nettisivu ja että nämä kaksi painivat aivan eri sarjassa: nettipankissa pääosassa ovat pankkipalvelut, joille nettisivu on vain käyttöliittymä, kun taas laten kotisivu on vain tyhjä kuori ilman palvelua. Jossain toisessa maailmassa nettipankkia varten voisi ehkä asentaa tietokoneelle työpöytäohjelman, kun taas ketään ei takuulla kiinnostaisi asentaa ohjelmana laten kotisivuja; toisaalta taas nettipankkia ei voisi laittaa nastalla ilmoitustaululle, kun taas laten kotisivut voisi printata laadun juurikaan kärsimättä. Tietenkin on monia välimuotoja, joissa palvelun ja sivujen kokosuhde voi olla lähes 1:1, mutta hyvän tavan mukaan silti palvelu ja sivut ovat pitkälti erilliset ja usein firmassa jopa eri henkilöiden harteilla.
Jos välttämättä haluat yhdistää palvelut ja sivustot, voit mielessäsi tulkata muiden viestejä niin, että palvelu on back-end ja sivusto on front-end.
Hmmm.. tuolla logiikalla moderni web-sivusto voisi olla palvelu jos siinä on vain riittävästi toiminnallisuutta. Pankkipalvelut ovat varmasti ääripää niinkuin henkilökohtainen sivusto / profiili netissä.
late kirjoitti:
Hmmm.. tuolla logiikalla moderni web-sivusto voisi olla palvelu jos siinä on vain riittävästi toiminnallisuutta. Pankkipalvelut ovat varmasti ääripää niinkuin henkilökohtainen sivusto / profiili netissä.
Täh, mitä ihmettä?
late kirjoitti:
Hmmm.. tuolla logiikalla moderni web-sivusto voisi olla palvelu jos siinä on vain riittävästi toiminnallisuutta.
Metabolix kirjoitti:
Tietenkin on monia välimuotoja, joissa palvelun ja sivujen kokosuhde voi olla lähes 1:1,
Oho?
Triton kirjoitti:
vesikuusi: Toivottavasti et nyt puhu Web-palvelusta kun tarkoitat Web Serviceä (esim. SOAPia)?
Hups, meinasin juurikin mm. SOAPilla pyöriviä servicejä. No pointtini kuitenkin on toivottavasti selvä.
Mä lataan sen yleensä palvelukeskuksen vessassa.
Mistä täällä oikein jutellaan? Ei ainakaan aloittajan aiheesta? Kiits mo ->
Mitä nyt on tullut puheeksi JS Frameworkkien osalta, ymmärrän niiden käytön jos muuta patternia ei ole saatavilla mikä kattaa myös serveripuolen toiminnot. Samasta syystä en ymmärrä esim MVVM patternin käyttöä js:ssä (esim knockoutJS), jos käytössä on ASP.Net MVC tai ror, jossa data oman patternin mukaisesti asetetaan enivei. käyttöliittymästä saa uskomattoman sekaisen, kun ensin asetetaan MVC:n mallista property js:n MVVM mallin propertyyn MVC:n näkymässä, josta se vasta rendataan. siinä vaan sotketaan kuvioita.
jos sivut on tarkoitus rakentaa js:n päälle kokonaisuudessaan, esimerkiksi templatepohjaisesti mvvm:n malleja vastaan, eikä käyttää esim MVC:tä, ymmärrän sen varsin hyvin. mutta en sitä että patterneja sotketaan keskenään. jos pitää valita MVC + ne pätkät jqueryä mitä tarvitaan versus MVC + js MVVM templatet MVC:n View:ssä, jälkimmäinen ei olisi edes vaihtoehto.
Ja koska MVC on Web applikaatioissa on melkoisen suosittua (joko uskaltaa sanoa jopa standardinomaista) PHP kehityksen ulkopuolella (Okei, tehdäänhän sitäkin. harvemmin vaan tulee vastaan)
, en liputtaisi täysin mallipohjaisten js frameworkkien puolesta.
Itselläni on kokemusta sentyyppisestä web-kehityksestä, että serveripäähän tehdään restful-tyyppisiä pyyntöjä ja vastaukseksi saadaan json/xml-dataa, mikä sitten rendataan html:ksi käyttäen esim. angularjs:ssää. Serveri päässä entrypointtina voi sitten olla servlet, joka delegoi varsinaisen bisneslogiikan vaatimat toimenpiteet muille olioille, tekee dao:n läpi tietokantamuutokset jne... Tähän asti ainakin kaikki on pysynyt melkolailla selkeäni.
Itse miellän MVC + MVVM arkkitehtuurin siten että ylätasolla MC sisältyy backendiin (data-access, business logic/rules, api) ja V on clientille staattisena resurssina servattava js-sovellus. Alemmalla tasolla V voidaan purkaa MVVM:ksi (tai MVW:ksi...) jota ui-sovellus taas toteuttaa.
Oma pinoni web-kehitykselle on samankaltainen kuin edellisessä viestissä, backend on Play/Scala rest-api ja frontend AngularJS-sovellus. Angular-projektin pohjana käytän ng-boilerplatesta personoitua versiota.
kyse olikin siitä, että mitä etua saadaan mvvm js:n hyödyntämisestä, jos taustalla on jo MVC, eikä suurempia javascript toiminnallisuusksia tarvita. Esimerkiksi, mitä lisäetua toisi mvvm:n käyttö seuraavanlaisessa partial view:ssä (yksi span, esimerkissä toteutettu kolmella tavalla)?
<!-- Ruby on rails -->
<span><%= model.propertyname %></span>
<!-- Asp.net MVC (Razor) -->
<span>@Model.propertyname</span>
<!-- Knockout JS -->
<span data-bind="text: propertyname" />
<!--Knockout JS:n scriptit -->
<script type="text/javascript">
function MyViewModel() {
//Rails
this.propertyname = "<%= model.propertyname %>";
//ASP.Net (razor)
this.propertyname = "@Model.propertyname";
}
ko.applyBindings(new MyViewModel());
</script>Aihe on jo aika vanha, joten et voi enää vastata siihen.