Noin 15 vuotta sitten työskentelin yrityksessä, jossa rakensimme sovelluksia matkatoimistoille, lentokenttätyöntekijöille ja lentoyhtiöille. Rakensimme myös oman sisäisen viitekehyksemme käyttöliittymäkomponenteille ja yksisivuisille sovellusominaisuuksille. Meillä oli komponentteja kaikkeen: kentät, painikkeet, välilehdet, alueet, tietotaulukot, valikot, päivämäärän valitsimet, valinnat ja monivalinta. Meillä oli jopa div-komponentti. Div-komponenttimme oli muuten loistava, sillä pystyimme pyöristämään kulmia kaikilla selaimilla, mikä ei ollut helppoa, uskokaa tai älkää.
Työmme tapahtui ajankohtana historiassamme, jolloin JS, Ajax ja dynaaminen HTML nähtiin vallankumouksena, joka toi meidät tulevaisuuteen. Yhtäkkiä pystyimme päivittämään sivun dynaamisesti, saamaan tietoja palvelimelta ja välttämään siirtymisen muille sivuille, mikä nähtiin hitaana ja välkkyi näytöllä iso valkoinen suorakulmio kahden sivun välissä. Siellä oli lause, jonka Jeff Atwood (StackOverflown perustaja) teki suosituksi ja joka kuului: "Kaikki sovellukset, jotka voidaan kirjoittaa JavaScriptillä, kirjoitetaan lopulta JavaScriptillä." - Jeff Atwood
Meistä tuolloin tämä tuntui uskallusta todella mennä luomaan nuo sovellukset. Tuntui yleiseltä hyväksynnältä tehdä kaikki JS:n kanssa. Joten teimme kaiken JS:n kanssa, emmekä käyttäneet aikaa muiden tapojen tutkimiseen. Emme todellakaan tunteneet kannustinta oppia kunnolla, mitä HTML ja CSS voivat tehdä. Emme todellakaan nähneet verkkoa kehittyvänä sovellusalustana kokonaisuudessaan. Näkimme sen enimmäkseen asiana, jota meidän piti kiertää, varsinkin kun kyse oli selaimen tuesta. Voisimme vain heittää enemmän JS:ää saadaksemme asiat tehtyä. Olisiko aikaa oppia lisää siitä, miten verkko toimii ja mitä alustalla oli saatavilla, olisin auttanut minua? Toki, olisin voinut luultavasti leikata joukon koodia, jota ei todellakaan tarvittu. Mutta tuolloin ehkä ei niin paljon. Katsos, selainerot olivat melko merkittäviä tuolloin. Tuolloin Internet Explorer oli edelleen hallitseva selain, jossa Firefox oli lähellä toista, mutta alkoi menettää markkinaosuuttaan Chromen nopean suosion vuoksi. Vaikka Chrome ja Firefox olivat melko hyviä sopimaan verkkostandardeista, ympäristöt, joissa sovelluksemme toimivat, merkitsivät sitä, että meidän piti tukea IE6:ta pitkään. Silloinkin kun saimme tukea IE8:aa, jouduimme silti käsittelemään monia selainten välisiä eroja. Ei vain sitä, mutta ajan verkossa ei vain ollut niin monia ominaisuuksia sisäänrakennettuna suoraan alustaan.
Pikakelaus tähän päivään. Asiat ovat muuttuneet valtavasti. Meillä ei ole ainoastaan enemmän näitä ominaisuuksia kuin koskaan ennen, vaan myös niiden saatavuus on lisääntynyt. Esitän sitten kysymyksen uudelleen: Auttaisiko se, että käytät aikaa oppiaksesi lisää siitä, miten verkko toimii ja mitä alustalla on saatavilla? Ehdottomasti kyllä. Verkkoalustan ymmärtämisen ja käytön oppiminen nykyään antaa sinulle valtavan edun muihin kehittäjiin verrattuna. Työskenteletpä sitten suorituskyvyn, käytettävyyden, reagoivuuden parissa, kaikkia niitä yhdessä tai vain käyttöliittymäominaisuuksien toimittamisessa, jos haluat tehdä sen vastuullisena insinöörinä, käytettävissäsi olevien työkalujen tunteminen auttaa sinua saavuttamaan tavoitteesi nopeammin ja paremmin. Jotkut asiat, joita et ehkä enää tarvitse kirjastoa varten Kun tiedämme, mitä selaimet tukevat nykyään, kysymys kuuluu: mitä voimme jättää huomiotta? Tarvitsemmeko div-komponentin pyöristettyjen kulmien tekemiseen vuonna 2025? Emme tietenkään. Kaikki tällä hetkellä käytetyt selaimet ovat tukeneet border-radius-ominaisuutta yli 15 vuoden ajan. Ja myös kulman muoto on tulossa pian, vieläkin hienompiin kulmiin. Tarkastellaanpa suhteellisen uusimpia ominaisuuksia, jotka ovat nyt saatavilla kaikissa yleisimmissä selaimissa ja joilla voit korvata koodikannassasi olemassa olevia riippuvuuksia. Tarkoituksena ei ole heti hylätä kaikkia rakastettuja kirjastojasi ja kirjoittaa koodikantasi uudelleen. Mitä tulee kaikkeen muuhun, sinun on ensin otettava huomioon selaimen tuki ja tehtävä päätös muiden projektiisi liittyvien tekijöiden perusteella. Seuraavat ominaisuudet on toteutettu kolmessa pääselainkoneessa (Chromium, WebKit ja Gecko), mutta sinulla saattaa olla erilaisia selaimen tukivaatimuksia, jotka estävät sinua käyttämästä niitä heti. Nyt on kuitenkin hyvä aika oppia näistä ominaisuuksista ja ehkä suunnitella niiden käyttöä jossain vaiheessa. Ponnahdusikkunat ja dialogit Popover API,
Toki Internet-yhteytesi nopeus on luultavasti noussut, mutta se ei koske kaikkia. Kaikilla ei myöskään ole samoja laiteominaisuuksia. Kolmannen osapuolen koodin ottaminen käyttöön asioille, joita voit tehdä alustalla, tarkoittaa todennäköisesti sitä, että lähetät enemmän koodia ja tavoitat siten vähemmän asiakkaita kuin normaalisti. Verkossa huono latausteho johtaa suuriin hylkäämisprosentteihin ja vahingoittaa brändin mainetta. Käyttää vähemmän koodia laitteilla Lisäksi asiakkaidesi laitteille toimittamasi koodi toimii todennäköisesti nopeammin, jos se käyttää vähemmän JavaScript-abstrahioita alustan päällä. Se on myös todennäköisesti reagoivampi ja helpommin saavutettavissa oletuksena. Kaikki tämä johtaa enemmän ja tyytyväisempiin asiakkaisiin. Katso kollegani Alex Russellin vuotuinen suorituskykyerojen erottomuusblogi, joka osoittaa, että premium-laitteet ovat suurelta osin poissa markkinoilta, joilla on miljardeja käyttäjiä varallisuuserojen vuoksi. Ja tämä ero vain kasvaa ajan myötä.
Sisäänrakennettu muurattu asettelu Yksi verkkoalustan ominaisuus, joka on tulossa pian ja josta olen erittäin innoissani, on CSS Masonry.
Aloitan selittämällä, mitä muuraus on. Mikä on muuraus Muuraus on eräänlainen asettelu, jonka Pinterest teki suosituksi vuosia sitten. Se luo itsenäisiä sisältöraitoja, joihin kohteet pakkaavat itsensä mahdollisimman lähelle raidan alkua.
Monet ihmiset pitävät muurausta loistavana vaihtoehtona portfolioihin ja valokuvagallerioihin, minkä se varmasti voi tehdä. Mutta muuraus on joustavampaa kuin mitä näet Pinterestissä, eikä se rajoitu vain vesiputouksen kaltaisiin asetteluihin. Muuratussa asettelussa:
Raidat voivat olla sarakkeita tai rivejä:
Kaikkien sisältöraitojen ei tarvitse olla samankokoisia:
Kohteet voivat kattaa useita raitoja:
Tavarat voidaan sijoittaa tietyille raiteille; niiden ei tarvitse aina noudattaa automaattista sijoittelualgoritmia:
Demot Tässä on muutamia yksinkertaisia demoja, jotka tein käyttämällä tulevaa CSS Masonry -toteutusta Chromiumissa. Kuvagallerian esittely, joka näyttää, kuinka kohteet (tässä tapauksessa otsikko) voivat kattaa useita raitoja:
Toinen kuvagalleria, jossa näkyy erikokoisia kappaleita:
Uutissivuston asettelu, jossa jotkut raidat ovat leveämpiä kuin toiset ja jotkut kohteet kattavat asettelun koko leveyden:
Kanban-taulu, joka näyttää, että esineitä voidaan sijoittaa tietyille raiteille:
Huomautus:aiemmat demot tehtiin Chromiumin versiolla, joka ei ole vielä useimpien verkkokäyttäjien saatavilla, koska CSS Masonry on vasta alkamassa ottaa käyttöön selaimissa. Verkkokehittäjät ovat kuitenkin iloisesti käyttäneet kirjastoja luodessaan muurausasetteluja jo vuosia. Nykyään muurausta käyttävät sivustot Itse asiassa muuraus on nykyään melko yleistä verkossa. Tässä muutama esimerkki, jonka löysin Pinterestin lisäksi:
Ja vielä muutama, vähemmän ilmeinen esimerkki:
Joten miten nämä asettelut luotiin? Ratkaisuja Yksi temppu, jota olen nähnyt käyttävän, on Flexbox-asettelun käyttäminen, sen suunnan muuttaminen sarakkeeksi ja sen asettaminen käärimään. Tällä tavalla voit sijoittaa erikorkuisia esineitä useisiin itsenäisiin sarakkeisiin, jolloin saat vaikutelman muuratusta asettelusta:
Tähän kiertotapaan liittyy kuitenkin kaksi rajoitusta:
Kohteiden järjestys eroaa siitä, mikä se olisi todellisessa muurausasettelussa. Flexboxilla kohteet täyttävät ensin ensimmäisen sarakkeen ja kun se on täynnä, siirtyvät seuraavaan sarakkeeseen. Muuraustyössä kohteet pinottaisiin siihen raitaan (tai tässä tapauksessa sarakkeeseen), jossa on enemmän tilaa. Mutta myös, ja mikä ehkä vielä tärkeämpää, tämä kiertotapa edellyttää, että asetat Flexbox-säiliölle kiinteän korkeuden. muuten käärettä ei tapahdu.
Kolmannen osapuolen muurauskirjastot Kehittyneemmissä tapauksissa kehittäjät ovat käyttäneet kirjastoja. Tunnetuin ja suosituin kirjasto tähän on yksinkertaisesti Masonry, ja se ladataan noin 200 000 kertaa viikossa NPM:n mukaan. Squarespace tarjoaa myös asettelukomponentin, joka tekee Masonry-asettelun ilman koodia, ja monet sivustot käyttävät sitä. Molemmat vaihtoehdot käyttävät JavaScript-koodia kohteiden sijoittamiseen asetteluun. Sisäänrakennettu muuraus Olen todella innoissani siitä, että Masonry alkaa nyt näkyä selaimissa sisäänrakennettuna CSS-ominaisuudena. Ajan myötä voit käyttää Masonrya aivan kuten Gridiä tai Flexboxia, eli ilman kiertotapoja tai kolmannen osapuolen koodia. Microsoftin tiimini on ottanut käyttöön sisäänrakennettua Masonry-tukea avoimen lähdekoodin Chromium-projektissa, johon Edge, Chrome ja monet muut selaimet perustuvat. Mozilla oli itse asiassa ensimmäinen selaintoimittaja, joka ehdotti Masonryn kokeellista toteutusta jo vuonna 2020. Apple on myös ollut erittäin kiinnostunut tekemään tästä uudesta web-asettelusta primitiivisen. Myös työ ominaisuuden standardoimiseksi etenee, CSS-työryhmässä on sovittu yleisestä suunnasta ja jopa uudesta näyttötyyppisestä näytöstä: grid-lanes. Jos haluat oppia lisää muurauksesta ja seurata edistymistä, tutustu CSS-muurausresursseihini. Ajan myötä, kun muurauksesta tulee Baseline-ominaisuus, kuten Grid tai Flexbox, voimme yksinkertaisesti käyttää sitä ja hyötyä:
Parempi suorituskyky, Parempi reagointikyky, Helppokäyttöinen ja yksinkertaisempi koodi.
Katsotaanpa näitä tarkemmin. Parempi suorituskyky Oman muurauksen kaltaisen asettelujärjestelmän luominen tai kolmannen osapuolen kirjaston käyttäminen sen sijaan tarkoittaa, että sinun on suoritettava JavaScript-koodi, jotta voit sijoittaa kohteita näytölle. Tämä tarkoittaa myös, että tämä koodi estää renderöinnin. Itse asiassa joko mitään ei näy tai asiat eivät ole oikeissa paikoissa tai oikean kokoisia, ennen kuin JavaScript-koodi on suoritettu. Muurattua ulkoasua käytetään usein web-sivun pääosassa, mikä tarkoittaa, että koodi saa pääsisältösi näkyviin myöhemmin kuin se muuten voisi olla, mikä heikentää LCP- tai Largest Contentful Paint -mittariasi, jolla on suuri merkitys havaittuun suorituskykyyn ja hakukoneoptimointiin. Testasin Masonry JS -kirjastoa yksinkertaisella asettelulla ja simuloimalla hidasta 4G-yhteyttä DevToolsissa. Kirjasto ei ole kovin suuri (24 kt, 7,8 kt gzippattu), mutta sen lataaminen kesti 600 ms testiolosuhteissani. Tässä on suoritustallenne, joka osoittaa, että Masonry-kirjaston pitkä 600 ms latausaika ja että mitään muuta renderöintitoimintoa ei tapahtunut sen tapahtuessa:
Lisäksi ensimmäisen latausajan jälkeen ladattu komentosarja oli jäsennettävä, käännettävä ja suoritettava. Kaikki tämä, kuten aiemmin mainittiin, esti sivun näyttämisen. Kun selaimessa on sisäänrakennettu Masonry-toteutus, meillä ei ole skriptiä ladattavaksi ja suoritettavaksi. Selainmoottori vain tekee tehtävänsä sivun ensimmäisen renderöintivaiheen aikana. Parempi reagointikyky Samoin kuin silloin, kun sivu latautuu ensimmäisen kerran, selainikkunan koon muuttaminen johtaa sivun asettelun hahmontamiseen uudelleen. Tässä vaiheessa, jos sivu kuitenkin käyttää Masonry JS -kirjastoa, komentosarjaa ei tarvitse ladata uudelleen, koska se on jotässä. Koodin, joka siirtää kohteita oikeisiin paikkoihin, on kuitenkin suoritettava. Nyt tämä tietty kirjasto näyttää tekevän tämän melko nopeasti, kun sivu latautuu. Se kuitenkin animoi kohteet, kun ne on siirrettävä toiseen paikkaan ikkunan koon muuttamisen yhteydessä, ja tällä on suuri ero. Käyttäjät eivät tietenkään käytä aikaa selainikkunoidensa koon muuttamiseen niin paljon kuin me kehittäjät. Mutta tämä animoitu koonmuutoskokemus voi olla melko hämmentävä ja lisää aikaa, joka kuluu sivun mukautumiseen uuteen kokoonsa. Helppokäyttöinen ja yksinkertaisempi koodi Se, kuinka helppoa verkkoominaisuuden käyttäminen on ja kuinka yksinkertaiselta koodi näyttää, ovat tärkeitä tekijöitä, joilla voi olla suuri merkitys tiimillesi. Ne eivät tietenkään voi koskaan olla yhtä tärkeitä kuin lopullinen käyttäjäkokemus, mutta kehittäjäkokemus vaikuttaa ylläpidettävyyteen. Sisäänrakennetun verkkoominaisuuden käyttäminen tuo tärkeitä etuja:
HTML:n, CSS:n ja JS:n jo tuntevat kehittäjät voivat todennäköisesti käyttää tätä ominaisuutta helposti, koska se on suunniteltu integroitumaan hyvin ja olemaan yhdenmukainen muun verkkoalustan kanssa. Ei ole vaaraa, että ominaisuuden käyttöön tehdään muutoksia. On lähes nolla riskiä, että tämä ominaisuus tulee vanhentuneeksi tai sitä ei ylläpidetä.
Sisäänrakennetun muurauksen tapauksessa, koska se on asetteluprimitiivi, käytät sitä CSS:stä, aivan kuten Grid tai Flexbox, ei JS:ää. Myös muut asetteluun liittyvät CSS-ominaisuudet, kuten aukko, toimivat odotetusti. Mitään temppuja tai kiertotapoja ei tarvitse tietää, ja oppimasi asiat on dokumentoitu MDN:ssä. Masonry JS lib:ssä alustus on hieman monimutkainen: se vaatii tietomääritteen tietyllä syntaksilla sekä piilotettuja HTML-elementtejä sarakkeiden ja välien koon asettamiseen. Lisäksi, jos haluat kattaa sarakkeita, sinun on sisällytettävä aukon koko itse ongelmien välttämiseksi:
Verrataan tätä siihen, miltä sisäänrakennettu muuraustoteutus näyttäisi:
Yksinkertaisempi, kompaktimpi koodi, joka voi käyttää vain sellaisia asioita, kuten aukko ja jossa raitojen ylittäminen tehdään span 2:lla, aivan kuten ruudukossa, eikä sinun tarvitse laskea oikeaa leveyttä, joka sisältää aukon koon. Mistä tietää, mitä on saatavilla ja milloin se on saatavilla? Kaiken kaikkiaan kysymys ei oikeastaan ole siitä, pitäisikö sinun käyttää sisäänrakennettua Masonryä JS-kirjaston päällä, vaan pikemminkin milloin. Masonry JS -kirjasto on hämmästyttävä ja se on täyttänyt aukon verkkoalustassa useiden vuosien ajan ja monille onnellisille kehittäjille ja käyttäjille. Siinä on tietysti muutamia haittoja, jos vertaat sitä sisäänrakennettuun muuraustoteutukseen, mutta ne eivät ole tärkeitä, jos toteutus ei ole valmis. Minun on helppo luetella näitä upeita uusia verkkoalustan ominaisuuksia, koska työskentelen selaintoimittajalla, ja siksi minulla on tapana tietää, mitä on tulossa. Mutta kehittäjät jakavat usein kysely toisensa jälkeen, että uusien asioiden seuraaminen on vaikeaa. Ajan tasalla pysyminen on vaikeaa, eivätkä yritykset aina aseta oppimista etusijalle. Tässä on muutamia resursseja, jotka tarjoavat päivitykset yksinkertaisilla ja kompakteilla tavoilla, jotta saat tarvitsemasi tiedot nopeasti:
Verkkoalustalla on tutkimussivusto: Saatat olla kiinnostunut sen julkaisutietosivusta. Ja jos pidät RSS:stä, tutustu julkaisutietosyötteeseen sekä Baseline Newly Available- ja Widely Available-syötteisiin.
WebAlustan tilan hallintapaneeli: Saatat pitää sen erilaisista perusvuosisivuista.
Chrome Platform Statusin etenemissuunnitelmasivu.
Jos sinulla on hieman enemmän aikaa, saatat olla kiinnostunut myös selainvalmistajien julkaisutiedoista:
Chrome Edge Firefox Safari
Jos haluat vielä lisää resursseja, tutustu Web-alustan navigointi -cheatsheet -lehteen. Asiaani ei ole vieläkään toteutettu Se on ongelman toinen puoli. Vaikka löytäisitkin aikaa, energiaa ja tapoja seurata tilannetta, on silti turhauttavaa saada äänesi kuuluviin ja suosikkitoimintosi käyttöön. Ehkä olet odottanut vuosia tietyn virheen ratkaisemista tai tietyn ominaisuuden toimittamista selaimeen, josta se vielä puuttuu. Sanon, että selaintoimittajat kuuntelevat. Olen osa useiden organisaatioiden välisiä tiimejä, joissa keskustelemme kehittäjien signaaleista ja palautteesta koko ajan. Tarkastelemme monia erilaisia palautelähteitä, sekä sisäisiä kunkin selaimen toimittajan että ulkoisia/julkisia foorumeilla, avoimen lähdekoodin projekteissa, blogeissa ja kyselyissä. Ja yritämme aina luoda parempia tapoja, joilla kehittäjät voivat jakaa erityistarpeensa ja käyttötapauksensa. Joten jos voit, pyydä enemmän selainvalmistajilta ja painosta meitä toteuttamaan tarvitsemasi ominaisuudet. Ymmärrän, että se vie aikaa ja voi myös olla pelottavaa (puhumattakaan korkeasta pääsyn esteestä), mutta se myös toimii. Tässä on muutamia tapoja saada oma (tai yrityksesi) äänesi kuuluviin: Osallistu vuotuisiin JS-, CSS- ja HTML-tilakyselyihin. Niillä on suuri rooli siinä, kuinka selaintoimittajat priorisoivat työnsä. Jos tarvitset tietyn standardipohjaisen sovellusliittymän, joka on otettava käyttöön johdonmukaisesti kaikissa selaimissa, harkitse ehdotuksen lähettämistä seuraavassa Interop-projektin iteraatiossa. Se vaatii enemmän aikaa, mutta harkitse, kuinka Shopify ja RUMvision jakoivat Interop 2026:n toivelistansa. Tämän kaltaiset yksityiskohtaiset tiedot voivat olla erittäin hyödyllisiä selaintoimittajille priorisoitaessa. Jos haluat lisää hyödyllisiä linkkejä selaimen toimittajiin vaikuttamiseen, katso Web-alustan navigointi -cheatsheet. Johtopäätös Lopuksi toivon, että tämä artikkeli on jättänyt sinulle muutaman pohdittavaa:
Jännitystä muurauksesta ja muista tulevista verkkoominaisuuksista. Muutamia verkkoominaisuuksia, joita haluat ehkä alkaa käyttää. Muutamia mukautetun tai kolmannen osapuolen koodin osia, jotka saatat pystyä poistamaan sisäänrakennettujen ominaisuuksien hyväksi. Muutamia tapoja seurata tulevaa ja vaikuttaa selainvalmistajiin.
Mikä tärkeintä, toivon, että olen vakuuttanut sinut verkkoalustan täyden potentiaalin käytön eduista.
