Rreth 15 vjet më parë, unë punoja në një kompani ku ndërtonim aplikacione për agjentët e udhëtimit, punonjësit e aeroportit dhe kompanitë e linjave ajrore. Ne ndërtuam gjithashtu kornizën tonë të brendshme për komponentët e ndërfaqes së përdoruesit dhe aftësitë e aplikacioneve me një faqe. Ne kishim komponentë për gjithçka: fusha, butona, skeda, diapazon, tabela të dhënash, meny, zgjedhës datash, përzgjedhje dhe shumëzgjedhje. Ne madje kishim një komponent div. Komponenti ynë div ishte i shkëlqyeshëm meqë ra fjala, na lejoi të bënim qoshe të rrumbullakosura në të gjithë shfletuesit, gjë që, besoni apo jo, nuk ishte një gjë e lehtë për t'u bërë në atë kohë.
Puna jonë u zhvillua në një pikë të historisë sonë kur JS, Ajax dhe HTML dinamike u panë si një revolucion që na solli në të ardhmen. Papritur, ne mund të përditësojmë një faqe në mënyrë dinamike, të marrim të dhëna nga një server dhe të shmangim nevojën për të lundruar në faqe të tjera, gjë që u pa si e ngadaltë dhe ndezi një drejtkëndësh të madh të bardhë në ekran midis dy faqeve. Ishte një frazë, e bërë e njohur nga Jeff Atwood (themeluesi i StackOverflow), e cila thoshte: "Çdo aplikacion që mund të shkruhet në JavaScript do të shkruhet përfundimisht në JavaScript." - Jeff Atwood
Për ne në atë kohë, kjo ndihej si një guxim për të shkuar dhe për të krijuar ato aplikacione. Ndihej si një miratim i plotë për të bërë gjithçka me JS. Kështu që ne bëmë gjithçka me JS dhe nuk gjetëm kohë për të hulumtuar mënyra të tjera për t'i bërë gjërat. Ne nuk e ndjemë vërtet nxitjen për të mësuar siç duhet se çfarë mund të bënin HTML dhe CSS. Ne nuk e perceptuam vërtet ueb-in si një platformë aplikacioni në zhvillim në tërësinë e tij. Ne kryesisht e pamë atë si diçka që duhej të punonim, veçanërisht kur bëhej fjalë për mbështetjen e shfletuesit. Ne thjesht mund të hedhim më shumë JS në të për t'i bërë gjërat. A do të më kishte ndihmuar gjetja e kohës për të mësuar më shumë se si funksiononte uebfaqja dhe çfarë ishte e disponueshme në platformë? Sigurisht, ndoshta mund të kisha rruar një tufë kodesh që nuk ishin vërtet të nevojshme. Por, në atë kohë, ndoshta jo aq shumë. E shihni, dallimet e shfletuesit ishin mjaft domethënëse në atë kohë. Kjo ishte një kohë kur Internet Explorer ishte ende shfletuesi dominues, me Firefox-in që ishte i dyti më afër, por filloi të humbiste pjesën e tregut për shkak të popullaritetit të shpejtë të Chrome. Megjithëse Chrome dhe Firefox ishin mjaft të mirë për të rënë dakord për standardet e uebit, mjediset në të cilat funksiononin aplikacionet tona nënkuptonin që ne duhej të mbështesnim IE6 për një kohë të gjatë. Edhe kur na lejohej të mbështesnim IE8, na u desh të merreshim me shumë ndryshime midis shfletuesve. Jo vetëm kaq, por ueb-i i asaj kohe thjesht nuk kishte aq shumë aftësi të integruara direkt në platformë.
Shpejt përpara për sot. Gjërat kanë ndryshuar jashtëzakonisht shumë. Jo vetëm që kemi më shumë nga këto aftësi se kurrë më parë, por shkalla me të cilën ato bëhen të disponueshme është rritur gjithashtu. Më lejoni të bëj përsëri pyetjen, atëherë: A do t'ju ndihmonte sot të merrni kohë për të mësuar më shumë rreth asaj se si funksionon ueb-i dhe çfarë disponohet në platformë? Absolutisht po. Të mësosh të kuptosh dhe të përdorësh platformën e internetit sot ju vë në një avantazh të madh ndaj zhvilluesve të tjerë. Pavarësisht nëse punoni në performancën, aksesueshmërinë, reagimin, të gjitha së bashku, ose thjesht dërgoni veçoritë e ndërfaqes së përdoruesit, nëse dëshironi ta bëni këtë si një inxhinier përgjegjës, njohja e mjeteve që janë në dispozicion për ju ju ndihmon të arrini qëllimet tuaja më shpejt dhe më mirë. Disa gjëra për të cilat mund të mos ju nevojitet më një bibliotekë Duke ditur se çfarë mbështesin shfletuesit sot, pyetja, pra, është: Çfarë mund të heqim dorë? A na duhet një komponent div për të bërë qoshe të rrumbullakosura në 2025? Sigurisht, ne nuk e bëjmë. Vetia e rrezes kufitare është mbështetur nga të gjithë shfletuesit e përdorur aktualisht për më shumë se 15 vjet në këtë pikë. Dhe së shpejti vjen edhe forma e këndit, për kënde edhe më të bukura. Le të hedhim një vështrim në veçoritë relativisht të fundit që janë tani të disponueshme në të gjithë shfletuesit kryesorë dhe të cilat mund t'i përdorni për të zëvendësuar varësitë ekzistuese në bazën tuaj të kodeve. Çështja nuk është të hiqni menjëherë të gjitha bibliotekat tuaja të dashura dhe të rishkruani bazën tuaj të kodeve. Si për çdo gjë tjetër, së pari duhet të merrni parasysh mbështetjen e shfletuesit dhe të vendosni bazuar në faktorë të tjerë specifikë për projektin tuaj. Karakteristikat e mëposhtme zbatohen në tre motorët kryesorë të shfletuesit (Chromium, WebKit dhe Gecko), por mund të keni kërkesa të ndryshme për mbështetjen e shfletuesit që ju pengojnë t'i përdorni ato menjëherë. Tani është ende një kohë e mirë për të mësuar rreth këtyre veçorive, megjithatë, dhe ndoshta të planifikoni t'i përdorni ato në një moment. Popovers Dhe Dialogët Popover API, elementi HTML
Sigurisht, shpejtësia e lidhjes suaj të internetit ndoshta është rritur gjithashtu, por nuk është kështu për të gjithë. Dhe jo të gjithë kanë të njëjtat aftësi të pajisjes. Tërheqja e kodit të palëve të treta për gjërat që mund të bëni me platformën, në vend të kësaj, ka shumë të ngjarë që do të thotë që dërgoni më shumë kod dhe për këtë arsye arrini më pak klientë sesa zakonisht. Në ueb, performanca e keqe e ngarkimit çon në përqindje të mëdha braktisjeje dhe dëmton reputacionin e markës. Duke ekzekutuar më pak kod në pajisje Për më tepër, kodi që dërgoni në pajisjet e klientëve tuaj ka të ngjarë të funksionojë më shpejt nëse përdor më pak abstraksione JavaScript në krye të platformës. Është gjithashtu ndoshta më i përgjegjshëm dhe më i arritshëm si parazgjedhje. E gjithë kjo çon në më shumë klientë dhe më të lumtur. Kontrolloni blogun vjetor të hendekut të pabarazisë së performancës së kolegut tim Alex Russell, i cili tregon se pajisjet premium mungojnë kryesisht në tregjet me miliarda përdorues për shkak të pabarazisë së pasurisë. Dhe ky hendek po rritet vetëm me kalimin e kohës.
Paraqitja e muraturës së integruar Një veçori e platformës së internetit që vjen së shpejti dhe për të cilën jam shumë i emocionuar është CSS Masonery.
Më lejoni të filloj duke shpjeguar se çfarë është Masoneria. Çfarë është Masoneria Masoneria është një lloj paraqitjeje që u bë e njohur nga Pinterest vite më parë. Ai krijon gjurmë të pavarura të përmbajtjes brenda të cilave artikujt paketohen sa më afër fillimit të pjesës që munden.
Shumë njerëz e shohin Masonerinë si një opsion të shkëlqyeshëm për portofolet dhe galeritë e fotografive, gjë që sigurisht mund ta bëjë. Por Masoneria është më fleksibël se ajo që shihni në Pinterest dhe nuk kufizohet vetëm në paraqitjet e ngjashme me ujëvarat. Në një plan urbanistik:
Gjurmët mund të jenë kolona ose rreshta:
Gjurmët e përmbajtjes nuk duhet të jenë të gjitha me të njëjtën madhësi:
Artikujt mund të përfshijnë disa pista:
Artikujt mund të vendosen në pista specifike; ata nuk duhet të ndjekin gjithmonë algoritmin e vendosjes automatike:
Demos Këtu janë disa demonstrime të thjeshta që kam bërë duke përdorur zbatimin e ardhshëm të CSS Masonry në Chromium. Një demonstrim i galerisë së fotografive, që tregon se si artikujt (titulli në këtë rast) mund të përfshijnë disa pjesë:
Një tjetër galeri fotografish që tregon këngë të madhësive të ndryshme:
Një strukturë faqesh lajmesh me disa pjesë më të gjera se të tjerat dhe disa artikuj që përfshijnë të gjithë gjerësinë e paraqitjes:
Një tabelë kanban që tregon se artikujt mund të vendosen në pista specifike:
Shënim: TheDemot e mëparshme janë bërë me një version të Chromium që nuk është ende i disponueshëm për shumicën e përdoruesve të uebit, sepse CSS Masonery sapo ka filluar të zbatohet në shfletues. Sidoqoftë, zhvilluesit e uebit kanë përdorur me kënaqësi bibliotekat për të krijuar paraqitjet e Masonerisë prej vitesh tashmë. Faqet që përdorin Masonerinë Sot Në të vërtetë, Masoneria është mjaft e zakonshme sot në internet. Këtu janë disa shembuj që gjeta përveç Pinterest:
Dhe disa shembuj të tjerë, më pak të dukshëm:
Pra, si u krijuan këto paraqitje? Zgjidhjet Një truk që kam parë të përdoret është përdorimi i një faqosjeje Flexbox, ndryshimi i drejtimit të tij në kolonë dhe vendosja e tij në mbështjellje. Në këtë mënyrë, ju mund të vendosni sende me lartësi të ndryshme në kolona të shumta, të pavarura, duke dhënë përshtypjen e një plan urbanistik:
Megjithatë, ka dy kufizime me këtë zgjidhje:
Rendi i artikujve është i ndryshëm nga ai që do të ishte me një plan urbanistik të vërtetë. Me Flexbox, artikujt mbushin fillimisht kolonën e parë dhe, kur ajo të jetë e plotë, më pas shkoni në kolonën tjetër. Me Masonerinë, artikujt do të grumbulloheshin në cilindo gjurmë (ose kolonë në këtë rast) që ka më shumë hapësirë në dispozicion. Por gjithashtu, dhe ndoshta më e rëndësishmja, kjo zgjidhje kërkon që të vendosni një lartësi fikse në kontejnerin Flexbox; përndryshe, nuk do të ndodhte mbështjellje.
Bibliotekat Masoneria të palëve të treta Për raste më të avancuara, zhvilluesit kanë përdorur bibliotekat. Biblioteka më e njohur dhe e njohur për këtë quhet thjesht Masoneria, dhe shkarkohet rreth 200,000 herë në javë sipas NPM. Squarespace ofron gjithashtu një komponent layout që jep një plan urbanistik të Masonerisë, për një alternativë pa kod, dhe shumë sajte e përdorin atë. Të dyja këto opsione përdorin kodin JavaScript për të vendosur artikujt në paraqitje. Masoneria e ndërtuar Jam vërtet i emocionuar që Masoneria tani ka filluar të shfaqet në shfletues si një veçori e integruar CSS. Me kalimin e kohës, do të jeni në gjendje të përdorni Masonerinë ashtu siç bëni Grid ose Flexbox, domethënë, pa pasur nevojë për ndonjë zgjidhje ose kod të palës së tretë. Ekipi im në Microsoft ka zbatuar mbështetje të integruar për Masonerinë në projektin me burim të hapur Chromium, mbi të cilin bazohen Edge, Chrome dhe shumë shfletues të tjerë. Mozilla ishte në fakt shitësi i parë i shfletuesit që propozoi një implementim eksperimental të Masonery në vitin 2020. Dhe Apple gjithashtu ka qenë shumë i interesuar për ta bërë këtë paraqitje të re të internetit primitive. Puna për standardizimin e veçorisë po ecën gjithashtu përpara, me marrëveshje brenda grupit të punës CSS për drejtimin e përgjithshëm dhe madje edhe një ekran të ri të llojit të ekranit: korsi rrjetë. Nëse dëshironi të mësoni më shumë rreth Masonerisë dhe të gjurmoni përparimin, shikoni faqen time të burimeve CSS Masonery. Me kalimin e kohës, kur Masoneria të bëhet një veçori bazë, ashtu si Grid ose Flexbox, ne do të jemi në gjendje thjesht ta përdorim atë dhe të përfitojmë nga:
Performancë më e mirë, Përgjegjshmëri më e mirë, Lehtësia e përdorimit dhe kodi më i thjeshtë.
Le t'i hedhim një vështrim më të afërt këtyre. Performancë më e mirë Krijimi i sistemit tuaj të paraqitjes si Masoneria, ose përdorimi i një biblioteke të palëve të treta në vend të kësaj, do të thotë që do t'ju duhet të ekzekutoni kodin JavaScript për të vendosur artikujt në ekran. Kjo do të thotë gjithashtu se ky kod do të jetë i bllokuar. Në të vërtetë, ose asgjë nuk do të shfaqet, ose gjërat nuk do të jenë në vendet e duhura ose në madhësitë e duhura, derisa të ekzekutohet ai kod JavaScript. Paraqitja e muraturës përdoret shpesh për pjesën kryesore të një faqeje interneti, që do të thotë se kodi do të bënte që përmbajtja juaj kryesore të shfaqet më vonë se sa mund të shfaqej ndryshe, duke degraduar LCP-në tuaj ose metrikën më të madhe të përmbajtjes së bojës, e cila luan një rol të madh në performancën e perceptuar dhe optimizimin e motorit të kërkimit. Kam testuar bibliotekën Masonry JS me një plan urbanistik të thjeshtë dhe duke simuluar një lidhje të ngadaltë 4G në DevTools. Biblioteka nuk është shumë e madhe (24 KB, 7.8 KB e mbyllur), por u deshën 600 ms për t'u ngarkuar në kushtet e testimit tim. Këtu është një regjistrim i performancës që tregon kohën e gjatë të ngarkimit prej 600 ms për bibliotekën Masonry dhe se asnjë aktivitet tjetër përkthimi nuk ka ndodhur gjatë kohës që po ndodhte:
Përveç kësaj, pas kohës fillestare të ngarkimit, skripti i shkarkuar më pas duhej të analizohej, përpilohej dhe më pas të ekzekutohej. E gjithë kjo, siç u përmend më parë, ishte duke bllokuar paraqitjen e faqes. Me një implementim të integruar të Masonerisë në shfletues, ne nuk do të kemi një skript për të ngarkuar dhe ekzekutuar. Motori i shfletuesit thjesht do të bëjë gjënë e tij gjatë hapit fillestar të paraqitjes së faqes. Përgjegjshmëri më e mirë Ngjashëm me rastin kur një faqe ngarkohet për herë të parë, ndryshimi i madhësisë së dritares së shfletuesit çon në paraqitjen përsëri të paraqitjes në atë faqe. Në këtë pikë, megjithatë, nëse faqja po përdor bibliotekën Masonry JS, nuk ka nevojë të ngarkoni përsëri skriptin, sepse tashmë ështëkëtu. Sidoqoftë, kodi që lëviz artikujt në vendet e duhura duhet të ekzekutohet. Tani kjo bibliotekë e veçantë duket se është mjaft e shpejtë për ta bërë këtë kur faqja ngarkohet. Megjithatë, ai animon artikujt kur duhet të zhvendosen në një vend tjetër në ndryshimin e madhësisë së dritares, dhe kjo bën një ndryshim të madh. Sigurisht, përdoruesit nuk shpenzojnë kohë duke ndryshuar madhësinë e dritareve të shfletuesit të tyre aq sa ne zhvilluesit. Por kjo përvojë e animuar e ndryshimit të madhësisë mund të jetë mjaft e bezdisshme dhe shton kohën e perceptuar që i duhet faqes për t'u përshtatur me madhësinë e saj të re. Lehtësia e përdorimit dhe kodi më i thjeshtë Sa e lehtë është përdorimi i një veçorie në internet dhe sa i thjeshtë duket kodi janë faktorë të rëndësishëm që mund të bëjnë një ndryshim të madh për ekipin tuaj. Ato nuk mund të jenë kurrë aq të rëndësishme sa përvoja e përdoruesit përfundimtar, natyrisht, por përvoja e zhvilluesit ndikon në mirëmbajtjen. Përdorimi i një veçorie të integruar në ueb vjen me përfitime të rëndësishme në këtë drejtim:
Zhvilluesit që njohin tashmë HTML, CSS dhe JS, ka shumë të ngjarë të jenë në gjendje ta përdorin atë veçori lehtësisht, sepse është krijuar për t'u integruar mirë dhe për të qenë në përputhje me pjesën tjetër të platformës së internetit. Nuk ekziston rreziku i prishjes së ndryshimeve në mënyrën se si përdoret funksioni. Ekziston pothuajse zero rrezik që kjo veçori të zhvlerësohet ose të mos mirëmbahet.
Në rastin e Masonerisë së integruar, për shkak se është një strukturë primitive, ju e përdorni atë nga CSS, ashtu si Grid ose Flexbox, pa përfshirë JS. Gjithashtu, vetitë e tjera CSS të lidhura me paraqitjen, të tilla si boshllëku, funksionojnë ashtu siç do të prisnit. Nuk ka truke apo zgjidhje për të ditur dhe gjërat që mësoni janë të dokumentuara në MDN. Për lib-in Masonry JS, inicializimi është paksa kompleks: kërkon një atribut të dhënash me një sintaksë specifike, së bashku me elementë të fshehur HTML për të vendosur madhësitë e kolonës dhe të boshllëqeve. Plus, nëse doni të shtrini kolonat, duhet të përfshini vetë madhësinë e boshllëkut për të shmangur problemet:
Le ta krahasojmë këtë me atë se si do të dukej një zbatim i integruar i Masonerisë:
Kod më i thjeshtë, më kompakt që mund të përdorë thjesht gjëra të tilla si boshllëku dhe ku gjurmët e shtrirjes kryhen me hapësirën 2, ashtu si në rrjet, dhe nuk kërkon që ju të llogaritni gjerësinë e duhur që përfshin madhësinë e hendekut. Si të dini se çfarë është në dispozicion dhe kur është e disponueshme? Në përgjithësi, pyetja nuk është nëse duhet të përdorni Masonerinë e integruar mbi një bibliotekë JS, por më tepër kur. Biblioteka Masonry JS është e mahnitshme dhe ka mbushur një boshllëk në platformën e internetit për shumë vite, dhe për shumë zhvillues dhe përdorues të lumtur. Ka disa të meta nëse e krahasoni me një zbatim të integruar të Masonerisë, sigurisht, por ato nuk janë të rëndësishme nëse ky zbatim nuk është gati. Është e lehtë për mua të rendis këto veçori të reja të platformës së internetit, sepse punoj në një shitës shfletuesi, dhe për këtë arsye prirem të di se çfarë po vjen. Por zhvilluesit shpesh ndajnë, sondazh pas sondazhi, se mbajtja e gjurmëve të gjërave të reja është e vështirë. Qëndrimi i informuar është i vështirë dhe kompanitë nuk i japin gjithmonë përparësi të mësuarit gjithsesi. Për të ndihmuar me këtë, këtu janë disa burime që ofrojnë përditësime në mënyra të thjeshta dhe kompakte, në mënyrë që të merrni informacionin që ju nevojitet shpejt:
Platforma e internetit përmban faqen e eksploruesit: Ju mund të jeni të interesuar në faqen e shënimeve të lëshimit të saj. Dhe, nëse ju pëlqen RSS, shikoni furnizimin e shënimeve të lëshimit, si dhe furnizimet e linjës bazë të disponueshme rishtazi dhe të disponueshme gjerësisht.
WebPaneli i statusit të platformës: Mund t'ju pëlqejnë faqet e ndryshme të vitit bazë.
Faqja e udhërrëfyesit të statusit të platformës Chrome.
Nëse keni pak më shumë kohë, mund të jeni të interesuar edhe për shënimet e lëshimit të shitësve të shfletuesit:
krom Buzë Firefox Safari
Për më shumë burime, shikoni fletën time të mashtrimit të Lundrimit në Platformën e Uebit. Gjëja ime ende nuk është zbatuar Kjo është ana tjetër e problemit. Edhe nëse gjeni kohën, energjinë dhe mënyrat për të mbajtur gjurmët, ka ende zhgënjim për të dëgjuar zërin tuaj dhe për të zbatuar veçoritë tuaja të preferuara. Ndoshta keni pritur për vite që një problem specifik të zgjidhet, ose një veçori specifike për t'u dërguar në një shfletues ku ende mungon. Ajo që do të them është se shitësit e shfletuesit dëgjojnë. Unë jam pjesë e disa ekipeve ndër-organizative ku diskutojmë sinjalet dhe reagimet e zhvilluesve gjatë gjithë kohës. Ne shikojmë shumë burime të ndryshme reagimesh, si të brendshme në çdo shitës të shfletuesit, ashtu edhe të jashtëm/publik në forume, projekte me burim të hapur, blogje dhe sondazhe. Dhe, ne jemi gjithmonë duke u përpjekur të krijojmë mënyra më të mira për zhvilluesit që të ndajnë nevojat e tyre specifike dhe rastet e përdorimit. Pra, nëse mundeni, kërkoni më shumë nga shitësit e shfletuesit dhe na bëni presion për të zbatuar veçoritë që ju nevojiten. E kuptoj se kërkon kohë, dhe gjithashtu mund të jetë frikësuese (për të mos përmendur një pengesë të lartë për hyrjen), por gjithashtu funksionon. Këtu janë disa mënyra se si mund të dëgjoni zërin tuaj (ose të kompanisë suaj): Merrni anketat vjetore të gjendjes së JS, gjendjes së CSS dhe gjendjes së HTML. Ata luajnë një rol të madh në mënyrën se si shitësit e shfletuesve i japin përparësi punës së tyre. Nëse keni nevojë për një API specifike të bazuar në standard për t'u zbatuar vazhdimisht nëpër shfletues, merrni parasysh paraqitjen e një propozimi në përsëritjen e ardhshme të projektit Interop. Kërkon më shumë kohë, por merrni parasysh se si Shopify dhe RUMvision ndanë listat e tyre të dëshirave për Interop 2026. Informacioni i detajuar si ky mund të jetë shumë i dobishëm për shitësit e shfletuesve për t'i dhënë përparësi. Për më shumë lidhje të dobishme për të ndikuar tek shitësit e shfletuesit, shikoni faqen time të lundrimit në platformën e internetit. konkluzioni Për ta mbyllur, shpresoj se ky artikull ju ka lënë disa gjëra për të menduar:
Eksitim për Masonerinë dhe veçori të tjera të ardhshme të internetit. Disa veçori të uebit që mund të dëshironi të filloni t'i përdorni. Disa pjesë të kodit të personalizuar ose të palës së tretë që mund të jeni në gjendje t'i hiqni në favor të veçorive të integruara. Disa mënyra për të mbajtur gjurmët e asaj që po vjen dhe për të ndikuar tek shitësit e shfletuesit.
Më e rëndësishmja, shpresoj se ju kam bindur për përfitimet e përdorimit të platformës së internetit në potencialin e saj të plotë.
