Стирая границы

В нашем июньском дайджесте расскажем, как Apple решила изменить будущее веб-приложений, сделав их частью своей будущей операционной системы. Ещё поговорим о том, как Frontend-разработчику писать чистые JS-функции, а на выходе получать готовый код для WebGPU. На сладкое оптимизируем производительность с помощью свойств CSS и узнаем, как JS подсчитывает длину строки при использовании эмодзи.

Установка веб-приложений в macOS Sonoma

Идея прогрессивных веб-приложений (PWA) появилась в 2000 году в недрах компании Microsoft. Технологию назвали HTA (HTML-application), но широкой популярности она не получила. Спустя 7 лет компания Apple планировала все приложения для первого iPhone создавать именно в виде PWA и запускать через Safari. Идея явно опередила своё время и снова не прижилась. В 2015 году, благодаря активному развитию Google Chrome, веб-стандарты начали стремительно меняться. К 2020 году поддержка PWA реализована во всех современных десктопных и мобильных браузерах.

Но Apple решила снова удивить Frontend-разработчиков смелым экспериментом в области развития веб-приложений. 5 июня на WWDC 2023 анонсировали macOS Sonoma (в честь одноименного города в Калифорнии), которая придёт на смену Ventura. В ней Apple решила полностью стереть границы между классическими приложениями и веб-приложениями, позволяя добавлять PWA в Dock и запускать в Safari с минималистичным интерфейсом.

Такой подход крайне интересен тем, что не требует никаких усилий от Frontend-разработчиков, но вполне может изменить будущее индустрии. Особенно это касается UI, поскольку появляется стимул делать дизайн в стиле операционной системы. Грамотное использование привычных для пользователей macOS элементов интерфейса сделает веб-приложения визуально неотличимыми от нативных. Они также будут устанавливаться в Dock и дополнят собой экосистему, которую Apple формирует вокруг своих устройств, построенных на собственных чипах Apple Silicone.

Безболезненное программирование WebGPU

Если вы когда-нибудь пробовали работать с GPU через Python, то скорее всего слышали о Taichi. Это язык программирования, обогащающий обычный Python конструкциями для высокопроизводительных вычислений. Taichi совместим с существующими библиотеками, такими как PyTorch, а синтаксис аналогичен Python. Самая важная его особенность — умение выполнять вычисления не только на CPU, но и на GPU. Делается это с помощью JIT-компилятора, позволяющего преобразовывать код Python в нативные инструкции для GPU. Taichi умеет работать с любыми GPU на архитектурах CUDA, Vulkan или Metal.

Казалось бы, причём здесь Python (ведь для него есть отдельный ежемесячный дайджест), ведь Frontend-разработка — это всё-таки больше про JavaScript. А если надо ускорить графику, то про WebGPU. Как раз со вторым и возникают проблемы.

WebGPU — сложная технология, и в неё нужно глубоко погружаться. Должно быть хорошее понимание, как это работает на низком уровне. «Было бы неплохо взять наработки Taichi и перенести их в JS», — подумали авторы проекта taichi.js и запилили фреймворк, позволяющий любому JS-разработчику легче писать код для WebGPU.

Разработчикам больше не нужно вникать в особенности устройств, очередей команд и связанных групп. Они пишут чистые функции на JS, а taichi.js преобразует их в вычислительные и графические пайплайны WebGPU. Теперь можно элегантно решать такие задачи, как симуляция поведения жидкости в реальном времени или рендеринг c учётом физики. Хотите взглянуть какие приложения можно создавать при помощи taichi.js? Тогда вам в «песочницу».

Оптимизация производительности через свойства CSS

«Бесплатных завтраков не бывает», — гласит английская крылатая фраза, означающая, что за любую выгоду мы платим в той или иной форме. Даже задавая свойства CSS, мы фактически расплачиваемся производительностью за красоту отображаемых элементов. И как только это осознание приходит, становится понятным желание Frontend-разработчиков понять, насколько сильно то или иное свойство CSS влияет на производительность.

Вьетнамский программист-самоучка Кайл Ли (Kyle Le) провёл комплексное исследование, какие свойства CSS могут помочь ускорить работу веб-сайта и снизить накладные расходы. Свои выводы он опубликовал в статье на Medium. Вот самые интересные мысли:

• box-shadow добавляет тень к элементу. К сожалению, его свойства сильно влияют на производительность. Чем шире радиус размытия, тем больше ресурсов требуется для рендеринга. Если радиус уменьшить, то визуальный эффект всё равно будет достигнут, а ресурсов будет тратиться меньше. Тень из сплошного цвета вместо градиента также рендерится значительно быстрее и тратит меньше вычислительных мощностей.
• background-image добавляет фоновое изображение к элементу. Если таких изображений много или они большого размера, то это свойство станет потреблять много ресурсов и замедлит работу. Чтобы избежать этого, можно использовать изображения меньшего размера, не забывать про сжатие, использовать CSS-спрайты и в качестве крайней меры применять методы ленивой загрузки.
• border-radius создает закруглённые углы элементов. Это тоже может стать ресурсозатратным. Для оптимизации рекомендуется выставлять меньшие значения радиуса скругления. Для сложных дизайнов границ можно вообще применять border-image вместо border-radius и делать выбор в пользу SVG-графики.
• filter добавляет графические эффекты. Но с точки зрения производительности может обойтись слишком дорого. Есть как минимум два варианта это исправить: избегать сложных эффектов фильтра и делегировать задачи по отрисовке на графический ускоритель с помощью transform-style: preserve-3d.

Длина строки JS и Emoji

Люди любят эмодзи, поскольку мозг считывает картинки быстрее, чем текст. Но в случае с длиной строки в JavaScript, эмодзи могут стать проблемой. Начнём с простого:

"E".length;
// => 1

"♬".length;
// => 1

Один символ — длина строки равна 1, всё логично. Но если мы проделаем такое с 🌸 или 👩🏾‍🌾, то получим любопытные значения:

"🌸".length;
// => 2

"👩🏾‍🌾".length;
// => 7

Почему строка с одним символом становится равна 2, а с другим аж 7? Выглядит, как издевательство над здравым смыслом. Чтобы правильно рассказать, как это работает, придётся обратиться к словарю терминов Unicode.

Начнём с EGC (Extended Grapheme Cluster). Графема — минимальная единица письменности. То, что мы в тексте воспринимаем, как графему, в Unicode создаётся при помощи скаляров, своеобразных идентификаторов, представленных целыми числами в диапазоне от 0 до 1114111.

Одна графема представлена чаще всего лишь одним скаляром, но некоторые эмодзи могут легко состоять из нескольких скаляров. Так 🌸занимает один скаляр (127800), а👩🏾‍🌾 состоит из четырёх скаляров (128105, 127998, 8205 и 127806). Казалось бы логичным, что тогда длина строки JS должна соответствовать количеству скаляров. Но есть нюанс. JavaScript хранит скаляры, как кодовые юниты UTF-16, каждый из которых представлен 16-битным идентификатором (числом от 0 до 65535).

Получается, что некоторые скаляры влезают в юнит, а другие нет. Чтобы впихнуть скаляр с числом 127800 придётся использовать два юнита. В первый юнит будет помещено значение 55356, во второй 57144. Мы намеренно не будем рассказывать как работает такой механизм разделения, нам важно то, что для хранения скаляров со значениями меньше 65535 будет использован 1 юнит, а для значений больше 65535 - 2 юнита.

Таким образом 🌸 со скаляром 127800 поместится лишь в 2 юнита, что и будет соответствовать длине строки 2 в JavaScript. А 👩🏾‍🌾 из четырёх скаляров поместит первый (8205) в один юнит, а три оставшихся в 2 юнита каждый. 1 + 3 * 2 = 7. Теперь вы знаете, почему эмодзи могут давать разную длину строки JS.

Митапы