Каля 15 гадоў таму я працаваў у кампаніі, дзе мы стваралі прыкладанні для турагентаў, работнікаў аэрапорта і авіякампаній. Мы таксама стварылі ўласную структуру для кампанентаў карыстальніцкага інтэрфейсу і магчымасцей аднастаронкавых прыкладанняў. У нас былі кампаненты для ўсяго: палі, кнопкі, укладкі, дыяпазоны, табліцы даных, меню, сродкі выбару дат, выбар і множны выбар. У нас нават быў кампанент div. Дарэчы, наш кампанент div быў выдатным, ён дазваляў нам рабіць закругленыя вуглы ва ўсіх браўзерах, што, верыце ці не, было нялёгкай справай у той час.
Наша праца адбывалася ў момант нашай гісторыі, калі JS, Ajax і дынамічны HTML разглядаліся як рэвалюцыя, якая прывяла нас у будучыню. Раптам мы маглі дынамічна абнаўляць старонку, атрымліваць даныя з сервера і пазбягаць неабходнасці пераходзіць на іншыя старонкі, што разглядалася як павольнае і міргаў вялікім белым прастакутнікам на экране паміж дзвюма старонкамі. Была фраза, якую зрабіў папулярным Джэф Этвуд (заснавальнік StackOverflow), якая абвяшчала: «Любое прыкладанне, якое можа быць напісана на JavaScript, у канчатковым выніку будзе напісана на JavaScript», — Джэф Этвуд
Для нас у той час гэта адчувалася як смеласць пайсці і стварыць гэтыя праграмы. Гэта адчувалася як поўнае адабрэнне рабіць усё з JS. Такім чынам, мы рабілі ўсё з JS, і мы сапраўды не марнавалі час на вывучэнне іншых спосабаў рабіць рэчы. Мы сапраўды не адчувалі стымулу належным чынам вывучаць, што могуць рабіць HTML і CSS. Мы на самой справе не ўспрымалі Інтэрнэт як платформу прыкладанняў, якая развіваецца ў цэлым. У асноўным мы разглядалі гэта як тое, што нам трэба абыйсці, асабліва калі справа даходзіла да падтрымкі браўзераў. Мы маглі б проста дадаць больш JS, каб зрабіць усё. Ці дапамог бы мне час, каб даведацца больш пра тое, як працуе Інтэрнэт і што даступна на платформе? Безумоўна, я мог бы скараціць кучу кода, які сапраўды не патрэбны. Але ў той час, магчыма, не так шмат. Разумееце, адрозненні ў браўзерах тады былі даволі значнымі. Гэта быў час, калі Internet Explorer па-ранейшаму быў дамінуючым браўзерам, а Firefox займаў другое месца, але пачаў губляць долю рынку з-за хуткага росту папулярнасці Chrome. Нягледзячы на тое, што Chrome і Firefox даволі добра ўзгаднілі вэб-стандарты, асяроддзе, у якім працавалі нашы праграмы, азначала, што мы павінны былі падтрымліваць IE6 на працягу доўгага часу. Нават калі нам дазволілі падтрымліваць IE8, нам усё роўна даводзілася мець справу з вялікай колькасцю адрозненняў паміж браўзерамі. Мала таго, сетка таго часу проста не мела столькі магчымасцей, убудаваных непасрэдна ў платформу.
Перамотка ў сённяшні дзень. Усё вельмі змянілася. У нас не толькі больш гэтых магчымасцей, чым калі-небудзь раней, але і хуткасць, з якой яны становяцца даступнымі, таксама павялічылася. Дазвольце мне яшчэ раз задаць пытанне: ці дапаможа вам сёння час, каб даведацца больш пра тое, як працуе Інтэрнэт і што даступна на платформе? Абсалютна так. Навучанне разуменню і выкарыстанні вэб-платформы сёння дае вам вялікую перавагу перад іншымі распрацоўшчыкамі. Незалежна ад таго, працуеце вы над прадукцыйнасцю, даступнасцю, хуткасцю рэагавання, усімі імі разам, або проста надае функцыямі карыстальніцкага інтэрфейсу, калі вы хочаце рабіць гэта як адказны інжынер, веданне даступных вам інструментаў дапаможа вам дасягнуць вашых мэтаў хутчэй і лепш. Некаторыя рэчы, для якіх вам можа больш не спатрэбіцца бібліятэка Ведаючы, якія браўзеры падтрымліваюць сёння, узнікае пытанне: ад чаго мы можам адмовіцца? Ці патрэбны нам кампанент div, каб рабіць закругленыя вуглы ў 2025 годзе? Вядома, мы не робім. На гэты момант уласцівасць border-radius падтрымліваецца ўсімі браўзерамі, якія выкарыстоўваюцца ў цяперашні час больш за 15 гадоў. Неўзабаве таксама з'явіцца кутняя форма для яшчэ больш шыкоўных куткоў. Давайце паглядзім на адносна нядаўнія функцыі, якія цяпер даступныя ва ўсіх асноўных браўзерах, і якія вы можаце выкарыстоўваць для замены існуючых залежнасцяў у вашай базе кода. Сэнс не ў тым, каб неадкладна адмовіцца ад усіх вашых любімых бібліятэк і перапісаць вашу кодавую базу. Што тычыцца ўсяго астатняга, вам трэба спачатку прыняць да ўвагі падтрымку браўзера і прыняць рашэнне на аснове іншых фактараў, характэрных для вашага праекта. Наступныя функцыі рэалізаваны ў трох асноўных рухавіках браўзера (Chromium, WebKit і Gecko), але ў вас могуць быць іншыя патрабаванні да падтрымкі браўзера, якія не дазваляюць выкарыстоўваць іх адразу. Тым не менш, зараз усё яшчэ добры час, каб даведацца пра гэтыя функцыі і, магчыма, запланаваць іх выкарыстанне ў нейкі момант. Усплывальныя вокны і дыялогі Popover API, HTML-элемент
Вядома, хуткасць вашага інтэрнэт-злучэння таксама павялічылася, але гэта не для ўсіх. І не ўсе маюць аднолькавыя магчымасці прылады. Замест старонняга кода для таго, што вы можаце рабіць з платформай, хутчэй за ўсё, вы адпраўляеце больш кода і, такім чынам, звяртаецеся да меншай колькасці кліентаў, чым звычайна. У інтэрнэце дрэнная загрузка прыводзіць да вялікай колькасці адмоваў і шкодзіць рэпутацыі брэнда. Запуск менш кода на прыладах Больш за тое, код, які вы адпраўляеце на прылады кліентаў, хутчэй за ўсё, будзе працаваць хутчэй, калі ён выкарыстоўвае менш абстракцый JavaScript на платформе. Ён таксама, верагодна, больш спагадны і больш даступны па змаўчанні. Усё гэта прыводзіць да павелічэння колькасці і шчаслівых кліентаў. Праверце штогадовы блог майго калегі Алекса Расэла аб разрыве ў няроўнасці ў прадукцыйнасці, які паказвае, што прылады прэміум-класа ў асноўным адсутнічаюць на рынках з мільярдамі карыстальнікаў з-за няроўнасці багацця. І гэты разрыў з часам толькі павялічваецца.
Планіроўка ўбудаванай мура Адна функцыя вэб-платформы, якая хутка з'явіцца і якой я вельмі рады, - гэта CSS Masonry.
Дазвольце мне пачаць з тлумачэння, што такое масонства. Што такое масонства Мур - гэта тып планіроўкі, які стаў папулярным на Pinterest шмат гадоў таму. Ён стварае незалежныя дарожкі змесціва, у якіх прадметы размяшчаюцца як мага бліжэй да пачатку дарожкі.
Многія людзі разглядаюць Masonry як выдатны варыянт для партфоліо і фотагалерэй, што, безумоўна, можа быць зроблена. Але Masonry больш гнуткі, чым тое, што вы бачыце на Pinterest, і ён не абмяжоўваецца толькі макетамі, падобнымі на вадаспад. У мураванай кампаноўцы:
Дарожкі могуць быць слупкамі або радкамі:
Не ўсе трэкі змесціва павінны быць аднолькавага памеру:
Элементы могуць ахопліваць некалькі дарожак:
Прадметы можна размяшчаць на пэўных дарожках; яны не павінны заўсёды прытрымлівацца алгарытму аўтаматычнага размяшчэння:
Дэманстрацыі Вось некалькі простых дэманстрацый, якія я зрабіў з дапамогай будучай рэалізацыі CSS Masonry у Chromium. Дэманстрацыя фотагалерэі, якая паказвае, як элементы (у дадзеным выпадку назва) могуць ахопліваць некалькі дарожак:
Яшчэ адна фотагалерэя, якая паказвае дарожкі розных памераў:
Макет навінавага сайта з некаторымі дарожкамі шырэй, чым іншыя, а некаторыя элементы займаюць усю шырыню макета:
Дошка канбан, якая паказвае, што прадметы можна размяшчаць на пэўных дарожках:
Заўвага: Theпапярэднія дэманстрацыі былі зроблены з версіяй Chromium, якая яшчэ недаступная для большасці вэб-карыстальнікаў, таму што CSS Masonry толькі пачынае ўкараняцца ў браўзеры. Тым не менш, вэб-распрацоўшчыкі ўжо шмат гадоў з задавальненнем выкарыстоўваюць бібліятэкі для стварэння макетаў Masonry. Сайты з выкарыстаннем масонства сёння Сапраўды, масонства сёння даволі часта сустракаецца ў Інтэрнэце. Вось некалькі прыкладаў, якія я знайшоў акрамя Pinterest:
І яшчэ некалькі, менш відавочных прыкладаў:
Такім чынам, як былі створаны гэтыя макеты? Абыходныя шляхі Адзін прыём, які я бачыў, - гэта выкарыстанне макета Flexbox, змяненне яго кірунку на слупок і наладжванне абгорткі. Такім чынам, вы можаце размясціць прадметы рознай вышыні ў некалькіх незалежных калонах, ствараючы ўражанне макета масонства:
Аднак у гэтага абыходнага шляху ёсць два абмежаванні:
Парадак прадметаў адрозніваецца ад таго, што было б у сапраўднай кладцы масонства. З дапамогай Flexbox элементы спачатку запаўняюць першы слупок, а калі ён запоўнены, пераходзяць да наступнага слупка. З Masonry прадметы будуць складацца ў той дарожцы (або калонцы ў дадзеным выпадку), дзе будзе больш вольнага месца. Але таксама, і, магчыма, больш важна, гэты абыходны шлях патрабуе, каб вы ўсталявалі фіксаваную вышыню для кантэйнера Flexbox; у адваротным выпадку абкручванне не адбылося б.
Масонскія бібліятэкі іншых вытворцаў Для больш складаных выпадкаў распрацоўшчыкі выкарыстоўваюць бібліятэкі. Самая вядомая і папулярная бібліятэка для гэтага называецца проста Masonry, і яна спампоўваецца каля 200 000 разоў на тыдзень, паводле NPM. Squarespace таксама забяспечвае кампанент макета, які адлюстроўвае макет Masonry, у якасці альтэрнатывы без кода, і многія сайты выкарыстоўваюць яго. Абодва гэтыя варыянты выкарыстоўваюць код JavaScript для размяшчэння элементаў у макеце. Убудаваны мур Я вельмі рады, што Masonry цяпер пачынае з'яўляцца ў браўзерах як убудаваная функцыя CSS. З часам вы зможаце выкарыстоўваць Masonry гэтак жа, як вы робіце Grid або Flexbox, гэта значыць без патрэбы ў абыходных шляхах або староннім коды. Мая каманда ў Microsoft укараняе ўбудаваную падтрымку Masonry у праект з адкрытым зыходным кодам Chromium, на якім заснаваны Edge, Chrome і многія іншыя браўзеры. Mozilla была першым пастаўшчыком браўзераў, які прапанаваў эксперыментальную рэалізацыю Masonry яшчэ ў 2020 годзе. Apple таксама была вельмі зацікаўлена ў тым, каб зрабіць гэты новы вэб-макет прымітыўным. Праца па стандартызацыі гэтай функцыі таксама ідзе наперад, у рабочай групе CSS дасягнута дамоўленасць аб агульным кірунку і нават аб новым тыпе дысплея: сетцы. Калі вы хочаце даведацца больш пра масонства і сачыць за прагрэсам, праверце маю старонку рэсурсаў CSS Masonry. З часам, калі Masonry стане функцыяй Baseline, гэтак жа, як Grid або Flexbox, мы зможам проста выкарыстоўваць яе і атрымліваць выгаду ад:
Лепшая прадукцыйнасць, Лепшая спагадлівасць, Прастата выкарыстання і больш просты код.
Давайце больш падрабязна разгледзім іх. Лепшая прадукцыйнасць Стварэнне ўласнай сістэмы раскладкі, падобнай на Masonry, або выкарыстанне старонняй бібліятэкі азначае, што вам трэба будзе запусціць код JavaScript, каб размясціць элементы на экране. Гэта таксама азначае, што гэты код будзе блакіраваць візуалізацыю. Сапраўды, альбо нічога не з'явіцца, альбо рэчы не будуць знаходзіцца ў патрэбных месцах і не будуць патрэбнага памеру, пакуль гэты код JavaScript не будзе запушчаны. Макет Masonry часта выкарыстоўваецца для асноўнай часткі вэб-старонкі, што азначае, што код зробіць так, каб ваш асноўны змест з'яўляўся пазней, чым гэта магло б адбыцца ў адваротным выпадку, пагаршаючы ваш LCP або метрыку Largest Contentful Paint, якая адыгрывае вялікую ролю ў ўспрыманні прадукцыйнасці і аптымізацыі пошукавай сістэмы. Я пратэставаў бібліятэку Masonry JS з простай кампаноўкай і мадэляваннем павольнага злучэння 4G у DevTools. Бібліятэка не вельмі вялікая (24 КБ, 7,8 КБ у сціснутым архіве), але для загрузкі ў маіх тэставых умовах спатрэбілася 600 мс. Вось запіс прадукцыйнасці, які паказвае гэты доўгі час загрузкі 600 мс для бібліятэкі Masonry і тое, што падчас гэтага не адбывалася ніякіх іншых дзеянняў па візуалізацыі:
Акрамя таго, пасля першапачатковага часу загрузкі загружаны скрыпт трэба было прааналізаваць, скампіляваць і затым запусціць. Усё гэта, як згадвалася раней, блакавала візуалізацыю старонкі. З убудаванай рэалізацыяй Masonry ў браўзеры ў нас не будзе скрыпту для загрузкі і запуску. Рухавік браўзера проста зробіць сваю справу падчас пачатковага этапу візуалізацыі старонкі. Лепшая спагадлівасць Як і пры першай загрузцы старонкі, змяненне памеру акна браўзера прыводзіць да паўторнага адлюстравання макета гэтай старонкі. Аднак на дадзены момант, калі старонка выкарыстоўвае бібліятэку Masonry JS, няма неабходнасці зноў загружаць скрыпт, таму што ён ужотут. Аднак код, які перамяшчае элементы ў патрэбныя месцы, павінен працаваць. Цяпер гэтая канкрэтная бібліятэка, здаецца, даволі хутка робіць гэта пры загрузцы старонкі. Аднак ён ажыўляе элементы, калі іх трэба перамясціць у іншае месца пры змене памеру акна, і гэта мае вялікае значэнне. Вядома, карыстальнікі не марнуюць час на змяненне памеру вокнаў браўзера так шмат, як мы, распрацоўшчыкі. Але гэта аніміраванае змяненне памеру можа быць вельмі раздражняльным і павялічвае адчувальны час, неабходны для адаптацыі старонкі да новага памеру. Прастата выкарыстання і больш просты код Наколькі лёгка выкарыстоўваць вэб-функцыю і наколькі просты код выглядае, важныя фактары, якія могуць мець вялікае значэнне для вашай каманды. Вядома, яны ніколі не могуць быць такімі ж важнымі, як канчатковы карыстацкі досвед, але вопыт распрацоўшчыка ўплывае на абслугоўванне. Выкарыстанне ўбудаванай вэб-функцыі дае важныя перавагі ў гэтым плане:
Распрацоўшчыкі, якія ўжо ведаюць HTML, CSS і JS, хутчэй за ўсё, змогуць лёгка выкарыстоўваць гэтую функцыю, таму што яна была распрацавана для добрай інтэграцыі і адпаведнасці з астатняй вэб-платформай. Няма рызыкі парушыць змены ў тым, як выкарыстоўваецца функцыя. Існуе амаль нулявы рызыка таго, што гэтая функцыя састарэе або не падтрымліваецца.
У выпадку ўбудаванай Masonry, паколькі гэта прымітыў макета, вы выкарыстоўваеце яго з CSS, гэтак жа, як Grid або Flexbox, без JS. Акрамя таго, іншыя ўласцівасці CSS, звязаныя з макетам, такія як прабел, працуюць так, як вы чакаеце. Тут няма ніякіх хітрасцяў і абыходных шляхоў, і тое, што вы даведаецеся, задакументавана на MDN. Для Masonry JS lib ініцыялізацыя трохі складаная: яна патрабуе атрыбута дадзеных з пэўным сінтаксісам, а таксама схаваных элементаў HTML для ўстаноўкі памераў слупкоў і прабелаў. Акрамя таго, калі вы хочаце ахапіць слупкі, вам трэба самастойна ўключыць памер прабелу, каб пазбегнуць праблем:
<стыль> .track-size, .item { шырыня: 20%; } .gutter-sizer { шырыня: 1бэр; } .item { вышыня: 100 пікселяў; margin-block-end: 1rem; } .item:nth-child(odd) { вышыня: 200 пікселяў; } .item--width2 { шырыня: calc(40% + 1rem); }
Давайце параўнаем гэта з тым, як будзе выглядаць убудаваная рэалізацыя Masonry: <стыль> .кантэйнер { адлюстраванне: сетка-палосы; grid-lanes: repeat(4, 20%); зазор: 1бэр; } .item { вышыня: 100 пікселяў; } .item:nth-child(odd) { вышыня: 200 пікселяў; } .item--width2 { сетка-слупок: пралёт 2; }
Больш просты і кампактны код, які можа выкарыстоўваць такія рэчы, як прамежак і дзе ахопліваючыя дарожкі выконваюцца з прамежкам 2, як і ў сетцы, і не патрабуе вылічэння патрэбнай шырыні, якая ўключае памер прабелу. Як даведацца, што даступна і калі гэта даступна? Увогуле, пытанне не ў тым, ці варта вам выкарыстоўваць убудаваную Masonry замест бібліятэкі JS, а ў тым, калі. Бібліятэка Masonry JS дзіўная і запаўняе прабел у вэб-платформе на працягу многіх гадоў, і для многіх шчаслівых распрацоўшчыкаў і карыстальнікаў. Вядома, у яго ёсць некалькі недахопаў, калі параўноўваць яго з убудаванай рэалізацыяй Masonry, але яны не важныя, калі гэтая рэалізацыя не гатовая. Мне лёгка пералічыць гэтыя цікавыя новыя функцыі вэб-платформы, таму што я працую ў пастаўшчыка браўзераў, і таму я імкнуся ведаць, што будзе. Але распрацоўшчыкі часта дзеляцца, апытанне за апытаннем, што адсочваць новыя рэчы складана. Заставацца ў курсе складана, і ў любым выпадку кампаніі не заўсёды аддаюць перавагу навучанню. Каб дапамагчы з гэтым, вось некалькі рэсурсаў, якія забяспечваюць абнаўленні простымі і кампактнымі спосабамі, каб вы маглі хутка атрымаць патрэбную інфармацыю:
Вэб-платформа мае правадыр сайта: Вас можа зацікавіць яго старонка заўваг да выпуску. І, калі вам падабаецца RSS, праверце стужку заўваг аб выпуску, а таксама стужкі Baseline Newly Available і Widely Available.
СеціваПанэль кіравання статусам платформы: Магчыма, вам спадабаюцца яго розныя старонкі базавага года.
Старонка дарожнай карты стану платформы Chrome.
Калі ў вас ёсць крыху больш часу, вас таксама могуць зацікавіць заўвагі да выпуску пастаўшчыкоў браўзераў:
Chrome край Firefox Сафары
Каб атрымаць яшчэ больш рэсурсаў, праверце маю шпаргалку "Навігацыя па вэб-платформе". Мая справа ўсё яшчэ не рэалізавана Гэта другі бок праблемы. Нават калі вы знаходзіце час, энергію і спосабы адсочвання, усё роўна застаецца расчараванне ў тым, каб ваш голас быў пачуты і вашы любімыя функцыі рэалізаваны. Магчыма, вы гадамі чакалі вырашэння пэўнай памылкі або ўключэння пэўнай функцыі ў браўзер, дзе яе ўсё яшчэ няма. Я скажу, што пастаўшчыкі браўзераў прыслухоўваюцца. Я ўваходжу ў некалькі міжарганізацыйных каманд, дзе мы ўвесь час абмяркоўваем сігналы распрацоўшчыкаў і водгукі. Мы разглядаем мноства розных крыніц зваротнай сувязі, як унутраных у кожнага пастаўшчыка браўзераў, так і знешніх/публічных на форумах, праектах з адкрытым зыходным кодам, блогах і апытаннях. І мы заўсёды спрабуем стварыць лепшыя спосабы для распрацоўшчыкаў падзяліцца сваімі канкрэтнымі патрэбамі і варыянтамі выкарыстання. Такім чынам, калі вы можаце, патрабуйце ад пастаўшчыкоў браўзераў большага і цісніце на нас, каб мы ўкаранілі неабходныя вам функцыі. Я разумею, што гэта патрабуе часу, а таксама можа выклікаць страх (не кажучы ўжо пра высокі ўваходны бар'ер), але гэта таксама працуе. Вось некалькі спосабаў, як вы можаце пачуць свой голас (або голас вашай кампаніі): прыняць удзел у штогадовых апытаннях "Стан JS", "Стан CSS" і "Стан HTML". Яны гуляюць вялікую ролю ў тым, як пастаўшчыкі браўзераў вызначаюць прыярытэты сваёй працы. Калі вам патрэбен пэўны стандартны API, які будзе паслядоўна рэалізаваны ў браўзерах, падумайце аб адпраўцы прапановы на наступнай ітэрацыі праекта Interop. Гэта патрабуе больш часу, але падумайце, як Shopify і RUMvision падзяліліся сваімі спісамі пажаданняў для Interop 2026. Падобная падрабязная інфармацыя можа быць вельмі карыснай для пастаўшчыкоў браўзераў, каб расставіць прыярытэты. Для атрымання больш карысных спасылак, каб паўплываць на пастаўшчыкоў браўзераў, азнаёмцеся з маёй шпаргалкай "Навігацыя па вэб-платформе". Заключэнне На заканчэнне я спадзяюся, што гэты артыкул пакіне вам некалькі рэчаў, над якімі варта падумаць:
Хваляванне для Masonry і іншых будучых вэб-функцый. Некалькі вэб-функцый, якімі вы можаце пачаць карыстацца. Некалькі фрагментаў карыстальніцкага або старонняга кода, які вы можаце выдаліць на карысць убудаваных функцый. Некалькі спосабаў сачыць за тым, што адбываецца, і ўплываць на пастаўшчыкоў браўзераў.
Што яшчэ больш важна, я спадзяюся, што я пераканаў вас у перавагах выкарыстання вэб-платформы ў поўнай меры.
