Prije otprilike 15 godina radio sam u kompaniji u kojoj smo pravili aplikacije za putničke agencije, aerodromske radnike i avio kompanije. Također smo izgradili vlastiti okvir za UI komponente i mogućnosti aplikacije za jednu stranicu. Imali smo komponente za sve: polja, dugmad, kartice, opsege, tabele podataka, menije, birače datuma, odabire i višestruke izbore. Čak smo imali i div komponentu. Usput, naša div komponenta je bila sjajna, omogućila nam je da napravimo zaobljene uglove na svim pretraživačima, što, vjerovali ili ne, nije bila laka stvar u to vrijeme.
Naš rad se odvijao u trenutku naše istorije kada su JS, Ajax i dinamički HTML viđeni kao revolucija koja nas je dovela u budućnost. Odjednom smo mogli dinamički ažurirati stranicu, dobiti podatke sa servera i izbjeći potrebu za navigacijom do drugih stranica, što se smatralo sporim i bljeskalo je velikim bijelim pravougaonikom na ekranu između dvije stranice. Postojala je fraza koju je popularizirao Jeff Atwood (osnivač StackOverflowa), a koja glasi: „Svaka aplikacija koja se može napisati u JavaScript-u će na kraju biti napisana u JavaScript-u.”— Jeff Atwood
Za nas je u to vrijeme ovo izgledalo kao usuđivanje da krenemo i kreiramo te aplikacije. Osjećao sam se kao opšte odobrenje da se sve radi sa JS-om. Dakle, sve smo radili sa JS-om i nismo baš odvojili vrijeme da istražimo druge načine za obavljanje stvari. Nismo baš osjećali poticaj da pravilno naučimo šta HTML i CSS mogu učiniti. Nismo zapravo percipirali web kao platformu aplikacija koja se razvija u cijelosti. Uglavnom smo to doživljavali kao nešto što moramo zaobići, posebno kada je u pitanju podrška pretraživača. Mogli bismo samo baciti više JS-a na to da stvari završimo. Da li bi mi pomoglo odvajanje vremena da saznam više o tome kako web radi i šta je bilo dostupno na platformi? Naravno, vjerovatno sam mogao obrijati gomilu koda koji nije bio zaista potreban. Ali, u to vrijeme, možda i ne toliko. Vidite, razlike u pretraživačima su tada bile prilično značajne. Ovo je bilo vrijeme kada je Internet Explorer još uvijek bio dominantan pretraživač, a Firefox je bio blizu drugog, ali je počeo gubiti tržišni udio zbog Chromea koji je brzo sticao popularnost. Iako su Chrome i Firefox bili prilično dobri u dogovoru oko web standarda, okruženja u kojima su naše aplikacije radile značile su da smo morali dugo vremena podržavati IE6. Čak i kada nam je bilo dozvoljeno da podržavamo IE8, i dalje smo morali da se nosimo sa mnogo razlika između pretraživača. I ne samo to, već tadašnji web jednostavno nije imao toliko mogućnosti ugrađenih u platformu.
Brzo naprijed do danas. Stvari su se strašno promijenile. Ne samo da imamo više ovih mogućnosti nego ikad prije, već se povećala i stopa po kojoj one postaju dostupne. Dozvolite mi da ponovo postavim pitanje: da li bi vam danas pomoglo odvajanje vremena da saznate više o tome kako veb funkcioniše i šta je dostupno na platformi? Apsolutno da. Učenje da razumete i koristite web platformu danas vas stavlja u ogromnu prednost u odnosu na druge programere. Bilo da radite na performansama, pristupačnosti, brzom odzivu, sve zajedno, ili samo isporučujete karakteristike korisničkog sučelja, ako to želite učiniti kao odgovoran inženjer, poznavanje alata koji su vam dostupni pomoći će vam da brže i bolje postignete svoje ciljeve. Neke stvari za koje vam možda više neće trebati biblioteka Znajući šta pretraživači podržavaju danas, postavlja se pitanje: Čega možemo odbaciti? Da li nam je potrebna div komponenta za zaobljene uglove 2025. godine? Naravno, ne radimo. Svojstvo radijusa granice podržavaju svi trenutno korišćeni pretraživači više od 15 godina u ovom trenutku. Uskoro dolazi i oblik uglova, za još elegantnije uglove. Pogledajmo relativno novije funkcije koje su sada dostupne u svim glavnim pretraživačima i koje možete koristiti da zamijenite postojeće ovisnosti u vašoj bazi kodova. Poenta nije u tome da odmah odbacite sve svoje omiljene biblioteke i prepišete svoju bazu kodova. Što se tiče svega ostalog, prvo ćete morati uzeti u obzir podršku preglednika i odlučiti na osnovu drugih faktora specifičnih za vaš projekat. Sljedeće funkcije su implementirane u tri glavna mehanizma pretraživača (Chromium, WebKit i Gecko), ali možda imate različite zahtjeve za podršku pretraživača koji vas sprečavaju da ih odmah koristite. Ipak, sada je još uvijek dobro vrijeme da naučite o ovim funkcijama i možda ih planirate koristiti u nekom trenutku. Popovers i dijalozi Popover API, HTML element
Naravno, vjerovatno se povećala i brzina vaše internetske veze, ali to nije slučaj sa svima. A nemaju svi iste mogućnosti uređaja. Umjesto toga, uvođenje koda treće strane za stvari koje možete raditi s platformom, najvjerovatnije znači da šaljete više koda i samim tim dolazite do manjeg broja kupaca nego što biste inače. Na webu, loš učinak učitavanja dovodi do velikih stopa napuštanja i šteti reputaciji brenda. Pokretanje manje koda na uređajima Nadalje, kod koji šaljete na uređaje svojih kupaca vjerovatno radi brže ako koristi manje JavaScript apstrakcija na vrhu platforme. Također je vjerovatno osjetljiviji i pristupačniji prema zadanim postavkama. Sve to dovodi do više i sretnijih kupaca. Provjerite godišnji blog o nejednakosti u performansama mog kolege Alexa Russella, koji pokazuje da su premium uređaji uglavnom odsutni na tržištima s milijardama korisnika zbog nejednakosti u bogatstvu. A ovaj jaz vremenom samo raste.
Ugrađeni zidni raspored Jedna od karakteristika web platforme koja dolazi uskoro i zbog koje sam veoma uzbuđen je CSS Masonry.
Dozvolite mi da počnem objašnjavajući šta je masonerija. Šta je zidanje Zidanje je vrsta rasporeda koju je Pinterest učinio popularnim prije mnogo godina. Stvara nezavisne staze sadržaja unutar kojih se stavke pakuju što bliže početku staze.
Mnogi ljudi vide Masonry kao odličnu opciju za portfelje i foto galerije, što svakako može učiniti. Ali Masonry je fleksibilniji od onoga što vidite na Pinterestu i nije ograničen samo na rasporede poput vodopada. U zidanom rasporedu:
Tragovi mogu biti stupci ili redovi:
Tragovi sadržaja ne moraju svi biti iste veličine:
Stavke mogu obuhvatati više staza:
Stavke se mogu postaviti na određene staze; ne moraju uvijek slijediti algoritam automatskog postavljanja:
Demos Evo nekoliko jednostavnih demonstracija koje sam napravio koristeći nadolazeću implementaciju CSS Masonry u Chromiumu. Demo galerije fotografija, koji pokazuje kako stavke (naslov u ovom slučaju) mogu obuhvatiti više pjesama:
Još jedna galerija fotografija koja prikazuje staze različitih veličina:
Izgled web-mjesta s vijestima s nekim stazama širim od drugih, a neke stavke pokrivaju cijelu širinu izgleda:
Kanban tabla koja pokazuje da se stavke mogu postaviti na određene staze:
Napomena: ThePrethodne demonstracije su napravljene s verzijom Chromiuma koja još uvijek nije dostupna većini web korisnika, jer CSS Masonry tek počinje da se implementira u pretraživače. Međutim, web programeri već godinama sa zadovoljstvom koriste biblioteke za kreiranje Masonry izgleda. Lokacije koje danas koriste zidanje Zaista, masonerija je danas prilično uobičajena na webu. Evo nekoliko primjera koje sam pronašao pored Pinteresta:
I još nekoliko, manje očiglednih primjera:
Dakle, kako su nastali ovi izgledi? Zaobilazna rješenja Jedan trik koji sam vidio da se koristi je korištenje Flexbox izgleda umjesto toga, mijenjanje njegovog smjera u stupac i postavljanje na premotavanje. Na ovaj način možete postaviti predmete različite visine u više, nezavisnih stupaca, dajući dojam zidanog izgleda:
Postoje, međutim, dva ograničenja s ovim rješenjem:
Redoslijed stavki je drugačiji od onoga što bi bio sa pravim zidarskim rasporedom. Sa Flexboxom, stavke prvo popunjavaju prvu kolonu i, kada je puna, zatim idu u sljedeću kolonu. Uz Masonry, stavke bi se slagale u bilo kojoj stazi (ili koloni u ovom slučaju) ima više slobodnog prostora. Ali takođe, i što je možda još važnije, ovo rešenje zahteva da postavite fiksnu visinu za Flexbox kontejner; u suprotnom ne bi došlo do umotavanja.
Masonry biblioteke trećih strana Za naprednije slučajeve, programeri su koristili biblioteke. Najpoznatija i najpopularnija biblioteka za ovo jednostavno se zove Masonry, a prema NPM-u se preuzima oko 200.000 puta sedmično. Squarespace takođe obezbeđuje komponentu rasporeda koja prikazuje Masonry raspored, kao alternativu bez koda, i mnoge lokacije je koriste. Obje ove opcije koriste JavaScript kod za postavljanje stavki u izgled. Ugrađeno zidanje Zaista sam uzbuđen što se Masonry sada počinje pojavljivati u pretraživačima kao ugrađena CSS funkcija. S vremenom ćete moći koristiti Masonry baš kao i Grid ili Flexbox, to jest, bez potrebe za zaobilaznim rješenjem ili kodom treće strane. Moj tim u Microsoftu implementirao je ugrađenu Masonry podršku u Chromium open source projekat, na kojem su Edge, Chrome i mnogi drugi pretraživači zasnovani. Mozilla je zapravo bila prvi dobavljač pretraživača koji je predložio eksperimentalnu implementaciju Masonryja još 2020. godine. A Apple je također bio vrlo zainteresiran da ovaj novi web izgled bude primitivan. Rad na standardizaciji ove karakteristike takođe napreduje, uz dogovor unutar CSS radne grupe o opštem pravcu, pa čak i o novom tipu prikaza: mrežne trake. Ako želite saznati više o Masonryju i pratiti napredak, pogledajte moju stranicu sa CSS Masonry resursima. S vremenom, kada Masonry postane osnovna značajka, baš kao Grid ili Flexbox, moći ćemo je jednostavno koristiti i imati koristi od:
bolje performanse, Bolja odzivnost, Jednostavna upotreba i jednostavniji kod.
Hajde da ih pobliže pogledamo. Bolje performanse Izrada vlastitog sistema rasporeda nalik na masoneriju ili korištenje biblioteke treće strane, znači da ćete morati pokrenuti JavaScript kod da biste postavili stavke na ekran. To također znači da će ovaj kod biti blokiran za renderiranje. Zaista, ili se ništa neće pojaviti, ili stvari neće biti na pravim mjestima ili prave veličine, dok se taj JavaScript kod ne pokrene. Zidani izgled se često koristi za glavni dio web stranice, što znači da bi kod učinio da se vaš glavni sadržaj pojavi kasnije nego što bi inače mogao imati, degradirajući vaš LCP, ili metriku Najveći sadržaj boje, koji igra veliku ulogu u percipiranim performansama i optimizaciji tražilice. Testirao sam Masonry JS biblioteku sa jednostavnim izgledom i simulacijom spore 4G veze u DevTools. Biblioteka nije velika (24 KB, 7,8 KB gzipirano), ali je trebalo 600 ms da se učita pod mojim testnim uslovima. Evo snimka performansi koji pokazuje dugo 600ms vrijeme učitavanja za Masonry biblioteku i da se nije dogodila nikakva druga aktivnost renderiranja dok se to dešavalo:
Osim toga, nakon početnog vremena učitavanja, preuzetu skriptu je tada trebalo raščlaniti, kompajlirati i zatim pokrenuti. Sve je to, kao što je već spomenuto, blokiralo prikazivanje stranice. Uz ugrađenu Masonry implementaciju u pretraživaču, nećemo imati skriptu za učitavanje i pokretanje. Motor pretraživača će samo učiniti svoje tokom početnog koraka renderiranja stranice. Better Responsiveness Slično kao kada se stranica prvi put učita, promjena veličine prozora pretraživača dovodi do ponovnog prikazivanja izgleda na toj stranici. Međutim, u ovom trenutku, ako stranica koristi biblioteku Masonry JS, nema potrebe da ponovo učitavate skriptu, jer je većovdje. Međutim, kod koji premješta stavke na prava mjesta mora se pokrenuti. Sada se čini da je ova konkretna biblioteka prilično brza u tome kada se stranica učita. Međutim, on animira stavke kada se moraju premjestiti na drugo mjesto pri promjeni veličine prozora, i to čini veliku razliku. Naravno, korisnici ne troše vrijeme na promjenu veličine prozora preglednika koliko mi programeri. Ali ovo iskustvo animirane promjene veličine može biti prilično uznemirujuće i povećava uočeno vrijeme koje je potrebno stranici da se prilagodi novoj veličini. Jednostavna upotreba i jednostavniji kod Koliko je jednostavno koristiti web funkciju i koliko jednostavno izgleda kod važni su faktori koji mogu napraviti veliku razliku za vaš tim. Oni, naravno, nikada ne mogu biti toliko važni kao konačno korisničko iskustvo, ali iskustvo programera utječe na održavanje. Upotreba ugrađene web funkcije donosi važne prednosti na tom planu:
Programeri koji već poznaju HTML, CSS i JS će najvjerovatnije moći lako da koriste tu funkciju jer je dizajnirana da se dobro integriše i bude u skladu s ostatkom web platforme. Ne postoji rizik od uvođenja promjena u načinu na koji se ova funkcija koristi. Gotovo je nula rizika da ta funkcija postane zastarjela ili neodržavana.
U slučaju ugrađenog Masonryja, pošto je to primitivan raspored, koristite ga iz CSS-a, baš kao Grid ili Flexbox, bez JS-a. Također, druga svojstva CSS-a vezana za izgled, kao što je gap, rade onako kako biste očekivali. Ne postoje trikovi ili zaobilazna rješenja o kojima treba znati, a stvari koje naučite dokumentirane su na MDN-u. Za Masonry JS lib, inicijalizacija je malo složena: zahtijeva atribut podataka sa specifičnom sintaksom, zajedno sa skrivenim HTML elementima za postavljanje veličina stupaca i praznina. Osim toga, ako želite obuhvatiti stupce, morate sami uključiti veličinu praznine kako biste izbjegli probleme:
Uporedimo ovo s tim kako bi izgledala ugrađena Masonry implementacija:
Jednostavniji, kompaktniji kod koji može koristiti samo stvari kao što je razmak i gdje se razmaknute staze obavljaju s rasponom 2, baš kao u mreži, i ne zahtijeva od vas da izračunate pravu širinu koja uključuje veličinu praznine. Kako znati šta je dostupno i kada je dostupno? Sve u svemu, pitanje zapravo nije treba li koristiti ugrađeni Masonry preko JS biblioteke, već kada. Biblioteka Masonry JS je nevjerovatna i već dugi niz godina popunjava prazninu na web platformi i za mnoge zadovoljne programere i korisnike. Ima nekoliko nedostataka ako ga uporedite sa ugrađenom Masonry implementacijom, naravno, ali oni nisu važni ako ta implementacija nije spremna. Lako mi je da navedem ove sjajne nove karakteristike web platforme jer radim kod dobavljača pretraživača i stoga sam sklon da znam šta dolazi. Ali programeri često dijele, anketu za anketom, da je teško pratiti nove stvari. Ostati informisan je teško, a kompanije ionako ne daju uvijek prioritet učenju. Da biste pomogli u tome, evo nekoliko resursa koji pružaju ažuriranja na jednostavne i kompaktne načine kako biste brzo dobili informacije koje su vam potrebne:
Web platforma sadrži istraživačku stranicu: Možda će vas zanimati stranica s napomenama o izdanju. I, ako volite RSS, pogledajte feed napomena o izdanju, kao i Baseline Newly Available i Widely Available feedove.
WebKontrolna tabla statusa platforme: Možda će vam se svidjeti različite stranice osnovne godine.
Stranica mape puta statusa Chrome platforme.
Ako imate malo više vremena, možda će vas zanimati i napomene o izdanju dobavljača pretraživača:
Chrome Edge Firefox Safari
Za još više resursa, pogledajte moj Cheatsheet Navigacija po web platformi. Moja stvar još uvijek nije implementirana To je druga strana problema. Čak i ako nađete vremena, energije i načina da pratite, još uvijek postoji frustracija da se vaš glas čuje i vaše omiljene funkcije implementiraju. Možda ste godinama čekali da se riješi određena greška ili da se određena funkcija isporuči u pregledniku gdje još uvijek nedostaje. Ono što ću reći je da prodavci pretraživača slušaju. Ja sam dio nekoliko međuorganizacijskih timova u kojima stalno razgovaramo o signalima i povratnim informacijama programera. Gledamo na mnogo različitih izvora povratnih informacija, kako internih kod svakog dobavljača pretraživača, tako i eksternih/javnih na forumima, projektima otvorenog koda, blogovima i anketama. I uvijek pokušavamo stvoriti bolje načine za programere da podijele svoje specifične potrebe i slučajeve upotrebe. Stoga, ako možete, zatražite više od dobavljača pretraživača i izvršite pritisak na nas da implementiramo funkcije koje su vam potrebne. Shvaćam da je za to potrebno vrijeme, a može biti i zastrašujuće (da ne spominjemo visoku barijeru za ulazak), ali također funkcionira. Evo nekoliko načina na koje možete dobiti glas (ili vaše kompanije): Uzmite godišnje ankete State of JS, State of CSS i State of HTML. Oni igraju veliku ulogu u tome kako dobavljači pretraživača daju prioritet svom radu. Ako vam je potreban određeni API baziran na standardu koji će se dosljedno implementirati u svim pretraživačima, razmislite o podnošenju prijedloga na sljedećoj iteraciji projekta Interop. Za to je potrebno više vremena, ali razmislite o tome kako su Shopify i RUMvision podijelili svoje liste želja za Interop 2026. Detaljne informacije poput ove mogu biti vrlo korisne za dobavljače pretraživača da daju prioritet. Za više korisnih linkova za uticaj na dobavljače pretraživača, pogledajte moj Cheatsheet Navigacija po web platformi. Zaključak Za kraj, nadam se da vas je ovaj članak ostavio na nekoliko stvari o kojima treba razmišljati:
Uzbuđenje za Masonry i druge nadolazeće web funkcije. Nekoliko web funkcija koje biste možda željeli početi koristiti. Nekoliko komada prilagođenog koda ili koda treće strane koje ćete možda moći ukloniti u korist ugrađenih funkcija. Nekoliko načina da pratite šta dolazi i utičete na dobavljače pretraživača.
Što je još važnije, nadam se da sam vas uvjerio u prednosti korištenja web platforme do njenog punog potencijala.
