Eli mikä on nykypäivänä nykyaikainen tapa tehdä asiakaspään (frontend) -nettisivuja?
Onko nykypäivän trendi ohjelmoida frontend pelkkien JavaScript-kirjastojen avulla (esim. Bootstrap, AngularJS, knockoutJS ja LESS)? Tiedot lähetetään sitten sovelluksen palvelinpäälle (backend) joka ottaa vastaan esimerkiksi JSON-olioita ja tallentaa ne esimerkiksi JPA entiteetteinä relaatio/nosql-kantaan.
Vai mikä on nykypäivän trendi? Mitkä ominaisuudet ovat myös tärkeitä nykypäivänä web-kehityksessä esim. responsiivisuus...?
Riippuu paljolti tilanteesta, mutta responsiivisuus on varmaankin yksi minkä nykyään voisi ajatella olevan useimmiten lähtökohta.
Client-puolen matskuista mainitsit useampaankin eri käyttötarkoitukseen sopivia matskuja. SPA-juttuihin Knockout tai Angular on hyviä vaihtoehtoja, ja Bootstrapilla saat perustan sivujen asettelulle ja lookille.
Mutta se mikä on tärkeää riippuu siitä mitä ollaan tekemässä. Esmes telkku.comin kaltainen saitti tuskin hirveämmin hyötyy Angularista jne.
Ehkä nykytrendinä voisi mainita APInoinnin, eli käyttöliittymä nettiselaimen kautta ja mobiilisovelluksen kautta toimii saman endpointin kautta.
timoh kirjoitti:
Ehkä nykytrendinä voisi mainita APInoinnin, eli käyttöliittymä nettiselaimen kautta ja mobiilisovelluksen kautta toimii saman endpointin kautta.
Mita mahdoit tarkoittaa APIoinnilla? Olisiko kyseisestä aiheesta mitään linkkiä tai pientä lisäinfoa?
Query kirjoitti:
Mita mahdoit tarkoittaa APIoinnilla? Olisiko kyseisestä aiheesta mitään linkkiä tai pientä lisäinfoa?
Miten olisi vaikka API eli ohjelmointirajapinta? timoh:n kuvaus tiivistääkin käyttötarkoituksen ihan hyvin.
Mitä tulee javascript frameworkkien käytöstä, sinun tulee tarkkaan punnita että tarvitsetko sitä vai et. Mikäli sivut pyörii ajax kutsujen ympärillä, tai haluat hallita suurempia määriä sivulle rendattuja, mutta piilotettuja sisältöja, tulee js framework näppärästi helpottamaan ja siistimään työtä. Mikäli sivun sisältö ei postbackien välillä oleellisesti muutu, on js framework usein turha lisäviritys pieniin määriin javascriptiä.
Oleellisena asiaan liittyy myös itse serveri ja client puolen välinen pattern: mikäli käytössäsi on jo esim. MVC -pohjainen ratkaisu (vaikka Ruby on rails, ASP.NET MVC tai PHP MVC), on yleensä turhaa sotkea väliin enää esim. Knockoutin MVVM patternia, koska saat samat asiat rendattua suoraan MVC:n näkymässä (Sen sijaan että rendailet MVC:n näkymän / partialin kamoja JS MVVM frameworkin näkymässä).
Usein käytetään frameworkkeja silloinkin kun ei oikeasti tarvitsisi. Groovybin pointti on erittäin hyvä. Mitä oikeasti tarvitset. Ja se rajapinta on sitten tärkeä. Serverin pitäisi pystyä pureskelemaan hyödyllinen tieto tuohon APIin sellaiseen muotoon, että selaimen puolella ei tarvitse JS:n arpoa puolta päivää.
Sen lisäksi, että frameworkit tuovat ominaisuuksia, tuovat ne myös bugeja. Varomaton käyttö käyttääkin palikkaa joka ei toimi IE jossain.
Voisin ilkeämielisesti myös sanoa, että webbisoftien suunnittelu on todella olematonta. Otetaan palikoita ja läiskitään yhteen kunnes jokin toimii jotenkin. Hyvin suunniteltu järjestelmä on yleensä nopea ja varsinkin jos API saadaan tuossa välissä fiksuksi. Normaalit ohjelmistosuunnittelutoimenpiteet ja KISS pätee tässäkin.
Aihe on jo aika vanha, joten et voi enää vastata siihen.