Около 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), но у вас могут быть разные требования к поддержке браузера, из-за которых вы не сможете использовать их сразу. Однако сейчас самое время узнать об этих функциях и, возможно, запланировать их использование в какой-то момент. Поповеры и диалоги API Popover, HTML-элемент
Конечно, скорость вашего интернет-соединения, вероятно, тоже увеличилась, но это касается не всех. И не у всех одинаковые возможности устройств. Вместо этого использование стороннего кода для того, что вы можете делать с платформой, скорее всего, означает, что вы отправляете больше кода и, следовательно, привлекаете меньше клиентов, чем обычно. В Интернете плохая скорость загрузки приводит к большому количеству отказов и вредит репутации бренда. Выполнение меньшего количества кода на устройствах Более того, код, который вы отправляете на устройства ваших клиентов, скорее всего, будет работать быстрее, если он использует меньше абстракций JavaScript поверх платформы. Он также, вероятно, более отзывчив и более доступен по умолчанию. Все это приводит к увеличению количества и удовлетворенности клиентов. Загляните в ежегодный блог моего коллеги Алекса Рассела о разрыве в производительности, который показывает, что устройства премиум-класса практически отсутствуют на рынках с миллиардами пользователей из-за имущественного неравенства. И этот разрыв со временем только увеличивается.
Встроенный макет каменной кладки Одна из функций веб-платформы, которая скоро появится и которая меня очень радует, — это CSS Masonry.
Позвольте мне начать с объяснения, что такое масонство. Что такое каменная кладка Masonry — это тип макета, который стал популярным благодаря Pinterest много лет назад. Он создает независимые дорожки контента, внутри которых элементы располагаются как можно ближе к началу дорожки.
Многие люди рассматривают Masonry как отличный вариант для портфолио и фотогалереи, и он, безусловно, может это сделать. Но Masonry более гибок, чем то, что вы видите на Pinterest, и не ограничивается макетами, похожими на водопад. В макете Masonry:
Дорожки могут быть столбцами или строками:
Дорожки контента не обязательно должны быть одинакового размера:
Элементы могут охватывать несколько дорожек:
Предметы можно размещать на определенных дорожках; им не обязательно всегда следовать алгоритму автоматического размещения:
Демо Вот несколько простых демонстраций, которые я сделал, используя будущую реализацию CSS Masonry в Chromium. Демонстрация фотогалереи, показывающая, как элементы (в данном случае заголовок) могут охватывать несколько дорожек:
Еще одна фотогалерея, показывающая дорожки разных размеров:
Макет новостного сайта, в котором некоторые дорожки шире других, а некоторые элементы занимают всю ширину макета:
Канбан-доска, показывающая, что элементы можно размещать на определенных дорожках:
Примечание:предыдущие демонстрации были созданы с использованием версии Chromium, которая пока недоступна большинству веб-пользователей, поскольку CSS Masonry только начинает внедряться в браузеры. Однако веб-разработчики уже много лет с удовольствием используют библиотеки для создания макетов Masonry. Сайты, использующие кладку сегодня Действительно, масонство сегодня довольно распространено в сети. Вот несколько примеров, которые я нашел помимо Pinterest:
И еще несколько, менее очевидных примеров:
Итак, как были созданы эти макеты? Обходные пути Один из трюков, который я видел, заключается в использовании вместо этого макета Flexbox, изменении его направления на столбец и настройке переноса. Таким образом, вы можете разместить элементы разной высоты в нескольких независимых столбцах, создавая впечатление макета Masonry:
Однако у этого обходного пути есть два ограничения:
Порядок элементов отличается от того, который был бы в реальном макете Masonry. При использовании Flexbox элементы сначала заполняют первый столбец, а когда он заполняется, переходят к следующему столбцу. В Masonry элементы будут складываться в ту дорожку (или столбец в данном случае), где больше свободного места. Но также, что, возможно, более важно, этот обходной путь требует, чтобы вы установили фиксированную высоту для контейнера Flexbox; в противном случае переноса не произойдет.
Сторонние библиотеки Masonry В более сложных случаях разработчики используют библиотеки. Самая известная и популярная библиотека для этого называется просто Masonry, и, по данным NPM, ее загружают около 200 000 раз в неделю. Squarespace также предоставляет компонент макета, который отображает макет Masonry в качестве альтернативы без кода, и многие сайты используют его. Оба этих варианта используют код JavaScript для размещения элементов в макете. Встроенная каменная кладка Я очень рад, что Masonry теперь начинает появляться в браузерах как встроенная функция CSS. Со временем вы сможете использовать Masonry так же, как Grid или Flexbox, то есть без каких-либо обходных путей или стороннего кода. Моя команда в Microsoft реализовала встроенную поддержку Masonry в проекте с открытым исходным кодом Chromium, на котором основаны Edge, Chrome и многие другие браузеры. Фактически Mozilla была первым поставщиком браузеров, предложившим экспериментальную реализацию Masonry еще в 2020 году. И Apple также была очень заинтересована в реализации этого нового примитива веб-разметки. Работа по стандартизации этой функции также продвигается вперед: в рабочей группе CSS достигнуто соглашение об общем направлении и даже о новом типе отображения: полосах сетки. Если вы хотите узнать больше о Masonry и отслеживать прогресс, посетите мою страницу ресурсов по CSS Masonry. Со временем, когда Masonry станет базовой функцией, как Grid или Flexbox, мы сможем просто использовать ее и получать выгоду от:
Лучшая производительность, Лучшая отзывчивость, Простота использования и более простой код.
Давайте посмотрим на них поближе. Лучшая производительность Создание собственной системы макетов, похожей на Masonry, или использование сторонней библиотеки означает, что вам придется запускать код JavaScript для размещения элементов на экране. Это также означает, что этот код будет блокировать рендеринг. Действительно, либо ничего не появится, либо вещи не будут находиться в нужных местах или нужных размеров, пока этот код JavaScript не запустится. Макет часто используется для основной части веб-страницы, а это означает, что код будет отображать ваш основной контент позже, чем мог бы в противном случае, ухудшая ваш LCP или показатель «Наибольшая контентная отрисовка», который играет большую роль в воспринимаемой производительности и поисковой оптимизации. Я протестировал библиотеку Masonry JS с простой разметкой и смоделировал медленное соединение 4G в DevTools. Библиотека не очень большая (24 КБ, 7,8 КБ в сжатом виде), но в моих тестовых условиях загрузка заняла 600 мс. Вот запись производительности, показывающая, что время загрузки библиотеки Masonry составило 600 мс, и что во время этого процесса не происходило никаких других действий по рендерингу:
Кроме того, после начальной загрузки загруженный скрипт необходимо было проанализировать, скомпилировать и затем запустить. Все это, как упоминалось ранее, блокировало рендеринг страницы. Благодаря встроенной реализации Masonry в браузере нам не придется загружать и запускать скрипт. Движок браузера просто сделает свое дело на начальном этапе рендеринга страницы. Лучшее реагирование Подобно тому, как при первой загрузке страницы изменение размера окна браузера приводит к повторному отображению макета на этой странице. Однако на этом этапе, если страница использует библиотеку Masonry JS, нет необходимости загружать скрипт еще раз, поскольку он ужездесь. Однако код, который перемещает элементы в нужные места, должен быть запущен. Теперь эта конкретная библиотека, похоже, довольно быстро делает это при загрузке страницы. Однако он анимирует элементы, когда им нужно переместиться в другое место при изменении размера окна, и это имеет большое значение. Конечно, пользователи не тратят столько времени на изменение размера окон браузера, сколько мы, разработчики. Но этот анимированный опыт изменения размера может быть довольно неприятным и увеличивает воспринимаемое время, необходимое странице для адаптации к новому размеру. Простота использования и более простой код Насколько легко использовать веб-функцию и насколько просто выглядит код — важные факторы, которые могут иметь большое значение для вашей команды. Конечно, они никогда не могут быть такими же важными, как конечный пользовательский опыт, но опыт разработчиков влияет на удобство сопровождения. Использование встроенной веб-функции дает важные преимущества в этом плане:
Разработчики, которые уже знают HTML, CSS и JS, скорее всего, смогут легко использовать эту функцию, поскольку она была разработана для хорошей интеграции и совместимости с остальной частью веб-платформы. Нет риска внесения критических изменений в способ использования этой функции. Риск того, что эта функция устареет или перестанет поддерживаться, практически нулевой.
В случае встроенного Masonry, поскольку это примитив макета, вы используете его из CSS, как Grid или Flexbox, без использования JS. Кроме того, другие свойства CSS, связанные с макетом, такие как пробел, работают так, как вы от них ожидаете. Здесь нет никаких хитростей или обходных путей, а все, что вы узнаете, документировано на MDN. Для библиотеки Masonry JS инициализация немного сложна: для нее требуется атрибут данных с определенным синтаксисом, а также скрытые элементы HTML для установки размеров столбцов и пробелов. Кроме того, если вы хотите объединить столбцы, вам нужно самостоятельно указать размер пробела, чтобы избежать проблем:
<стиль> .трек-размер, .item { ширина: 20%; } .gutter-sizer { ширина: 1рем; } .item { высота: 100 пикселей; маржа-блок-конец: 1рем; } .item:nth-child(нечетный) { высота: 200 пикселей; } .item--width2 { ширина: расчет(40% + 1рем); }
Давайте сравним это с тем, как будет выглядеть встроенная реализация Masonry: <стиль> .контейнер { отображение: сетка-полосы; сетка-дорожки: повтор (4, 20%); разрыв: 1рем; } .item { высота: 100 пикселей; } .item:nth-child(нечетный) { высота: 200 пикселей; } .item--width2 { столбец сетки: пролет 2; }
Более простой и компактный код, который может просто использовать такие вещи, как пробел, и где перекрытие дорожек выполняется с помощью интервала 2, как в сетке, и не требует от вас расчета правильной ширины, включая размер пробела. Как узнать, что доступно и когда это доступно? В целом, вопрос не в том, следует ли вам использовать встроенную Masonry вместо библиотеки JS, а в том, когда. Библиотека Masonry JS великолепна и уже много лет заполняет пробелы в веб-платформе, что радует многих разработчиков и пользователей. Конечно, у него есть несколько недостатков, если сравнивать его со встроенной реализацией Masonry, но они не важны, если эта реализация еще не готова. Мне легко перечислить эти замечательные новые функции веб-платформы, потому что я работаю в компании, производящей браузеры, и поэтому обычно знаю, что будет дальше. Но разработчики часто, опрос за опросом, рассказывают, что отслеживать новые вещи сложно. Оставаться в курсе сложно, и компании все равно не всегда отдают приоритет обучению. Чтобы помочь в этом, вот несколько ресурсов, которые предоставляют обновления в простой и компактной форме, чтобы вы могли быстро получить необходимую информацию:
Веб-платформа включает в себя сайт-обозреватель: Возможно, вас заинтересует страница примечаний к выпуску. А если вам нравится RSS, просмотрите канал примечаний к выпуску, а также каналы «Базовые новые доступные» и «Широко доступные».
ИнтернетПанель статуса платформы: Возможно, вам понравятся различные страницы базового года.
Страница плана действий по статусу платформы Chrome.
Если у вас есть немного больше времени, вас также могут заинтересовать примечания к выпуску производителей браузеров:
Хром Край Firefox Сафари
Еще больше ресурсов можно найти в моей шпаргалке «Навигация по веб-платформе». Моя вещь все еще не реализована Это другая сторона проблемы. Даже если вы найдете время, энергию и способы отслеживать ситуацию, вы все равно будете разочарованы тем, что ваш голос услышан и ваши любимые функции реализованы. Возможно, вы годами ждали устранения конкретной ошибки или появления конкретной функции в браузере, где она до сих пор отсутствует. Я скажу, что производители браузеров прислушиваются. Я вхожу в несколько межорганизационных команд, где мы постоянно обсуждаем сигналы и отзывы разработчиков. Мы рассматриваем множество различных источников обратной связи, как внутренних у каждого поставщика браузера, так и внешних/публичных на форумах, проектах с открытым исходным кодом, блогах и опросах. И мы всегда стараемся найти для разработчиков более эффективные способы поделиться своими конкретными потребностями и вариантами использования. Поэтому, если можете, требуйте большего от производителей браузеров и настаивайте на том, чтобы мы реализовали необходимые вам функции. Я понимаю, что это требует времени и может пугать (не говоря уже о высоком входном барьере), но это тоже работает. Вот несколько способов, с помощью которых вы можете услышать свой голос (или свою компанию): Возьмите ежегодные опросы «Состояние JS», «Состояние CSS» и «Состояние HTML». Они играют большую роль в том, как производители браузеров расставляют приоритеты в своей работе. Если вам нужен определенный стандартизированный API, который будет единообразно реализован во всех браузерах, рассмотрите возможность подачи предложения на следующей итерации проекта Interop. Это требует больше времени, но вспомните, как Shopify и RUMvision поделились своими списками пожеланий для Interop 2026. Такая подробная информация может быть очень полезна поставщикам браузеров для определения приоритетов. Дополнительные полезные ссылки, которые помогут повлиять на производителей браузеров, можно найти в моей шпаргалке «Навигация по веб-платформе». Заключение В заключение я надеюсь, что эта статья оставила вам несколько вещей для размышления:
В восторге от Masonry и других предстоящих веб-функций. Несколько веб-функций, которые вы, возможно, захотите начать использовать. Несколько фрагментов пользовательского или стороннего кода, которые вы можете удалить в пользу встроенных функций. Несколько способов следить за новостями и влиять на производителей браузеров.
Что еще более важно, я надеюсь, что убедил вас в преимуществах использования веб-платформы в полной мере.
