Mistäs lähtis liikenteeseen jos haluais olemassa olevista sivuista hienot ja nykyaikaiset. Eli lähinnä "livenä" muuttuvat. Kommentit ja maholliset muutokset / tykkäykset yms. tulisi samantien eikä päivittäisi koko sivua. Haluaisin oma tekemästä keskustelusta mm. facebookmaisemman.
Varmaan html5 ja javascript on avainsanoja? Käytetäänkö noissa yleensä jotain valmiita kirjastoja vai koodataanko tuollaisia ominaisuuksia helposti ite? Mielellään tekisi itse, eikä lataisin mitään valtavia koodipaketteja.
Googlella kun kattelee niin iskee runsauden pula, ei oikein keksi mihin tarttua.
esim. jQuery ja Bootstrap ovat yksiä avainsanoja, joilla lähtisin liikkeelle.
Tietysti facebook on tehnyt melkoisesti työtä omien kirjastoiden luontiin, joilla juuri yritetään ratkoa noita ajax-tekniikan luomia ongelmia, eli kun päivitetään useampaa aluetta samaan aikaan.
Tietenkin tätä varten kannattaa pitää mielessä sekin, että sivujen olisi hyvä toimia myös ilman javascriptiä. Eli ajaxia käytettäessä kannattaa aina luoda jokin fallback-toiminto, että esim. osoiterivi päivittyy asianmukaisesti. Lisäksi itse taas olen käyttänyt ajaxin kanssa ihan html-vastauksia, joista jqueryllä parsitaan tarvittaessa eri alueisiin sisältöä, mutta myös JSON-muotoa, jolloin voi saada myös erilaista dataa ja päättää sen perusteella, mitä vastausviestillä tehdään.
JQueryllä ei ole mitään tekemistä single page -webbisovellusten kanssa. Kyllä siihen hommaan pitää ihan oikea framework-tyylinen kirjasto ottaa käyttöön. Backbonella päässee helpoiten liikenteeseen, koska siinä ei ole kovin paljoa opeteteltavaa, mutta toisaalta sillä ei myöskään sitten saa automaagisesti hienoa sovellusta aikaiseksi.
Riippuu myös ihan käyttötarkoituksesta, tarvitseeko saitin toimia ilman js-tukea – kaikilla on kuitenkin javascript-tuki ja on täysin ok vaatia sitä. "Fallback" voi ihan hyvin tarkoittaa sitä, että näytetään siisti ilmoitus siitä, ettei sivu ole käytettävissä ilman js:ää.
Datan ja käyttöliittymien hallinnassa (eventit, templatet,modelit,controllerit etc) JS Frameworkit toimivat olennaisena osana SPA -sovellusta, mutta ajaxin käyttö client-server kommunikointiin alkaa olla menneen talven lumia, jos puhutaan nykyaikaisesta kehityksestä. Erikseen väsättyjen ajaxien sijaan, datat tulisi streamata esim. Html5 websocket -Apilla, streamaukseen erikseen tarkoitetulla kirjastolla tai ohjelmointikielen omalla streamaus ominaisuudella.
Tästä esimerkkinä vaikka .Net maailmasta SignalR, Rails 4:sen natiivi live stream, tai NodeJs
ja kun puhutaan Single page applikaatioista, tulee osata erottaa oikea SPA -sovellus, kuten gmail tai azuren hallintasovellus, tämän hetken trendistä rakentaa normaali websivusto toimimaan yhdellä sivulla, käyttäen vaikka valmista bootstrap tai foundation leiskaa. SPA <> yksisivuinen, perinteinen verkkosivu.
Jos halutaan rakentaa vain moderni nettisivu, siihen käy ihan hyvin jQuery + bootstrap combo. JS Frameworkkia on turha puskea sivuja ja koodia bloattaamaan, jos ainoat toiminnallisuudet ovat käytännössä sivuilta toiselle, tai toiseen sisältöosioon siirtyminen.
No mut puhutaanko me samoista asioista enää?
Tyypillä on sivut ja se haluaa niistä nykyaikaisemmat? Eikö tällöin fallback ole juuri tärkeää, että sivut toimivat hakukoneiden takia normaalisti myös ilman javascriptiä? Eli että sivut ovat oikeasti olemassa myös "fyysisesti".
Samaa mieltä tuosta väkisin ajaxilla tunkemisesta, tosin välillä on "siistiä", että sivulla on jokin jippo, miten sivut "vaihtuvat".
Tuli tuosta Bootstrapista mieleen...
Miten sivujen muokkaus CSS:llä on tarkoitus tehdä? Muokkaanko suoraan Bootstrapin omia CSS-tiedostoja vai lisäänkö esim. ID:n Bootstrapin omiin tageihin joita sitten muokkaan omalla ulkoisella CSS-tiedostolla?
Esimerkkinä navigointi...:
<nav class="navbar navbar-default" >
<nav class="navbar navbar-default" id="navigointi">
Vai kuinka?
Miksi sinun tarvitsisi lisätä id? Tuossahan on jo monta asiaa, joilla pystyt kohdistamaan omat CSS-tyylisi oikealle elementille. (Kai tiedät, että sama CSS-valitsin, esimerkiksi nav.navbar.navbar-default, voi esiintyä monessa CSS-tiedostossa.)
Ainakaan "navigointi" ei ole id-tunnisteena järkevä. Nav-elementti ilmaisee navigaatiota. Samoin luokat navbar ja navbar-default ilmaisevat navigaatioita. "Navigointi" ei kerro lainkaan, miksi tämä yksi elementti (id on täysin elementtikohtainen) on erityinen.
Okei, eli fiksuin tapa on siis "ylikirjoittaa" Bootstrapin CSS-määritykset omalla tyylitiedostolla, ymmärsinkö oikein?
Tee niin kuin järkevimmäksi, sinun projektisihan se on. Jos se toimii, niin se toimii; ei pidä tehdä asioista liian vaikeita ennen kuin on edes aloittanut.
Ehdottomasti tyhmintä on tietysti muokata Bootstrapin css-tiedostoja, sillä silloin teet täysin mahdottomaksi päivittää Bootstrap-kirjastoja enää koskaan rikkomatta sivujasi. "Lähdekoodi" on less-tiedostoissa, joiden muokkaaminen on jo tietyin ehdoin jopa tarkoituksenmukaista. Less-tyylit generoidaan css-tiedosto(i)ksi tuotantokäyttöä varten.
Tyylit voi toki "ylikirjoittaa" omalla css-tiedostolla, mutta silloin selaimelle syötetään paljon turhaa css:ää (ne alkuperäiset Bootstrapin määritykset), jota ei koskaan tarvita. Luullakseni selain joutuu kuitenkin tekemään saman työn kuin jos tyylit olisivatkin oikeasti käytössä, mikä tarkoittaa turhaa työtä. Joka tapauksessa siitä seuraa turhaa trafiikkia verkossa. Pienillä saiteilla sillä ei kuitenkaan ole varsinaisesti merkitystä, joten devaamisen helpottaminen oikeuttanee asian.
Toisaalta Bootstrapin less-versio on aika modulaarinen, joten turhat duplikaattisäännöt voi onnistua poistamaan ihan pudottelemalla pois tarpeettomia less-tiedostoja. Tarkoittanet kuitenkin pieniä pinnallisia muutoksia, joten voit päästä pitkälle pelkästään muokkaamalla tiedostoa variables.less, joka on tavallaan Bootstrapin konffitiedosto.
Onni kirjoitti:
Okei, eli fiksuin tapa on siis "ylikirjoittaa" Bootstrapin CSS-määritykset omalla tyylitiedostolla, ymmärsinkö oikein?
Totta kai voit ylikirjoittaa, mutta yritä silti hyödyntää bootstrappia mahdollisimman paljon. Voit tietenkin käyttää siitä vain tarvittavan verran.
En nyt ymmärrä, miksi niitä ylipäätään pitäisi ylikirjoitella miksikään. Bootstrapin variables.less sisältää kaikki mitä muokata tarvitsee (esim eri collien raja-arvot jne) ja bootstrapiin liittyvät värimaailmat ja muut hoidetaan yleensä erillisellä teema templatella (Theme example). Teeman ulkopuolella käytät normaalisti omia css luokkiasi.
Lähinnä hän taitaa haluata vaihdella esim. oletusvärejä yms. omia luokkia käyttämällä, eikä vaihtaa värejä kaikkialle teemaan.
TL;DR: sivujen nykyaikaistaminen ei riitä. Pitää nykyaikaistaa myös työtavat.
---
Kivikaudellehan täällä on jääty kun jQueryä vielä suositellaan johonkin! Näppärä se toki on, mutta myös tarpeettoman isokokoinen varsinkin jos pääsääntöinen käyttötarkoitus on luoda elementtejä, pistää eventtejä pystyyn ja ehkä heittää pari Ajax-kutsua ilmoille. Joten hypätään nyt tässä ketjussa tälle vuosikymmenluvulle (kuvitelkaa mielessänne joku vanha peli ja transitio seuraavalle tasolle).
Frameworkkien kautta on muutama eri vaihtoehto. Niiden valinnassa kannattaa pitää mielessä pääpaino siinä, että asiat täytyy tehdä tietyllä tavalla (ts. sidotaan vähän käsiä ja luovuutta), jotta härävärkkikoodilta voitaisiin välttyä. Esimerkiksi jQuery ei sido minkäänmoiseen runkoon, vaan sillä voi tehdä kunnon "toimivaa" spagettia ilman mitään rajoitteita. Se on siis ennemminkin vain kirjasto. Maailma on kuitenkin yllätyksiä täynnä ja Backbone on vaihtoehto, jos haluaa rajoittaa villeimpiä koodin järjestelyongelmiaan, mutta pitäytyä samalla jQueryssä. En ole Backbonea itse käyttänyt kuin ihan hitusen verran, mutta muistaakseni monet käyttävät sitä nimenomaan jQueryn kanssa.
Angular on helppo laittaa olemassa olevalle HTML-sivulle ja sitten väkertää muutamat templaatit ja/tai sotkea muutamat kytkökset HTML:n sekaan. Vaikeampi puoli Angularissa on oppia mitä himskattia tarkoittavat direktiivit, scopet ynnä muut tilpehöörit. Angularin API sisältää jotkut 130 eri kilkettä, joten opiskeltavaa riittää. Ja jos haluaa että asiat on nopeita, niin joutuu kiinnittämään huomiota (esim. koska pitää kutsua $scope.$digest(), jotta suorituskyky ei hyydy totaalisesti).
React on sitten se Facebookin itsensä käyttämä hilavitkutin, jolla voi tehdä juurikin ajantasalla pysyvää höttöä. React poikkeaa Angularista vahvasti siinä, että templaatteja ei ole olemassa. Toisaalta React ei ole ihan täysverinen framework, vaan se keskittyy ihan vain näkymän puolelle. Frameworkmäisen Reactista tekee lähinnä se, että koodaaja on pakotettu käyttämään Reactin maailmankuvaa, eli käytännössä komponentteja, joille syötetään propseja ja joiden sisällä on oma state, jota taas voidaan jakaa seuraaville komponenteille. Tieto kulkee pääasiallisesti yhteen suuntaan ja päinvaistaiseen suuntaan kuljettamisesta on tehty tarkoituksella vaikeaa, jotta asiat pysyvät ruodussa. Puhtaimmat React-komponentit ovat sellaisia, että jos se saa tietyt propsit sisään, niin renderöity lopputulos on aina samanlainen.
Reactissa on sitten se nurja puoli, että se esittelee oman JSX-syntaksinsa (jota tosin ei ole pakko käyttää), joka mahdollistaa "HTML:n kirjoittamisen JavaScriptissä". Kuulostaa hurjalta, mutta se on aika yksinkertainen asia jahka aivoja vähän taivuttaa. Isoin ongelma on muistaa kirjoittaa className class:n sijasta ja htmlFor for:n sijasta, kun kirjoittaa attribuutteja. Oikeasti siis HTML:stä muodostuu JavaScriptiä, joka sitten suoritetaan ja se luo virtuaalisen DOM-puun, jota valikoiden vertaillaan oikeaan DOMiin.
Sitten on semmoinen hieno juttu kuin isomorfisuus. Tarkoittaa sitä, että palvelimella oleva React-koodi ajetaan, tarjoillaan HTML:nä ja selaimessa oleva React sitten ottaa kopin sivunlatauksen yhteydessä ja alkaa natsittaa DOMmia ja pitää sitä reaaliaikaisesti yllä. Semmoista asiaa, joka helposti pistää pään sekaisin kun koodissa voi olla palvelinpuolen ja selainpuolen koodia rinnakkain. Ja vaatii Node.js:n pyörittämässä ympäristöä, joten en usko että tässä nyt kukaan heti alkaa innokkaasti tehdä isomorfista React-sivustoa...
Mithril on sitten söpö pieni väkkyrä. Ja mahdollistaa himskatin nopean koodin teon. Se on vain jonkun 7 kt minifioituna ja gzipattuna tarjottuna, eli tosi pieni. Sisältää silti kaiken olennaisen rakenteen, jotta ohjelmia voi tehdä täysipainoisesti. Toisin kuin Reactin tai Angularin kohdalla, niin opiskeltavaa ei ole kovinkaan paljoa. Mithril on siitä reactimainen, että sekin luo DOM-puut virtuaalisen DOMin avulla ja JavaScript-syntaksista käsin (tosin ilman JSX:ää). Sitten on jokusia framework-työkaluja kuten routen (urlien) hallintaa ja Ajax-pyynnöt mahdollistava kilke. Kaikkiaan pieni API, joka on vain jossain tusinassa opiskeltavassa metodissa.
Tässä sitten loppusaatteena voinee tuoda esiin sen, että nykyään ECMAScript5 on JavaScript-koodauksen minimitaso. Eli kaikkea hienoa kuten isArray-juttuja, mappauksia, reducea, somea ja everyä pääsee käyttämään. Vanhemmille selaimille voi heittää es5-shimmin. Isoin tuulahdus on kuitenkin se, että väki on alkanut käyttää jo ES6:tta (tai siis ES2015 kuten se nykyään nimeltään on), koska Babel osaa hoitaa kääntämiset selainystävälliseksi ES5:ksi. Tämä sitten vaatii kehitysympäristön ynnä muun hienouden säätämistä käyttökuntoon, mutta sitten kun sellaiset on pystyssä niin koodaaminen on mukavan vikkelää.
JavaScript-maailmassa tapahtuu tällä hetkellä todella paljon ja erilaisia ratkaisuja on aikamoinen määrä. Nuo nelisen esilletuomaani vaihtoehtoja on vain pintaraapaisu kaikesta valittavissa olevasta. Yksi tapa tehdä vertailuja eri vaihtoehtojen välillä on tarkastella TodoMVC-toteutuksia. Kannattaa myös asentaa Node ja opetella komento npm install. Ja sitten vaan alkaa kokeilla.
Aihe on jo aika vanha, joten et voi enää vastata siihen.