Duela 15 bat urte, bidaia-agenteentzat, aireportuetako langileentzat eta aire-konpainientzat aplikazioak eraiki genituen enpresa batean lan egiten nuen. Gainera, gure barneko markoa eraiki dugu UI osagaietarako eta orri bakarreko aplikazioen gaitasunetarako. Denetarako osagaiak genituen: eremuak, botoiak, fitxak, barrutiak, datu-taulak, menuak, data-hautatzaileak, hautaketak eta aukeraketa anitzak. Div osagai bat ere izan genuen. Gure div osagaia bikaina zen bide batez, nabigatzaile guztietan ertz biribilak egiteko aukera ematen zigun, eta hori, sinetsi ala ez, ez zen gauza erraza garai hartan.
Gure lana gure historiako une batean gertatu zen, JS, Ajax eta HTML dinamikoa etorkizunera eraman gintuen iraultza gisa ikusi zirenean. Bat-batean, orri bat dinamikoki eguneratu genezake, zerbitzari batetik datuak eskuratu eta beste orri batzuetara nabigatu beharrik saihestu, motel ikusten zen eta bi orrialdeen artean laukizuzen zuri handi bat keinu egiten zuen pantailan. Jeff Atwood-ek (StackOverflow-en sortzaileak) ezagun egin zuen esaldi bat zegoen: "JavaScript-en idatzi daitekeen edozein aplikazio azkenean JavaScript-en idatziko da." - Jeff Atwood
Garai hartan, aplikazio horiek sortzeko ausardia iruditu zitzaigun. JS-rekin dena egiteko onarpen orokor bat bezala sentitu zen. Beraz, dena egin genuen JSrekin, eta ez genuen denborarik hartu gauzak egiteko beste modu batzuk ikertzeko. Ez genuen benetan pizgarririk sentitu HTML eta CSS zer egin dezaketen behar bezala ikasteko. Ez genuen weba bere osotasunean eboluzionatzen ari den aplikazio-plataforma gisa hautematen. Gehienetan landu behar genuen zerbait bezala ikusi genuen, batez ere arakatzailearen laguntzari dagokionez. JS gehiago bota genitzake gauzak egiteko. Webak nola funtzionatzen zuen eta plataforman erabilgarri zegoenari buruz gehiago jakiteko denbora hartzeak balio izan al dit? Noski, ziurrenik behar ez zen kode mordo bat moztu nezakeen. Baina, garai hartan, agian ez hainbeste. Ikusten duzu, arakatzaileen desberdintasunak nahiko nabarmenak ziren orduan. Garai hau Internet Explorer nabigatzaile nagusi zen oraindik, Firefox izan zen gertuko bigarrena, baina merkatu-kuota galtzen hasi zen Chrome-k ospea azkar irabazten zuelako. Nahiz eta Chrome eta Firefox nahiko onak izan web-estandarrak adosten, gure aplikazioak exekutatzen ari ziren inguruneek IE6 onartzen behar izan genuen denbora luzez. IE8 onartzen zigutenean ere, nabigatzaileen arteko desberdintasun askori aurre egin behar izan genion. Hori ez ezik, garai hartako sareak ez zuen horrenbeste gaitasun eraikita plataforman.
Azkar aurrera gaur arte. Gauzak izugarri aldatu dira. Inoiz baino gaitasun horietariko gehiago ditugu ez ezik, erabilgarri dauden tasa ere handitu egin da. Utzidazu berriro galdera egiten, orduan: lagungarri al zaizu gaur egun sareak nola funtzionatzen duen eta plataforman eskuragarri dagoenari buruz gehiago jakiteko denbora hartzea? Erabat bai. Gaur egun web plataforma ulertzen eta erabiltzen ikasteak abantaila handia ematen dizu beste garatzaileen aldean. Errendimenduan, irisgarritasunan, erantzunkizunean lan egiten baduzu, denak batera, edo UI funtzioak bidaltzen badituzu, ingeniari arduratsu gisa egin nahi baduzu, eskura dituzun tresnak ezagutzeak zure helburuak azkarrago eta hobeto lortzen lagunduko dizu. Liburutegirik behar ez dituzun gauza batzuk Gaur egun nabigatzaileek zer onartzen duten jakinda, galdera hau da: Zer baztertu dezakegu? Div osagai bat behar al dugu 2025ean izkin biribilak egiteko? Noski, ez dugu. Border-radius propietatea gaur egun erabiltzen diren arakatzaile guztiek onartzen dute 15 urte baino gehiago une honetan. Eta izkina-forma ere laster etorriko da, txoko dotoreagoetarako. Ikus ditzagun orain arakatzaile nagusi guztietan eskuragarri dauden funtzio berri samarrak eta zure kode-basean dauden mendekotasunak ordezkatzeko erabil ditzakezunak. Kontua ez da zure liburutegi maite guztiak berehala baztertzea eta zure kode-basea berridaztea. Gainerako guztiari dagokionez, lehenik arakatzailearen laguntza kontuan hartu beharko duzu eta zure proiektuaren beste faktore batzuen arabera erabaki. Ezaugarri hauek hiru arakatzaile nagusietan (Chromium, WebKit eta Gecko) ezartzen dira, baina baliteke arakatzailearen laguntza-eskakizun desberdinak izatea, horiek berehala erabiltzea eragozten dizutenak. Orain oraindik une egokia da ezaugarri hauek ezagutzeko, eta, agian, noizbait erabiltzeko asmoa. Popovers Eta Elkarrizketak Popover APIak,
Noski, zure Interneteko konexioaren abiadura ere handitu egin da ziurrenik, baina hori ez da guztion kasua. Eta denek ere ez dituzte gailuen gaitasun berdinak. Plataformarekin egin ditzakezun gauzetarako hirugarrenen kodea sartzeak, horren ordez, ziurrenik, kode gehiago bidaltzen dituzula esan nahi du, eta, beraz, normalean baino bezero gutxiagorengana iristen zara. Sarean, kargatze-errendimendu txarrak abandonu tasa handiak eragiten ditu eta markaren ospea kaltetzen du. Kode gutxiago exekutatzen gailuetan Gainera, zure bezeroen gailuetan bidaltzen duzun kodea azkarrago exekutatzen da litekeena da plataformaren gainean JavaScript abstrakzio gutxiago erabiltzen baditu. Era berean, ziurrenik, erantzun handiagoa eta eskuragarriagoa izango da lehenespenez. Horrek guztiak bezero gehiago eta zoriontsuagoak dakartza. Begiratu nire lankide Alex Russell-en urteroko errendimendu-desberdintasunen hutsunearen bloga, eta horrek erakusten du premium gailuak aberastasunaren desberdintasunaren ondorioz milaka milioi erabiltzaile dituzten merkatuetatik kanpo daudela. Eta hutsune hori denborarekin hazten ari da.
Harlanduzko Diseinua Laster etorriko den eta oso hunkituta nagoen web plataformaren funtzio bat CSS Masonry da.
Hasteko, Igeltseroria zer den azaltzen. Zer da Igeltseroria Igeltserotza duela urte Pinterest-ek ezagun egin zuen diseinu mota bat da. Edukien pista independenteak sortzen ditu, eta elementuak pistaren hasieratik ahalik eta hurbilen biltzen dira.
Jende askok Igeltseroria portafolioetarako eta argazki galerietarako aukera bikaina dela ikusten du, eta hori egin dezake. Baina Masonry Pinterest-en ikusten duzuna baino malguagoa da, eta ez da ur-jauziaren antzeko diseinuetara mugatzen. Harlanduzko diseinuan:
Pistak zutabeak edo errenkadak izan daitezke:
Edukiaren ibilbideak ez du zertan tamaina berdina izan:
Elementuek hainbat pista izan ditzakete:
Elementuak pista zehatzetan jar daitezke; ez dute beti kokapen automatikoaren algoritmoa jarraitu beharrik:
Demoak Hona hemen Chromium-en CSS Masonry-ren hurrengo inplementazioa erabiliz egin ditudan demo sinple batzuk. Argazki-galeriaren demo bat, elementuek (kasu honetan izenburua) hainbat pistak nola zabal ditzaketen erakusten duena:
Tamaina ezberdinetako ibilbideak erakusten dituen beste argazki galeria bat:
Albiste-gunearen diseinua, pista batzuk besteak baino zabalagoak dituena, eta elementu batzuk diseinuaren zabalera osoan zehar:
Elementuak pista zehatzetan jar daitezkeela erakusten duen kanban taula:
Oharra: Theaurreko demoak web-erabiltzaile gehienentzat oraindik eskuragarri ez dagoen Chromium bertsio batekin egin ziren, CSS Masonry arakatzaileetan ezartzen hasi besterik ez delako. Hala eta guztiz ere, web garatzaileek jadanik urteak daramatzate liburutegiak pozik erabiltzen Masonry diseinuak sortzeko. Gaur egun harlandua erabiltzen duten guneak Izan ere, Igeltseroria nahiko ohikoa da sarean gaur egun. Hona hemen Pinterestez gain aurkitu ditudan adibide batzuk:
Eta beste adibide batzuk, ez hain agerikoak:
Beraz, nola sortu ziren diseinu horiek? Konponbideak Erabili ikusi dudan trikimailu bat Flexbox diseinua erabiltzea da, bere norabidea zutabera aldatzea eta biltzeko ezartzea. Horrela, altuera ezberdineko elementuak hainbat zutabe independentetan jar ditzakezu, Harlanduaren diseinuaren inpresioa emanez:
Hala ere, konponbide honek bi muga ditu:
Elementuen ordena benetako Harlanduzko diseinuarekin izango litzatekeenaren desberdina da. Flexbox-ekin, elementuek lehenengo zutabea betetzen dute eta, beteta dagoenean, hurrengo zutabera joan. Masonry-rekin, elementuak pilatuko lirateke leku gehiago dagoen pistan (edo zutabean, kasu honetan). Baina, gainera, eta agian garrantzitsuagoa dena, konponbide honek Flexbox edukiontziari altuera finko bat ezartzea eskatzen du; bestela, ez litzateke bilgarririk gertatuko.
Hirugarrenen Igeltserotzako Liburutegiak Kasu aurreratuagoetarako, garatzaileek liburutegiak erabili dituzte. Horretarako liburutegirik ezagunena eta ezagunena Masonry deitzen da, eta astean 200.000 aldiz deskargatzen da NPMren arabera. Squarespace-k Masonry diseinua errendatzen duen diseinu-osagai bat ere eskaintzen du, koderik gabeko alternatiba baterako, eta gune askok erabiltzen dute. Bi aukera hauek JavaScript kodea erabiltzen dute diseinuan elementuak jartzeko. Eraikitako harlandua Oso hunkituta nago Masonry arakatzaileetan CSS funtzio integratua bezala agertzen hasten ari delako. Denborarekin, Masonry Grid edo Flexbox egiten duzun bezala erabili ahal izango duzu, hau da, konponbiderik edo hirugarrenen koderik behar izan gabe. Microsoft-eko nire taldeak Masonry euskarria inplementatzen ari da Chromium kode irekiko proiektuan, zeinetan oinarritzen diren Edge, Chrome eta beste hainbat arakatzailetan. Mozilla izan zen 2020an Masonry-ren inplementazio esperimentala proposatu zuen lehen arakatzaile-saltzailea. Eta Apple-k ere oso interesatuta egon da web-diseinu berri hau primitibo bihurtzeko. Funtzioa estandarizatzeko lana ere aurrera doa, CSS lantaldearen barnean norabide orokorrari buruz eta baita pantaila motako pantaila berri bat ere: grid-lanes. Igeltserotzari buruz gehiago jakin nahi baduzu eta aurrerapenaren jarraipena egin nahi baduzu, begiratu nire CSS Masonry baliabideen orria. Denborarekin, Masonry oinarrizko funtzioa bihurtzen denean, Grid edo Flexbox bezala, besterik gabe erabili ahal izango dugu eta aprobetxatu:
Errendimendu hobea, Erantzun hobea, Erabiltzeko erraztasuna eta kode sinpleagoa.
Ikus ditzagun hauei hurbilagotik. Errendimendu hobea Zure Masonry itxurako diseinu-sistema egiteak edo hirugarrenen liburutegi bat erabiltzeak esan nahi du JavaScript kodea exekutatu beharko duzula elementuak pantailan jartzeko. Horrek esan nahi du kode hau errendatzeko blokeoa izango dela. Izan ere, edo ezer ez da agertuko, edo gauzak ez dira leku egokietan edo tamaina egokietan egongo, JavaScript kode hori exekutatu arte. Harlanduaren diseinua sarritan erabiltzen da web-orri baten zati nagusirako, eta horrek esan nahi du kodeak zure eduki nagusia bestela izan lezakeena baino beranduago agertuko litzatekeela, zure LCP edo Greatest Contentful Paint metrika degradatuz, hautematen den errendimenduan eta bilatzaileen optimizazioan zeresan handia duena. Masonry JS liburutegia diseinu sinple batekin probatu nuen eta DevTools-en 4G konexio motela simulatuz. Liburutegia ez da oso handia (24KB, 7.8KB gzipped), baina 600 ms behar izan zituen nire proba baldintzetan kargatzeko. Hona hemen Masonry liburutegiaren 600 ms-ko karga-denbora luze hori eta hori gertatzen ari zen bitartean beste errendatze-jarduerarik gertatu ez dela erakusten duen errendimendu-grabaketa bat:
Gainera, hasierako karga-denbora igaro ondoren, deskargatutako script-a analizatu, konpilatu eta exekutatu behar zen. Horrek guztiak, lehen esan bezala, orriaren errendatzea blokeatzen zuen. Arakatzailean Masonry inplementazio integratua izanik, ez dugu kargatu eta exekutatzeko scriptik izango. Arakatzaile-motorrak bere lana egingo du hasierako orrialdea errendatzeko urratsean. Erantzunbide hobea Orrialde bat lehen aldiz kargatzen denean bezala, arakatzailearen leihoaren tamaina aldatzeak orri horretan diseinua berriro errendatzera eramaten du. Une honetan, ordea, orria Masonry JS liburutegia erabiltzen ari bada, ez dago scripta berriro kargatu beharrik, dagoeneko baitago.hemen. Hala ere, elementuak leku egokietara mugitzen dituen kodea exekutatu behar da. Orain liburutegi jakin hau nahiko azkarra dela dirudi orria kargatzen denean. Hala ere, elementuak animatzen ditu leihoaren tamaina aldatzean beste leku batera eraman behar direnean, eta horrek alde handia egiten du. Jakina, erabiltzaileek ez dute denborarik pasatzen arakatzailearen leihoak dimentsionatzen garatzaileek bezainbeste. Baina animaziozko tamaina aldatzeko esperientzia hau nahiko ikaragarria izan daiteke eta orrialdeak bere tamaina berrira egokitzeko behar duen denbora gehitzen du. Erabiltzeko erraztasuna eta kode sinpleagoa Web-eginbide bat erabiltzea zein erraza den eta kodea zein itxura sinplea den zure taldearentzat diferentzia handia izan dezaketen faktore garrantzitsuak dira. Ezin dira inoiz erabiltzailearen azken esperientzia bezain garrantzitsuak izan, noski, baina garatzaileen esperientziak mantentzen du eragina. Web-eginbide integratua erabiltzeak abantaila garrantzitsuak ditu alde horretatik:
Dagoeneko HTML, CSS eta JS ezagutzen duten garatzaileek, ziurrenik, funtzio hori erraz erabili ahal izango dute, ondo integratzeko eta gainerako web plataformarekin koherentea izateko diseinatuta dagoelako. Ez dago funtzioaren erabileran aldaketak hausteko arriskurik. Ez dago ia arriskurik funtzio hori zaharkitu edo mantentzen ez izateko.
Eraikitako Masonry-ren kasuan, diseinu primitiboa denez, CSStik erabiltzen duzu, Grid edo Flexbox bezala, ez dago JSrik. Gainera, diseinuarekin erlazionatutako beste CSS propietate batzuk, hala nola, hutsunea, espero zenituzkeen moduan funtzionatzen dute. Ez dago jakin beharreko trikimailurik edo konponbiderik, eta ikasten dituzun gauzak MDNn dokumentatuta daude. Masonry JS libarentzat, hasieratzea pixka bat konplexua da: sintaxi zehatz bat duen datu-atributu bat behar du, ezkutuko HTML elementuekin batera zutabeen eta hutsuneen tamaina ezartzeko. Gainera, zutabeak zabaldu nahi badituzu, hutsunearen tamaina zuk zeuk sartu behar duzu arazoak saihesteko:
Konpara dezagun hau Masonry inplementazio integratua izango litzatekeenarekin:
Kode sinpleagoa eta trinkoagoa, hutsunea bezalako gauzak erabil ditzakeena eta non hedatzen diren ibilbideak 2. tartearekin egiten den, sarean bezala, eta ez du behar hutsunearen tamaina barne hartzen duen zabalera egokia kalkulatzea. Nola jakin zer dagoen eskuragarri eta noiz dagoen? Orokorrean, galdera ez da benetan JS liburutegi baten gainean eraikitako Masonry erabili behar duzun, baizik eta noiz. Masonry JS liburutegia harrigarria da eta urte asko daramatza web plataforman hutsune bat betetzen, eta garatzaile eta erabiltzaile zoriontsu askorentzat. Eragozpen batzuk ditu Igeltserotzako inplementazio integratu batekin alderatzen baduzu, noski, baina horiek ez dira garrantzitsuak ezarpen hori prest ez badago. Niretzat erraza da web-plataformaren ezaugarri berri hauek zerrendatzea, arakatzaileen saltzaile batean lan egiten dudalako, eta, beraz, zer datorren jakin ohi dudalako. Baina garatzaileek askotan partekatzen dute, inkestaz inkesta, gauza berrien jarraipena egitea zaila dela. Informatuta egotea zaila da, eta enpresek ez dute beti ikaskuntza lehenesten, hala ere. Horretan laguntzeko, hona hemen eguneraketak modu erraz eta trinkoan eskaintzen dituzten baliabide batzuk, behar duzun informazioa azkar lor dezazun:
Web plataformak esploratzaile gunea du: Baliteke bere kaleratze-oharraren orrialdea interesatzea. Eta, RSSa gustatzen bazaizu, begiratu argitalpen-oharraren jarioa, baita Eskuragarri Berriak eta Eskuragarri diren Oinarrizko jarioak ere.
WebaPlataformaren egoera-panela: Baliteke bere Oinarrizko urteko orriak gustatzea.
Chrome Platform Status-en bide orria.
Denbora pixka bat gehiago baduzu, arakatzaileen saltzaileen oharrak ere interesatuko zaizkizu:
Chrome Ertza Firefox Safaria
Are baliabide gehiago lortzeko, begiratu nire web-plataformako tranpa-orria Navigating the Cheatsheet. Nire gauza oraindik ez dago inplementatu Hori da arazoaren beste aldea. Denbora, energia eta jarraipena egiteko moduak aurkitzen badituzu ere, frustrazioa dago zure ahotsa entzutea eta gogoko dituzun funtzioak inplementatzeak. Agian urteak daramatzazu akats zehatz bat konpondu arte edo oraindik falta den arakatzaile batean bidaltzeko eginbide zehatz bat. Esango dudana da arakatzaileen saltzaileek entzuten dutela. Erakundeen arteko hainbat taldetako parte naiz, garatzaileen seinaleak eta iritziak uneoro eztabaidatzen ditugun. Iritzi-iturri ezberdin asko aztertzen ditugu, bai arakatzaileen saltzaile bakoitzeko barnekoak, bai kanpoko/publikoak foroetan, kode irekiko proiektuetan, blogetan eta inkestetan. Eta, beti saiatzen ari gara garatzaileek beren behar zehatzak eta erabilera kasuak partekatzeko modu hobeak sortzen. Beraz, ahal baduzu, eskatu gehiago arakatzaileen saltzaileei eta presiona gaitzazu behar dituzun funtzioak ezar ditzagun. Denbora behar dela ulertzen dut, eta beldurra ere izan daitekeela (sarrerarako oztopo handia ez aipatzearren), baina funtzionatzen du. Hona hemen zure (edo zure konpainiaren) ahotsa entzuteko modu batzuk: Hartu urtero JS-en, CSS-ren eta HTML-ren egoeraren inkestak. Zeresan handia dute arakatzaileen saltzaileek beren lana lehenesten dutenean. Arakatzaile guztietan koherentziaz inplementatzeko estandar-oinarritutako API espezifiko bat behar baduzu, kontuan hartu proposamen bat aurkeztea Interop proiektuaren hurrengo iteraldian. Denbora gehiago behar du, baina kontuan hartu nola Shopify-k eta RUMvision-ek Interop 2026rako nahien zerrendak partekatu zituzten. Horrelako informazio zehatza oso erabilgarria izan daiteke arakatzaileen saltzaileek lehentasuna emateko. Arakatzaileen saltzaileei eragiteko esteka erabilgarriagoak lortzeko, begiratu nire web-plataformako tranpa-orria Navigating the Cheatsheet. Ondorioa Amaitzeko, espero dut artikulu honek pentsatzeko gauza batzuk utzi izana:
Harlangintzarako eta datozen web-eginbideetarako zirrara. Erabiltzen hasi nahi dituzun web-eginbide batzuk. Baliteke kode pertsonalizatu edo hirugarrenen zati batzuk kendu ahal izango dituzun funtzio integratuen alde. Datorrenaren jarraipena egiteko eta arakatzaileen saltzaileek eragiteko modu batzuk.
Are garrantzitsuagoa dena, espero dut web-plataforma bere potentzial guztian erabiltzearen onurez konbentzitu izana.
