Sisältö:
Palvelinten toinen tuleminen
Miksi web-standardit ovat hyvä asia?
Miten Remix auttaa kehittämään verkkosovelluksia, jotka kestävät aikaa?
Voiko web-sovellukseen käytetty teknologia kestää 10 vuotta?
Miten Remix on kestänyt jo kymmenen vuotta?
Miksi juuri Remix eikä esimerkiksi Next.js?
TL;DR
- Kautta aikain web-kehitys on rakentunut web-standardien päälle.
- JavaScriptin myötä sisältöä voitiin luoda ja muuttaa dynaamisesti lataamatta sivua uudelleen. Samalla hylättiin web-standardeihin jo toteutetut tavat tehdä kyseiset asiat.
- Hakukoneet eivät tykänneet tästä, eivätkä myöskään korkean suorituskyvyn vaativat palvelut, sillä nyt samat asiat piti suorittaa käyttäjän selaimessa.
- Web-kehityksessä palattiin palvelinpohjaiseen malliin, jolloin käyttäjän selaimessa suoritettavaa koodia oli vähemmän. Tämä parantaa suorituskykyä ja saavutettavuutta verrattuna pelkästään JavaScript-pohjaisiin ratkaisuihin.
-
Remix on paluu takaisin web-kehityksen juurille. Remix noudattaa web-standardeja, vähentää ylläpidettävää koodia ja toimii alustariippumattomasti.
-
Remix tarjoaa paremman kehityskokemuksen kuin esimerkiksi Next.js keskittyen taaksepäinyhteensopivuuteen ja yksinkertaisuuteen.
Teknologian kehitys tuntuu etenevän sykleissä.
Teknologia kehittyy, kun luodaan ratkaisu johonkin tiettyyn tekniseen haasteeseen. Tämän jälkeen kehitetään uusi teknologia, joka ratkaisee edellisen teknologian ongelmat, mutta samalla tulee luoneeksi kasan uusia ongelmia.
Usein vasta muutamien tällaisten iteraatioiden jälkeen todella ymmärretään vanhojen teknologioiden hyvät puolet. Myös uusista teknologioista on kerennyt kertyä oppeja. Tällöin onkin hyvä aika tarkastella vanhempia teknologioita uudemmista teknologioista viisastuneena.
Näin on tapahtunut myös web-sovellusten kehityksessä. Kerrataanpa siis hieman, miten web-palveluja on ajan saatossa rakennettu.
Aluksi web-sovellukset suoritettiin pelkästään palvelimella, ja selaimen osuudeksi jäi esittää palvelimelta palautuva HTML. Palvelimen rooli oli verrattain iso, kun taas selaimen ja JavaScriptin osuus hyvin pieni.
Selaimen osoiterivi (URL-osoite) kertoi, millä sivulla ollaan, ja dataa siirrettiin selaimen ja palvelimen välillä GET- ja POST-pyynnöillä.
Sitten sovellukset siirtyivät enenevissä määrin selaimeen JavaScript-koodin avustuksella. Palvelimen uusi rooli oli tarjoilla JSON-vastauksia rajapinnasta. Käyttäjän selaimessa suoritettavan JavaScriptin osuus kasvoi kasvamistaan, ja palvelimella suoritettavan koodin osuus vastaavasti pieneni.
Tämä johti hakukoneoptimointi-, suorituskyky- ja saavutettavuushaasteisiin. Näihin liittyvät ongelmat oli ratkaistu HTML:ssä mutta ei JavaScriptissä. Villeimmissä sovelluksissa selaimen URL-osoitekaan ei enää vastannut sitä, mitä käyttäjä ruudullaan näki.
Pyörä oli siis keksitty uudelleen JavaScriptillä. Ongelmana vain oli, että se toimi monissa tapauksissa huonommin kuin jo olemassa olevat web-standardit.
Palvelinten toinen tuleminen
Sovelluksia alettiin siirtää takaisin palvelimille.
Ymmärrettiin, että palvelin onkin itse asiassa erinomaisen hyvä suorittamaan koodia ja palauttamaan suoraan selaimen ymmärtämää HTML:ää. Mihin sitä JavaScriptiä taas tarvittiinkaan?
Palvelin on myös nopea. Yleensä huomattavasti nopeampi kuin käyttäjän laite ja sen selain. Selaimen suorittama JavaScript kun suoritetaan nimenomaan käyttäjän laitteessa – ei palvelimella.
Tämän päivän trendinä onkin palauttaa palvelimelta suoraan vanha kunnon HTML-sivu, jota sitten piristetään sopivalla annoksella JavaScriptiä, jotta saadaan aikaan web-palvelu modernilla käyttökokemuksella.
JavaScriptiä tietysti siis tarvitaan, mutta sillä ei tarvitse tehdä kaikkea. Tältä osin ympyrä sulkeutuu ja olemme palanneet vanhojen tuttujen web-standardien pariin.
Miksi web-standardit ovat hyvä asia?
Web-standardien ymmärtämiseksi meidän tulee ymmärtää muutama asia selaimen toiminnasta: URL, tiedon hakeminen palvelimelta ja lähettäminen palvelimelle.
Kuten tiedämme, URL määrittelee, mistä HTML-dokumentti tai muu resurssi löytyy. Web-sovelluksissa URL myös määrittelee osittain sovelluksen tilan hakuparametreilla (search params).
Web-standardit määrittelevät (monen muun asian ohessa) tavat sekä hakea tietoa palvelimelta että lähettää tietoa palvelimelle.
Oletetaan, että käyttäjä menee sivulle https://fraktio.fi/blogi. Tällöin selain tekee GET-pyynnön palvelimelle kyseiseen osoitteeseen, palvelin käsittelee sen, ja lopputuloksena käyttäjän selaimeen latautuu Fraktion blogi.
Tietoa haetaan palvelimelta myös, kun siirrytään sivulta toiselle. Linkittäminen eri sivujen välillä tapahtuu käyttämällä linkkejä, eli <a>-elementtiä (anchor). Esimerkiksi: <a href=”/blogi/remix”>siirry Remix blogikirjoitukseen</a>.
Tätä linkkiä painaessa selain lähettää GET-pyynnön palvelimelle hakeakseen osoitteen /blogi/remix.
Tietoa lähetetään palvelimelle käyttämällä lomakkeita eli <form>-elementtiä. Tästä esimerkkinä vaikkapa hakukentän käyttäminen tai järjestelmään uuden tiedon lisääminen. Tällöin selain tekee POST-pyynnön palvelimelle lähettäen samalla mm. lomakkeessa olevien <input>-kenttien sisällön.
Nämä toiminnallisuudet ovat olleet web-standardeissa jo vuodesta 1995 lähtien. Näiden käyttäminen ei vaadi JavaScriptiä ja näin ollen ne toimivat vaikka Netscape 1.0:ssa.
Miten Remix auttaa kehittämään verkkosovelluksia, jotka kestävät aikaa?
Remix rakentuu näiden olemassaolevien web-standardien päälle sen sijaan, että pyörää keksittäisiin uudelleen hyödyntäen pelkästään JavaScriptiä.
Tämä on perustavanlaatuisesti erilainen ajattelutapa kuin monilla muilla suosituilla Reactiin pohjautuvilla frameworkeilla.
Remixin tarkoituksena onkin olla mahdollisimman kevyt kerros jo olemassa olevien web-standardien päälle. Mitä enemmän käytämme valmiita standardeja, sitä paremmin tuemme automaattisesti esimerkiksi saavutettavuutta ja selaimeen sisäänrakennettuja toiminnallisuuksia, kuten lomakkeita ja välimuistitusta.
Kehittäjille tämä tarkoittaa vähemmän ylläpidettävää koodia. Kun käytetään <form>eja, JavaScriptin Request- ja Response-objekteja, eli siis standardeja, kehittäjät oppivat paremmin ymmärtämään sitä alustaa, jonka päälle web-sovelluksia rakennetaan.
Mukavana bonuksena tulemme rakentaneeksi sovelluksia, jotka eivät välttämättä tarvitse ollenkaan JavaScriptiä toimiakseen.
JavaScriptillä voidaan sovellukseen lisätä esimerkiksi latausanimaatioita ja parempi tuki saavutettavuudelle sekä saada moderni ja mukavampi käyttökokemus. Perustoiminnallisuuksiltaan sovellus kuitenkin toimii ilman JavaScriptiä.
Lopputulos myös latautuu nopeammin ja on kestävämpää, sillä selaimessa suoritettavaa JavaScriptiä on vähemmän.
Voiko web-sovellukseen käytetty teknologia kestää kymmenen vuotta?
Kymmenen vuotta on pieni ikuisuus web-kehityksessä. Teknologia kehittyy uskomatonta vauhtia. On suorastaan ihme, että teknologia, joka on ollut käytössä yli kymmenen vuotta, on vielä tänäkin päivänä näin laajalti tuettu ja kehittäjien suosiossa.
Kyseinen teknologia on tietenkin React.
Me olemme uskoneet Reactiin jo vuodesta 2015 lähtien. Remix on rakennettu Reactin päälle. Remixiä kehitetään samalla ajatusmallilla kuin Reactia. Taaksepäinyhteensopivuudesta pidetään visusti kiinni.
Ennustus on aina vaikeaa. Etenkin tulevaisuuden ennustus. Jos mietitään mitkä teknologiat tulevat kestämään aikaa, niin web-standardit ovat listamme kärkipäässä. Myös React-maailman ulkopuolella useat JavaScript-frameworkit, kuten esimerkiksi SvelteKit ja Astro ovat tehneet samoja ratkaisuja ja kasvattaneet suosiotaan web-standardien voimalla.
Kun rakennetaan standardien päälle, niin on todennäköistä, että ainakaan nämä alla olevat teknologiat eivät tule häviämään. Selaimet tulevat toimimaan ja tukemaan näitä teknologioita, kuten ne ovat niitä tukeneet viimeiset 30 vuotta.
Miten Remix on kestänyt jo kymmenen vuotta?
Remix on julkaistu vuonna 2021. Kuitenkin se on kestänyt aikaa jo lähes kymmenen vuotta. Miten tämä on mahdollista?
Remixin kehittäjät Ryan Florence ja Michael Jackson (ei se Michael Jackson) ovat muissa avoimen lähdekoodin projekteissaan (mm. React Router) osoittaneet, miten taaksepäinyhteensopivuus voidaan huomioida ilman merkittäviä vaikeuksia versiopäivitysten yhteydessä.
Remix on kehittäjiensä mukaan 90 % React Router ja itseasiassa Remixin seuraava versio tuleekin olemaan yhtä kuin React Router v7.
Jos tarkastellaan React Routerin omistautuneisuutta taaksepänyhteensopivuudelle ja miten hyvän päivityspolun se tarjoaa uusien versioiden välillä, niin voidaan todeta, että Remixin tulevaisuus näyttää erittäin valoisalta.
Toisaalta voidaan myös todeta, että Remixin (siis käytännössä React Routerin) historia on näyttänyt valoisalta koko sen olemassaolon ajan, eli kymmenisen vuotta.
Miksi juuri Remix eikä esimerkiksi Next.js?
Näiden kahden React-frameworkin suurimpina eroina on tukeutuminen web-standardeihin, taaksepäinyhteensopivuuden huomiointi ja alustariippumattomuus. Subjektiivisena mielipiteenä voisi mainita vielä Next.js:n monimutkaisuuden.
Remixissä web-standardit ovat korkeimmalla prioriteetilla, taaksepäinyhteensopivuuden huomiointi on toteutettu oikein (“feature flageilla”), ja Remixiä voi ajaa ajoympäristöstä riippumatta.
“Feature flageillä” uusia ominaisuuksia voidaan ottaa käyttöön ominaisuus kerrallaan. Ei siis välttämättä tarvitse odotella seuraavaa isoa julkaisua ja taaksepäinyhteensopimattomien muutosten korjaamista yhdellä kertaa.
Ainakaan toistaiseksi Next.js:ää ei kehitetä näillä periaatteilla. Remixin osalta voidaan todeta, että näin on toimittu jo sen alkuajoista lähtien.
Alustariippumattomuus tarkoittaa sitä, että Remix toimii lähes missä tahansa ajoympäristössä. Sen kehittäjillä ei näytä olevan rahallisia tai ideologisia motiiveja olla toimimatta siellä missä ikinä JavaScriptiä voi suorittaa. Next.js:n osalta tilanne on hieman monimutkaisempi, koska sen omistaa Vercel, joka tarjoaa alustaa ja laajaa kirjoa erilaisia palveluja käyttäjilleen.
Olemme vuosien saatossa tehneet useita suuria sovelluksia erilaisilla React-frameworkeilla. Käytetyimmät näistä ovat olleet Gatsby ja Next.js.
Edellä mainituissa frameworkeissä kehittäjän kokemus ei ole yltänyt erinomaiseen. Näissä on ollut ongelmia palvelimen puolen renderöinnissä (SSR) tai muuta epämääräistä, joka on johtanut frameworkin kanssa tappeluun koodin tasolla tai suureen tuskaan versiopäivitysten yhteydessä.
Remixin kanssa kehittäminen on tuntunut huomattavasti paremmalta. Moni fraktiolainen on kokenut jopa pienoisen flashbackin PHP-maailmasta ja paluusta vanhaan, mutta paremmalla teknologialla.
Siirtyminen puhtaasta Reactista tai Next.js:stä Remixiin on tuntunut suurelta harppaukselta taaksepäin. Ja vain ja ainoastaan lausahduksen positiivisessa merkityksessä.
Lue lisää Remixin ominaisuuksista sivuiltamme.
