Apmēram pirms 15 gadiem es strādāju uzņēmumā, kurā mēs veidojām lietotnes ceļojumu aģentiem, lidostu darbiniekiem un aviokompānijām. Mēs arī izveidojām savu iekšējo sistēmu lietotāja saskarnes komponentiem un vienas lapas lietotņu iespējām. Mums bija komponenti visam: lauki, pogas, cilnes, diapazoni, datu tabulas, izvēlnes, datumu atlasītāji, atlases un vairākas atlases. Mums pat bija div komponents. Mūsu div komponents, starp citu, bija lielisks, tas ļāva mums izveidot noapaļotus stūrus visās pārlūkprogrammās, kas, ticiet vai nē, tolaik nebija viegli izdarāms.
Mūsu darbs norisinājās mūsu vēstures brīdī, kad JS, Ajax un dinamiskais HTML tika uzskatīts par revolūciju, kas mūs ieveda nākotnē. Pēkšņi mēs varējām dinamiski atjaunināt lapu, iegūt datus no servera un izvairīties no nepieciešamības pārvietoties uz citām lapām, kas tika uzskatīta par lēnu un ekrānā starp abām lapām mirgo liels balts taisnstūris. Bija frāze, ko populāru padarīja Džefs Atvuds (StackOverflow dibinātājs), un kas skanēja: "Jebkura lietojumprogramma, ko var rakstīt JavaScript, galu galā tiks rakstīta JavaScript." - Džefs Atvuds
Mums tajā laikā tas šķita kā uzdrīkstēšanās iet un izveidot šīs lietotnes. Likās kā vispārējs apstiprinājums darīt visu ar JS. Tāpēc mēs visu darījām ar JS, un mēs īsti netērējām laiku, lai izpētītu citus darbības veidus. Mēs īsti nejutām stimulu pareizi apgūt HTML un CSS iespējas. Mēs īsti neuztvērām tīmekli kā attīstošu lietotņu platformu kopumā. Lielākoties mēs to uzskatījām par kaut ko, kas mums jārisina, it īpaši attiecībā uz pārlūkprogrammas atbalstu. Mēs varētu mest vairāk JS, lai paveiktu lietas. Vai veltītais laiks, lai uzzinātu vairāk par to, kā tīmeklis darbojas un kas bija pieejams platformā, būtu man palīdzējis? Protams, es droši vien būtu varējis noskūt virkni koda, kas patiesībā nebija vajadzīgs. Bet tajā laikā varbūt ne tik daudz. Redziet, pārlūkprogrammu atšķirības toreiz bija diezgan ievērojamas. Tas bija laiks, kad Internet Explorer joprojām bija dominējošā pārlūkprogramma, kur Firefox bija tuvu otrajā vietā, bet sāka zaudēt tirgus daļu, jo Chrome strauji kļūst arvien populārāks. Lai gan pārlūkprogrammas Chrome un Firefox diezgan labi spēja vienoties par tīmekļa standartiem, vide, kurā darbojās mūsu lietotnes, nozīmēja, ka mums ilgu laiku bija jāatbalsta IE6. Pat tad, kad mums bija atļauts atbalstīt IE8, mums joprojām bija jārisina daudz atšķirību starp pārlūkprogrammām. Ne tikai tas, bet arī tā laika tīmeklī nebija tik daudz iespēju, kas iebūvētas tieši platformā.
Ātri uz priekšu uz šodienu. Lietas ir ārkārtīgi mainījušās. Mums ir ne tikai vairāk šo iespēju nekā jebkad agrāk, bet arī ir palielinājies to pieejamības ātrums. Ļaujiet man vēlreiz uzdot jautājumu: vai, veltot laiku, lai uzzinātu vairāk par to, kā tīmeklis darbojas un kas ir pieejams platformā, jums šodien palīdzētu? Pilnīgi jā. Mācoties izprast un izmantot tīmekļa platformu šodien, jūs iegūstat milzīgas priekšrocības salīdzinājumā ar citiem izstrādātājiem. Neatkarīgi no tā, vai strādājat ar veiktspēju, pieejamību, atsaucību, to visu kopā vai vienkārši piegādājat lietotāja saskarnes funkcijas, ja vēlaties to darīt kā atbildīgs inženieris, pieejamo rīku pārzināšana palīdz ātrāk un labāk sasniegt savus mērķus. Dažas lietas, kurām, iespējams, vairs nav vajadzīga bibliotēka Zinot, ko mūsdienās atbalsta pārlūkprogrammas, rodas jautājums: ko mēs varam atteikties? Vai mums ir nepieciešams div komponents, lai 2025. gadā izveidotu noapaļotus stūrus? Protams, mēs to nedarām. Robežas rādiusa rekvizītu jau vairāk nekā 15 gadus atbalsta visas pašlaik izmantotās pārlūkprogrammas. Drīzumā būs pieejama arī stūra forma, kas paredzēta vēl pievilcīgākiem stūriem. Apskatīsim salīdzinoši nesenos līdzekļus, kas tagad ir pieejami visās lielākajās pārlūkprogrammās un kurus varat izmantot, lai aizstātu esošās atkarības savā kodu bāzē. Lieta nav nekavējoties pamest visas iecienītās bibliotēkas un pārrakstīt kodu bāzi. Attiecībā uz visu pārējo jums vispirms ir jāņem vērā pārlūkprogrammas atbalsts un jāizlemj, pamatojoties uz citiem jūsu projektam raksturīgiem faktoriem. Tālāk norādītās funkcijas ir ieviestas trīs galvenajās pārlūkprogrammas programmās (Chromium, WebKit un Gecko), taču jums var būt atšķirīgas pārlūkprogrammas atbalsta prasības, kas neļauj tās izmantot uzreiz. Tomēr tagad joprojām ir piemērots laiks, lai uzzinātu par šīm funkcijām un, iespējams, kādreiz plānojiet tās izmantot. Popovers un dialogi Popover API,
Protams, arī jūsu interneta savienojuma ātrums, iespējams, ir palielinājies, taču tas neattiecas uz visiem. Un ne visiem ir vienādas ierīces iespējas. Tā vietā trešās puses koda izmantošana darbībām, ko varat darīt ar platformu, visticamāk, nozīmē, ka nosūtāt vairāk koda un tādējādi sasniedzat mazāk klientu nekā parasti. Tīmeklī slikta ielādes veiktspēja izraisa lielu atteikšanās gadījumu skaitu un kaitē zīmola reputācijai. Ierīcēs darbojas mazāk koda Turklāt kods, ko nosūtāt klientu ierīcēs, visticamāk, darbosies ātrāk, ja platformas augšdaļā tiek izmantots mazāk JavaScript abstrakciju. Iespējams, tas ir arī atsaucīgāks un pēc noklusējuma pieejamāks. Tas viss rada vairāk un laimīgāku klientu. Apskatiet mana kolēģa Aleksa Rasela ikgadējo veiktspējas nevienlīdzības atšķirības emuāru, kurā redzams, ka bagātības nevienlīdzības dēļ augstākās kvalitātes ierīces lielākoties nav pieejamas tirgos ar miljardiem lietotāju. Un šī plaisa laika gaitā tikai palielinās.
Iebūvēts mūra izkārtojums Viena tīmekļa platformas funkcija, kas drīzumā būs pieejama un par ko esmu ļoti sajūsmā, ir CSS Masonry.
Ļaujiet man sākt, paskaidrojot, kas ir mūrēšana. Kas ir mūrēšana Mūris ir izkārtojuma veids, ko pirms gadiem populārs padarīja Pinterest. Tas rada neatkarīgus satura ierakstus, kuros vienumi tiek salikti pēc iespējas tuvāk ieraksta sākumam.
Daudzi cilvēki uzskata, ka mūrēšana ir lieliska iespēja portfeļiem un foto galerijām, ko tas noteikti var darīt. Taču Masonry ir elastīgāks par to, ko redzat vietnē Pinterest, un tas neaprobežojas tikai ar ūdenskritumam līdzīgiem izkārtojumiem. Mūra izkārtojumā:
Trases var būt kolonnas vai rindas:
Visiem satura ierakstiem nav jābūt vienāda izmēra.
Vienumi var aptvert vairākus ierakstus:
Preces var novietot uz noteiktām trasēm; tiem ne vienmēr ir jāievēro automātiskās izvietošanas algoritms:
Demonstrācijas Šeit ir dažas vienkāršas demonstrācijas, kuras izveidoju, izmantojot gaidāmo CSS Masonry ieviešanu programmā Chromium. Fotoattēlu galerijas demonstrācija, kas parāda, kā vienumi (šajā gadījumā nosaukums) var aptvert vairākus ierakstus:
Vēl viena fotogalerija, kurā redzamas dažāda izmēra trases:
Ziņu vietnes izkārtojums, kurā daži ieraksti ir platāki nekā citi, un daži vienumi aptver visu izkārtojuma platumu:
Kanban dēlis, kas parāda, ka vienumus var ievietot noteiktās trasēs:
Piezīme:Iepriekšējās demonstrācijas tika veidotas ar Chromium versiju, kas vēl nav pieejama lielākajai daļai tīmekļa lietotāju, jo CSS Masonry tikai tagad tiek ieviests pārlūkprogrammās. Tomēr tīmekļa izstrādātāji jau gadiem ilgi ir laimīgi izmantojuši bibliotēkas, lai izveidotu mūra izkārtojumus. Vietnes, kurās izmanto mūri šodien Patiešām, mūrēšana mūsdienās ir diezgan izplatīta tīmeklī. Šeit ir daži piemēri, ko atradu bez Pinterest:
Un vēl daži, mazāk acīmredzami piemēri:
Tātad, kā tika izveidoti šie izkārtojumi? Risinājumi Viens triks, ko esmu redzējis, ir tā vietā izmantot Flexbox izkārtojumu, mainot virzienu uz kolonnu un iestatot iesaiņojumu. Tādā veidā jūs varat novietot dažāda augstuma priekšmetus vairākās, neatkarīgās kolonnās, radot iespaidu par mūra izkārtojumu:
Tomēr šim risinājumam ir divi ierobežojumi:
Preču secība atšķiras no tā, kāda tā būtu īsta mūra izkārtojuma gadījumā. Izmantojot Flexbox, vienumi vispirms aizpilda pirmo kolonnu un, kad tā ir pilna, pāriet uz nākamo kolonnu. Izmantojot Masonry, vienumi tiks sakrauti tajā celiņā (vai šajā gadījumā kolonnā), kurā ir vairāk vietas. Bet arī un, iespējams, vēl svarīgāk, šim risinājumam ir jāiestata fiksēts Flexbox konteinera augstums; pretējā gadījumā iesaiņošana nenotiktu.
Trešo pušu mūra bibliotēkas Izvērstākos gadījumos izstrādātāji ir izmantojuši bibliotēkas. Vispazīstamākā un populārākā bibliotēka tiek vienkārši saukta par Masonry, un saskaņā ar NPM tā tiek lejupielādēta aptuveni 200 000 reižu nedēļā. Squarespace nodrošina arī izkārtojuma komponentu, kas atveido mūra izkārtojumu bezkoda alternatīvai, un daudzas vietnes to izmanto. Abas šīs opcijas izmanto JavaScript kodu, lai ievietotu vienumus izkārtojumā. Iebūvēts mūris Esmu ļoti sajūsmā, ka Masonry tagad sāk parādīties pārlūkprogrammās kā iebūvēta CSS funkcija. Laika gaitā jūs varēsiet izmantot Masonry tāpat kā Grid vai Flexbox, tas ir, bez jebkādiem risinājumiem vai trešās puses koda. Mana Microsoft komanda ir ieviesusi iebūvētu Masonry atbalstu Chromium atvērtā pirmkoda projektā, uz kura pamatā ir Edge, Chrome un daudzas citas pārlūkprogrammas. Mozilla faktiski bija pirmais pārlūkprogrammas pārdevējs, kas ierosināja eksperimentālu Masonry ieviešanu 2020. gadā. Un arī Apple ir ļoti ieinteresēts, lai šis jaunais tīmekļa izkārtojums būtu primitīvs. Darbs, lai standartizētu funkciju, arī virzās uz priekšu, CSS darba grupā vienojoties par vispārējo virzienu un pat jaunu displeja veida displeju: režģa joslas. Ja vēlaties uzzināt vairāk par mūrniecību un izsekot progresam, skatiet manu CSS mūra resursu lapu. Ar laiku, kad mūrēšana kļūs par bāzes funkciju, tāpat kā Grid vai Flexbox, mēs varēsim to vienkārši izmantot un gūt labumu no:
Labāka veiktspēja, Labāka atsaucība, Vienkārša lietošana un vienkāršāks kods.
Apskatīsim šīs lietas tuvāk. Labāka veiktspēja Izveidojot savu mūrēšanai līdzīgu izkārtojuma sistēmu vai tā vietā izmantojot trešās puses bibliotēku, jums būs jāpalaiž JavaScript kods, lai vienumus ievietotu ekrānā. Tas arī nozīmē, ka šis kods bloķēs renderēšanu. Patiešām, vai nu nekas neparādīsies, vai arī lietas nebūs pareizajās vietās vai pareizajā izmērā, kamēr šis JavaScript kods nebūs palaists. Mūrētais izkārtojums bieži tiek izmantots tīmekļa lapas galvenajai daļai, kas nozīmē, ka kods liks jūsu galvenajam saturam parādīties vēlāk, nekā tas citādi varētu būt, pasliktinot jūsu LCP jeb lielākās satura krāsas metriku, kam ir liela nozīme uztveres veiktspējā un meklētājprogrammu optimizācijā. Es pārbaudīju Masonry JS bibliotēku ar vienkāršu izkārtojumu un simulējot lēnu 4G savienojumu programmā DevTools. Bibliotēka nav ļoti liela (24 KB, 7,8 KB gzip), taču tā ielāde prasīja 600 ms manos testa apstākļos. Šeit ir veiktspējas ieraksts, kas parāda, ka Mūra bibliotēkas ielādes laiks ir 600 ms un ka šīs darbības laikā nenotika neviena cita renderēšanas darbība:
Turklāt pēc sākotnējās ielādes laika lejupielādētais skripts bija jāparsē, jāapkopo un pēc tam jāpalaiž. Tas viss, kā minēts iepriekš, bloķēja lapas renderēšanu. Izmantojot pārlūkprogrammā iebūvētu Masonry ieviešanu, mums nebūs skripta, ko ielādēt un palaist. Pārlūka dzinējs tikai darīs savu darbu sākotnējā lapas renderēšanas posmā. Labāka atsaucība Līdzīgi kā tad, kad lapa tiek ielādēta pirmo reizi, pārlūkprogrammas loga lieluma maiņa noved pie šīs lapas izkārtojuma atkārtotas atveidošanas. Tomēr šajā brīdī, ja lapa izmanto Masonry JS bibliotēku, skripts nav jāielādē vēlreiz, jo tas jau iršeit. Tomēr ir jāpalaiž kods, kas pārvieto vienumus pareizajās vietās. Tagad šķiet, ka šī konkrētā bibliotēka to dara diezgan ātri, kad lapa tiek ielādēta. Tomēr tas animē vienumus, kad tie ir jāpārvieto uz citu vietu, mainot loga izmēru, un tas rada lielas atšķirības. Protams, lietotāji netērē laiku, mainot pārlūkprogrammas logu izmērus, kā mēs, izstrādātāji. Taču šī animētā izmēra maiņa var būt diezgan satraucoša un palielina laiku, kas nepieciešams, lai lapa pielāgotos jaunajam izmēram. Vienkārša lietošana un vienkāršāks kods Tas, cik viegli ir izmantot tīmekļa funkciju un cik vienkāršs izskatās kods, ir svarīgi faktori, kas var būtiski ietekmēt jūsu komandu. Protams, tie nekad nevar būt tik svarīgi kā gala lietotāja pieredze, taču izstrādātāja pieredze ietekmē apkopi. Izmantojot iebūvēto tīmekļa funkciju, šajā jomā ir svarīgas priekšrocības:
Izstrādātāji, kuri jau zina HTML, CSS un JS, visticamāk, varēs viegli izmantot šo funkciju, jo tā ir izstrādāta tā, lai tā labi integrētos un atbilstu pārējai tīmekļa platformai. Nav riska, ka funkcijas izmantošanas veidā tiks ieviestas izmaiņas. Pastāv gandrīz nulle risks, ka šī funkcija novecos vai netiks uzturēta.
Iebūvētā Masonry gadījumā, tā kā tas ir primitīvs izkārtojums, jūs to izmantojat no CSS, tāpat kā Grid vai Flexbox, bez JS. Arī citi ar izkārtojumu saistīti CSS rekvizīti, piemēram, sprauga, darbojas tā, kā jūs to gaidāt. Nav jāzina nekādi triki vai risinājumi, un jūsu apgūtās lietas ir dokumentētas MDN. Masonry JS lib inicializācija ir nedaudz sarežģīta: tai ir nepieciešams datu atribūts ar noteiktu sintaksi, kā arī slēptie HTML elementi, lai iestatītu kolonnas un atstarpes izmērus. Turklāt, ja vēlaties aptvert kolonnas, jums pašam jāiekļauj atstarpes lielums, lai izvairītos no problēmām.
Salīdzināsim to ar to, kā izskatītos iebūvēta mūra ieviešana:
Vienkāršāks, kompaktāks kods, kurā var vienkārši izmantot tādas lietas kā atstarpe un kur sliežu ceļi tiek veikti ar 2. laidumu, tāpat kā režģī, un nav nepieciešams aprēķināt pareizo platumu, kas ietver atstarpes izmēru. Kā uzzināt, kas ir pieejams un kad tas ir pieejams? Kopumā jautājums nav par to, vai JS bibliotēkā vajadzētu izmantot iebūvēto Masonry, bet gan par to, kad. Masonry JS bibliotēka ir pārsteidzoša, un tā jau daudzus gadus aizpilda tīmekļa platformas robus, un daudziem laimīgiem izstrādātājiem un lietotājiem. Protams, tam ir daži trūkumi, ja to salīdzina ar iebūvētu mūra ieviešanu, taču tie nav svarīgi, ja šī ieviešana nav gatava. Man ir viegli uzskaitīt šīs lieliskās jaunās tīmekļa platformas funkcijas, jo es strādāju pie pārlūkprogrammas pārdevēja, un tāpēc man ir tendence zināt, kas gaidāms. Taču izstrādātāji bieži vien aptauju pēc aptaujas stāsta, ka ir grūti izsekot jaunām lietām. Ir grūti būt informētam, un uzņēmumi ne vienmēr piešķir mācīšanos par prioritāti. Lai to izdarītu, šeit ir daži resursi, kas nodrošina vienkāršus un kompaktus atjauninājumus, lai jūs varētu ātri iegūt nepieciešamo informāciju.
Tīmekļa platforma piedāvā pārlūkprogrammas vietni: Jūs varētu interesēt tā izlaiduma piezīmju lapa. Un, ja jums patīk RSS, apskatiet izlaiduma piezīmju plūsmu, kā arī bāzes līnijas jaunpieejamās un plaši pieejamās plūsmas.
TīmeklisPlatformas statusa informācijas panelis: Jums varētu patikt tās dažādās bāzes gada lapas.
Chrome platformas statusa ceļveža lapa.
Ja jums ir nedaudz vairāk laika, jūs varētu interesēt arī pārlūkprogrammu piegādātāju izlaiduma piezīmes:
Chrome Mala Firefox Safari
Lai iegūtu vēl vairāk resursu, skatiet manu navigācijas tīmekļa platformas cheatsheet. Mana lieta joprojām nav īstenota Tā ir problēmas otra puse. Pat ja atrodat laiku, enerģiju un veidus, kā sekot līdzi, joprojām ir neapmierinātība ar jūsu balss sadzirdēšanu un iecienītāko funkciju ieviešanu. Iespējams, jūs jau gadiem ilgi gaidījāt, līdz tiks novērsta noteikta kļūda vai kāda konkrēta funkcija tiks piegādāta pārlūkprogrammā, kurā tās joprojām trūkst. Es teikšu, ka pārlūkprogrammu pārdevēji klausās. Esmu daļa no vairākām starporganizāciju komandām, kurās mēs visu laiku apspriežam izstrādātāju signālus un atsauksmes. Mēs aplūkojam daudzus dažādus atsauksmju avotus — gan iekšējos pie katra pārlūkprogrammas piegādātāja, gan ārējos/publiskos forumos, atvērtā pirmkoda projektos, emuāros un aptaujās. Un mēs vienmēr cenšamies radīt labākus veidus, kā izstrādātāji dalīties ar savām īpašajām vajadzībām un lietošanas gadījumiem. Tāpēc, ja varat, lūdzu, pieprasiet vairāk no pārlūkprogrammu pārdevējiem un piespiediet mūs ieviest vajadzīgās funkcijas. Es saprotu, ka tas prasa laiku un var būt arī biedējoši (nemaz nerunājot par augstu barjeru ienākšanai), taču tas arī darbojas. Šeit ir daži veidi, kā panākt, lai jūsu (vai sava uzņēmuma) balss tiktu sadzirdēta. Piedalieties ikgadējās JS, CSS un HTML stāvokļa aptaujās. Viņiem ir liela nozīme tajā, kā pārlūkprogrammu pārdevēji nosaka sava darba prioritātes. Ja jums ir nepieciešama īpaša uz standartu balstīta API, kas konsekventi jāievieš visās pārlūkprogrammās, apsveriet iespēju iesniegt priekšlikumu nākamajā Interop projekta iterācijā. Tas prasa vairāk laika, taču apsveriet, kā Shopify un RUMvision kopīgoja savus vēlmju sarakstus saistībā ar Interop 2026. Šāda detalizēta informācija var būt ļoti noderīga pārlūkprogrammu pārdevējiem, lai noteiktu prioritāti. Lai iegūtu noderīgākas saites, lai ietekmētu pārlūkprogrammu pārdevējus, skatiet manu navigācijas tīmekļa platformas cheatsheet. Secinājums Noslēgumā es ceru, ka šis raksts lika jums padomāt par dažām lietām:
Aizraušanās ar mūrēšanu un citām gaidāmajām tīmekļa funkcijām. Dažas tīmekļa funkcijas, kuras, iespējams, vēlēsities sākt lietot. Dažas pielāgota vai trešās puses koda daļas, kuras, iespējams, varēsiet noņemt, lai izmantotu iebūvētās funkcijas. Daži veidi, kā sekot līdzi gaidāmajam un ietekmēt pārlūkprogrammu pārdevējus.
Vēl svarīgāk ir tas, ka es ceru, ka esmu jūs pārliecinājis par priekšrocībām, ko sniedz tīmekļa platformas izmantošana pilnībā.
