Modernin front-end JavaScript-sovelluskehyksen valinta

(1)

Modernin front-end JavaScript-sovelluskehyksen valinta

Niko Mäkeläinen

Pro gradu –tutkielma

Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede

Marraskuu 2020

(2)

i

ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Joensuu Tietojenkäsittelytieteen laitos

Tietojenkäsittelytiede

Opiskelija, Niko Mäkeläinen: Modernin front-end JavaScript-sovelluskehyksen valinta

Pro gradu –tutkielma, 108 s., 5 liitettä (5 s.) Pro gradu –tutkielman ohjaaja: FT Simo Juvaste Marraskuu 2020

Tiivistelmä:

Tutkielman tavoitteena oli selvittää mitä JavaScript-sovelluskehykset ovat ja tehdä katsaus tämän ajan suosituimpiin ja hyödyllisimpiin sovelluskehyksiin sekä toimia va- lintaoppaana ja helpottaa sovelluskehyksen valintaa Reactin, Angularin, Vuen ja Em- berin välillä.

JavaScript on suosittu ohjelmointikieli, jota käytetään esimerkiksi verkkosovellusten kehityksessä. JavaScript-sovelluskehykset ovat JavaScriptiä hyödyntäviä työkaluja, jotka suoraviivaistavat verkkosovellusten kehitystä. Verkkosovellusten kehitys on ny- kyään suositumpaa kuin työpöytä- tai mobiilisovellusten kehitys.

Vertailuun valittiin React, Angular, Vue ja Ember, koska ne keskittyvät verkkosovellusten asiakaspäähän ja ne ovat olleet markkinoilla jo useita vuosia. Sovelluskehykset valittiin myös siksi, että haluttiin selvittää vastaavatko tutkielmassa muodostetut joh- topäätökset sovelluskehysten käyttäjien näkemyksiä suosituimmista sovelluskehyk- sistä. Aiemman tutkimuksen mukaan JavaScript-sovelluskehyksen valintaan vaikuttavat muun muassa suosio, dokumentaatio, laajennettavuus, kustannukset ja sovelluskehysten tuottama koodi. Tutkielmassa sovelluskehyksistä vertailtiin edellä mainittujen lisäksi sovelluskehysten versiojulkaisuja, jatkokehitystä, ylläpitoa, tiimejä, yhteisöjä, käyttömääriä ja työpaikkoja. Vertailussa hyödynnettiin muun muassa kyselyitä ja sovelluskehysten virallisia dokumentaatioita.

Kustannuksissa, laajennettavuudessa, yhteensopivuudessa ja yhdistettävyydessä ei ole suuria eroja. React on varma valinta, jos hakee suosittua, kehittäjiä kiinnostavaa ja markkinoilla aktiivisesti hyödynnettyä sovelluskehystä. Angularin valintaa tukevat paras ylläpito ja taustalla vaikuttava suuri tiimi. Vue on hyvä valinta, mikäli arvostaa yhteisölähtöisen tiimin toimesta kehitettävää sovelluskehystä ja hyvää dokumentaa- tiota. Emberiä on vaikeaa suositella muille kuin suurille yrityksille, jotka arvostavat sisäänrakennettuja testaustyökaluja ja sovelluksen jakamista useisiin itsenäisesti toi- miviin alisovelluksiin.

Avainsanat: Verkkosovellukset, JavaScript, asiakaspää, sovelluskehykset ACM-luokat (ACM Computing Classification System, 2012 version):

•Information systems~Web applications •Software and its engineering~Scripting lan- guages •Software and its engineering~Development frameworks and environments • Information systems~Web interfaces

(3)

ii

UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, Joensuu School of Computing

Computer Science

Student, Niko Mäkeläinen: Selection of modern front-end JavaScript framework Master’s Thesis, 108 p., 5 appendixes (5 p.)

Supervisor of the Master’s Thesis: PhD Simo Juvaste November 2020

Abstract:

The goal of this thesis was to find out what JavaScript frameworks are and review at the most popular and the most useful JavaScript frameworks of this time. Another goal was that the thesis would work as a selection tool and help in choosing between React, Angular, Vue and Ember.

JavaScript is a popular programming language which is used e.g. in web application development. JavaScript frameworks are tools which utilize JavaScript and make it more straightforward to develop web applications.

React, Angular, Vue and Ember were selected for comparison because they focus on front-end of web applications and because they have been on the market for several years. Frameworks were selected also because one objective of the thesis was to find out if the obtained conclusions and the opinions of the framework users about the most popular frameworks were the same. According to a previous study, popularity, documentation, extensibility, costs and code generated by the frameworks have an impact on selection of JavaScript framework. In addition to the previous factors, version re- leases, further development, maintenance, teams, communities, jobs and usage of the frameworks were compared. For example, surveys and official documentations were used in the comparison.

There is no big difference in costs, extensibility, compatibility, and connectivity. React is a clear choice if one is searching for a framework that is popular, interesting for developers and actively used in the market. Best maintenance and large team behind Angular support its choice. Vue is a good option if one values community driven team behind the framework and a good documentation. Ember is difficult to recommend to others than large companies which value built-in test tools and the ability to divide applications into several standalone sub-applications.

Keywords: Web applications, JavaScript, front-end, frameworks CR Categories (ACM Computing Classification System, 2012 version):

•Information systems ~Web applications •Software and its engineering~Scripting lan- guages •Software and its engineering~Development frameworks and environments • Information systems ~ Web interface

(4)

iii

Esipuhe

Tein tämän tutkielman opintojeni loppuvaiheessa Itä-Suomen yliopiston tietojenkäsit- telytieteen laitokselle viimeisimpinä työnä ennen valmistumistani. Valitsemaani tutkielman aiheeseen päädyin, koska olen tähänastisen työurani aikana työskennellyt joi- takin vuosia web-kehittäjän roolissa verkkosovellusten front-endin ja back-endin parissa. Työtehtävissäni olen käyttänyt erilaisia teknologioita, mutta haluan oppia niistä jatkuvasti enemmän. Työtehtävät ovat painottuneet enemmän back-endin puolelle, ja tämän takia halusin ymmärtää front-end sovelluskehyksiä paremmin.

Työtehtävissäni sekä vapaa-ajan projekteissa olen huomannut, että JavaScript-sovel- luskehyksiä on markkinoilla todella paljon ja itselle sopivimman sovelluskehyksen valinta on haastavaa. Urani aikana olen huomannut, että verkkosovellusten back-end teknologiat ovat pysyneet vuosien saatossa lähes vakiona, mutta front-end puolella teknologioiden vaihtuvuustahti on hurja ja myös se tekee valinnasta haastavaa.

Tutkielman aihe osoittautui mielenkiintoiseksi. Aloittaessani tutkielman tekoa, en ollut aivan varma mitä asioita haluan sovelluskehyksistä vertailla ja käsitellä ja välillä vertailtavien asioiden valitseminen tuntui vaikealta. Visioni tutkielman tarkoituksesta, rakenteesta ja sisällöstä kuitenkin selkeytyi, kun löysin tutkielman kolmannessa luvussa esitellyn tieteellisen tutkimuksen. Jo aiheen hahmotteluvaiheessa tiesin, että en halua vertailla sovelluskehyksiä hyvin teknisellä ja yksityiskohtaisella tasolla, koska kyseisiä vertailuja löytyy internetistä jo valmiiksi sekä tarkat tekniset yksityiskohdat on parasta opetella ja tarkistaa suoraan virallisista dokumentaatioista. Tekniset yksityiskohdat voivat muuttua merkittävästi esimerkiksi versiojulkaisujen välillä. Tutkiel- massa perehdyin sovelluskehysten dokumentaatioihin siten, että sain jokaisesta sovel- luskehyksestä käsityksen vähintään korkealla tasolla. Tulen todennäköisesti jossain vaiheessa tulevaisuudessa perehtymään Vueen tai Angulariin tarkemmin, koska ne vaikuttivat itsestäni mielenkiintoisimmilta.

Koska tämä tutkielma on viimeinen suuri työni Itä-Suomen yliopistoon, niin haluan esittää kiitokseni. Haluan kiittää kaikkia Itä-Suomen yliopiston, Joensuun kampuksen, opettajia, joiden kursseilta sain vuosien varrella tärkeitä oppeja. Oppimani asiat ovat olleet hyödyllisiä jo alkaneella työurallani ja uskon vahvasti, että ne tulevat olemaan hyödyllisiä myös jatkossa. Kiitokseni haluan osoittaa etenkin kaikille tietojenkäsitte- lytieteen laitoksen opettajille, laitoksella työskenteleville ja muihin haasteisiin tai jo eläkkeelle poistuneille. Osoitan kiitokseni Simo Juvasteelle tutkielmani ohjauksesta.

Lisäksi kiitän kaikkia opiskelukavereitani hauskoista ja mieleenpainuneista kokemuk- sista, joita koimme yhdessä opintojen aikana, etenkin Joensuussa. Lopuksi esitän suurimmat kiitokseni perheelleni kaikesta tuesta ja kannustuksesta, joita olen saanut opintojeni, tutkielman teon ja muun elämäni aikana.

Tästä on hyvä jatkaa.

Niko Mäkeläinen

(5)

iv

Lyhenneluettelo

AJAX Asynchronous JavaScript and XML. Asynkroninen JavaScript ja XML eli joukko teknologioita verkkosovellusten ja palvelimen väliseen kom- munikaatioon.

Back-end Verkkosovellusten palvelinpää.

CLI Command-line interface. Komentorivi.

CSR Client-side rendering. Asiakaspäässä piirtäminen.

CSS Cascading Style Sheets. Käytetään mm. tyyliohjeina verkkosivuilla ja verkkosovelluksissa.

DOM Document Object Model. Dokumenttioliomalli eli tapa kuvata rakentei- nen dokumentti kuten HTML-rakennepuu.

FCP First Contentful Paint. Hetki, kun verkkoselain piirtää DOM:in ensim- mäisen osan käyttäjälle ja käyttäjä saa palautteen, että sivu latautuu.

FP First Paint. Aika, kun mikä tahansa verkkosivun pikseli tulee käyttäjän näkyviin.

Front-end Verkkosovellusten asiakaspää.

HTML Hypertext Markup Language. Hypertekstin merkintäkieli. Käytetään mm. verkkosivujen rakentamisessa.

IDE Integrated Development Environment. Integroitu kehitysympäristö, joka sisältää ohjelmistokehityksessä tarvittavia työkaluja ja prosesseja.

JS JavaScript. Ohjelmointikieli, jota käytetään mm. verkkosivujen ja verkkosovellusten kehityksessä.

JSX JavaScript XML. HTML:ää ja XML:ää muistuttava syntaksilaajennus, joka käännetään JavaScriptiksi.

LTS Long-Term Support. Pitkän ajan tuki eli aika, jona ohjelmistoa ylläpide- tään.

MVC Model-View-Controller. Malli-Näkymä-Ohjain, suunnittelumalli.

PWA Progressive Web Application. Verkon yli tarjoiltu mobiilisovelluksen toimintaa jäljittelevä verkkosovellus.

REST Representational state transfer. Arkkitehtuurityyli, joka tarjoaa standardeja internetissä toimivien tietokonejärjestelmien väliseen kommunikaa- tioon.

SOC Separation of Concerns. Tietokoneohjelmien suunnitteluperiaate, jossa ohjelman erilliset osat erotellaan siten, että jokainen osa tarjoaa ratkaisun vain tiettyyn ongelmaan.

SPA Single-page application. Yhdellä sivulla toimiva verkkosovellus tai verkkosivu.

SSR Server-side Rendering. Palvelimella piirtäminen.

TTFB Time to First Byte. Aika linkin klikkauksen ja sisällön ensimmäisen bitin latauksen välillä.

TTI Time to Interactive. Aika, jossa sivusta tulee interaktiivinen ja käyttäjä pystyy olemaan vuorovaikutuksessa sivun kanssa.

UI User Interface. Käyttöliittymä.

UX User Experience. Käyttäjäkokemus.

XML Moderni verkkoteknologia.

(6)

v

Sisällysluettelo

1 Johdanto ... 1

2 Modernit verkkosovellukset ... 3

2.1 Verkkosovellukset ... 3

2.2 Modernien verkkosovellusten arkkitehtuuri ... 4

2.3 Verkkosovellusten käyttöliittymät ... 5

2.4 Verkkosovellusten käyttöliittymien rakennus- ja piirtämismenetelmät7 2.5 Kehityksen siirtyminen internettiin ja käyttäjien odotukset ... 10

2.6 JavaScript, JavaScript-kirjastot ja -sovelluskehykset ... 14

2.7 SPA-, PWA- ja mobiilisovellukset ... 17

3 Tutkimus sovelluskehyksen valinnasta, kyselyiden esittely ja sovelluskehysten rajaaminen ... 19

3.1 Tutkimus JavaScript-sovelluskehyksen valinnasta ... 19

3.2 Kyselyt ... 26

3.3 Tutkielmaan valitut sovelluskehykset ... 29

4 Tutkielman sovelluskehykset ... 32

4.1 React ... 32

4.2 Angular ... 34

4.3 Vue ... 36

4.4 Ember ... 38

5 Sovelluskehysten vertailu ja keskinäiset suhteet ... 41

5.1 Kustannukset ja lisenssit ... 42

5.2 Versiojulkaisut, jatkokehitys ja ylläpito ... 42

5.2.1 Versiojulkaistut ja ylläpito ... 42

5.2.2 GitHub issuet ... 46

5.2.3 GitHub forkkaukset ja pull requestit ... 47

5.2.4 GitHub commitit ... 48

5.3 Sovelluskehysten tiimit ja yhteisöt ... 51

5.3.1 Tiimit ... 51

5.3.2 GitHub-yhteisöjen koko ja osallistuminen kehitykseen ... 54

5.3.3 Yhteisöjen aktiivisuus kommunikaatioalustoilla ... 56

5.3.4 Paikalliset yhteisöt ... 58

5.4 Suosio ja kiinnostus ... 59

5.4.1 Npm-lataukset ja -riippuvuudet ... 59

5.4.2 GitHub-tähdet ... 61

5.4.3 Kyselyt ... 64

5.5 Laajennettavuus, yhteensopivuus ja yhdistettävyys ... 68

5.5.1 Piirtäminen palvelimella ... 68

5.5.2 Muut sovelluskehykset, kirjastot ja lisäosat ... 69

5.5.3 Rajapinnat ja tietokannat ... 74

5.6 Dokumentaatio ... 76

5.7 Käyttömäärät Suomessa ja maailmalla ... 77

(7)

vi

5.8 Työpaikat Suomessa ja maailmalla ... 81

6 Keskustelu vertailun tuloksista ja sovelluskehysten roolitus ... 86

7 Yhteenveto ... 96

Viitteet ... 98

Liite 1: Sovelluskehyksen valinta ... 109

Liite 2: Valinta – Arvostus ja luotettavuus (osa 1) ... 110

Liite 3: Valinta – Arvostus ja luotettavuus (osa 2) ... 111

Liite 4: Valinta – Dokumentaatio, sisäiset ja ulkoiset kirjastot ... 112

Liite 5: Valinta – Kustannukset, lisenssit ja työpaikat ... 113

(8)

1 Johdanto

Tämä pro gradu -tutkielma on kirjallisuuskatsaus moderneista JavaScript-sovelluske- hyksistä ja niiden hyödyntämisestä verkkosovelluksissa. Tutkielman tavoitteena on käydä läpi tämän ajan suosituimpia ja hyödyllisimpiä front-end sovelluskehyksiä ja - kirjastoja sekä toimia työkaluna, joka auttaa omiin käyttötarkoituksiin parhaiten sopi- van sovelluskehyksen valinnassa. Tutkielmassa sovelluskehyksiä pyritään käsittele- mään näkökulmista, jotka tarjoavat esimerkiksi yritysten päättäjille ja kehittäjille hyö- dyllistä informaatiota. Kehittäjillä voidaan tutkielman kontekstissa tarkoittaa opiske- lijoita tai henkilöitä, jotka haluavat esimerkiksi ymmärtää mitä sovelluskehyksiä kannattaa opiskella tulevaa työnhakua ajatellen. Näkökulmien käsittelyssä on jätetty pois sovellusten loppukäyttäjien näkökulmat, koska eri sovelluskehyksillä kehitetty verkkosovellus näyttäytyy yleensä käyttäjille samanlaisena eivätkä loppukäyttäjät ole vält- tämättä kiinnostuneita siitä, millä sovelluskehyksellä tai teknologialla mikäkin sovellus on kehitetty. Sovelluskehysten välillä on eroja esimerkiksi kustannuksissa, tehok- kuudessa tai helppokäyttöisyydessä, mutta kyseiset asiat yleensä kiinnostavat eniten päättäjiä ja kehittäjiä. Tutkielma on toteutettu kirjallisuuskatsauksena, joka ei sisällä itse tehtyä kokeellista osiota, koska sovelluskehityksistä ja niihin liittyvistä asioista on saatavilla jo valmiiksi paljon tietoa. Tutkielman tarkoituksena ei myöskään ole toimia tarkkana syntaksioppaana tai tarkkojen teknisten yksityiskohtien esittelynä, koska ky- seisiin asioihin löytyy paras ja ajankohtaisin tieto kunkin sovelluskehyksen virallisesta dokumentaatiosta. Tutkielman teoriaosuudessa käytetään tieteellisiä lähteitä ja sovelluskehysten käsittelyssä ja vertailussa hyödynnetään pääsääntöisesti sovelluskehysten virallisia dokumentaatioita ja muita tukevia materiaaleja.

Tutkielman tutkimusongelmana on selvittää JavaScript-sovelluskehyksiin ja niiden valintaan liittyviä kysymyksiä. Mitä JavaScript-sovelluskehykset ovat ja mitkä kehykset ovat tällä hetkellä suosituimpia? Mikä tai mitkä tarjolla olevista sovelluskehyksistä kehittäjien ja päättäjien tulisi valita, annetut vaatimukset huomioon ottaen? Kuinka sovelluskehys toimii muiden järjestelmien kanssa? Kuinka sovelluskehys toimii tois- ten sovelluskehysten kanssa?

(9)

Tutkielma koostuu yhteensä seitsemästä erillisestä luvusta, joista johdanto on ensim- mäinen luku. Tutkielman toisessa luvussa käsitellään mitä modernit verkkosovellukset ovat ja millaisia odotuksia käyttäjillä on niitä kohtaan. Lisäksi luvussa lyhyesti esitel- lään JavaScript-kirjastot ja sovelluskehykset sekä kuinka suuri osa nykyajan kehityk- sestä liittyy verkkosovelluksiin. Kolmannessa luvussa tarkastellaan tieteellisen tutkimuksen löydösten pohjalta, millaiset asiat vaikuttavat JavaScript-sovelluskehyksen valintaan ja saman luvun viimeisessä kohdassa rajataan tutkielmassa käsitellyt sovelluskehykset. Neljännessä luvussa valitut sovelluskehykset esitellään lyhyesti. Viiden- nessä luvussa sovelluskehyksiä vertaillaan muun muassa seuraavien osa-alueiden osalta: kustannukset ja lisenssit, versiojulkaisut, jatkokehitys ja ylläpito, sovelluskehysten tiimit ja yhteisöt, suosio ja kiinnostus, laajennettavuus, yhteensopivuus ja yh- distettävyys, dokumentaatio, käyttömäärät sekä viimeisenä työpaikat. Kuudennessa luvussa käsitellään viidennen luvun vertailujen tuloksia ja tehdään tuloksista johtopää- töksiä ja suosituksia. Viimeisenä lukuna on yhteenveto tutkielmasta.

Kehittäjien ja ammatinharjoittajien näkökulmasta omiin käyttötarkoituksiin soveltu- van JavaScript-sovelluskehyksen valinta voi olla haastavaa. Markkinoilla on paljon sovelluskehyksiä ja monet niistä ovat myös hyvin samanlaisia. Jo vuonna 2013 tutkijat (Graziotin & Abrahamsson, 2013) totesivat tutkimuksessaan, että kyseinen valinta on haastavaa, koska tarjolla on useita sovelluskehyksiä, mutta ammatinharjoittajia hyö- dyttävää tutkimusta tai materiaalia valinnasta on vähän. Joistakin sovelluskehyksistä on tarjolla suorituskykytestejä, mutta ammatinharjoittajia kiinnostavat usein eri asiat kuin vain suorituskyky. Ammatinharjoittajat ovat kiinnostuneita esimerkiksi sovelluskehysten koosta tai selaintuesta. Suorituskykyyn ja perinteisiin ohjelmistomittareihin pohjautuvia tutkimuksia on tehty, mutta ne hyödyttävät tutkijoiden mukaan enemmän akateemisia tutkijoita kuin ammatinharjoittajia.

JavaScript-sovelluskehykset ovat hyödyllisiä, koska ne voivat tehdä sovelluksista helpommin ymmärrettäviä ja nopeuttaa ohjelmistokehitystä. Sovelluskehyksiä hyödyntä- mällä kehittäjien ei välttämättä tarvitse itse huolehtia monimutkaisten ja vaikeiden operaatioiden toteutuksista eikä selainyhteensopivuuksista. (Graziotin & Abrahams- son, 2013)

(10)

2 Modernit verkkosovellukset

Tässä luvussa esitellään ja käsitellään tutkielman kannalta tärkeimpiä käsitteitä ja teo- rioita. Ensimmäisessä kohdassa 2.1. esitellään mitä verkkosovellukset ovat ja sen jäl- keen tarkastellaan verkkosovellusten arkkitehtuuria (kohta 2.2.), käyttöliittymiä (kohta 2.3.) sekä verkkosovellusten käyttöliittymien rakentamista ja piirtämistä (kohta 2.4.).

Kohdassa 2.5. tarkastellaan kehityksen internettiin siirtymistä ja käyttäjien odotuksia.

Tämän jälkeen käsitellään JavaScriptiä ja JavaScriptiin liittyviä kirjastoja ja sovellus- kehyksiä (kohta 2.6.). Viimeisessä kohdassa 2.7. määritellään lyhyesti SPA-, PWA- ja mobiilisovellukset.

2.1 Verkkosovellukset

Network Encyclopedia (2020) määrittelee verkkosovelluksen (engl. web application) verkkosivulla olevaksi elementtikokoelmaksi, joka suorittaa toimintoja internetin yli.

Verkkosovellukset suoritetaan yleensä jollakin verkkopalvelimella ja sovellusten käyt- töliittymä näytetään käyttäjille verkkoselaimen kautta. Google Chrome on yksi esi- merkki mahdollisesta verkkoselaimesta. Käyttäjien toimenpiteiden seurauksena verk- kopalvelimelle lähetetään internetin yli pyyntö (engl. request), johon verkkopalveli- mella oleva sovelluspalvelin generoi vastauksen. Vastaus palautuu sovelluspalvelimen ja verkkopalvelimen kautta takaisin käyttäjän selaimeen. Network Encyclopedian mukaan verkkosovelluksia ei tarvitse erikseen asentaa eivätkä ne vaadi suurta tallennustilaa käyttäjän laitteelta, koska verkkosovellukset ainoastaan näyttävät käsiteltävän datan selaimen kautta ja varsinainen data tallennetaan yleensä jonnekin etäsijaintiin. Fa- cebook, Gmail, LinkedIn ja Amazon ovat esimerkkejä verkkosovelluksista.

Network Encyclopedia (2020) käsittelee määritelmässä verkkosovellusten eroja verrattuna perinteisiin verkkosivuihin sekä verkkosovellusten heikkouksia. Perinteisiin verkkosivuihin verrattuna verkkosovellukset ovat usein interaktiivisempia ja ne vaati- vat usein jonkinlaisen todennuksen (engl. authentication) käyttöä. Kaikissa tapauksissa todennusta ei kuitenkaan vaadita. Verkkosovelluksia myös integroidaan useammin toi- siin järjestelmiin kuin perinteisiä verkkosivuja. Verkkosovelluksilla on myös heik-

(11)

kouksia, sillä verkkosovellukset ovat hyvin riippuvaisia palvelimesta, jolla ne suoritetaan. Esimerkiksi jos palvelinyhteys kaatuu, taustalla vaikuttava palvelin sammutetaan kokonaan tai sitä hallinnoiva yritys lopettaa toimintansa, ei sovellusta voi enää käyttää.

Heikkoutena on myös, että verkkosovelluksessa käytetty data on usein hyvin sidottu sovellukseen eikä käyttäjällä ole välttämättä mahdollisuutta tallentaa dataa käytettä- väksi toisissa sovelluksissa. Verkkosovellukset myös noudattavat erilaisia standardeja, joita verkkoselaimet tukevat eri tavoin. Jos jokin selain ei tue tiettyä standardia, ei käyttäjä välttämättä pysty käyttämään verkkosovellusta ollenkaan. Lisäksi verkkosovellusten käyttökokemus olla erilainen verrattuna perinteisiin sovelluksiin.

Perinteiset verkkosovellukset muodostavat käyttöliittymän HTML:nä ja tarpeen vaatiessa sitä laajennetaan mediatiedostoilla ja esimerkiksi CSS-, JS-, JSON- ja XML- resursseilla. Palvelimen ja asiakkaan välisessä vuorovaikutuksessa hyödynnetään yleensä TCP/IP-protokollan päälle rakennettuja HTTPS- ja HTTP-protokollia. HTTP- protokolla tukee osittaisia, yleensä asynkronisia, palvelinpyyntöjä sovelluksen resurs- seihin. Esimerkki asynkronisesta pyynnöstä on AJAX (engl. Asyncronous JavaScript and XML). Palvelimet tuottavat käyttöliittymän asiakkaille HTML-muodossa, mutta muita koodeja tai abstrakteja kieliä voidaan käyttää tarvittaessa laajentamaan HTML:ää. Esimerkiksi PHP-koodin avulla voidaan laajentaa verkkosovelluksen toi- minnallisuuksia. Abstrakti kieli mahdollistaa sovellusten osien kuvaamisen yleisellä tasolla sekä sovellusten osien muuntamisen HTML- tai JavaScript-koodiksi ennen kuin sovellus lähetetään asiakkaalle. Yksi esimerkki abstraktin kielen eduista on kielen kyky tuottaa abstraktista määritelmästä spesifit sovellusversiot eri selaimille. Google Web Toolkit (GWT) on esimerkki abstraktista kielestä. (Cerny & Donahoo, 2016)

2.2 Modernien verkkosovellusten arkkitehtuuri

Nykyajan modernit verkkoteknologiat mahdollistavat verkkosovellusten kehittämisen nopeasti ja saman koodipohjan käyttämisen siten, että sovellukset toimivat luontevasti verkkoselaimissa sekä mobiililaitteissa. Mobiililaitteilla tarkoitetaan esimerkiksi äly- puhelimia ja tabletteja. Saman koodipohjan käyttäminen mahdollistaa sovellusten muuntamisen ”natiiveiksi”, mobiililaitteilla toimiviksi, sovelluksiksi myöhemmin, mi- käli muunnos halutaan myöhempänä ajankohtana tehdä. Uusien teknologioiden, kuten

(12)

sovelluskehysten ja kirjastojen, hyödyntäminen tarjoaa yrityksille mahdollisuuden ke- hittää uusia ja paranneltuja tuotteita kilpailijoita nopeammalla tahdilla. Useimmat verkkoselaimissa toimivat sovellukset koostuvat HTML, JavaScript (JS) ja CSS-tek- nologioista. (Shahzad, 2017)

Kuva 1. Moderni verkkosovelluksen arkkitehtuuri. (Shahzad, 2017)

Kuvassa 1 havainnollistetaan modernin verkkosovelluksen tyypillistä arkkitehtuuria.

Modernin verkkosovelluksen arkkitehtuurissa pyritään siihen, että DOM (engl. Docu- ment Object Model) toimii irrallisena kokonaisuutena, jota verkkosovellus päivittää tarpeen vaatiessa. DOM:iin esimerkiksi tulostetaan sovelluksen HTML-koodi ja DOM:n elementteihin kohdistetaan tarvittavat operaatiot. Arkkitehtuurissa pyritään siihen, että DOM:sta ei lueta dataa. Dataa ei myöskään tallenneta DOM:iin vaan dataa hallinnoidaan erityisten mallien (engl. model) kautta. Mallit vastaavat datan varastoin- nista, yleensä tietokantaan, hyödyntämällä AJAX-teknologiaa tai palvelinpuolen skriptejä. Sovelluksen näkymät (engl. view) tarkkailevat datan muutoksia malleissa ja kun näkymät saavat tiedon datan muutoksesta, niin näkymät piirretään uusiksi tarpei- den vaatimalla tasolla. Näkymät hyödyntävät informaation piirtämisessä myös malli- kappaleita (engl. template), jotka voidaan toteuttaa käyttöliittymän muotoilun mukai- sesti.

2.3 Verkkosovellusten käyttöliittymät

Käyttöliittymät (engl. User Interface, usein lyhennetty UI) ovat erilaisten sovellusten, kuten työpöytä- tai verkkosovellusten osa, jonka kautta käyttäjille esitetään staattista

(13)

tai dynaamista sisältöä, jonka kanssa he ovat vuorovaikutuksessa. Käyttöliittymissä esitettävä sisältö voidaan tuottaa joko sovellusten asiakaspäässä tai palvelimella. Käyt- töliittymiin liittyy usein keskeisesti myös käyttäjäkokemus (engl. User Experience, usein lyhennetty UX). Verkkosovellusten hyvällä käyttäjäkokemuksella pyritään usein hyvään käyttäjätyytyväisyyteen. (Kiruthika et al., 2016)

Cernyn ja Donahoon mukaan (2016) käyttöliittymien kehitystä lähestytään usein toimintojen, käytettävyyden ja myös esimerkiksi kehitys- ja ylläpitokustannusten näkö- kulmasta. Käyttäjien kasvaneet odotukset muun muassa sovellusten toimintojen suhteen lisäävät vaatimuksia sovellusten laskennalliseen puoleen. Useat nykyaikaiset rat- kaisut toteuttavat käyttöliittymiin liittyvää laskentaa enemmän asiakkaan selaimessa kuin sovellusta tarjoilevalla palvelimella.

Cernyn ja Donahoon (2016) mukaan käyttöliittymäkehityksen vaativuutta kuvaa se, että noin 48 % sovellusten koodista on käyttöliittymiin liittyvää ja noin 50 % sovellus- kehityksen kehitysajasta kuluu käyttöliittymien kehittämiseen. Edellä mainitun kehityksen haastavuus kasvaa entisestään, kun otetaan huomioon useiden eri alustojen tu- keminen ja eri kontekstit. Cernyn ja Donahoon mukaan tutkijat yrittävät löytää keinoja, joiden avulla käyttöliittymien kehitykseen ja ylläpitoon liittyviä kustannuksia voidaan pienentää. Etsittyjä keinoja ovat muun muassa korkean tason ja toimialakoh- taiset kielet (engl. Domain-Specific Language, DSL), joilla käyttöliittymiä kuvataan mallipohjaisilla lähestymistavoilla (engl. Model-Based Approaches, MBA). Tutkijat etsivät myös keinoja, joilla laskentaa voidaan siirtää tehtäväksi asiakaspäässä. Artik- kelin kirjoittajat kuitenkin toteavat, että käytettyjen menetelmien lopputuloksissa voi olla heikkouksia, vaikka motiivi menetelmien käyttämiseen on selvä. Esimerkkinä kirjoittajat esittävät tilanteen, jossa korkean tason kielten (DSL ja MBA) hyödyntäminen muuntaa käyttöliittymän kuvauksen matalan tason HTML-, JS-, JSON- ja CSS-koodiksi, joka on kuitenkin hyvän lopputuloksen kannalta usein sekavaa. Esimerkiksi koo- dien tuottamien käyttöliittymähaasteiden vuoksi palvelimen ja asiakkaiden välillä siir- retyn datan määrä kasvaa. Lisäksi palvelinpään toteutuksesta tulee monimutkaisem- paa.

(14)

Verkkosovellusten käyttöliittymäkehyksiä (engl. UI framework) pyritään suunnittele- maan siten, että niiden avulla pystytään toteuttamaan vaikuttavia käyttöliittymiä. Täl- laisten käyttöliittymien ominaisuudet vaihtelevat sen mukaan, keiden toimesta käyttö- liittymäkehyksiä suunnitellaan. Ihmisen ja tietokoneen välisen interaktion (engl. HCI, Human-Computer Interaction) parissa työskentelevät tutkijat pyrkivät kehyksiin, jotka tarjoavat hyvän vuorovaikutuksen ja käytettävyyden. Toisesta näkökulmasta katsot- tuna ohjelmistoinsinöörit painottavat käyttöliittymien hyvää responsiivisuutta (engl.

responsivity), saatavuutta (engl. availability), skaalautuvuutta (engl. scalability) tai testattavuutta (engl. testability). (Cerny & Donahoo, 2016)

2.4 Verkkosovellusten käyttöliittymien rakennus- ja piirtämismene- telmät

Cerny ja Donahoo (2016) esittävät artikkelissa kaksi erilaista menetelmää, joilla käyt- töliittymiä voidaan rakentaa ja prosessoida. Ensimmäisessä vaihtoehdossa palvelin vastaa käyttöliittymän rakentamisesta ja piirtämisestä. Tässä vaihtoehdossa asiakkaiden päähän lähetetään isohko HTML-koodi, tarpeellisilla lisäresursseilla varustettuna.

Käyttäjän muuttaessa sovelluksen tilaa, palvelin uudelleenrakentaa käyttöliittymän kokonaan tai osittain ja lähettää uuden version käyttöliittymästä käyttäjälle. Toisessa vaihtoehdossa käyttäjälle lähetetään tarpeelliset resurssit ja työkalut käyttöliittymän rakentamiseen lokaalisti, sovelluksen eri käyttötilanteissa. Yksinkertaisimmillaan tässä vaihtoehdossa palvelin lähettää käyttäjälle tarpeellisen datan, jota käyttäjän (engl. client), myöhemmin myös asiakas, osa prosessoi. Kyseinen menetelmä erottelee varsinaisen datan resursseista, joiden avulla käyttöliittymä piirretään. Suurin ero menetelmien välillä on, että ensimmäisessä esitetyssä vaihtoehdossa sovelluksen suurin prosessointi suoritetaan palvelimella ja jälkimmäisessä vaihtoehdossa asiakkaan päässä. Palvelinpuolen prosessointi on hyvä vaihtoehto tilanteissa, joissa asiakkaan käytössä olevat resurssit ovat rajalliset.

Google Developers -sivustolla julkaistussa blogitekstissä (Google Developers, 2020b) kerrotaan jo Cernyn ja Donahoon (2016) esittelemistä menetelmistä tarkemmalla tasolla sekä kuvaillaan muita käyttöliittymien rakennusmenetelmiä. Blogin kirjoittajien mukaan SSR-menetelmällä (engl. Server-Side Rendering) tarkoitetaan Cernyn ja

(15)

Donahoon artikkelissa käsiteltyä ensimmäistä menetelmää, jossa käyttöliittymä rakennetaan ja piirretään palvelimella. SSR:n etuina on, että menetelmässä voidaan välttää suurten JavaScript-määrien lähettäminen asiakaspäähän ja tilanne, jossa käyttäjät joutuvat asiakaspäässä odottamaan prosessoririippuvaisen JavaScriptin suoritusta ennen kuin kohdesivuja voidaan käyttää. CSR-menetelmä (engl. Client-Side Rendering) nou- dattelee Cernyn ja Donahoon artikkelissa ollutta jälkimmäistä menetelmää eli jossa käyttöliittymä rakennetaan selaimessa. Blogitekstin kirjoittajat, Miller ja Osmani, kä- sittelevät kyseisten vaihtoehtojen lisäksi myös muita menetelmiä, joista tärkeimpänä voidaan mainita staattinen piirtäminen (engl. static rendering). Staattisessa piirtämi- sessä HTML-tiedostot luodaan jo ennakkoon sovelluksen rakennusvaiheessa (engl.

build-time) jokaiseen käytettävään URL:iin. Staattisen piirtämisen yhtenä heikkoutena on, että yksittäiset HTML-tiedostot pitää luoda jokaiselle URL:ille ennakkoon, jolloin kyseisten tiedostojen ja kaikkien erilaisten vaihtoehtojen tietäminen etukäteen voi olla mahdotonta, etenkin suurissa sovelluksissa.

Blogitekstissä (Google Developers, 2020b) Miller ja Osmani käsittelevät myös lyhyesti menetelmää, jossa yhdistetään SSR:n ja CSR:n tekniikoita. Menetelmälle ei ole suoraa suomennosta olemassa, mutta sitä voisi kutsua esimerkiksi termillä jatkojalos- tus (engl. rehydrating). Jatkojalostuksessa pyritään tekemään kompromisseja SSR- ja CSR-menetelmien suhteen. Menetelmässä erilaiset navigointipyynnöt, kuten koko- naisten sivujen lataukset, käsitellään palvelimen toimesta, mutta palvelimen tuottamiin HTML-dokumentteihin upotetaan myöhemmin tapahtuvaa piirtämistä varten tarvit- tava data ja JavaScript. Kun sovelluksen käyttämä dokumentti on lähetetty asiakaspää- hän, ottavat asiakaspään teknologiat ja resurssit sovelluksen haltuun ja piirtävät sovelluksen uusiksi. Tämän menetelmän heikkoutena on, että sovelluksen sivut eivät voi vastata käyttäjän toimintoihin ennen kuin JavaScript on suoritettu kokonaan. Sivut voivat näyttäytyä käyttäjälle valmiilta, mutta JavaScriptin suoritus voi silti kestää taustalla vielä useita sekunteja tai minuutteja ja näin ollen johtaa huonoon käyttäjäkokemuk- seen. Miller ja Osmani mainitsevatkin blogissaan, että huonon käyttäjäkokemuksen vuoksi jatkojalostusta ei suositella käytettäväksi. SSR-, CSR- ja jatkojalostusmenetel- mät esitetään tiivistettynä kuvassa 2.

(16)

Kuva 2. Verkkosovellusten käyttöliittymien yleisimmät piirtämismenetelmät (Google Developers, 2020b).

SSR:n hyödyllisyys riippuu lähtökohtaisesti siitä, millaista verkkosovellusta ja kokemusta ollaan rakentamassa. SSR:ää voidaan hyödyntää vain osittain, eli sitä hyödyn- netään verkkosovelluksen muutamilla sivuilla ja loput sivuista voidaan piirtää asiakas- päässä. Yksi SSR:n etu on mahdollisuus tarjota käyttäjille räätälöidympiä sivuja kuin mitä esimerkiksi staattisessa piirtämisessä on mahdollista tarjota. SSR:n heikkoutena on, että sivujen luonti palvelimella ottaa aikaa ja luonti voi johtaa hitaaseen TTFB- tulokseen (engl. Time to first byte). Menetelmä vaatii myös palvelimelta enemmän laskentatehoa ja kehittäjiltä kokemusta, koska menetelmässä pitää yleensä ottaa huomioon esimerkiksi välimuistin käyttöön ja muistinhallintaan liittyviä seikkoja. SSR:n hyödyntäminen ei myöskään kaikissa tapauksissa tarkoita sitä, että kehittäjillä olisi vähemmän kehitystöitä tehtävänä. (Google Developers, 2020b)

CSR:n suurimpana heikkoutena on yleensä, että sovellusten koon kasvaessa myös selaimessa suoritettavan JavaScriptin määrä kasvaa. Kasvanut määrä voi aiheuttaa haasteita, koska esimerkiksi ulkoiset JavaScript-koodit ja -kirjastot kilpailevat asiakaspään prosessointitehosta ja selaimen pitää yleensä käsitellä koodit ennen kuin sovelluksen

(17)

varsinainen sisältö voidaan piirtää käyttäjälle. Tämän takia CSR-menetelmää hyödyn- tävien sovellusten suorituksen pitäminen nopeana esimerkiksi mobiililaitteilla voi olla haastavaa, pienemmän suorituskyvyn ja joissakin tapauksissa heikomman internet-no- peuden vuoksi. CSR-menetelmän suorituskyky on mahdollista saada lähelle SSR-me- netelmää, mikäli JavaScriptin käyttö pyritään pitämään kurissa sekä palvelimen ja asiakaspään välinen viive pyritään minimoimaan. CSR:ssä on myös mahdollista hyö- dyntää HTTP/2-palvelinsysäystä (engl. server push), jossa sovelluksen kannalta kriit- tiset skriptit ja datat (esim. HTML ja CSS) lähetetään koottuna vastauksena asiakas- pään ensimmäiseen kutsuun useiden erillisten vastausten sijasta. Kun tarvittavat resurssit lähetetään suoraan ensimmäisessä vastauksessa, ei selaimen jäsentimen (engl.

parser), joka rakentaa sovelluksen resursseista, tarvitse odottaa enää muita resursseja ennen kuin se voi alkaa työstämään sivustoa. (Google Developers, 2020b)

2.5 Kehityksen siirtyminen internettiin ja käyttäjien odotukset

Rempel (2015) esitti näkemyksen, jonka mukaan selkeä raja perinteisten ja verkkosovellusten välillä on pienentymässä. Eri sovellustyypit, kuten perinteiset työpöytäso- vellukset, mobiilisovellukset ja verkkosovellukset, kaikki hyödyntävät samanlaisia toimintoja kuten esimerkiksi pilvilaskentaa ja tietojen tallennusta verkkoon. Läpinäky- vyyden takia sovellusten käyttäjät eivät välttämättä enää tiedä käyttävätkö he itsenäi- sesti toimivia sovelluksia vai sovelluksia, jotka ovat verkkoon yhteydessä. Rempelin mukaan tämä johtaa siihen, että käyttäjät odottavat samanlaisia toimintoja ja suoritus- kykyä riippumatta siitä, minkä teknologian tai alustan kautta sovelluksia käytetään.

Rempelin toteaa asiakas-palvelin (engl. client-server) tyylistä kommunikaatiota käy- tettävän päivittäin.

Kyselyiden tulokset antavat viitteitä siitä, että verkkosovelluksia kehitetään enemmän kuin esimerkiksi perinteisiä työpöytäsovelluksia ja mobiilisovelluksia. Tämä voi tarkoittaa myös sitä, että verkkosovelluksia käytetään aktiivisemmin kuin muita sovel- lustyyppejä. JetBrains suoritti vuosina 2017–2020 kyselyitä (JetBrains s.r.o, 2020a;

JetBrains s.r.o, 2020b; JetBrains s.r.o, 2020c; JetBrains s.r.o, 2020d), joissa kysyttiin vastaajilta minkä tyyppisiä sovelluksia vastaajat kehittävät. Kyselyiden tuloksia esitel- lään kuvissa 3 ja 4.

(18)

Kuvassa 3 on esitettynä vuosien 2017 ja 2018 JetBrainsin suorittamien kyselyiden ti- lastoja siitä, millaisia sovellustyyppejä kyselyihin vastanneet henkilöt kehittävät. Ku- vaan liitetyt kaaviot on otettu kyselyistä kuvakaappauksina, jotka on sen jälkeen yh- distetty yhdeksi kuvaksi tutkielmaa varten. Kuvan tuloksista on nähtävillä, että mo- lempina tarkasteluvuosina verkkosovellusten kehitys (Web Back-end ja Web Front- end) on ollut suuremmassa roolissa kuin esimerkiksi mobiili- tai työpöytäsovellusten kehitys. Vuoden 2018 tuloksissa kehitys on jaettu rahaa vastaan ja harrastuksena teh- tävään kehitykseen, mutta molemmilla osa-alueilla verkkosovellusten kehitys on ollut suosituinta. Vuonna 2017 verkkosovellusten palvelinpään (engl. back-end) kehitys on ollut 3 % suositumpaa kuin asiakaspään (engl. front-end) kehitys. Vuonna 2018 jär- jestys on pysynyt samana, mutta palvelinpään ja asiakaspään ero on kasvanut 7 % vuo- teen 2017 verrattuna.

Kuva 3. Eri sovellustyyppien kehitysten osuudet JetBrainsin kyselyiden (JetBrains s.r.o, 2020d; JetBrains s.r.o, 2020c) mukaan vuosina 2017 ja 2018.

(19)

Kuva 4. Eri sovellustyyppien kehitysten osuudet JetBrainsin kyselyiden (JetBrains s.r.o, 2020b; JetBrains s.r.o, 2020a) mukaan vuosina 2019 ja 2020.

Kuvassa 4 on esitettynä JetBrainsin vuosien 2019 ja 2020 kyselyiden tuloksia samaan tapaan kuin kuvassa 3. Vuosien 2019 ja 2020 tuloksia tarkastellessa verkkosovellukset ovat pysyneet edelleen suosituimpana sovellustyyppinä ja myös palvelinpään ja asia- kaspään kehityksen keskinäinen suhde on pysynyt samana. Kuvan 3 tuloksiin verrattuna palvelinpään ja asiakaspään erot ovat kasvaneet, koska vuonna 2019 ero oli 14 % ja 12 % vuonna 2020.

Työpöytäsovelluksiin verrattuna sovellusten ydintoiminnot on helpompaa toimittaa verkkosovellusten ja selaimen kautta käyttäjille ja erilaisille laitteille. Selaimessa toimivat sovellukset ovat myös helppokäyttöisiä. Konvertoimalla työpöytäsovelluksia verkkoon organisaatiot pystyvät vähentämään tarvetta optimoida sovelluksia eri lait- teistoille ja ohjelmistoille sekä käyttäjätuen määrää. Verkkosovellusten tuki ja hallinta pystytään työpöytäsovelluksia helpommin keskittämään ja verkkosovellukset ovat helpommin siirrettävissä toisille alustoille. (Kiruthika et al., 2016)

(20)

Verkkosovellusten hyvät käyttäjäkokemukset tarkoittavat, että yritykset pyrkivät pa- nostamaan käyttäjäkokemukseen aiempaa enemmän, sillä hyvä käyttäjäkokemus pie- nentää käyttäjätukeen tarvittavia resursseja. Käyttäjäkokemusta voidaan myös käyttää markkinointi- ja tuotekehitysstrategiana. Tutkijoiden mukaan mobiililaitteiden määrä ja aktiivinen käyttö tulevat kasvamaan tulevaisuudessa ja tästä johtuen yritykset antavat aiempaa enemmän painoarvoa selainpään teknologioille. Selainpäässä toimivissa sovelluksissa liiketoimintalogiikka suoritetaan käyttäjien laitteilla. Tutkijat arvioivat vuoden 2018 aktiivisten mobiililaitteiden määräksi kaksi miljardia kappaletta. (Kirut- hika et al., 2016)

Verkossa toimivat sovellukset tarjoavat paljon mahdollisuuksia ja samalla haasteita, jotka tulee ottaa huomioon. Verkkosovellusten nopea toimivuus on yksi haasteista.

Vuonna 2014 tehdyssä raportissa (Everts, 2014) testattiin useiden maailman suosi- tuimpien vähittäiskaupan verkkosivustojen latausaikoja ja raportin yhtenä tuloksena oli, että verkkosivustojen useimmat käyttäjät hylkäävät sivuston, mikäli lataus kestää enemmän kuin kolme sekuntia. Raportissa vertaillut sivustot latautuivat keskimäärin 5,4 sekuntia ennen kuin ne alkoivat vastata käyttäjien toimintoihin. Raportin mukaan kymmenen sekuntia oli maksimiaika, jonka sivuston käyttäjät malttoivat odottaa sivujen latausta. Raportissa kuvattiin, että sivustojen keskimääräiset latausajat olivat kasvaneet kevään 2012 ja kevään 2014 välillä 47 % eli 6,8 sekunnista 10,0 sekuntiin.

Sivustojen hidastumiseen oli useita syitä, mutta raportin mukaan yksi isoimmista oli sivustoilla käytetyt optimoimattomat kuvat, jotka suurten kokojensa vuoksi hidastivat sivuja.

Verkkosovellusten suorituskyvyn mittaamiseen on paljon erilaisia standardeja ja mittareita, jotka tarjoavat näkemyksiä siihen, millaisia suorituskykyaikoja (mm. odotus- aika) käyttäjät odottavat sovellusten eri toiminnoilta. Suorituskykyyn liittyvässä kirjallisuudessa päämenetelmiä on yleensä kolme: fysiologiset mittaukset, empiiriset tut- kimukset ja kyselyt. Fysiologiset mittaukset tarjoavat raja-arvot suorituskyvyn mittaa- miseen siitä, kuinka nopeasti yksilölliset käyttäjät pystyvät fyysisesti reagoimaan erilaisiin ärsykkeisiin. Mittausten avulla suorituskykyä on mahdollista optimoida ylei- sellä tasolla, raja-arvot huomioon ottaen, siten, että ohjelma on suorituskyvyltään ”riit- tävän hyvä”. Empiiriset tutkimukset mittaavat yleensä kestoa, ajassa mitattuna, verk-

(21)

kosivun ensimmäisen sivupyynnön käynnistymisen ja käyttäjän toimenpiteestä tapah- tuvan keskeytyksen välillä. Empiiristen tutkimusten tarjoamia tuloksia pystytään hyö- dyntämään kun suorituskyvyn parantamisen jälkeen vanhoja arvoja verrataan uusiin arvoihin eli tarkistetaan ovatko empiirisessä tutkimuksessa mitatut ajat kasvaneet vai pienentyneet. Eli esimerkiksi odottavatko käyttäjät sivujen latauksia aiempaa pidem- pään vai jättävätkö he käyttäjän toimesta tehtävän keskeytyksen kokonaan tekemättä.

Kyselyt mittaavat yleensä käyttäjien erilaisia tunnetiloja, kuten tyytyväisyystasoa tai turhautumista, suorituskykyyn liittyen. Käyttäjien suorittamat itsearvioinnit ovat myös mahdollisia eli käyttäjät arvioivat omasta näkökulmastaan, kuinka kauan he esimerkiksi odottavat verkkosivun latautumista ennen kuin sivun lataus keskeytetään. Käyt- täjien erilaiset tunnetilat vaikuttavat vahvasti siihen millaisena he kokevat sovelluksen eri ominaisuudet, esimerkiksi sovelluksen laadukkuuden. Rempel yhdistää tutkimusar- tikkelissa kyseisiä standardeja ja mittareita ja päätyy niiden tutkimisen pohjalta loppu- tulokseen, jonka mukaan käyttäjien pitäisi pystyä suorittamaan useimmat verkkosovellusten toiminnot alle kahdessa sekunnissa. (Rempel, 2015)

2.6 JavaScript, JavaScript-kirjastot ja -sovelluskehykset

JavaScript (usein lyhennetty JS) on pääsääntöisesti verkkosivuilla ja –sovelluksissa käytetty kevyt, tulkattu ja olio-ohjelmointiin soveltuva ohjelmointikieli. JavaScript on ohjelmointikieli, jonka avulla verkkosivuille on mahdollista lisätä dynaamisia toimintoja, kuten erilaisia animaatioita ja käyttäjien toimintoihin vastaavia funktioita. Ja- vaScript toimii verkkosivujen asiakaspäässä eli selaimissa, mutta sitä käytetään muis- sakin ympäristöissä kuten tietokannoissa sekä palvelinpään sovelluksissa. JavaScriptin avulla voidaan esimerkiksi suorittaa kyselyitä MongoDB-tietokannassa. (Mozilla, 2020a) Node.Js on palvelinpään JavaScript-ympäristö, jossa voidaan suorittaa Ja- vaScriptillä toteutettuja palvelinpään sovelluksia. Node.Js-ympäristö mahdollistaa sen, että yhtä ohjelmointikieltä voidaan käyttää lähes koko verkkosovelluksen toteut- tamiseen, koska kielen avulla on mahdollista toteuttaa sovelluksen asiakas- ja palve- linosat. (Tilkov & Vinoski, 2010) JavaScript on kolmas normaalisti käytössä olevista, standardeista, verkkoteknologioista HTML-merkintäkielen ja CSS-tyyliohjeiden li- säksi (Mozilla, 2020b).

(22)

JavaScript on hyvin suosittu ja yleisesti käytetty ohjelmointikieli nettisivuilla sekä ke- hittäjien keskuudessa. W3Techs-sivuston (Q-Success, 2020) mukaan JavaScriptiä käytetään 96,8 % kaikista nettisivuista. Stack Overflow -sivuston helmikuussa 2020 tuottamassa kyselyssä (Stack Overflow, 2020a), JavaScript nousi kaikista yleisimmin käytetyksi ohjelmointikieleksi kyselyn ohjelmointi, skriptaus ja merkintäkielet -kategoriassa ja kysymyksessä. Kysymyksen tulosta havainnollistetaan kuvassa 5, jossa on nähtävillä kaikkien vastausten prosessiosuudet. Kysymykseen annettiin 57 378 vas- tausta. JavaScript oli korkeimmalla sijoituksella myös ammattikehittäjien vastauksissa.

Kuva 5. Stack Overflow kyselyn (Stack Overflow, 2020a) ohjelmointi, skriptaus ja merkintäkielet -kategoria.

Stack Overflow suoritti vuoden 2020 kyselyä vastaavan kyselyn myös vuosina 2018 (Stack Overflow, 2020c) ja 2019 (Stack Overflow, 2020b). Myös kyseisten vuosien ohjelmointi, skriptaus ja merkintäkielet -kategoriassa JavaScript oli korkeimmalla sijoituksella yleisimmin käytetyimpänä ohjelmointikielenä. Vuonna 2018 kysymykseen vastasi 78 334 vastaajaa ja vuonna 2019 vastaajia oli puolestaan 87 354.

(23)

JavaScript-kirjastot (engl. JavaScript library) ovat kehittäjien paketoimia ja uudelleen- käytettäviä paketteja, jotka tarjoavat valmiita ratkaisuja erilaisiin kehitysongelmiin.

Kirjastoja alkoi tulla saataville, kun JavaScriptin markkinoille tulon jälkeen nettisivu- jen interaktiivisuus lisääntyi suuresti ja kehittäjät alkoivat paketoimaan työkaluja ja ratkaisuja kehityksessä ilmenneisiin ongelmiin, jotta muut voisivat hyödyntää niitä.

Kirjastojen lisääntyneellä määrällä oli positiivinen vaikutus internetin suosion kas- vuun. JavaScript-sovelluskehykset (engl. JavaScript framework) ovat JavaScript-kirjastoja, jotka tarjoavat määritettyjä menetelmiä siihen, kuinka sovelluksia tulee rakentaa. Yleensä kaikki sovelluskehysten tarjoamat menetelmät on mahdollista kehittää suoraan pelkällä JavaScriptillä, mutta sovelluskehykset poistavat tarpeen ratkaista näitä ongelmia itse. Menetelmien hyödyntäminen nopeuttaa ja helpottaa kehitystä sekä parantaa rakennetun sovelluksen ylläpitoa. Sovelluskehykset helpottavat ja suoraviivaistavat etenkin monimutkaisten ja interaktiivisten sovellusten rakentamista.

(Mozilla, 2020c)

Jokaisella JavaScript-sovelluskehyksellä on yleensä tapa käsitellä seuraavia asioita:

DOM-päivitys, selaimen tapahtumien käsittely ja hyvän kehittäjäkokemuksen tarjoa- minen. Kaikki suurimmat JavaScript-sovelluskehykset käyttävät yleensä samankaltai- sia menetelmiä sovellusten piirtämisessä, mutta piirtämisessä on pieniä eroja. Kaikki sovelluskehykset yleensä seuraavat selaimen rakentamaa DOM:ia ja tekevät sovellus- kehyksestä riippuen ratkaisuja, kuinka DOM:ia pitää päivittää, mikäli sovelluksen eri osat päivittyvät. Koska sovelluskehykset tarkkailevat ja päivittävät DOM:ia, ei sovelluskehyksen käyttäjän tarvitse suoraan olla tekemisessä DOM-operaatioiden kanssa.

JavaScript-sovelluskehysten yhtenä ominaispiirteenä on yleensä myös toimialakoh- taisten kielten (DSL) hyödyntäminen osana sovelluskehystä. DSL-kielillä tarkoitetaan ohjelmointikieliä, jotka liittyvät johonkin tiettyyn ohjelmistokehityksen alueeseen. Ja- vaScript-sovelluskehysten tapauksessa DSL-kieliä voivat olla esimerkiksi JSX, Ty- peScript ja Handlebars. DSL-kielten hyödyntäminen on yleensä vapaaehtoista, mutta niiden hyödyntäminen helpottaa kehitystyötä sekä tarjoaa parhaimman kehittäjäkoke- muksen (engl. developer experience). (Mozilla, 2020c)

JavaScript-sovelluskehyksiin liittyy myös asioita, joita kannattaa huomioida ennen sovelluskehysten käyttöönottoa. Vaikka sovelluskehysten avulla sovellusten kehittämi-

(24)

nen voi olla helpompaa, niiden hyödyntäminen ei kuitenkaan ratkaise kaikkia ongelmia. Sovelluskehysten käytön oppiminen ja ymmärtäminen voi viedä aikaa. Sovellus- kehykset eivät myöskään välttämättä ole tarpeellisia kaikissa tapauksissa ja sovelluskehysten käyttö voi olla liian raskas vaihtoehto sovelluksille tai verkkosivuille, joissa on hyvin vähän interaktiivisuutta. Jos sovelluskehyksiä hyödyntää paljon, voivat niitä käyttävät kehittäjät unohtaa verkkosivustojen tärkeimmän rakennusosan eli HTML:n tärkeyden, koska sovelluskehykset yleensä toteuttavat asiat pääsääntöisesti JavaScrip- tillä. Liika sovelluskehyksen hyödyntäminen voi johtaa siihen, että sovelluksesta tulee täysin riippuvainen JavaScriptistä eikä se toimi ilman sitä. Koska sovelluskehysten yhtenä suurimpana tarkoituksena on nopeuttaa ja helpottaa kehitystä eli tavoitella pa- rempaa kehittäjäkokemusta, niin sovelluskehysten suuresta hyödyntämisestä voi seu- rata virheellinen ajattelumalli ”JavaScript ensin, käyttökokemus sen jälkeen”. Tällä tarkoitetaan sitä, että kehittäjien tarpeet tulevat ennen loppusovelluksen tarpeita ja esimerkiksi loppusovelluksen käyttäjäkokemus voi olla huono. Huono käyttäjäkokemus voi olla seurausta huonosta saavutettavuudesta tai suorituskyvystä. (Mozilla, 2020c)

2.7 SPA-, PWA- ja mobiilisovellukset

Yhden sivun sovellukset (engl. Single-Page Application, SPA), jäljempänä SPA, ovat verkkoselaimissa toimivia moderneja sovelluksia, jotka jäljittelevät natiivien sovellusten sulavaa toimintaa ilman verkkosivujen toistuvia uudelleenlatauksia. Kyseisissä yhden sivun sovelluksissa ladataan HTML-sivu, joka päivittyy käyttäjän toimintojen perusteella. AJAX-teknologian hyödyntäminen mahdollistaa yhden sivun sovellusten jouhevan toiminnan, koska AJAX hoitaa kommunikoinnin sovellusten palvelinpuolen skriptien kanssa ilman erillisiä sivujen uudelleenlatauksia. Sovelluskehykset tarjoavat mahdollisuuden kontrolloida verkkosovellusten rakennetta, eri sivunäkymien välistä navigointia ja jakaa sovelluksen eri kerroksiin, jotka noudattavat MVC-suunnittelupe- riaatetta (engl. Model-View-Controller). (Shahzad, 2017)

Progressiiviset verkkosovellukset (engl. Progressive Web App, PWA), jäljempänä PWA, ovat verkkosovelluksia, jotka yhdistävät verkkosovellusten ja natiivien mobiilisovellusten parhaita puolia. PWA-sovellukset tarjoavat natiiveja mobiilisovelluksia vastaavan käyttäjäkokemuksen jäljittelemällä mobiilisovellusten toimintaa. Lähelle

(25)

natiivia käyttökokemusta on mahdollista päästä esimerkiksi hyödyntämällä PWA-sovellusten push-ilmoituksia (engl. push notification). PWA-sovellukset toimivat verkkosovellusten tavoin käyttäjän laitteella, mutta ne käynnistetään selaimen sijaan erilli- sestä sovellusikonista natiivien sovellusten tavoin. PWA-sovellukset lataavat käyttä- jän laitteessa ”sovelluskuoren” (engl. app shell), joka sisältää tärkeimmät toiminnot ja HTML-elementit ja jonka sisältö ladataan dynaamisesti JavaScriptillä internetistä.

Koska sovelluskuori sisältää käynnistyksen yhteydessä jo tärkeimmät toiminnot, voidaan sovellusta käyttää myös offline-tilassa ja sisältö päivitetään ja synkronoidaan uu- simpaan tilaan aina kun sovellus on yhteydessä internettiin. Datan dynaaminen lataa- minen internetistä mahdollistaa sen, että PWA-sovellukset eivät vaadi asennuksen yh- teydessä yhtä suurta tallennustilaa kuin natiivit sovellukset. PWA-sovellusten yhtenä päätarkoituksena on pyrkiä pienentämään natiivien, eri alustoille kehitettävien, mobiilisovellusten kehityskustannuksia sekä pienentämään mobiilisovellusten ja verkkosovellusten välisiä eroja. PWA-sovellukset eivät ole riippuvaisia jostakin tietystä käyt- töjärjestelmästä ja niiden kehityksessä voidaan hyödyntää samoja teknologioita ja me- netelmiä, joita useimmat yritykset hyödyntävät jo valmiiksi verkkosovellusten kehi- tyksessä. PWA-sovellusten heikkoutena on, että tietyt PWA-sovellusten ominaisuudet ovat riippuvaisia tietyistä selaimista ja niiden rajapinnoista. (Behl & Raj, 2018) Natiivit mobiilisovellukset (engl. native mobile application) ovat tietyille mobiilialus- toille kehitettyjä sovelluksia, jotka pystyvät hyödyntämään mobiililaitteiden laitteistoa kuten kameraa, mikrofonia ja muita sensoreita. Android ja iOS ovat esimerkkejä suosituimmista mobiilialustoista. Natiivien mobiilisovellusten kehityksessä täytyy ottaa huomioon erilaiset laitetyypit, käyttöjärjestelmät ja käyttöjärjestelmien erilaiset ver- siot. Natiivien mobiilisovellusten levitys (engl. distributing) käyttäjille tapahtuu kunkin alustan oman sovelluskaupan (engl. app store) kautta. Sovelluskaupat suorittavat kauppaan ladattaville sovelluksille auditoinnin, jolla vahvistetaan, että alustan mini- mivaatimukset tulevat täytetyksi. Natiivien mobiilisovellusten etuja ovat niiden kyky toimia offline-tilassa ja taustalla huomaamattomasti sekä hyvä suorituskyky. Natiivien mobiilisovellusten heikkoutena on kalliit kehityskustannukset, koska natiivien sovellusten koodia ei ole mahdollista jakaa eri alustojen välillä. Tämä tarkoittaa sitä, että jokaiselle eri alustalle täytyy tehdä oma versio käyttäen kunkin alustan tiettyä kehitys- tyyliä. Kustannuksiin vaikuttavat olennaisesti myös jokaisen eri version ylläpito ja uu-

(26)

3 TUTKIMUS SOVELLUSKEHYKSEN VALINNASTA, KYSELYIDEN ESITTELY JA SOVELLUSKEHYSTEN RAJAAMINEN

Tässä luvussa käsitellään aiempaa JavaScript-sovelluskehysten valintaan liittyvää tie- teellistä tutkimusta (kohta 3.1.) ja esitellään lyhyesti tutkielmassa käytettyjen kyselyiden (kohta 3.2.) taustatiedot. Luvussa tehdään myös rajaus tutkielmassa käsiteltäviin sovelluskehyksiin ja esitetään perustelut valinnan taustalla (kohta 3.3.).

3.1 Tutkimus JavaScript-sovelluskehyksen valinnasta

Tutkimuksessa (Pano et al., 2018) tutkijat totesivat JavaScript-kirjastojen määrän ja suosion kasvaneen rajusti, minkä sen seurauksena kehittäjien ja päätöksentekijöiden on vaikeaa valita omiin käyttötarkoituksiinsa sopiva JavaScript-sovelluskehys tai ym- märtää mitä asioita on hyvä ottaa huomioon sopivaa sovelluskehystä valittaessa. Tut- kijat havaitsivat, että alan kirjallisuudessa on olemassa paljon erilaisia tutkimuksia liittyen mittausmenetelmiin, esimerkiksi suorituskykyyn liittyen, mutta saatavilla ei ollut tutkimuksen suorittamisen aikaan selkeää tieteellistä näkemystä asioista, joiden perusteella henkilöt päätyvät valitsemaan sopivimman JavaScript-sovelluskehyksen. Edellä mainittujen seikkojen takia tutkijat suorittivat omien sanojensa mukaan ensimmäisen aiheeseen liittyvän laadullisen eli kvalitatiivisen tutkimuksen, jonka tavoitteena oli vastata tutkimuskysymykseen ”Mitkä tekijät ja toimijat johtavat JavaScript-sovellus- kehyksen käyttöönottoon?”. Tutkimuksessa haastateltiin 18 asiantuntijaa ja yritettiin selvittää millä perusteilla he valitsevat JavaScript-sovelluskehyksen tuhansien erilaisten joukosta. Valittujen asiantuntijoiden työkokemus verkkokehityksen parissa vaih- teli 4–15 vuoden välillä. Tutkimuksen tuloksena tutkijat pystyivät tuottamaan mallin tekijöistä ja ominaisuuksista, jotka vaikuttavat kyseiseen valintaan (kuva 6, sivu 20).

Tutkijat esittävät mallinsa yhteydessä myös toimijat (kuva 7, sivu 23), jotka ovat yleensä mukana sovelluskehyksen valintaprosessissa. Mallin avulla kyseisten toimi- joiden on mahdollista arvioida eri JavaScript-sovelluskehyksiä ja -kirjastoja sekä valita niistä sopivin. Tutkijoiden mukaan mallin avulla on myös mahdollista tarkastella

(27)

seikkoja, jotka uutta sovelluskehystä kehittäessä on hyvä ottaa huomioon, jotta sovelluskehys pystyy vastaamaan muun muassa eri kehittäjien tarpeisiin.

Kuva 6. JavaScript-sovelluskehyksen valintaan vaikuttavat tekijät ja alikategoriat tut- kijoiden (Pano et al., 2018) kehittämän mallin mukaan.

Kuvassa 6 on esitetty tutkimuksessa (Pano et al., 2018) esitetty malli tekijöistä, jotka vaikuttavat JavaScript-sovelluskehyksen valintaan. Mallissa on viisi päätekijää (engl.

Factor): suorituskyvyn odotukset (engl. Performance Expectancy), vaivannäkö (engl.

Effort Expectancy), sosiaalinen vaikutus (engl. Social Influence), edistävät olosuhteet (engl. Facilitating Conditions), hinta-arvo (engl. Price Value). Tekijät jakaantuvat omiksi alikategorioiksi, jotka on esitetty taulukoissa 1–5 (tutkielman sivut 21–23).

(28)

Tutkijat määrittelevät (Pano et al., 2018) suorituskyvyn odotukset -tekijän mittariksi, joka tarkkailee sitä, kuinka paljon mahdollisesti hyödynnettävä järjestelmä tarjoaa suorituskykyyn tai kehitystyöhön liittyviä etuja. Tutkijat tarkentavat, että he tarkkaili- vat erityisesti sovelluskehyksen avulla rakennetun sovelluksen suorituskykyä. Vaivan- näkö on mittari, joka tarkkailee kuinka helppoa jotakin järjestelmää on käyttää. Tutki- jat jatkojalostavat tätä tulkintaa sillä, että mittariin otetaan mukaan näkökulmat, joihin liittyy JavaScript-sovelluskehyksen ominaisuus vähentää ohjelmointityöhön kuluvaa työtä ja monimutkaisuutta. Sosiaalinen vaikutus määrittelee, kuinka yksilö tarkkailee muiden yksilöiden järjestelmien käyttämistä tai kuinka hän arvioi itse käyttävänsä jär- jestelmää. Teknologian hyödyntämiseen voivat vaikuttaa normit, sosiaalinen vaikutus, kollegoiden paine sekä kilpailu. Edistävät olosuhteet -tekijä määrittelee, kuinka paljon yksilö uskoo, että käytettävässä järjestelmässä on valmista infrastruktuuria, joka tukee järjestelmän käyttöä. Tutkijat täsmentävät, että JavaScript-sovelluskehysten yhtey- dessä tällä tarkoitetaan sovelluskehyksen ominaisuuksia, joiden avulla pystytään vastaamaan kehitettävän sovelluksen vaatimuksiin tai integraatiopotentiaaliin. Hinta- arvo-tekijälle tutkijat eivät anna tarkempia määritelmiä, mahdollisesti termin itsestään selittävyyden vuoksi.

Alakategoria suomeksi

Alakategoria englanniksi

Selitys ja suhde vastaajien lausuntoihin

Suorituskyky Performance Suorituskyky liittyi vastaajien keskuudessa lo- pullisen sovelluksen suorituskykyyn ja sovelluksen kokoon. Merkittävimpiä suorituskykyyn vaikuttavia haittoja olivat iso koodimäärä (perustoi- minnoissa), iso muistinkäyttö tai suuri kaistanle- veyden käyttö.

Koko Size JavaScript-sovelluskehyksellä kehitetyn sovelluksen koko. Esim. rivimäärissä mitattuna.

Taulukko 1. Suorituskyvyn odotusten -tekijän alikategoriat.

Selitys ja suhde vastauksiin

Automaatio Automatiza- tion

Ei selitetty tarkemmin.

(29)

Opittavuus Learnability Kuinka paljon työtä sovelluskehyksen oppiminen vaatii kehittäjältä. Oppimiseen vaadittavan työn määrä riippuu kehittäjän teknisistä taidoista. Jois- sakin vastauksissa tähän asiaan vaikutti myös se, paljonko kehittäjillä oli aikaa käytettävissä projektin kehittämiseen.

Monimutkai- suus

Complexity Mahdollisuus vähentää loppusovelluksen monimutkaisuutta sovelluskehyksen avulla.

Ymmärrettä- vyys

Understanda- bility

Kuinka nopeasti sovelluskehystä voidaan ym- märtää ja hyödyntää käytännön sovelluksissa.

Hyvä dokumentaatio ja sovelluskehyksen koo- dien rakenne pienentävät tähän kuluvaa aikaa.

Taulukko 2. Vaivannäkö-tekijän alikategoriat

Selitys ja suhde vastauksiin Kilpailija-ana-

lyysi

Competitor Analysis

Kuinka paljon samankaltaiset kilpailijayrityk- set hyödyntävät sovelluskehystä.

Kollegiaalinen neuvonta

Collegial Ad- vice

Työkollegoilta tai omien verkostojen kautta saatavat suositukset ja näkemykset sovellus- kehyksestä. Myös nettiarvostelut, -kokemukset ja -mielipiteet.

Yhteisön koko Community Size

Etenkin avoimelle lähdekoodille pohjautuvat sovelluskehykset on yleensä kehitetty ja yllä- pidetty yhteisön toimesta. Isommassa yhtei- sössä sovelluskehykseen liittyvät tilanteet (engl. issue) ratkaistaan nopeammin.

Yhteisön rea- gointikyky

Community Re- sponsiveness

Kuinka nopeasti sovelluskehyksen taustalla oleva yhteisö pystyy reagoimaan erilaisiin ti- lanteisiin.

Taulukko 3. Sosiaaliset vaikutukset -tekijän alikategoriat.

Soveltuvuus Suitability Täyttääkö sovelluskehys asetetut tarpeet.

(30)

Päivitykset Updates Kuinka usein sovelluskehystä päivitetään sään- nöllisesti ja kuinka usein siihen tulee uusia toi- minnallisuuksia, jotka auttavat ylläpitämään kilpailukykyä markkinoilla.

Modulaarisuus Modularity Sovelluskehyksen yhden moduulin muuttami- sen ei pitäisi vaikuttaa muualle sovelluskehykseen. Lisäksi sovelluskehykseen pitäisi olla mahdollista lisätä (engl. import) muita kirjastoja ja ominaisuuksia. Tarkoitetaan myös mahdollisuutta ottaa sovelluskehys käyttöön kehitysprosessin myöhemmissä vaiheissa.

Eristys Isolation Esimerkiksi sovellusten asiakaspää ja sovellus- pää eriytetään mahdollisimman paljon toisis- taan.

Laajennetta- vuus

Extensibility Onko sovelluskehykseen mahdollisuutta lisätä myöhemmin muita ulkoisia kirjastoja.

Taulukko 4. Edistävät olosuhteet -tekijän alikategoriat.

Taulukko 5. Hinta-arvo-tekijän alikategoriat

Kuva 7. Toimijat JavaScript-sovelluskehyksen valinnassa (Pano et al., 2018) mallin mukaan.

Tutkijat havaitsivat tutkimuksen vastauksista (Pano et al., 2018) kuvassa 7 näkyvät toimijat, jotka ovat yleensä mukana, kun JavaScript-sovelluskehystä valitaan. Mallissa

Selitys ja suhde vastauksiin Kustannus Cost Sovelluskehyksen kustannus.

(31)

asiakkaat voivat olla vaikuttamassa päätökseen, vähintään epäsuorasti, mikäli kehittä- jät joutuvat työskentelemään asiakkaan aikaisempien projektien kanssa. Vastauksista nousi esiin myös se, että päätöksiä tehdään tiimin kesken ja myös tiiminvetäjän toimesta. Yksittäiset kehittäjät voivat esimerkiksi etsiä potentiaalisia sovelluskehyksiä tietyn projektin tai ongelman ratkaisuun ja kustakin ehdotuksesta käydään hyvät ja huonot puolet läpi yhdessä tiimin kesken ja tiimi tai tiiminvetäjä päättää mikä sovelluskehys lopulta valitaan käyttöön.

Kuva 8. Tutkimuksen (Pano et al.,2018) johtopäätökset.

Kuvassa 8 on esitetty tutkijoiden (Pano et al., 2018) tekemiä johtopäätelmiä liittyen JavaScript-sovelluskehysten valintaan. Kuvassa johtopäätöksiä on 15 kappaletta. Tut- kijoiden esittämistä johtopäätöksistä koostettiin tähän tutkielmaan kokonaisuudet so- velluskehyksen arvostus ja luotettavuus, dokumentaatio, koodit ja sisäiset ja ulkoiset

(32)

kirjastot. Kokonaisuuksien alle kasattiin kuvassa 8 näkyviä päätelmiä. Nämä kokonai- suudet on esitetty seuraavana.

Tutkijat esittävät päätelmiä, jotka liittyvät sovelluskehyksen arvostukseen ja luotetta- vuuteen. Vastaajat muun muassa pitivät sovelluskehystä luotettavana, mikäli samankaltaiset yritykset hyödyntävät sitä ja jos sovelluskehyksen taustalla on yhteisö, jonka jäsenet panostavat sovelluskehykseen. Säännöllisesti päivittyviä ja kauan markkinoilla ja käytössä olleita sovelluskehyksiä arvostetaan uusia ja harvoin päivittyviä sovellus- kehyksiä enemmän. Arvostusta lisää kehittäjien keskuudessa myös, mikäli sovelluskehyksiin päivitetään ominaisuuksia, joiden avulla pystytään vastaamaan uusiin verk- kotrendeihin ja pysymään kilpailussa mukana. Päätelmistä nousee esiin, että ilmaisia sovelluskehyksiä suositaan enemmän kuin maksullisia.

Dokumentaation osalta esiin nousee, että sovelluskehyksen dokumentaation tulee olla selkeää ja täsmällistä. Dokumentaation tulee selkeästi kertoa sovelluskehyksen käyt- tötarkoitus eli onko sovelluskehyksen avulla tarkoitus kehittää pääsääntöisesti asiakas- pään vai palvelinpään sovelluksia. Dokumentaation tulee myös tarjota esimerkkejä ja ohjeita tavallisten kehitystehtävien ratkaisuun ja nopeaan kehittämiseen.

Tutkijoiden esittämien päätelmien perusteella on tulkittavissa huomioita liittyen sovelluskehyksen ja sovelluskehyksen tuottaman sovelluksen koodiin. Päätelmien mukaan sovelluskehystä hyödyntävän koodin tulee olla helppolukuista ja ymmärrettävää.

Sovelluskehyksen avulla kehitetyn koodin pitäisi olla mahdollisimman selkää ja lo- pullisen sovelluksen rivimäärän tulisi olla mahdollisimman pieni. Lopullisten sovellusten tulisi myös toimia erilaisissa selaimissa. Koodiin liittyvinä päätelminä nousi myös esiin, että yksinkertaiset tehtävät tuli olla automatisoitu sovelluskehyksen toimesta. Esimerkkinä kyseisestä tehtävästä on DOM-manipulaatio. Sovelluskehyksen koodin ja kehyksen itsessään tulisi myös olla siten modulaarinen, että yhden osion muuttaminen ei vaikuta muihin osiin.

Sisäisistä ja ulkoisista koodikirjastoista mainitaan, että kirjastojen käytön tulee olla joustavaa. Sovelluskehysten mukana tulevien kirjastojen tulee mahdollistaa yksinker- taisten ja edistyneiden toimintojen kehittäminen missä tahansa kehitysprosessin vaiheessa. Lisäksi ulkoisia kirjastoja tulisi pystyä käyttämään yhdessä sovelluskehysten

(33)

kanssa siten, että käytettäviä kirjastoja ei tarvitse erikseen muokata sovelluskehykseen sopiviksi.

Tutkijat muistuttavat tutkimuksessaan (Pano et al., 2018), että esiin nousseiden johto- päätösten välillä voi olla ristiriitoja ja päällekkäisyyksiä ja että johtopäätökset saavat isomman painoarvon, mikäli johtopäätöstä käytetään irrallaan. Esimerkkinä ristirii- doista tutkijat mainitsevat sovelluskehyksen, joka voi olla maksullinen, mutta koodil- taan helposti ymmärrettävä. Tutkijat jättävät ristiriitojen analysoimisen myöhemmille tutkimuksille.

Jokaisella tutkimuksella on yleensä myös rajoituksia tai puutteita. Tutkijat toteavat tutkimuksessa (Pano et al., 2018) suurimmaksi puutteeksi tutkimuksen otannan. Otan- nassa huomiotavia seikkoja olivat otannan koko sekä osallistujien tausta aiheen parissa. Tutkimukseen osallistui ainoastaan 18 vastaajaa ja kaikki olivat eksperttitason osaajia eikä niin sanottuja aloittelijoita otettu mukaan. Tutkijat kuitenkin perustelivat rajallista osallistujamäärää sillä, että otannan koko oli laadullisille tutkimuksille suo- siteltujen raja-arvojen sisällä. Yhtenä puutteena tutkijat myös mainitsevat, että osallis- tujat saivat itse arvioida ja määrittää mitä JavaScript-sovelluskehyksellä tarkoitetaan.

Osa vastaajista kertoi muun muassa käyttävänsä työpaikkansa omaa sovelluskehystä, mutta sen toimintaa ei avattu tutkijoille tarkemmin.

3.2 Kyselyt

Tässä kohdassa esitellään lyhyesti kyselyt, joiden tuloksia ja huomioita hyödynnetään soveltuvin osin tutkielman myöhemmissä luvuissa, kohdissa ja alakohdissa. Myös kunkin kyselyn taustalla vaikuttavat yritykset, sivustot ja tiimit esitellään lyhyesti.

Vuosien 2017–2020 aikana JetBrains s.r.o niminen yritys on suorittanut The State of Developer Ecosystem -nimellä kulkevia kyselyitä (JetBrains s.r.o, 2020a; JetBrains s.r.o, 2020b; JetBrains s.r.o, 2020c; JetBrains s.r.o, 2020d) ohjelmistoalan ammattilai- sille ja muille alan parissa työskenteleville henkilöille. Kyselyiden tarkoituksena (Jet- Brains s.r.o, 2020a) on ollut selvittää ohjelmistoalan uusia trendejä liittyen muun muassa työkaluihin, teknologioihin ja ohjelmointikieliin. JetBrains s.r.o itsessään on vuonna 2000 perustettu tshekkiläinen ohjelmistoyritys (JetBrains s.r.o, 2020e), joka

(34)

on kehittänyt muun muassa suosittuja kehitysympäristöjä (engl. Integrated Develop- ment Environment, IDE) erilaisille ohjelmistokielille. IntelliJ IDEA on yksi esimerkki kehitysympäristöistä. JetBrains on kehittänyt myös Kotlin-ohjelmointikielen.

Vuosi Vastaajamäärä (infografiikat) Kokonaisvastaajamäärä

2020 19 696 34 000 +

2019 6 993 19 000 +

2018 n. 6000 15 000 +

2017 n. 5000 + 9 000 +

Taulukko 6. State of Developer Ecosystem -kyselyiden vastausmäärät vuosittain ja- oteltuna (JetBrains s.r.o, 2020a; JetBrains s.r.o, 2020b; JetBrains s.r.o, 2020c; Jet- Brains s.r.o, 2020d).

Taulukko 6 on kasattuna eri vuosien State of Developer Ecosystem -kyselyiden vas- taajamääriä. Kyselyiden vastaajamääristä huomioitavaa on, että kyselyiden todellinen vastausmäärä on ollut isompi kuin mitä infografiikoissa käytetty vastausmäärä on. Eri määrät johtuvat siitä, että eri vuosien kyselyissä JetBrains pyrki rajaamaan mahdollisesti puolueellisia vastauksia pois. Esimerkiksi vuonna 2017 (JetBrains s.r.o, 2020d) JetBrains suoritti ja markkinoi kyselyä JetBrainsin sisäisten ja ulkoisten kanavien kautta, jolloin todellisten vastausten määrä oli isompi kuin infograafikoissa käytetty määrä. Sisäisillä kanavilla tarkoitetaan esimerkiksi JetBrainsin Twitter- tai Facebook- tilejä ja ulkoisilla kanavilla esimerkiksi Twitterin tai Facebookin mainoksia. Puolueel- lisuuden pienentämisen takia JetBrains kuitenkin rajasi infografiikasta pois sisäisten kanavien kautta saadut vastaukset ja käytti ainoastaan ulkoisten kanavien kautta saa- tuja vastauksia. Myös esimerkiksi vuonna 2019 (JetBrains s.r.o, 2020b) vastausten ra- jaamisessa ja painottamisessa käytettiin vastaavanlaista menetelmää. JetBrains ei erit- tele kyselyissään eri maiden tarkkoja vastaajamääriä.

Stack Overflow Developer Survey -kyselyt ovat Stack Overflown järjestämiä jokavuo- tisia koodaaville henkilöille kohdennettuja kyselyitä, joiden tarkoituksena (Stack Overflow, 2020a) ollut selvittää muun muassa erilaisiin ohjelmointikieliin ja teknologioihin liittyviä trendejä. Stack Overflown kyselyissä on myös kysymyksiä yhteisöihin ja kehittäjien taustoihin liittyen. Stack Overflow (Stack Exchange Inc., 2020) on suuri verkkosivusto ja -yhteisö koodauksen parissa toimiville henkilöille ja kehittäjille. Si-