Близько 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 є більш гнучким, ніж те, що ви бачите на Pinterest, і воно не обмежується лише макетами, схожими на водоспад. У кладці кладки:
Доріжки можуть бути стовпцями або рядками:
Доріжки вмісту не обов’язково мають бути однакового розміру:
Елементи можуть охоплювати кілька доріжок:
Предмети можна розмістити на певних доріжках; їм не обов’язково завжди слідувати алгоритму автоматичного розміщення:
Демо Ось кілька простих демонстрацій, які я зробив, використовуючи майбутню реалізацію CSS Masonry у Chromium. Демо-версія фотогалереї, яка показує, як елементи (у цьому випадку назва) можуть охоплювати кілька доріжок:
Ще одна фотогалерея, де зображені доріжки різного розміру:
Макет новинного сайту з деякими доріжками ширшими за інші, а деякі елементи охоплюють всю ширину макета:
Дошка канбану, яка показує, що предмети можна розміщувати на певних доріжках:
Приміткапопередні демонстрації були зроблені з версією Chromium, яка ще не доступна для більшості веб-користувачів, оскільки CSS Masonry тільки починає впроваджуватися в браузери. Однак веб-розробники вже багато років із задоволенням використовують бібліотеки для створення макетів Masonry. Сайти, де використовується масонство сьогодні Дійсно, масонство сьогодні досить поширене в Інтернеті. Ось кілька прикладів, які я знайшов, крім Pinterest:
І ще кілька менш очевидних прикладів:
Отже, як були створені ці макети? Обхідні шляхи Один трюк, який я бачив, полягає в тому, щоб замість цього використовувати макет Flexbox, змінюючи його напрямок на стовпець і налаштовуючи його на обтікання. Таким чином, ви можете розмістити предмети різної висоти в кількох незалежних стовпцях, створюючи враження макета масонства:
Однак це обхідне рішення має два обмеження:
Порядок елементів відрізняється від того, який був би у справжньому макеті масонства. У Flexbox елементи спочатку заповнюють перший стовпець, а коли він заповнений, переходять до наступного стовпця. У Masonry предмети складатимуться на будь-яку доріжку (або стовпець у цьому випадку), де є більше вільного місця. Але також, і, можливо, важливіше, цей обхідний шлях вимагає встановлення фіксованої висоти для контейнера Flexbox; інакше обгортання не відбулося б.
Сторонні бібліотеки масонства Для більш складних випадків розробники використовували бібліотеки. Найвідоміша та найпопулярніша бібліотека для цього називається просто Masonry, і згідно з NPM її завантажують близько 200 000 разів на тиждень. Squarespace також надає компонент макета, який рендерить макет Masonry, як альтернативу без коду, і багато сайтів використовують його. Обидва ці параметри використовують код JavaScript для розміщення елементів у макеті. Вбудована кладка Я дуже радий, що Masonry тепер починає з’являтися у браузерах як вбудована функція CSS. З часом ви зможете використовувати Masonry так само, як Grid або Flexbox, тобто без будь-яких обхідних шляхів або коду сторонніх розробників. Моя команда в Microsoft впроваджує вбудовану підтримку Masonry у проекті з відкритим кодом Chromium, на якому базуються Edge, Chrome і багато інших браузерів. Mozilla була фактично першим постачальником браузерів, який запропонував експериментальну реалізацію Masonry ще в 2020 році. І Apple також була дуже зацікавлена в тому, щоб зробити цей новий веб-макет примітивним. Робота зі стандартизації функції також просувається вперед, досягнувши домовленості в робочій групі CSS про загальний напрямок і навіть про новий тип відображення: сітки. Якщо ви хочете дізнатися більше про масонство та відстежувати прогрес, перегляньте мою сторінку ресурсів CSS Masonry. Згодом, коли Masonry стане базовою функцією, так само як Grid або Flexbox, ми зможемо просто використовувати її та мати переваги від:
Краща продуктивність, Краща чуйність, Простота використання та простіший код.
Давайте розглянемо їх ближче. Краща продуктивність Створення власної системи компонування, схожої на Masonry, або використання натомість сторонньої бібліотеки означає, що вам доведеться запустити код JavaScript, щоб розмістити елементи на екрані. Це також означає, що цей код буде блокувати візуалізацію. Дійсно, або нічого не з’явиться, або речі не будуть у потрібних місцях чи потрібних розмірів, доки цей код JavaScript не запуститься. Макет макета Masony часто використовується для основної частини веб-сторінки, що означає, що код змусить ваш основний вміст з’явитися пізніше, ніж це могло б відбутися в іншому випадку, погіршуючи ваш LCP або метрику малювання найбільшого вмісту, яка відіграє важливу роль у сприйнятті продуктивності та оптимізації пошукової системи. Я протестував бібліотеку Masonry JS із простим макетом і імітацією повільного з’єднання 4G у DevTools. Бібліотека не дуже велика (24 КБ, 7,8 КБ у стиснутому файлі gzip), але за моїх тестових умов для завантаження знадобилося 600 мс. Ось запис продуктивності, який показує цей довгий час завантаження 600 мс для бібліотеки Masonry, і що під час цього не відбувалося жодних інших дій рендерингу:
Крім того, після початкового часу завантаження завантажений сценарій потрібно було проаналізувати, скомпілювати та запустити. Все це, як згадувалося раніше, блокувало рендеринг сторінки. З вбудованою реалізацією Masonry у браузері ми не матимемо сценарію для завантаження та запуску. Механізм браузера просто зробить свою справу під час початкового етапу відтворення сторінки. Краща чуйність Подібно до першого завантаження сторінки, зміна розміру вікна веб-переглядача призводить до повторного відтворення макета цієї сторінки. Але на цьому етапі, якщо сторінка використовує бібліотеку Masonry JS, немає потреби завантажувати сценарій знову, оскільки він ужетут. Однак код, який переміщує елементи в потрібні місця, повинен працювати. Ця конкретна бібліотека, здається, досить швидко робить це під час завантаження сторінки. Однак він анімує елементи, коли їх потрібно перемістити в інше місце під час зміни розміру вікна, і це має велике значення. Звичайно, користувачі не витрачають час на зміну розміру вікон браузера так багато, як ми, розробники. Але цей анімований досвід зміни розміру може бути досить приголомшливим і збільшує сприйнятий час, потрібний для адаптації сторінки до нового розміру. Простота використання та простіший код Наскільки легко користуватися веб-функцією та наскільки простий код виглядає, є важливими факторами, які можуть мати велике значення для вашої команди. Звичайно, вони не можуть бути такими ж важливими, як кінцевий досвід користувача, але досвід розробника впливає на обслуговування. Використання вбудованої веб-функції дає важливі переваги на цьому фронті:
Розробники, які вже знають HTML, CSS і JS, швидше за все, зможуть легко використовувати цю функцію, оскільки її було розроблено для гарної інтеграції та узгодженості з рештою веб-платформи. Немає жодного ризику поломки змін, внесених у спосіб використання функції. Існує майже нульовий ризик того, що ця функція стане застарілою або не підтримується.
У випадку вбудованого Masonry, оскільки це примітив макета, ви використовуєте його з CSS, так само як Grid або Flexbox, без JS. Крім того, інші властивості CSS, пов’язані з макетом, такі як проміжок, працюють так, як ви очікуєте. Немає жодних хитрощів чи обхідних шляхів, про які варто знати, і те, що ви дізнаєтесь, задокументовано на MDN. Для бібліотеки Masonry JS ініціалізація є дещо складною: вона вимагає атрибута даних із певним синтаксисом разом із прихованими елементами 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: <стиль> .container { відображення: смуги-сітки; grid-lanes: повтор (4, 20%); зазор: 1рем; } .item { висота: 100 пікселів; } .item:nth-child(odd) { висота: 200 пікселів; } .item--width2 { сітка-стовпчик: проміжок 2; }
Простіший і компактніший код, який може просто використовувати такі речі, як розрив і де охоплюючі доріжки виконуються за допомогою проміжку 2, як і в сітці, і не вимагає від вас обчислення правильної ширини, яка включає розмір проміжку. Як дізнатися, що є в наявності та коли це доступно? Загалом питання полягає не в тому, чи варто використовувати вбудовану Masonry замість бібліотеки JS, а в тому, коли. Бібліотека Masonry JS є дивовижною та заповнює прогалини у веб-платформі протягом багатьох років і для багатьох щасливих розробників і користувачів. У нього, звичайно, є кілька недоліків, якщо порівнювати його з вбудованою реалізацією Masonry, але вони не важливі, якщо ця реалізація не готова. Мені легко перерахувати ці чудові нові функції веб-платформи, тому що я працюю у постачальника браузерів, і тому я прагну знати, що буде. Але розробники часто розповідають, опитування за опитуванням, що відстежувати нові речі важко. Бути в курсі справ складно, і компанії все одно не завжди віддають пріоритет навчанню. Щоб допомогти з цим, ось кілька ресурсів, які надають оновлення простими та компактними способами, щоб ви могли швидко отримати потрібну інформацію:
Веб-платформа має такі функції: Вас може зацікавити його сторінка приміток до випуску. А якщо вам подобається RSS, перегляньте канал приміток до випуску, а також канали базових нещодавно доступних і широкодоступних.
ІнтернетІнформаційна панель стану платформи: Вам можуть сподобатися різноманітні сторінки базового року.
Сторінка плану розвитку платформи Chrome.
Якщо у вас є трохи більше часу, вас також можуть зацікавити примітки до випуску постачальників браузерів:
Chrome Край Firefox Сафарі
Щоб отримати більше ресурсів, перегляньте мою шпаргалку «Навігація веб-платформою». Моя справа досі не реалізована Це інший бік проблеми. Навіть якщо ви знайдете час, енергію та способи стежити, все одно залишиться розчарування від того, щоб ваш голос почули та реалізували ваші улюблені функції. Можливо, ви роками чекали вирішення певної помилки або появи певної функції у веб-переглядачі, де її все ще немає. Я скажу, що постачальники браузерів прислухаються. Я входжу до кількох міжорганізаційних команд, де ми постійно обговорюємо сигнали та відгуки розробників. Ми розглядаємо багато різних джерел відгуків, як внутрішніх у кожного постачальника браузера, так і зовнішніх/публічних на форумах, проектах з відкритим кодом, блогах і опитуваннях. І ми завжди намагаємося створити кращі способи для розробників, щоб поділитися своїми конкретними потребами та сценаріями використання. Тож, якщо можете, будь ласка, вимагайте більше від постачальників браузерів і тисніть на нас, щоб ми запровадили потрібні вам функції. Я розумію, що це вимагає часу, а також може лякати (не кажучи вже про високий бар’єр для входу), але це також працює. Ось кілька способів, за допомогою яких ви можете почути свій голос (або голос вашої компанії): візьміть участь у щорічних опитуваннях щодо стану JS, стану CSS і стану HTML. Вони відіграють важливу роль у тому, як постачальники браузерів розставляють пріоритети у своїй роботі. Якщо вам потрібен певний стандартний API для узгодженої реалізації в усіх веб-переглядачах, надішліть пропозицію під час наступної ітерації проекту Interop. Це вимагає більше часу, але подумайте про те, як Shopify і RUMvision поділилися своїми списками побажань для Interop 2026. Подібна детальна інформація може бути дуже корисною для постачальників браузерів, щоб визначити пріоритети. Щоб отримати більше корисних посилань для впливу на постачальників браузерів, перегляньте мою шпаргалку «Навігація веб-платформою». Висновок На завершення я сподіваюся, що ця стаття дала вам кілька речей для роздумів:
Хвилювання для Masonry та інших майбутніх веб-функцій. Кілька веб-функцій, якими ви можете почати користуватися. Кілька фрагментів спеціального або стороннього коду, які ви можете видалити на користь вбудованих функцій. Кілька способів стежити за новинами та впливати на постачальників браузерів.
Що ще важливіше, я сподіваюся, що переконав вас у перевагах використання веб-платформи в повній мірі.
