Körülbelül 15 évvel ezelőtt egy olyan cégnél dolgoztam, ahol utazási irodák, repülőtéri dolgozók és légitársaságok számára készítettünk alkalmazásokat. Kiépítettük saját házon belüli keretrendszerünket is a felhasználói felület összetevőihez és az egyoldalas alkalmazások képességeihez. Mindenhez voltak összetevőink: mezők, gombok, tabulátorok, tartományok, adattáblák, menük, dátumválasztók, kijelölések és többszörös kijelölések. Még div komponensünk is volt. A div komponensünk egyébként remek volt, lehetővé tette, hogy minden böngészőben lekerekített sarkokat csináljunk, ami akkoriban, akár hiszi, akár nem, nem volt egyszerű dolog.
Munkánkra történelmünk egy olyan pontján került sor, amikor a JS-t, az Ajaxot és a dinamikus HTML-t olyan forradalomnak tekintették, amely a jövőbe vitt minket. Hirtelen dinamikusan frissíthettünk egy oldalt, adatokat kaphattunk a szerverről, és nem kellett más oldalakra navigálni, ami lassúnak tűnt, és egy nagy fehér téglalapot villantott a képernyőn a két oldal között. Volt egy kifejezés, amelyet Jeff Atwood (a StackOverflow alapítója) tett népszerűvé, és ez így hangzott: „Minden alkalmazás, amely JavaScriptben írható, végül JavaScriptben lesz megírva.” – Jeff Atwood
Számunkra akkoriban úgy éreztük, hogy merjük létrehozni ezeket az alkalmazásokat. Egy általános jóváhagyásnak tűnt, hogy mindent a JS-sel csináljak. Tehát mindent a JS-sel csináltunk, és nem igazán fordítottunk időt arra, hogy a dolgok más módjait kutassuk. Nem igazán éreztük a késztetést arra, hogy megfelelően megtanuljuk, mire képes a HTML és a CSS. Nem igazán fogtuk fel a webet egy fejlődő alkalmazásplatformnak a maga teljességében. Leginkább úgy láttuk, hogy meg kell oldanunk, különösen ami a böngésző támogatását illeti. Csupán több JS-t dobhatnánk rá, hogy elintézzük a dolgokat. Segített volna nekem, ha időt szánnék arra, hogy többet megtudjak az internet működéséről és arról, hogy mi áll rendelkezésre a platformon? Persze, valószínűleg le tudtam volna borotválni egy csomó kódot, amelyre valójában nem volt szükség. De akkoriban talán nem annyira. Látod, a böngészők közötti különbségek akkoriban elég jelentősek voltak. Ekkor még az Internet Explorer volt a domináns böngésző, a Firefox pedig a második helyen állt, de a gyors népszerűségnek örvendő Chrome miatt veszíteni kezdett a piaci részesedéséből. Bár a Chrome és a Firefox elég jól megállapodott a webes szabványokban, a környezet, amelyben az alkalmazásaink futottak, azt jelentette, hogy sokáig támogatnunk kellett az IE6-ot. Még akkor is, amikor engedélyeztük az IE8 támogatását, még mindig sok különbséggel kellett megküzdenünk a böngészők között. Nem csak ez, de a korabeli web egyszerűen nem tartalmazott ennyi képességet közvetlenül a platformba.
Gyorsan előre a mai napra. A dolgok óriásit változtak. Nemcsak, hogy több ilyen képességgel rendelkezünk, mint valaha, de az elérhetővé válás üteme is megnőtt. Hadd tegyem fel ismét a kérdést: Segítene-e ma, ha rászánná az időt arra, hogy többet megtudjon a web működéséről és a platformon elérhető dolgokról? Abszolút igen. Ha ma megtanulja megérteni és használni a webes platformot, óriási előnyhöz jut a többi fejlesztővel szemben. Függetlenül attól, hogy a teljesítményen, a hozzáférhetőségen, a reakciókészségen dolgozik – mindezen együtt, vagy csak a felhasználói felületi funkciók szállításán –, ha felelős mérnökként szeretné ezt tenni, a rendelkezésére álló eszközök ismerete segít gyorsabban és jobban elérni céljait. Néhány dolog, amihez talán már nincs szüksége könyvtárra Ha tudjuk, hogy ma mit támogatnak a böngészők, a kérdés tehát az: mit hagyhatunk el? Szükségünk van div komponensre a lekerekített sarkok elkészítéséhez 2025-ben? Természetesen nem. A border-radius tulajdonságot az összes jelenleg használt böngésző támogatja több mint 15 éve. És hamarosan jön a sarokforma is, a még szebb sarkokhoz. Vessünk egy pillantást a viszonylag friss szolgáltatásokra, amelyek már minden nagyobb böngészőben elérhetők, és amelyek segítségével helyettesítheti a kódbázisában meglévő függőségeket. A lényeg nem az, hogy azonnal feladja az összes szeretett könyvtárát, és átírja a kódbázist. Ami minden mást illeti, először figyelembe kell vennie a böngésző támogatását, és a projektre jellemző egyéb tényezők alapján kell döntenie. A következő szolgáltatások a három fő böngészőmotorban (Chromium, WebKit és Gecko) vannak megvalósítva, de előfordulhat, hogy eltérő böngészőtámogatási követelmények vonatkoznak, amelyek megakadályozzák, hogy azonnal használja őket. Még mindig itt az ideje, hogy megismerjük ezeket a funkciókat, és esetleg tervezzük, hogy valamikor használni is fogjuk őket. Felbukkanó ablakok és párbeszédek A Popover API, a
Persze, valószínűleg az internetkapcsolat sebessége is nőtt, de ez nem mindenkinél van így. És nem mindenki rendelkezik egyforma eszközképességekkel. Harmadik féltől származó kód bekérése a platformmal használható dolgokhoz, ehelyett valószínűleg azt jelenti, hogy több kódot szállít, és így kevesebb ügyfelet ér el, mint általában. Az interneten a rossz betöltési teljesítmény nagymértékű elhagyási arányhoz vezet, és rontja a márka hírnevét. Kevesebb kód futtatása az eszközökön Ezenkívül az ügyfelei eszközeire szállított kód valószínűleg gyorsabban fut, ha kevesebb JavaScript-absztrakciót használ a platform tetején. Valószínűleg érzékenyebb és alapértelmezés szerint is könnyebben elérhető. Mindez több és boldogabb vásárlóhoz vezet. Tekintse meg Alex Russell kollégám éves teljesítmény-egyenlőtlenségi rés blogját, amely azt mutatja, hogy a prémium eszközök nagyrészt hiányoznak a több milliárd felhasználót számláló piacokról a vagyoni egyenlőtlenség miatt. És ez a szakadék idővel csak nő.
Beépített falazott elrendezés Az egyik webes platform funkció, amely hamarosan megjelenik, és nagyon izgatott vagyok, a CSS Masonry.
Hadd kezdjem azzal, hogy elmagyarázom, mi az a kőművesség. Mi az a falazat A falazat egy olyan elrendezéstípus, amelyet a Pinterest évekkel ezelőtt népszerűvé tett. Független tartalomsávokat hoz létre, amelyeken belül az elemek a lehető legközelebb csomagolják magukat a pálya kezdetéhez.
Sokan úgy látják, hogy a kőművesség nagyszerű lehetőség portfóliók és fotógalériák készítésére, amire biztosan képes. De a Masonry rugalmasabb, mint amit a Pinteresten lát, és nem korlátozódik csupán a vízesésszerű elrendezésekre. Falazott elrendezésben:
A sávok lehetnek oszlopok vagy sorok:
Nem kell minden tartalomsávnak azonos méretűnek lennie:
Az elemek több sávra is kiterjedhetnek:
Az elemek meghatározott sávokra helyezhetők; nem kell mindig követniük az automatikus elhelyezési algoritmust:
Demos Íme néhány egyszerű demó, amelyet a CSS Masonry Chromiumban hamarosan megjelenő megvalósításával készítettem. A fotógaléria bemutatója, amely bemutatja, hogy az elemek (jelen esetben a cím) hogyan terjedhetnek több sávra:
Egy másik képgaléria, amely különböző méretű pályákat mutat be:
A híroldal elrendezése, amelyen egyes sávok szélesebbek, mint mások, és néhány elem az elrendezés teljes szélességében:
Kanban tábla, amely megmutatja, hogy az elemek meghatározott sávokra helyezhetők:
Megjegyzés: AA korábbi demók a Chromium egy olyan verziójával készültek, amely még nem érhető el a legtöbb webfelhasználó számára, mert a CSS Masonry megvalósítása még csak most kezdődik a böngészőkben. A webfejlesztők azonban már évek óta boldogan használnak könyvtárakat falazott elrendezések létrehozásához. Ma falazatot használó webhelyek Valójában a kőművesség meglehetősen gyakori az interneten manapság. Íme néhány példa, amit a Pinterest mellett találtam:
És még néhány, kevésbé nyilvánvaló példa:
Szóval hogyan készültek ezek az elrendezések? Megoldások Az egyik trükk, amelyet használtam, a Flexbox elrendezés használata helyett az irányt oszlopra változtatva, és a burkolásra állítva. Így több, egymástól független oszlopba helyezheti el a különböző magasságú elemeket, így egy falazott elrendezés benyomását keltve:
Ennek a megoldásnak azonban két korlátja van:
A tételek sorrendje eltér attól, ami egy valódi falazott elrendezés esetén lenne. A Flexbox használatával az elemek először az első oszlopot töltik ki, és ha az megtelt, akkor ugorjon a következő oszlopra. A Masonry használatával az elemek abban a sávban (vagy ebben az esetben oszlopban) helyezkednek el, ahol több hely áll rendelkezésre. De az is, és ami talán még fontosabb, ez a megoldás megköveteli, hogy fix magasságot állítson be a Flexbox tárolóhoz; ellenkező esetben nem történik csomagolás.
Harmadik fél kőműves könyvtárai A fejlettebb esetekben a fejlesztők könyvtárakat használnak. Ennek legismertebb és legnépszerűbb könyvtárát egyszerűen Masonrynak hívják, és az NPM szerint hetente körülbelül 200 000 alkalommal töltik le. A Squarespace egy olyan elrendezési összetevőt is biztosít, amely kőműves elrendezést jelenít meg, kód nélküli alternatívaként, és sok webhely használja. Mindkét beállítás JavaScript-kódot használ az elemek elrendezésben való elhelyezéséhez. Beépített falazat Nagyon izgatott vagyok, hogy a Masonry beépített CSS-funkcióként kezd megjelenni a böngészőkben. Idővel a Masonryt ugyanúgy használhatja, mint a Grid-et vagy a Flexboxot, vagyis anélkül, hogy bármilyen megoldásra vagy harmadik féltől származó kódra lenne szüksége. A Microsoftnál dolgozó csapatom beépített Masonry támogatást valósított meg a Chromium nyílt forráskódú projektben, amelyen az Edge, a Chrome és sok más böngésző alapul. Valójában a Mozilla volt az első böngészőgyártó, aki 2020-ban javasolta a Masonry kísérleti megvalósítását. Az Apple-t is nagyon érdekelte, hogy ez az új webelrendezés primitív legyen. A funkció szabványosítására irányuló munka is halad, a CSS munkacsoporton belül egyetértés van az általános irányról, sőt egy új megjelenítési típusról is: grid-lanes. Ha többet szeretne megtudni a kőművességről, és nyomon szeretné követni az előrehaladást, nézze meg a CSS Masonry forrásoldalamat. Idővel, amikor a falazat alapvonali funkcióvá válik, akárcsak a Grid vagy a Flexbox, egyszerűen használhatjuk, és élvezhetjük a következőket:
Jobb teljesítmény, Jobb reakciókészség, Könnyű használat és egyszerűbb kód.
Nézzük meg ezeket közelebbről. Jobb teljesítmény Ha saját falazathoz hasonló elrendezési rendszert készít, vagy helyette harmadik féltől származó könyvtárat használ, akkor JavaScript-kódot kell futtatnia, hogy elemeket helyezzen el a képernyőn. Ez azt is jelenti, hogy ez a kód renderelést blokkol. Valójában vagy semmi nem jelenik meg, vagy a dolgok nem a megfelelő helyeken vagy a megfelelő méretűek lesznek, amíg a JavaScript-kód le nem fut. A falazott elrendezést gyakran használják a weboldal fő részére, ami azt jelenti, hogy a kód a fő tartalmat később jeleníti meg, mint ahogy egyébként megjelenhetne, ami rontja az LCP-t vagy a Legnagyobb tartalommal rendelkező festék mutatót, amely nagy szerepet játszik az észlelt teljesítményben és a keresőoptimalizálásban. A Masonry JS könyvtárat egy egyszerű elrendezéssel és a DevTools lassú 4G kapcsolatának szimulálásával teszteltem. A könyvtár nem túl nagy (24 KB, 7,8 KB gzip), de az én tesztkörülményeim között 600 ms-ig tartott a betöltése. Íme egy teljesítményfelvétel, amely azt mutatja, hogy a Masonry könyvtár hosszú, 600 ms-os betöltési idejét mutatja, és hogy közben nem történt más renderelési tevékenység:
Ezenkívül a kezdeti betöltési idő után a letöltött szkriptet elemezni, lefordítani, majd le kellett futtatni. Mindez, mint korábban említettük, blokkolta az oldal megjelenítését. A böngészőbe beépített Masonry implementációval nem lesz letölthető és futtatható szkriptünk. A böngészőmotor csak a kezdeti oldalmegjelenítési lépés során teszi a dolgát. Jobb válaszkészség Hasonlóan az oldal első betöltéséhez, a böngészőablak átméretezése az elrendezés ismételt megjelenítéséhez vezet az oldalon. Ezen a ponton azonban, ha az oldal a Masonry JS könyvtárat használja, nem kell újra betölteni a szkriptet, mert az máritt. Az elemeket a megfelelő helyre mozgó kódnak azonban futnia kell. Most úgy tűnik, hogy ez a könyvtár elég gyorsan megteszi ezt az oldal betöltésekor. Azonban animálja az elemeket, amikor az ablak átméretezésénél más helyre kell áthelyezni őket, és ez nagy különbséget jelent. Természetesen a felhasználók nem töltenek annyi időt a böngészőablak átméretezésével, mint mi, fejlesztők. Ez az animált átméretezési élmény azonban meglehetősen felkavaró lehet, és megnöveli azt az időt, amely ahhoz szükséges, hogy az oldal alkalmazkodjon az új mérethez. Könnyű használat és egyszerűbb kód A webes funkciók használatának egyszerűsége és a kód egyszerű megjelenése fontos tényezők, amelyek nagy változást hozhatnak a csapat számára. Természetesen soha nem lehetnek olyan fontosak, mint a végső felhasználói élmény, de a fejlesztői tapasztalat befolyásolja a karbantarthatóságot. A beépített webszolgáltatás használata fontos előnyökkel jár ezen a téren:
Azok a fejlesztők, akik már ismerik a HTML-t, a CSS-t és a JS-t, valószínűleg könnyen tudják használni ezt a funkciót, mert úgy tervezték, hogy jól integrálódjon és konzisztens legyen a webes platform többi részével. Nem áll fenn annak a veszélye, hogy a funkció használatában változásokat vezetnek be. Szinte nulla annak a kockázata, hogy ez a funkció elavulttá vagy karbantartatlanná váljon.
A beépített Masonry esetében, mivel ez egy elrendezés primitív, CSS-ből használja, akárcsak a Grid vagy a Flexbox, nincs benne JS. Ezenkívül az egyéb elrendezéssel kapcsolatos CSS-tulajdonságok, például a gap, úgy működnek, ahogyan azt elvárná. Nincsenek trükkök vagy megkerülő megoldások, amelyeket tudni kell, és a tanultak dokumentálva vannak az MDN-en. A Masonry JS lib esetében az inicializálás kissé összetett: egy adott szintaxisú adatattribútumra van szükség, valamint rejtett HTML-elemekre az oszlop- és hézagméret beállításához. Ezenkívül, ha oszlopokat szeretne átfogni, a problémák elkerülése érdekében magának kell megadnia a hézag méretét:
Hasonlítsuk össze ezt azzal, hogy hogyan nézne ki egy beépített Masonry implementáció:
Egyszerűbb, kompaktabb kód, amely csak olyan dolgokat tud használni, mint például a rés, és ahol a sávok átívelése a 2. fesztávval történik, csakúgy, mint a rácsban, és nem szükséges kiszámolnia a megfelelő szélességet, amely magában foglalja a rés méretét. Honnan tudhatjuk, hogy mi és mikor érhető el? Összességében nem az a kérdés, hogy érdemes-e a beépített Masonry-t használni a JS-könyvtár felett, hanem inkább az, hogy mikor. A Masonry JS könyvtár csodálatos, és évek óta hiánypótló a webes platformon, és sok boldog fejlesztő és felhasználó számára. Természetesen van néhány hátránya, ha összehasonlítjuk egy beépített Masonry implementációval, de ezek nem fontosak, ha az implementáció nincs készen. Könnyű felsorolnom ezeket a nagyszerű új webes platform-szolgáltatásokat, mivel böngészőgyártónál dolgozom, és ezért hajlamos vagyok tudni, hogy mi várható. De a fejlesztők gyakran felmérésről felmérésre osztják meg, hogy nehéz nyomon követni az új dolgokat. Nehéz tájékozódni, és a vállalatok egyébként sem mindig priorizálják a tanulást. Ennek elősegítése érdekében íme néhány forrás, amelyek egyszerű és kompakt módokon biztosítanak frissítéseket, így gyorsan megkaphatja a szükséges információkat:
A webes platform felfedező webhelyet tartalmaz: Érdekelheti a kiadási megjegyzések oldala. Ha pedig szereti az RSS-t, nézze meg a kiadási megjegyzések hírcsatornáját, valamint a Baseline Newly Available és Widely Available feedeket.
A WebPlatform állapotának irányítópultja: Lehet, hogy tetszeni fog a különböző alapszintű évoldalai.
A Chrome Platform Status ütemtervoldala.
Ha van egy kicsit több ideje, a böngészőgyártók kiadási megjegyzései is érdekelhetik:
Chrome Edge Firefox Safari
Még több forrásért tekintse meg a Navigálás a webplatformon Cheatsheet-et. Az én dolgaim még mindig nem valósulnak meg Ez a probléma másik oldala. Még ha talál is időt, energiát és módot a nyomon követésre, továbbra is csalódott lesz, ha hallatja a hangját, és alkalmazza kedvenc funkcióit. Lehet, hogy évek óta vár egy adott hiba kijavítására, vagy arra, hogy egy adott szolgáltatás megjelenjen egy böngészőben, ahol az még mindig hiányzik. Azt mondom, hogy a böngészőgyártók figyelnek. Tagja vagyok több szervezeten átívelő csapatnak, ahol folyamatosan megbeszéljük a fejlesztői jelzéseket és a visszajelzéseket. Számos különböző visszajelzési forrást vizsgálunk, mind belső, mind a külső/nyilvános visszajelzéseket fórumokon, nyílt forráskódú projekteken, blogokon és felméréseken. És mindig arra törekszünk, hogy jobb módszereket teremtsünk a fejlesztők számára, hogy megosszák konkrét igényeiket és használati eseteiket. Tehát, ha teheti, kérjen többet a böngésző gyártóitól, és nyomást gyakoroljon ránk, hogy megvalósítsuk a szükséges funkciókat. Megértem, hogy időbe telik, és ijesztő is lehet (nem beszélve a magas belépési korlátról), de működik is. Íme néhány módszer, amellyel saját (vagy cége) hangját hallathatja: Vegye ki az éves JS-, CSS- és HTML-állapot-felméréseket. Nagy szerepet játszanak abban, hogy a böngészőgyártók hogyan rangsorolják munkájukat. Ha egy adott szabvány alapú API-ra van szüksége a böngészők közötti konzisztens megvalósításához, fontolja meg egy javaslat benyújtását a következő Interop projekt iterációja során. Ez több időt igényel, de fontolja meg, hogy a Shopify és a RUMvision hogyan osztotta meg kívánságlistájukat az Interop 2026-hoz. Az ehhez hasonló részletes információk nagyon hasznosak lehetnek a böngészőgyártók számára a prioritások meghatározásában. Ha további hasznos linkeket szeretne találni a böngésző gyártóinak befolyásolására, tekintse meg a Navigálás a webplatformon Cheatsheet-et. Következtetés Zárásként remélem, hogy ez a cikk néhány gondolatot hagyott maga után:
Izgalom a kőművességért és más közelgő webes szolgáltatásokért. Néhány webes funkció, amelyet érdemes elkezdeni használni. Néhány egyedi vagy harmadik féltől származó kód, amelyet esetleg eltávolíthat a beépített funkciók javára. Néhány módszer az újdonságok nyomon követésére és a böngészőszállítók befolyásolására.
Ami még ennél is fontosabb, remélem, sikerült meggyőzni a webes platform teljes potenciáljának kihasználásában rejlő előnyökről.
