Web-sovellusten tulevaisuudesta ja rakennuspalikoista – haastattelussa Juho Vepsäläinen

Suomessa ei ole kovin paljon ohjelmistokehittäjiä, jotka voivat sanoa kehittäneensä sellaisia sovelluskehyksiä, joita oikeasti käytetään laajasti maailmalla. Juho Vepsäläinen on tästäkin näkökulmasta harvinainen asiantuntija, ja ehkä vielä harvinaisempi hänestä tulee, kun huomioidaan, että hän on kohta väitellyt tohtori ja aiheena ovat juurikin web-kehityksen teknologiat. Juhon väitöskirja on juuri painossa ja väitöstilaisuus on nyt keväällä.

Lisäksi Juho tunnetaan Javascript- ja frontend-kehittäjien parissa Future Frontend -seminaarin (aiemmin React Finland -nimellä) järjestäjänä. Kyseinen seminaari on harvinainen kotimainen konferenssi, koska se ei ole vielä kuollut, vaan porskuttaa edelleen. Ehkä selviytymiseen on syy Juhon kontakteissa maailmalla, ehkä kyse on kotimaisten web-kehittäjäkentän aktiivisuudesta. Oli mikä oli, seminaari on vielä elossa ja toteutuu taas toukokuun lopussa kaksipäiväisenä versiona. Vierityspalkki kannustaa lämpimästi alan ohjelmistokehittäjiä ja muita asiantuntijoita hankkimaan liput konferenssiin, koska ei näitä kotimaisia laadukkaita web-kehitykseen keskittyviä konferensseja vain ole liikaa (tämä on käytännössä ainut konferenssi joka ei ole johonkin tiettyyn teknologiaan keskittynyt).

Juhon sivuston oma kuvaus historiastaan web-sovelluskehittäjänä ja avoimen lähdekoodin yhteisöaktiivina on varsin hyvä tiivistys siitä, kenestä on kyse.

It was only in early 2000s that I started to become more serious about programming as I became involved with the Blender↗ project for several years starting from 2005 as I contributed to the project by coding and improving documentation. I was one of the founders of webpack↗ core team and helped to establish the project to a broader public through my webpack book. I have also authored numerous open source projects primarily for my own purposes, although several have become popular on their own as other people and companies have found my work useful. At the moment I pursue a PhD at Aalto University↗ and so far I have produced numerous research outputs related to web development and mentored several students in their BSc and MSc work.

Haastattelussa Juho tuo esiin muun muassa web-kehityksen sovelluskehysten siirtymän  kevyempiin ratkaisumalleihin, jotta käyttäjien päätelaitteita ei kuormitettaisi liikaa raskailla sovelluskehyksillä. Näistä Juho käyttää termiä ’katoavat sovelluskehykset’. Haastattelussa sivutaan myös sitä todellisuutta, että teknologia harvoin kehittyy lineaarisesti tai edes kovin johdonmukaisesti. Enemmänhän teknologian kehityksessä on kyse jonkinlaisesta spiraalimallisesta kehityksestä, jossa mennään välillä taaksepäin ja keksitään samoja asioita uudestaan, mutta yleensä kuitenkin jollain hieman uudella kulmalla.

Webin teknologiakehitys on täynnä esimerkkejä tällaisesta ympyrän muotoisesta kehityksestä, jossa samoja ideoita esitellään hieman uudelleen paketoituna uudestaan. Joskus kyse on vain siitä, että ensimmäisellä kierroksella malli ei saanut riittävästi suosiota. Joskus on kyse taas ihan realiteeteistä liittyen esimerkiksi verkon siirtonopeuksiin tai päätelaitteiden tehokkuuteen.

Tällä hetkellä kehitys on menossa sekä eteenpäin että taaksepäin, koska osa alasta keskittyy optimointiin ja keveyteen, osa taas panostaa esimerkiksi tekoälytoimintoihin, joiden kuormitus saattaa olla hyvinkin suurta per käyttäjä. Tästä voi olla montaa mieltä, mutta ainakin Juhon suhde on ihailtavan viileä, tutkijana hän tarkastelee ilmiöitä enemmänkin niiden mitattavien vaikutusten kautta. Tunnepohjaiset mielipiteet kehityksen suunnasta Juho jättää muille.

Haastattelu on tehty Teams-keskustelun ja LinkedIn-keskustelun kautta. Vierityspalkin kysymykset lihavoituna.

1) Mikä on tutkimuksesi punainen lanka? Mitä aihepiirejä tutkit ja mikä sinua kiinnostaa tutkijana eniten?

Väitöstutkimukseni lähti liikkeelle havainnosta siitä että tapamme kehittää webbisovelluksia ei ole kenties ideaali ja sattuman kautta päädyin Aalto-yliopiston koulutusohjelmaan, jossa aloitin 2022 kesällä. Tutkimukseni punainen lanka liittyykin juurikin vaihtoehtoisiin tapoihin kehittää webiä ja väitöksessäni keskityn erityisesti nichen historiaan sekä uusimpiin tekniikoihin erityisesti sivujen renderöinnin osalta. Osana tutkimustani tutkin myös reunalaskentaa (edge computing), joka on noussut perinteisempien tapojen rinnalle palvelinpuolella latenssietujensa vuoksi.

Nyt väitöstutkimukseni päätyttyä olen tehnyt yhteistyötä Janne Kalliolan kanssa vihreän laskennan saralla paperimuodossa. Jannen väitöstutkimus kun menee tuohon suuntaan ja nyt mankelin läpikäyneenä tässä on hyvä yhteistyön paikka. Vihreän laskennan lisäksi käytän aikaa oman sovelluskehikkoni kehittämiseen hiljakseen ideoita testatakseni.

Vaikken olekaan julkaissut asiasta vielä papereita, nähdäkseni vihreän laskennan, webin ja tekoälyn välimaastosta voisi löytyä mielenkiintoisia jatkotutkimusaiheita olettaen, että saan järjestettyä rahoitusta jatkotutkimukselleni. Varsinkin tekoäly näyttää muuttavan tapaamme kehittää sovelluksia, mutta toisaalta tässä voi olla ristiriita vihreyden kanssa.

2) Mistä tämä konferenssien järjestäminen on lähtenyt sinulla, miksi tällaisia tarvitaan?

Ajauduin konferenssien järjestämiseen vuonna 2017, kun Samuli Hakoniemi ehdotti että voisimme React-teemaisen tapahtuman järjestää. Ennen tätä aiemmin Suomessa oli toiminut Webshaped-niminen tapahtuma eikä tuohon aikaan webbipuolella ollut Suomessa tapahtumaa. Ensimmäinen React Finland-tapahtuma pidettiin vuonna 2018 ja sitä seuraavatkin olivat riittävän menestyksekkäitä, jotta homma sai jatkoa. Välillä pidimme GraphQL-tapahtumankin joka jäi yhden kerran mittaiseksi. Vuodeksi 2023 uusimme brändin laajemmaksi ja olemme siitä asti kulkeneet nimen Future Frontend alla. Future Frontend kulkee käsi kädessä tutkimuskiinnostusteni kanssa ja olenkin pyrkinyt kuratoimaan ohjelmaan tulevia trendejä kartoittavia sessioita.

Vaikka koronapandemia muuttikin osaltaan markkinaa, näen silti että erikokoisille tapahtumille on selkeä tarpeensa. Pandemian aikana järjestimme sisältöpitoisia onlinetapahtumia, mutta käytännössä noista jää vain toinen puoli tapahtumakokemuksesta käteen. Sisällön lisäksi tapahtumissa on kyse siitä että tapaa oman viiteryhmänsä edustajia ja samalla käsittää paremmin missä ollaan menossa. Pohjimmiltaan kyse on inspiraatiosta ja inspiraatio nousikin esille viime tapahtumamme lopussa teettämässäni kyselyssä, jossa osallistujamme kokivat itsensä inspiroituneeksi tapahtuman jälkeen. Mikä voisikaan olla parempi saavutus näin tapahtumanjärjestäjän näkökulmasta.

3) Olet tehnyt web-sovelluksia pitkään, mitä asioita pidät 2000-luvulla isoimpina muutoksina tällä alueella?

Webille suunnatut sovelluskehykset ovat tuoneet mukanaan tarvittua rakennetta ja abstraktioita, jotta yhä suurempien ja kasvavien kokonaisuuksien hallinta on tullut mahdolliseksi. Teknisesti ajatellen monia asioita olisi voitu tehdä jo 2000-luvun alussa tuodun AJAX-tekniikan ympärille mutta tuolloin kehittäjäyhteisöllä ei ollut vielä selvää käsitystä siitä mitä kaikkea websovelluksissa voisikaan tehdä. Käytännössä jokaisessa sovelluskehyksessä on mukana jonkinlainen komponentin käsite komposition mahdollistamiseksi sekä jonkinlainen mielipide vähintäänkin tilanhallintaan sekä reititykseen. Erot löytyvät sitten yksityiskohdista ja toisinaan arkkitehtuuristakin. Kehykset asettavat osaltaan rajat sille mitä on helppoa tehdä ja mitä ei ja näkisin että kehykset voivat mennä teknisesti eteenpäin vielä huomattavasti.

Toinen oleellinen seikka on itse web-alustan kehitys noin standardoinnin näkökulmasta. Erityisesti JavaScript (ECMAScript), HTML ja CSS selain-apien ohella ovat menneet kovasti eteenpäin. Standardien kehittyessä myös sovelluskehyksillä on vähemmän tehtävää, mikä sinänsä on hyvä asia. Nähdäkseni tarve kehyksille on vähentynyt ja jokseenkin monimutkaisia sovelluksia voidaan kehittää muutamaa kevyttä kirjastoakin käyttäen.

Lisäksi ns. katoavista sovelluskehyksistä on tullut selkeä ilmiönsä. Kysymys on siis siitä että kyseiset sovelluskehykset pyrkivät katoamaan sovelluksestasi ja minimoimaan asiakkaalle lähetettävän tietomäärän tältä osalta. Tämä trendi näkyy varsinkin uusimmissa kehyksissä, kuten vaikkapa Svelte, Astro ja Qwik. Mielenkiintoisesti Googlen tehokas suljetun lähdekoodin Wiz tullaan integroimaan jollain tavoin Angulariin, joten uudet ideat voivat ruokkia myös pidempään käytössä olleita kehyksiä.

4) Mitä hyvää on tapahtunut viime vuosina tällä alueella, mitkä asiat ovat muuttuneet paremmiksi?

Nähdäkseni suurin muutos liittyy ekosysteemin kokoon. Erityisesti käyttöliittymäpuolella on paljon vaihtoehtoja, jotka ovat yhä laadukkaampia.

Infrastruktuurin tasolla reunalaskenta on ruvennut näkymään myös uusissa sovelluskehyksissä, jotka ovat usein yhteensopivia suoraan uuden lähestymistavan kanssa. Toki tämä voi vaatia sopeutumista kehittäjäpuolelta eikä siirtymä reunalle ole välttämättä aina mahdollista tai helppoa. Se voi tuoda mukanaan myös uusia haasteita mahdollisista latenssieduistaan huolimatta.

Web kehittyy alustana vuosi vuodelta. Toki siinä menee aikansa että asiakkaat saavat päivitettyä selaimiaan, mutta toisaalta esimerkiksi uusimpia kielten ominaisuuksia voi hyödyntää vaivatta, koska useimmilla kehittäjillä on joka tapauksessa jonkinlainen kääntäjä, useimmiten TypeScript, käytössä.

5) Mitä huonoa on tapahtunut viime vuosina, tai mitkä asiat eivät tunnu menevän parempaan suuntaan?

Todennäköisesti webbisovellusten kehittäminen ei ole milloinkaan ennen ollut niin helppoa kuin nykyään erityisesti uusien tekoälypohjaisten työkalujen myötä. Toisaalta webbisivustojen koko tuntuu kasvavan jatkuvasti. Ympäristön kannalta suunta ei ole siis hyvä saati kestävä varsinkin jos otetaan uusimmat alan energiankulutusta huomioivat projektiot mukaan.

Onkin hyvä kysymys, miten tätä ns. koko- ja kulutusongelmaa lähteä ratkomaan. Ongelmaa ei ole helppoa ratkoa, koska siinä on paljon eri tekijöitä mukana. Sinänsä vaikka yksittäinen kehittäjä optimoisikin sivustonsa, se ei vaikuta merkittävästi suureen kuvaan. Toisaalta jos esimerkiksi sovelluskehys onnistuu säästämään hiemankin, niin skaala voi olla automaattisesti jo isompi. Tästä edelleen infrastruktuuritason kehitysaskeleilla on isompi merkityksensä politiikasta ja kannustimista puhumattakaan.

6) Mitä sovellusten kuormittavuudelle ja raskaudelle voi tehdä? Mistä asioista yksittäisen sovelluskehittäjän kannattaisi aloittaa?

Usein ongelmaksi muodostuu se ettei kestävästä tavasta kehittää makseta erityisesti. Sen sijaan se saatetaan jopa nähdä kustannuksena. Tästä huolimatta jo tietoisuus asiasta on hyvä ensimmäinen askel. Tietoisuuden kautta päästään kiinni matalalla roikkuviin hedelmiin, jotka eivät välttämättä edes vaadi huomattavaa kehityspanosta.

Eräs helppo happotesti on webbisivuston analysointi esim. Googlen PageSpeed Insights-työkalua tai vastaavaa hyödyntäen. Monet näiden työkalujen osoittamista seikoista ovat varsin nopeita korjata.

Skaalasta riippuen kestävämpi tapa kehittää voi lisäksi säästää selvää rahaa alempien palvelinkustannusten muodossa parantuneesta käyttäjäkokemuksesta puhumattakaan. Nopeat sivustot näyttävät voimansa erityisesti mobiiliympäristöissä, joissa kaistaa ei ole saatavilla huomattavaa määrää.

7) Mitä asiakkaiden kannattaisi vaatia, jotta saisivat kestävämpiä ja laadullisesti parempia sovelluksia? Voiko asiakas jättää freimien ja muiden teknologioiden valinnan tiimin konsulttikoodareille?

Perinteisesti sanotaan että sitä saat mitä mittaat. Vaikka asiakas vaatisikin hyödyntämään esimerkiksi mainittua Google PageSpeed Insights-työkalua, ei se välttämättä tarkoita paljoa. Tämän vuoksi paraikaa tutkinkin parempia keinoja selvittää webbipalveluiden hiilihintaa. Tähänkin löytyy jo työkalunsa, mutta niissä on selvästi omat puutteensa ja epätarkkuutensa.

Tämän vuoksi kenties olennaisin vinkkini olisikin arvioida tarkoin mitä ominaisuuksia todellakin tarvitaan ja punnita tarvitaanko esimerkiksi niin paljon videota ja kuvaa. Tällainen prioriteettianalyysi voi säästää myös kustannuksia kun keskitytään oikeisiin asioihin ja toissijaista toiminnallisuutta jätetään toteuttamattakin. Harkitsisin myös tarkoin kolmannen osapuolen palveluiden hyödyntämistä, koska usein nuo näkyvät selvästi sivustojen koossa ja sitä kautta latauskustannuksessa.

Sovelluskehyksen valinta on osin poliittinen kysymys johon vaikuttavat myös jo organisaatiossa hyödynnettävät teknologiaratkaisut. Toisinaan konsulttipuolella puhutaan ns. konservatiivisesta tavasta valita teknologioita, koska tämä säästää vaivaa ja ongelmia. Toisaalta tällöin ei välttämättä saada kaikkein uusimpia ideoita mukaan. Kehysvalintaan vaikuttaa myös projektin laajuus sekä suunniteltu elinikä. Näkisin että lyhyissä prototyypeissä teknologialla ei ole suurta merkitystä mutta pidemmissä ylläpitoa vaativissa projekteissa teknologiavalinta muuttuu oleellisemmaksi, koska sillä on selkeä pidemmän aikavälin kustannus.

8) Webbiä ei tosiaan ole luotu sovellusalustaksi, ja varmaan tästä perusongelmasta on lähtöisin moni muu ongelma, mutta mitä näet isoimpina puutteina? Mitkä ovat webin valuvikoja sovellusalustana käytön näkökulmasta?

Webin sivustopohjainen lähtökohta näkyy yhä monessa asiassa ja webin päälle on luontevinta tehdä erilaisia sisältöjä. Sovellusmielessä puutteita on korvattu erityisesti kehyspuolella ja sieltä ne webin puutteetkin löytyvät. Esimerkiksi asiakaspuolen tilanhallinta on yhä työlästä ilman pientä kirjastoa tai kehystä. Sama ongelma toistuu myös komponenttien sekä reitityksen puolella vaikka molempiin löytyy omat rajapintansa. Standardoinnin näkökulmasta ongelmana tässä saattaa olla se että on hankalaa ottaa mielipidettä joka sopisi moneen käyttötarkoitukseen ilman että kumartaa liikaa johonkin tiettyyn suuntaan. Juurikin tästä syystä tuskin näemme koskaan selaintason tukea esimerkiksi Reactin hyödyntämälle JSX-kielelle.

En välttämättä näkisi webin puutteita sovelluskehityksen näkökulmasta ongelmina. Sinällään alusta on ollut riittävän hyvä mahdollistaakseen monia eri kehitystapoja. Tietyn kehitystavan lukitseminen itse alustaan saattaisi olla jopa vaarallista, koska se voisi sulkea uusia, parempia kehitystapoja pois. Standardien näkökulmasta on siis hyvä että standardit kehittyvät, mutta toisaalta niiden ei kannattaisi kehittyä turhan nopeasti vaan hiljalleen parhaita ideoita hyödyntäen varsinkin koska web-standardiin lisättyjä ominaisuuksia voi olla sittemmin hankalaa poistaa siitä.

9) Jos olisit aloittava ohjelmistokehittäjä, mitä nyt kannattaisi opetella mielestäsi?

Vastaukseni on kenties kliseinen mutta käyttäisin aikaa itse web-alustan opetteluun, eli perehtyisin hyvin CSS-, HTML- ja JavaScript-kieliin. Todennäköisesti JavaScriptin kylkeen ottaisin nopealla aikataululla TypeScriptin, joka on muodostunut standardiksi alalla. Sovelluskehyksistä ottaisin aluksi käyttöön eniten itseä miellyttävän ja vilkaisisin ajan kuluessa muitakin, koska tietyt ideat toistuvat kaikissa. Syvään päätyyn pääsee kehittämällä omat abstraktionsa ja tuo on usein myös hyvä tapa oppia paljon teknologioista nopeasti varsinkin jos ohjelmointi ei ole pullonkaula enää.

Toki koska eletään vuotta 2025, opettelisin myös hyödyntämään tekoälypohjaisia työkaluja tehokkaasti varsinkin koska ne voivat tehostaa tekemistä niin paljon. Toisaalta samalla on hyvä pitää tietty kriittinen asenne ja puntaroida sitä onko generoitu koodi riittävän laadukasta. Tekoälypuolella työkalukehitys on paraikaa valtavan nopeaa ja viikko viikolta näemme parempia ratkaisuja. Haaste on sitten löytää noista ne itselle toimivimmat työkalut.

10) Jos taas ajattelet kokeneen kehittäjän näkökulmasta, niin mihin silloin kannattaisi keskittyä? Mitkä asiat ovat isoja juttuja 5-10 vuoden päästä?

Todennäköisesti panostaisin juurikin uusimpien tekoälytyökalujen opetteluun hieman työtehtävistä riippuen. Lisäksi perehtyisin nouseviin arkkitehtuurihin ja tekniikoihin. Noista voisin mainita esimerkkeinä Astron hyödyntämän saariarkkitehtuurin ja yleisemmän mikrofronttiarkkitehtuurin (micro frontend architecture), joka voidaan nähdä saarien yleistyksenä. Väittäisin myös että perusteknologioista lukemalla löytää kaikenlaista uutta. Nykyään jo ihan HTML:ää ja CSS:ää hyödyntämällä pääsee yllättävänkin pitkälle ja tämä näkyy ns. HTML First-tavassa kehittää websovelluksia.

11) Miten merkityksellisenä pidät frameworkkien erilaisia taustatahoja ja niiden tapaa kehittää tuotetta ja ekosysteemiä? Esimerkiksi React ja Vue ovat taustavoimiltaan hyvin erilaiset yhteisöt. Olemme myös viime aikoina todistaneet, että yksittäisten ihmisten liiallinen valta-asema voi heiluttaa isojakin ekosysteemejä. (case Mullenweg ja WordPress) Mitä asiakkaiden kannattaisi näistä taustoista tietää ja mihin taustat mielestäsi eniten vaikuttavat?

Oma kokemukseni avoimen lähdekoodin koodista juontaa aina 2000-luvun alkuun ja tänä aikana avoimen lähdekoodin ekojärjestelmät ovat kehittyneet huomattavasti. Varsinkin alkuaikoina toiminta saattoi olla hyvinkin ideologista ja sittemmin tähän ympärille on kasvanut kaupallisia tapoja kehittää. Tästä päästäänkin itse kysymykseen, eri tuohon projektien taustatahojen merkitykseen.

Tänäkin päivänä ihmiset ja yritykset pyörittävät projektejaan erilaisin motivaatioin. Avoimen lähdekoodin alta löytyy niin pieniä harrasteprojekteja kuten myös laajalti käytettyjä oman nichensä tärkeimpiä ratkaisuita, kuten juurikin tuo mainitsemasi WordPress. Kummassakin ääripäässä on omat ongelmansa. Pieni, mutta oleellinen harrastajavoimin kehitetty projekti voi olla yksinkertaisesti hidas vasteessaan, koska ihmistyö ei skaalaudu. Toisaalta oikein lähestyttynä tällaiset projektit voivat olla hyvinkin avoimia yhteistyölle ja olenkin kehittäjänä käyttänyt tällaista mallia toisinaan, kun asiakas on motivoinut kirjastojeni kehitystä ja suoraan rahoittanut sitä.

Kaupallisesti tärkeät, yrityksen pääosin kehittämät projektit, voivat johtaa jonkinlaiseen ristiriitaan yrityksen ja projektin käyttäjien välillä. Hyvä esimerkki tästä on Vercelin kehittämä erittäin suosittu Next.js-sovelluskehys. Vercel toimii tässä tapauksessa kaksoisroolissa, koska yrityksen varsinainen liiketoiminta liittyy Next.js-hostaukseen. Tästä seuraa että kehys toimiikin parhaiten juuri heidän alustallaan ja yritystä onkin kritisoitu tästä. Koska puhutaan kuitenkin avoimen lähdekoodin projektista, Vercelin ulkopuolinen yhteisö on ratkonut asiaa OpenNext-projektillaan, vaikkakin se sisältää omat rajoituksensa.

Mahdollisten ristiriitojen lisäksi toinen merkittävä seikka on projektien kehityssykli. Sitoutumalla sovelluskehykseen, tämä voi aiheuttaa eräänlaista kitkaa, koska uusimmat ominaisuudet ja korjaukset ovat tietenkin saatavilla vain uusimmissa versioissa. Toisaalta versiosta toiseen päivittäminen ei välttämättä aina ole helppoa ja voi sinällään johtaa uusiin ongelmiin ratkottaviksi. Tämä onkin eräs argumentti jo aiemmin mainitsemani konservatiivisen valinnan puolesta, koska jo vakiintuneissa ratkaisuissa on yksinkertaisesti vähemmän kehitettävää. Myöskin web-alustan lähellä pysytteleminen voi olla järkevää, koska web on alustana varsin vakaa. Mitä kauempana sovelluskehys on ns. puhtaasta webistä, sitä enemmän välissä on todennäköisesti liikkuvia palasia jotka voivat mennä tavalla tai toisella rikki tai vaatia ylläpitoa.

12) Lopuksi kysymys kevään tulevasta konferenssista. Jos sinun olisi pakko valita kolme sessiota konferenssista, joita odotat eniten, mitkä valitset?

Tämän vuoden ohjelma on varsin kattava kattaus aihepiiriin. Itse odotan eniten Charlie Gerardin ja Tero Parviaisen ensimmäisen konferenssipäivän päättäviä demonstraatioita. Uskoisin myös että saan innoitusta Georgios Diamantopouloksen ja Olavi Haapalan työelämää sivuasta sessiosta. Veikkaan että Rachel Naborsin, Stephanie Nemethin ja Sebastian Obelin tapahtuman päättävä tekoälyä sivuava sessio voi olla varsin ajatuksia herättävä.

—

>> Tutustu Future Frontend -seminaarin ohjelmaan. Liput alkaen 399 euroa (+alv.).