Maždaug prieš 15 metų dirbau įmonėje, kurioje kūrėme programas kelionių agentams, oro uostų darbuotojams ir oro linijų bendrovėms. Taip pat sukūrėme savo vidines sąsajos komponentų ir vieno puslapio programų galimybių sistemą. Turėjome viskam skirtus komponentus: laukus, mygtukus, skirtukus, diapazonus, duomenų lenteles, meniu, datos rinkiklius, pasirinkimus ir kelis pasirinkimus. Mes netgi turėjome div komponentą. Mūsų div komponentas, beje, buvo puikus, jis leido daryti užapvalintus kampus visose naršyklėse, o tai, patikėkite ar ne, tuo metu nebuvo lengvas dalykas.
Mūsų darbas vyko mūsų istorijos momentu, kai JS, Ajax ir dinaminis HTML buvo laikomi revoliucija, atvedusia mus į ateitį. Staiga galėjome dinamiškai atnaujinti puslapį, gauti duomenis iš serverio ir išvengti naršymo į kitus puslapius, o tai buvo lėta ir ekrane tarp dviejų puslapių mirgėjo didelis baltas stačiakampis. Buvo frazė, kurią išpopuliarino Jeffas Atwoodas (StackOverflow įkūrėjas), kuri skambėjo: „Bet kokia programa, kurią galima parašyti JavaScript, galiausiai bus parašyta JavaScript“ – Jeffas Atwoodas
Tuo metu mums tai atrodė kaip išdrįsimas iš tikrųjų eiti ir kurti tas programas. Jaučiausi kaip visiškas sutikimas daryti viską su JS. Taigi mes padarėme viską su JS ir tikrai neskyrėme laiko tyrinėti kitų būdų, kaip elgtis. Mes tikrai nejautėme paskatos tinkamai išmokti, ką gali padaryti HTML ir CSS. Mes tikrai nesuvokėme žiniatinklio kaip visos besivystančios programų platformos. Dažniausiai tai matėme kaip kažką, ką reikia apeiti, ypač kai tai susiję su naršyklės palaikymu. Galėtume tiesiog įdėti daugiau JS, kad galėtume atlikti reikalus. Ar skyręs laiko sužinoti daugiau apie tai, kaip veikia žiniatinklis ir kas yra platformoje, man būtų padėję? Žinoma, tikriausiai galėjau nusiskusti daugybę kodų, kurių tikrai nereikėjo. Bet tuo metu gal ne tiek daug. Matote, naršyklių skirtumai tada buvo gana dideli. Tai buvo laikas, kai „Internet Explorer“ vis dar buvo dominuojanti naršyklė, o „Firefox“ buvo beveik antroji, tačiau pradėjo prarasti rinkos dalį dėl sparčiai populiarėjančios „Chrome“. Nors „Chrome“ ir „Firefox“ gana gerai susitarė dėl žiniatinklio standartų, aplinka, kurioje veikė mūsų programos, lėmė, kad ilgą laiką turėjome palaikyti IE6. Net kai mums buvo leista palaikyti IE8, vis tiek turėjome susidurti su daugybe naršyklių skirtumų. Negana to, to meto žiniatinklis tiesiog neturėjo tiek daug galimybių platformoje.
Greitai į priekį į šiandieną. Viskas labai pasikeitė. Šių galimybių ne tik turime daugiau nei bet kada anksčiau, bet ir sparčiai, kuriais jos tampa prieinamos, padidėjo. Leiskite man dar kartą užduoti klausimą: ar skirdami laiko daugiau sužinoti apie tai, kaip veikia žiniatinklis ir kas yra platformoje, jums padėtų šiandien? Visiškai taip. Išmokę suprasti žiniatinklio platformą ir ja naudotis šiandien, įgyjate didžiulį pranašumą prieš kitus kūrėjus. Nesvarbu, ar dirbate su našumu, prieinamumu, reagavimu, visa tai kartu, ar tiesiog pristatote vartotojo sąsajos funkcijas, jei norite tai daryti kaip atsakingas inžinierius, žinodami jums prieinamus įrankius galėsite greičiau ir geriau pasiekti savo tikslus. Kai kurie dalykai, kuriems jums gali nebereikėti bibliotekos Žinant, ką šiandien palaiko naršyklės, kyla klausimas: ko galime atsisakyti? Ar mums reikia div komponento, kad 2025 m. padarytume užapvalintus kampus? Žinoma, mes ne. Sienos spindulio ypatybę šiuo metu palaiko visos šiuo metu naudojamos naršyklės daugiau nei 15 metų. Netrukus pasirodys ir kampo forma, skirta dar įdomesniems kampams. Pažvelkime į palyginti naujausias funkcijas, kurios dabar pasiekiamos visose pagrindinėse naršyklėse ir kurias galite naudoti norėdami pakeisti esamas priklausomybes savo kodų bazėje. Esmė ne iš karto atsisakyti visų mėgstamų bibliotekų ir perrašyti savo kodų bazę. Kalbant apie visa kita, pirmiausia turėsite atsižvelgti į naršyklės palaikymą ir nuspręsti pagal kitus jūsų projektui būdingus veiksnius. Toliau nurodytos funkcijos įdiegtos trijuose pagrindiniuose naršyklės varikliuose („Chromium“, „WebKit“ ir „Gecko“), tačiau gali būti taikomi skirtingi naršyklės palaikymo reikalavimai, dėl kurių negalite jų iš karto naudoti. Vis dėlto dabar vis dar tinkamas metas sužinoti apie šias funkcijas ir galbūt kada nors planuoti jas panaudoti. Iššokimai ir dialogai Popover API,
Žinoma, jūsų interneto ryšio greitis tikriausiai taip pat padidėjo, bet tai ne visiems. Ir ne visi turi vienodas įrenginio galimybes. Vietoj to, jei įtrauksite trečiosios šalies kodą dalykams, kuriuos galite atlikti naudodami platformą, greičiausiai atsiųsite daugiau kodo ir pasieksite mažiau klientų nei įprastai. Žiniatinklyje blogas įkėlimo našumas lemia didelį atsisakymo skaičių ir kenkia prekės ženklo reputacijai. Įrenginiuose veikia mažiau kodo Be to, kodas, kurį siunčiate savo klientų įrenginiuose, greičiausiai veiks greičiau, jei platformos viršuje bus naudojama mažiau „JavaScript“ abstrakcijų. Jis taip pat tikriausiai labiau reaguoja ir lengviau pasiekiamas pagal numatytuosius nustatymus. Visa tai veda prie daugiau ir laimingesnių klientų. Peržiūrėkite mano kolegos Alexo Russello metinį našumo nelygybės skirtumo tinklaraštį, kuriame matyti, kad aukščiausios kokybės įrenginių rinkose, kuriose yra milijardai vartotojų, dėl turto nelygybės iš esmės nėra. Ir šis atotrūkis laikui bėgant tik didėja.
Įmontuotas mūrinis išdėstymas Viena žiniatinklio platformos funkcija, kuri netrukus pasirodys ir dėl kurios aš labai džiaugiuosi, yra CSS Masonry.
Leiskite pradėti nuo paaiškinimo, kas yra mūras. Kas yra Mūrija Mūras yra išdėstymo tipas, kurį prieš metus išpopuliarino Pinterest. Jis sukuria nepriklausomus turinio takelius, kuriuose elementai susirenka kuo arčiau takelio pradžios.
Daugelis žmonių mano, kad mūras yra puikus pasirinkimas portfeliams ir nuotraukų galerijoms, o tai tikrai gali padaryti. Tačiau mūras yra lankstesnis nei tai, ką matote Pinterest, ir neapsiriboja tik krioklio pavidalo maketais. Mūriniame išdėstyme:
Takeliai gali būti stulpeliai arba eilutės:
Turinio takeliai nebūtinai turi būti vienodo dydžio:
Elementai gali apimti kelis takelius:
Daiktai gali būti dedami į konkrečius takelius; jie neturi visada vadovautis automatinio išdėstymo algoritmu:
Demonstracinės versijos Štai keletas paprastų demonstracinių versijų, kurias sukūriau naudodamas būsimą CSS Masonry diegimą „Chromium“. Nuotraukų galerijos demonstracinė versija, rodanti, kaip elementai (šiuo atveju pavadinimas) gali apimti kelis takelius:
Kita nuotraukų galerija, kurioje rodomi skirtingų dydžių takeliai:
Naujienų svetainės išdėstymas, kai vieni takeliai platesni nei kiti, o kai kurie elementai apima visą išdėstymo plotį:
Kanban lenta, rodanti, kad daiktus galima sudėti į konkrečius takelius:
Pastaba:ankstesnės demonstracinės versijos buvo sukurtos naudojant Chromium versiją, kuri dar nepasiekiama daugumai žiniatinklio vartotojų, nes CSS Masonry dar tik pradedama diegti naršyklėse. Tačiau žiniatinklio kūrėjai jau daugelį metų mielai naudojasi bibliotekomis kurdami mūrinius maketus. Šiandien mūro naudojamos svetainės Iš tiesų, mūrininkystė šiandien yra gana paplitusi žiniatinklyje. Štai keli pavyzdžiai, kuriuos radau be Pinterest:
Ir dar keli ne tokie akivaizdūs pavyzdžiai:
Taigi, kaip buvo sukurti šie maketai? Sprendimai Vienas iš gudrybių, kurias mačiau naudojamą, yra naudoti „Flexbox“ išdėstymą, pakeisti jo kryptį į stulpelį ir nustatyti, kad jis būtų apvyniotas. Tokiu būdu skirtingo aukščio elementus galite sudėti į keletą nepriklausomų stulpelių, sukuriant mūrinio išdėstymo įspūdį:
Tačiau šis sprendimas turi du apribojimus:
Elementų tvarka skiriasi nuo tikrojo mūro išdėstymo. Naudojant Flexbox, elementai pirmiausia užpildo pirmąjį stulpelį, o kai jis pilnas, pereina į kitą stulpelį. Naudojant mūrą, daiktai būtų sukraunami į tą takelį (arba šiuo atveju stulpelį), kuriame yra daugiau vietos. Tačiau taip pat ir galbūt dar svarbiau, kad šis sprendimas reikalauja, kad nustatytumėte fiksuotą „Flexbox“ konteinerio aukštį; kitu atveju nevyktų.
Trečiųjų šalių mūro bibliotekos Pažangesniais atvejais kūrėjai naudojo bibliotekas. Labiausiai žinoma ir populiariausia biblioteka yra tiesiog vadinama Masonry ir, remiantis NPM, ji atsisiunčiama apie 200 000 kartų per savaitę. „Squarespace“ taip pat suteikia išdėstymo komponentą, kuris pateikia mūrinį išdėstymą, kad būtų be kodo alternatyva, ir daugelis svetainių jį naudoja. Abi šios parinktys naudoja „JavaScript“ kodą, kad įdėtų elementus į maketą. Įmontuotas mūras Labai džiaugiuosi, kad „Masonry“ dabar naršyklėse pradeda pasirodyti kaip integruota CSS funkcija. Laikui bėgant galėsite naudoti „Masonry“ taip pat, kaip „Grid“ ar „Flexbox“, ty nereikės jokių problemų sprendimo būdų ar trečiosios šalies kodo. Mano „Microsoft“ komanda įdiegė integruotą „Masonry“ palaikymą „Chromium“ atvirojo kodo projekte, kurio pagrindu yra „Edge“, „Chrome“ ir daugelis kitų naršyklių. „Mozilla“ iš tikrųjų buvo pirmasis naršyklės pardavėjas, kuris 2020 m. pasiūlė eksperimentinį „Masonry“ diegimą. „Apple“ taip pat labai norėjo, kad šis naujas žiniatinklio išdėstymas būtų primityvus. Darbas standartizuoti funkciją taip pat juda į priekį, CSS darbo grupė susitarė dėl bendros krypties ir netgi naujo tipo ekrano: tinklelio juostos. Jei norite sužinoti daugiau apie mūrą ir stebėti pažangą, peržiūrėkite mano CSS mūro išteklių puslapį. Laikui bėgant, kai mūras taps bazine funkcija, kaip ir „Grid“ ar „Flexbox“, galėsime ja tiesiog naudotis ir gauti naudos iš:
Geresnis našumas, Geresnis reagavimas, Lengvas naudojimas ir paprastesnis kodas.
Pažvelkime į šiuos dalykus atidžiau. Geresnis našumas Sukūrę savo į mūrą panašią išdėstymo sistemą arba naudodami trečiosios šalies biblioteką, turėsite paleisti „JavaScript“ kodą, kad galėtumėte įdėti elementus į ekraną. Tai taip pat reiškia, kad šis kodas bus blokuojamas. Iš tikrųjų arba nieko nebus rodoma, arba viskas nebus tinkamose vietose arba tinkamo dydžio, kol nebus paleistas tas „JavaScript“ kodas. Mūrinis išdėstymas dažnai naudojamas pagrindinėje tinklalapio dalyje, o tai reiškia, kad dėl kodo pagrindinis turinys būtų rodomas vėliau, nei būtų kitu atveju, o tai pablogins jūsų LCP arba didžiausio turinio dažų metriką, kuri atlieka svarbų vaidmenį suvokiant našumą ir optimizuojant paieškos variklius. Išbandžiau Masonry JS biblioteką su paprastu išdėstymu ir modeliuodamas lėtą 4G ryšį programoje DevTools. Biblioteka nėra labai didelė (24 KB, 7,8 KB gzip), bet mano bandymo sąlygomis įkelti prireikė 600 ms. Štai našumo įrašas, rodantis ilgą 600 ms Mūro bibliotekos įkėlimo laiką ir kad tuo metu nevyko jokia kita atvaizdavimo veikla:
Be to, praėjus pradiniam įkėlimo laikui, atsisiųstą scenarijų reikėjo išanalizuoti, sukompiliuoti ir paleisti. Visa tai, kaip minėta anksčiau, blokavo puslapio pateikimą. Naudojant naršyklėje integruotą mūro diegimą, neturėsime įkelti ir paleisti scenarijaus. Naršyklės variklis tiesiog atliks savo darbą pradiniame puslapio atvaizdavimo etape. Geresnis reagavimas Panašiai kaip puslapis pirmą kartą įkeliamas, pakeitus naršyklės lango dydį, tame puslapyje vėl pateikiamas išdėstymas. Tačiau šiuo metu, jei puslapis naudoja Masonry JS biblioteką, nereikia dar kartą įkelti scenarijaus, nes jis jau yračia. Tačiau kodas, perkeliantis elementus į reikiamas vietas, turi būti paleistas. Dabar atrodo, kad ši biblioteka gana greitai tai daro, kai įkeliamas puslapis. Tačiau jis animuoja elementus, kai juos reikia perkelti į kitą vietą keičiant lango dydį, ir tai labai skiriasi. Žinoma, vartotojai negaišta tiek laiko keisdami naršyklės langų dydį, kiek mes, kūrėjai. Tačiau ši animuota dydžio keitimo patirtis gali būti gana varginanti ir prailgina laiką, kurio prireikia, kol puslapis prisitaiko prie naujo dydžio. Lengvas naudojimas ir paprastesnis kodas Tai, kaip lengva naudotis žiniatinklio funkcija ir kaip paprastas atrodo kodas, yra svarbūs veiksniai, galintys turėti didelės įtakos jūsų komandai. Žinoma, jie niekada negali būti tokie svarbūs kaip galutinio vartotojo patirtis, tačiau kūrėjo patirtis turi įtakos priežiūrai. Naudojant integruotą žiniatinklio funkciją, yra svarbių pranašumų:
Kūrėjai, kurie jau žino HTML, CSS ir JS, greičiausiai galės lengvai naudotis šia funkcija, nes ji sukurta taip, kad būtų gerai integruota ir derėtų su likusia žiniatinklio platforma. Nėra pavojaus, kad bus atlikti funkcijos naudojimo pakeitimai. Beveik nėra jokios rizikos, kad ši funkcija taps nebenaudojama ar neprižiūrima.
Integruoto mūro atveju, kadangi tai yra primityvus išdėstymas, jį naudojate iš CSS, kaip ir Grid arba Flexbox, JS nedalyvauja. Be to, kitos su išdėstymu susijusios CSS savybės, pvz., tarpas, veikia taip, kaip tikitės. Nėra jokių gudrybių ar sprendimų, apie kuriuos reikia žinoti, o tai, ko išmokstate, yra dokumentuojama MDN. Masonry JS lib inicijavimas yra šiek tiek sudėtingas: norint nustatyti stulpelių ir tarpų dydžius, reikia duomenų atributo su konkrečia sintaksė ir paslėptais HTML elementais. Be to, jei norite aprėpti stulpelius, turite patys nurodyti tarpo dydį, kad išvengtumėte problemų:
Palyginkime tai su tuo, kaip atrodytų įmontuotas mūro diegimas:
Paprastesnis, kompaktiškesnis kodas, kuriame gali būti naudojami tik tokie dalykai kaip tarpas ir kur apimantys takeliai atliekami naudojant 2 intervalą, kaip ir tinklelyje, ir nereikalaujama apskaičiuoti tinkamo pločio, įskaitant tarpo dydį. Kaip sužinoti, kas yra prieinama ir kada ji yra prieinama? Apskritai, klausimas iš tikrųjų yra ne tai, ar turėtumėte naudoti įmontuotą masoniją per JS biblioteką, o greičiau, kada. „Masonry JS“ biblioteka yra nuostabi ir jau daugelį metų užpildo žiniatinklio platformos spragą ir daugeliui laimingų kūrėjų bei vartotojų. Žinoma, jis turi keletą trūkumų, jei palyginsite jį su įmontuotu mūro diegimu, tačiau jie nėra svarbūs, jei tas diegimas nėra paruoštas. Man nesunku išvardyti šias puikias naujas žiniatinklio platformos funkcijas, nes dirbu naršyklės pardavėjo paskyroje, todėl esu linkęs žinoti, kas bus. Tačiau kūrėjai dažnai apklausa po apklausos dalijasi, kad sunku sekti naujus dalykus. Sunku būti informuotam, o įmonės vis tiek ne visada teikia pirmenybę mokymuisi. Norėdami tai padaryti, pateikiame kelis šaltinius, kuriuose paprastai ir kompaktiškai pateikiami naujiniai, kad galėtumėte greitai gauti reikiamą informaciją:
Žiniatinklio platformoje yra naršyklės svetainė: Galbūt jus sudomins jo išleidimo pastabų puslapis. Ir jei jums patinka RSS, peržiūrėkite leidimo pastabų kanalą, taip pat bazinius naujienas ir plačiai prieinamus kanalus.
ŽiniatinklisPlatformos būsenos prietaisų skydelis: Jums gali patikti įvairūs pradinių metų puslapiai.
„Chrome“ platformos būsenos plano puslapis.
Jei turite šiek tiek daugiau laiko, jus taip pat gali sudominti naršyklės pardavėjų leidimo pastabos:
Chrome Kraštas Firefox Safari
Norėdami gauti dar daugiau išteklių, peržiūrėkite mano naršymo žiniatinklio platformoje lapą. Mano reikalas vis dar neįgyvendintas Tai yra kita problemos pusė. Net jei randate laiko, jėgų ir būdų sekti, vis tiek nerimaujate dėl to, kad jūsų balsas išgirstas ir įdiegtos mėgstamos funkcijos. Galbūt metų metus laukėte, kol bus išspręsta konkreti klaida arba kokia nors konkreti funkcija bus pristatyta naršyklėje, kurioje jos vis dar trūksta. Aš pasakysiu, kad naršyklių pardavėjai klauso. Aš priklausau kelioms įvairių organizacijų komandoms, kuriose nuolat diskutuojame apie kūrėjų signalus ir atsiliepimus. Mes žiūrime į daugybę skirtingų atsiliepimų šaltinių – tiek vidinių kiekvieno naršyklės pardavėjo, tiek išorinių/viešų forumuose, atvirojo kodo projektuose, tinklaraščiuose ir apklausose. Be to, mes visada stengiamės sukurti geresnius būdus, kaip kūrėjai galėtų pasidalinti savo konkrečiais poreikiais ir naudojimo atvejais. Taigi, jei galite, reikalaukite daugiau iš naršyklių pardavėjų ir spauskite mus, kad įdiegtume jums reikalingas funkcijas. Suprantu, kad tai užtrunka ir gali būti bauginanti (jau nekalbant apie didelę kliūtį patekti į rinką), bet tai taip pat veikia. Štai keli būdai, kaip išgirsti savo (ar įmonės) balsą: Dalyvaukite metinėse JS būklės, CSS būsenos ir HTML būklės apklausose. Jie vaidina svarbų vaidmenį nustatant, kaip naršyklių pardavėjai teikia pirmenybę savo darbui. Jei reikia, kad konkreti standartu pagrįsta API būtų nuosekliai įdiegta visose naršyklėse, apsvarstykite galimybę pateikti pasiūlymą kitos „Interop“ projekto iteracijos metu. Tam reikia daugiau laiko, tačiau apsvarstykite, kaip Shopify ir RUMvision bendrino savo pageidavimų sąrašus, skirtus „Interop 2026“. Tokia išsami informacija gali būti labai naudinga naršyklių pardavėjams, kad jie galėtų teikti pirmenybę. Norėdami gauti daugiau naudingų nuorodų, galinčių paveikti naršyklių pardavėjus, peržiūrėkite mano naršymo žiniatinklio platformos lapą. Išvada Baigdamas tikiuosi, kad šis straipsnis paliko jums keletą dalykų, apie kuriuos turėtumėte pagalvoti:
Džiaugsmas dėl mūro ir kitų būsimų žiniatinklio funkcijų. Keletas žiniatinklio funkcijų, kurias galbūt norėsite pradėti naudoti. Keletas pasirinktinio arba trečiosios šalies kodo dalių, kurias galbūt galėsite pašalinti, kad galėtumėte naudoti integruotas funkcijas. Keletas būdų, kaip sekti, kas ateina, ir paveikti naršyklių pardavėjus.
Dar svarbiau, tikiuosi, kad įtikinau jus, kad žiniatinklio platforma išnaudotų visas jos galimybes.
