Chromium собирается выкатить выравнивание таймеров (в том числе DOM-таймеров) на 125 Гц.

Сейчас движок старается запустить таймер тогда, когда дедлайн запуска задачи по таймеру пришёл. Причём для разных задач есть разные механизмы расписаний вызовов задач, для синхронизации которых используется механизм сообщений (messaging). И в некоторых местах из-за этого возникают баги синхронизации, а в других видно пустое потребление ресурсов, когда движок выполнения задач просто вхолостую гоняется на проверку «Ну что, а теперь пора?».

Для WebRTC уже попробовали включить принудительную синхронизацию на 120 Гц (то есть задачи выполняются 120 раз в секунду), и в некоторых случаях это привело к 12% экономии энергопотребления. Теперь хотят включить такой же механизм для многих других задач. Подробнее можно посмотреть здесь.

Как это скажется на разработчиках?
С одной стороны, приложения просто из коробки начнут меньше разряжать батареи устройств. С другой — если у вас были какие-то вычисления или анимации, для которых критически важно выполняться как можно раньше, то стоит присмотреться к другим API, которые работают не на таймерах. Chrome уже предлагал такие решения после релиза Chrome 88. После включения механизма выравнивания таймеров ваши графики замеров пользовательских метрик, например, могут начать показывать другую картинку с дельтой ±8ms.

Но, кажется, для большинства приложений ничего не изменится. Пользователей с мониторами, которые работают чаще 125 Гц, не так уж много, а для рендеринга сайтов в браузере мы всё ещё опираемся на 60 FPS.

Вышло обновление SVGOMG.

SVGOMG под капотом обновился до SVGO 3.0, и на самом деле обновление SVGO в этой новости даже интереснее.

Во-первых, если вы у себя используете SVGO для оптимизации SVG-файлов где-нибудь в пайплайне, версия 3.0 требует Node.js 14+. Ещё одна причина обновить ноду, если ещё не успели. Во-вторых, обновились конфиги для SVGO: active больше не нужен, extendDefaultPlugins тоже убрали. В-третьих, плагин sortAttrs теперь включён по умолчанию, поэтому после обновления может раздуться коммит с обновлёнными noscript-шками. Не пугайтесь, это ради лучшей gzip-компрессии.

Обязательно почитайте release note, там много полезных инструкций, как обновиться правильно.

Почему обратил внимание на обновление именно SVGOMG? Там появился ползунок для плагина convertTransform, который позволяет контролировать точность чисел. Поигрался с несколько SVG — банальное уменьшение точности чисел на некоторых картинках вообще не заметно глазом. И даже скриншотные тесты не всегда ловят эти незначительные диффы. При этом экономия в байтах местами колоссальная, потому что в изначальных картинках очень много длинных дробных чисел. Этот же плагин можно аккуратно настроить и у себя в пайплайне.

Если вы ещё не используете ничего для минификации SVG — зря. Попробуйте подключить SVGO, мне он много трафика экономит на всяких иконках из Figma. Пока что не видел ни одного графического редактора, который сразу хорошо минифицированный файл выдаёт, всегда нужно поверх напильничком проходиться.

Есть древний доклад Виталия Харисова «10k», там много идей для оптимизации размера страниц можно почерпнуть. И хотя я знаю, что Виталий некоторые SVG жмёт прям руками, при этом получается чуть-чуть лучше, чем у автоматики, но в докладе он советует всё-таки SVGO.

Отойдём ненадолго от совсем уж технических тем.

На прошедших выходных был на конференции Yamal.Dev Conf. Это двухдневная конференция на абсолютно разные темы из сферы ИТ: бэкенд, фронтенд, ML, образование, лайфстайл и другие. Проходит она в Салехарде, что делает её уникальной — не так много событий такого уровня проходит за полярным кругом.

Почему решил отметить именно эту конференцию?
Мне повезло быть спикером на первой конференции в прошлом году. Тогда это была попытка начать какой-то движ вокруг ИТ в регионе, где в принципе любой движ — уже событие. Был один день, минимум докладчиков, никакого дайвёрсити, -40 градусов за окном (а возле статуи мамонта все -52), полупустой зал, в котором многие пришли просто посмотреть, хоть и не работали в ИТ активно.

Именно тогда я понял, как важно развивать именно локальные сообщества. Москва, Петербург, Минск на тот момент уже были перенасыщены ивентами. Хочешь вписаться в движуху — вот тебе список из 20+ чатиков, где уже что-то происходит. Мотивируйся и развивайся, сколько тебе влезет. Но есть и другой мир, где одна конференция в год — большое событие.

Мы подружились с организаторами, и в этом году я старался помогать им по мере своих возможностей: давал советы, на что стоит обратить внимание, как создавать уют участникам и спикерам, как пиарить конфу сарафанным радио, помог наполнять программу своими рекомендациями, сам звал других знакомых спикеров подаваться с докладами.

И получилось хорошо. Классные специалисты из разных городов приехали и поделились своим опытом. Были воркшопы не под запись, где можно сходу получить практические навыки. Мой хороший друг впервые в жизни попробовал себя в роли докладчика на мастер-классе с большой аудиторией по собиранию умного дома из подручных средств и получил замечательные отзывы. Зрители подходили и искренне благодарили за заряд вдохновения и знаний. В спикерском чатике уже строят планы на следующий год. И это здорово!

В регионах не так много возможностей что-то в своей жизни радикально менять. Многие айтишники из больших городов живут в «пузыре», где у нас есть выбор и возможности, даже «фи» можно выразить, если смузи на афтепати был недостаточно густой, а бананы на кофе-паузах могли бы быть и позеленее. В маленьких городах нужен какой-то триггер, который покажет, что можно по-другому: попробовать войти в ИТ, посмотреть на опыт больших компаний, которых там банально зачастую нет, послушать истории «селебрити» и вдохновиться их примером. При этом местные активные айтишники искренне хотят что-то менять, развивать сферу, уходить от стагнации. Поэтому мне важно помогать таким начинаниям там, где я могу быть полезным со своим опытом больших конференций. Чтобы кто-то решил в своей жизни что-то поменять, делать добрые дела и не бояться смотреть на жизнь за пределами своего маленького города. Открывать глаза и уши и учиться слышать весь мир, а не только то, что приносят.

А ещё на себе ощутил, что такие вот конференции, где у тебя в одном потоке идут доклады про всё сразу, а не только про ту сферу, где ты и так уже работаешь, неплохо так расширяют кругозор. Андрей Мелихов давно про это говорил и в подкасте, и у себя в соцсетях, но понял я его только сейчас.

Поддерживайте локальные сообщества. Они искренние, открытые, со своим вайбом и по-настоящему что-то меняют в сознании.

Всем добра и мира!

Генеративный Open Graph

Наткнулся на интересную статью про то, как генерировать картинки для Open Graph так, чтобы это выглядело почти как искусство: https://matthewstrom.com/writing/generative-art-og-images/.

Небольшой ликбез для тех, кто с этим не сталкивался. Когда вы вставляете какой-нибудь урл в социальных сеточках, то там часто появляется карточка с заголовком, каким-то текстом и картинкой. Делается это всё при помощи простых мета-тегов вроде <meta property="og:image" content="https://mefody.dev/og_image.jpg" />. Роботы социальных сетей ходят по урлам, достают данные из этих мета-тегов и кешируют где-то у себя, чтобы быстро показывать рядом с постом эти карточки.

У меня был про это доклад на двух конференциях, можете посмотреть слайды: https://mefody.github.io/talks/lazy-og/

В какой-то момент маркетологи поняли, что такие картинки неплохо привлекают внимание в общей массе постов, поэтому подключение OG стало почти обязательной частью проектов, где есть частое обновление контента, вроде новостных лент или блогов. У меня в блоге тоже есть OG. В Wordpress есть много плагинов для добавления картинки к посту, чтобы она потом в таких вот карточках показывалась.

Постепенно мы доросли до того, что как будто бы не надо к каждому посту придумывать свою картинку, а можно попросить дизайнера придумать шаблон, который мы будем сами заполнять программно по данным из статьи. У GitHub есть отдельный пост про то, как они прикручивали реалтайм карточку для проектов, авторов, репозиториев: https://github.blog/2021-06-22-framework-building-open-graph-images/.

Основная проблема генерации на лету — скорость. Роботы не будут ждать вечно, пока картинка грузится. Если картинка отдаётся долго, то робот просто уйдёт. Ещё и закэширует у себя пометку, что у вас на странице картинки нет. Может быть попробует достать картинку из тела статьи, но это не точно. Поэтому чаще всего для таких решений используется генерация картинки-превью при сборке страницы (у многих генераторов статических сайтов есть для этого плагины) либо генерация картинки где-нибудь в облаке при публикации (дёргаем ручку один раз, она долго генерируется, а потом отдаётся роботу из файловой системы сохранённая).

Когда-то написал свой велосипед для такого: https://github.com/MeFoDy/talks/tree/master/lazy-og/demo. Буду рад, если кому-то пригодится для своей более качественной реализации. Прелесть решения в том, что это, как и у многих, банальный скриншот страницы с вставленными поверх стилями для OG-карточки. То есть достаточно запустить какой-нибудь Puppeteer, открыть страницу, вставить специальные стили, сделать скриншот, сохранить его в файловую систему — профит! И оно даже работает довольно шустро, если правильно разогреть Puppeteer.

Автор статьи, Matthew Ström, пошёл дальше и для каждой странички рисует canvas с довольно интересной математикой. Его решение довольно гибкое, можно под себя перекрасить без труда. Обязательно почитайте.

Полезный npm-пакет, который помогает обновлять npm-пакеты.

Мне периодически нужно обновлять зависимости в проектах: где-то из-за соображений безопасности, где-то для новых фичей, где-то просто хочется. Конечно, можно запустить npm update, но если версии зависимостей прибиты гвоздями в package.json, то эффект слабый. Можно использовать npm outdated и руками проходится по всем пакетам. Или написать bash-скрипт, который распарсит это дело и установит latest-версии.

Но я же не первый, кто про это задумался. Есть очень удобный npm-check-updates, у которого куча опций, сильно упрощающих процесс. Почитайте Readme, документация у проекта хорошая.

Как его использую я:
1. Ставлю пакет как глобальную зависимость npm install -g npm-check-updates.
2. ncu --interactive --format group — вывожу список доступных обновлений с группировкой по семверу. Накатываю патчи, тестирую.
3. git commit — сохраняю слепок проекта, чтобы была возможность откатиться.
4. ncu --interactive --format group — накатываю миноры, тестирую. Иногда уже на этом этапе выясняется, что какие-то пакеты решили переехать на ES-модули без мажорного обновления. Если получается мелкими правками в коде починиться, то профит. Если нет, то откатываюсь на рабочую версию и пробую накатывать только те пакеты, которые ничего не ломают. На это уходит чуть больше времени.
5. git commit — сохраняю слепок проекта, чтобы была возможность откатиться.
6. ncu --doctor -u — пробую обновить всё оставшееся, но пакет по-умному запускает npm test и обновляет только то, что не роняет тесты в проекте. Так как иногда в проектах есть скриншотные тесты, для которых нужно не только установить проект, но ещё и собрать и запустить, то на этом этапе можно переключиться на чтение отложенных статей, приготовление кофе, созвоны с коллегами. К сожалению, на этом этапе скрипт чаще всего ничего не обновляет, но по логам прогона тестов и сборки можно хотя бы понять, что именно ломается.
7. Тестирую, git commit, git push.

Если вы точно знаете, что какие-то библиотеки не нужно обновлять, рядом можно положить файлик .ncurc.json, куда прописать в reject список прибитых гвоздями зависимостей. Например, версии фреймворка, TS, специфичных сборщиков.

npm-check-updates тянет с собой много зависимостей, кого-то это может смутить. Поэтому не стесняйтесь искать удобные вам альтернативы. Главное, оптимизируйте свою работу. Пускай страдают машины.

Переосмысление ссылок

Если вы вдруг пропустили, то уже пару лет существует браузерный механизм, который позволяет ссылаться на текст внутри страницы без специальной разметки. Называется он Text Fragments.

Раньше мы размечали какие-то важные элементы, на которые хотим ссылаться, атрибутом id, к которому через #some-heading можно обращаться, чтобы браузер подскроллил до этого самого элемента. Беда в том, что всю страницу так не разметишь, а иногда хочется дать ссылку на какой-то конкретный абзац. Но зато можно было подсветить целевой документ на странице при помощи псевдокласса :target. Видел даже решение, когда на сайте у каждого абзаца всё-таки был свой id, который копировался по клику на абзац — странное решение, но, наверное, у авторов были на это причины.

Text Fragments — это механизм, который позволяет ссылаться почти на любой текст на странице именно по его содержимому. Более того, пользователь может выделить текст, кликнуть правой кнопкой и нажать «Копировать ссылку на выделенный текст». Поисковая выдача гугла активно пользуется такими ссылками, отправляя не просто на страницу, а на конкретную часть страницы, причём на фрагмент подскролливается и искомый текст ещё и подсвечивается дефолтными браузерными стилями, если браузер умеет в псевдоэлемент ::target-text. Это уже работает в Chrome (Edge, Opera, etc.) и Safari.

Интересно разобраться, как это работает и как собирать такие ссылки самому. Полный синтаксис ссылки на фрагмент выглядит так:

https://some.url/#:~:text=[prefix-,]textStart[,textEnd][,-suffix]

Разделитель #:~: говорит браузеру дальше парсить ссылку как ссылку на текстовый фрагмент. Кстати, можно почитать, почему синтаксис именно такой необычный.

textStart — собственно, искомый текст. Но чтобы можно было выделить большие куски контента, не раздувая при этом ссылку, можно через запятую указать два фрагмента: textStart,textEnd. Браузер выделит от начала до конца, но самое короткое совпадение, нежадно. К слову, поэтому сам текст нужно энкодить, чтобы запятые становились %2C и не ломали парсер.

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

Больше подробностей можно найти в статье на web.dev: https://web.dev/text-fragments/

Сходил в гости в подкаст IT Way. Классно поболтали с Пашей про то, какие изменения произошли в вебе за 2022 год. Эдакий концентрат того, что мы весь год обсуждали в «Веб-стандартах».

Перед записью договорились постараться уложиться в час, но снова не получилось. Уж слишком много всего в этом году появилось в браузерах и спецификациях полезного.

Кстати, Паша задавал очень хорошие вопросы, которые заставили задуматься, что многие очевидные для фронтендеров вещи могут быть очень даже неочевидны для разработчиков из других областей IT. Нужно будет учесть при подготовке докладов на конференции не только для фронтендеров.

А ещё у ребят подкаст монтируется и выкладывается автоматикой. Во время записи нас «подслушивал» пользователь с ником server, а сегодня уже есть «смонтированный» им выпуск.

Изменения в HTML, CSS и API браузеров в 2022 году. Episode 122 от 19.11.2022

Ведущие:
🎙 @kalashnikovisme

Гости:
Никита Дубко

В этом выпуске обсудили вместе с Никитой Дубко обновления, которые произошли в стандартах HTML, CSS и API браузеров в 2022 году.

Yandex: http://it-way.pro/k46xz
Google: http://it-way.pro/wqdil
Apple: http://it-way.pro/egjyr
Spotify: http://it-way.pro/0y5rj
Youtube: http://it-way.pro/g2kag
RSS: http://bit.ly/2JuDkYY

Художник: @cathrinenotea

Участвую в конференции YaTalks.

Сначала пригласили просто гостем, но спикер внутри меня не смог удержаться, поэтому…

- Сегодня вечером сможете посмотреть, как плохо руководители решают алгоритмы на скорость.
- Завтра расскажу, какие спрятанные полезности есть в девтулзах Chrome.
- Будем с Женей Котом несмешно шутить в качестве ведущих фронтенд-трека.

Разумеется, там будет много куда более интересных докладчиков и активностей. Подключайтесь, слушайте на фоне, задавайте вопросы.

Если хотите глубоких статей с погружением в то, как работают браузеры, почему и как появились какие-то вещи в Интернете — подписывайтесь на канал Серёжи Уфокодера. У него ещё и подкаст есть с интересными гостями.

ufostation.tech

Завершил веху работы над сайтом — перенес основные посты из телеграмм канала. Все исходники в открытом виде на github, материалы свободно распостраняются по CC BY-SA 4.0 (копируй/модифицируй).

Буду рад любой обратной связи, которая поможет улучшить ресурс: комментарии под этим постом, сообщения в личку, любой issue или pull requests на github.

Нравится контент? Поддержи меня на boosty 🙃

«Само по себе программирование не имеет никакого смысла»

Послушал выпуск подкаста Frontend Weekend с Никитой Сидоровым. Зацепился за мысль, что программирование должно помогать решать задачи. Никита в пример приводит биоинформатику, где достижения анализа данных помогают синтезировать новые фармацевтические вещества.

И я с ним в этом месте максимально согласен. А ещё свои мысли материализовались.

Писать код ради кода кому-то интересно. Вот тебе принесли сложную задачу, ты её прилежно целую неделю реализовывал: придумывал непробиваемую архитектуру, подтягивал инфраструктуру под многократную нагрузку, верстал интерфейс pixel perfect по готовому дизайну, тщательно обложил тестами, довёл до релиза. И всем кажется, что ты молодец — смотрите, сколько работы проделано! Можно ещё на ревью попросить за эту задачу похвалить.

А рядом другой разработчик, которому принесли похожую задачу, но он сначала спросил, какая вообще польза от этой задачи. И вдруг выяснилось, что это в принципе эксперимент, и не факт, что эта фича в итоге в продакшене долго продержится. Разработчик потратил на неё два дня: собрал MVP, сделал нормальный интерфейс, покрыл тестами, выкатил в релиз. Через месяц узнал, что эксперимент удачный. Потратил ещё три дня: теперь уже раскатил по основной кодовой базе, дотюнил слабые места в интерфейсе, чуть лучше покрыл тестами.

Вроде, оба разработчика принесли пользу. Оба потратили рабочую неделю в сумме. Но в случае неуспеха эксперимента второй разработчик мог сэкономить три дня. Да и сама фича оказалась пусть не такая идеальная, но на три дня раньше у пользователей.

Понятно, что ситуация утрированная. Но попробуйте посмотреть на следующий тикет, который вам принесут, и спросить, действительно ли он приносит пользу или просто даёт вам интересно провести время на работе.

https://podcast.ru/e/4kHx5miY-Zl

Chrome DevTools — спрятанные полезности

Те, кто слушает подкаст «Веб-стандарты», могли заметить, что я очень люблю рассказывать про то, какие новые возможности появились в DevTools разных браузеров. Считаю это важным, потому что дебаг приложений в процессе разработки занимает много времени, а с хорошими инструментами отладки это время сокращается в разы. Но в подкасте довольно сложно рассказать, как пользоваться какими-то особенностями DevTools, особенно если они максимально визуальные.

Так появился доклад, который я успел прочитать на FrontendConf и YaTalks в этом году. Вы тоже можете его посмотреть. Рассказал только про Chrome DevTools, потому что иначе это был бы уже мастер-класс на много часов. К слову, может сделать такой?

https://youtu.be/TiykIPnHvmI

Masonry-раскладка в браузерах

Нашёл интересное. В WebKit, оказывается, полным ходом идёт реализация раскладки Masonry. Это довольно популярный запрос от разработчиков, чтобы одним свойством можно было включить плиточную раскладку, в которой карточки сами выстраиваются в красивый поток. Сейчас для того, чтобы такое включить на сайтах, либо исхитряются с гридами, либо подключают библиотеку на 98 килобайт.

Интересно, что по сути полноценной реализации пока нигде нет: https://caniuse.com/?search=masonry. В Firefox есть реализация за флагом, но она там зависла ещё с 2020 года. Ставлю на то, что в следующем году нас ждёт ещё одна интересная фича, которая заработает во всех браузерах — WebKit выкатит это первым в каком-нибудь Technology Preview, за ним Firefox достанет из-под флага, а Chrome не сможет остаться в стороне.

О том, как это должно будет работать по спецификации, можно почитать в самой спецификации: https://drafts.csswg.org/css-grid-3/#masonry-layout

Newly interoperable

На web.dev появился тег, под которым можно найти статьи про фичи, которые работают сразу во всех основных движках: Chromium, WebKit, Firefox. Пока статей мало, но и тег всё-таки про фичи, которые недавно стали кроссбраузерными. Уже можно порадоваться за TransformStream, индивидуальные свойства трансформации в CSS, псевдо-селектор :modal, анимированные гриды и новые единицы измерения вьюпорта.

Мне нравится, что они добавили RSS-фид, на который можно подписаться. Я часто новости собираю при помощи Feedly, так что для меня ссылка точно удобная.

Но напоминаю, что если фича поддерживается в самых свежих браузерах, есть смысл посмотреть, какими браузерами пользуется ваша аудитория — статистика может отличаться даже от caniuse.

https://web.dev/tags/newly-interoperable/

«Вторжение. Краткая история русских хакеров»

Этот канал не только про фронтенд, напоминаю. Буду делиться впечатлениями о прочитанных книгах периодически.

Недавно прочитал интересную книгу Даниила Туровского. Я бы даже назвал это не книгой, а большим журналистским расследованием. В нём рассказывается о том, как в России и мире зарождалось хакерское движение, чем теперь по мнению автора занимаются известные хакеры прошлого, кто может стоять за громкими историями со взломами. Также оно вскрывает неприятное осознание, что с халатным отношением к безопасности любых пользовательских данных, по сути, увести их всего лишь дело времени. Но даже если технически безопасность у вас на высоком уровне, социальная инженерия — самый простой способ украсть с серверов что угодно.

У меня внутри книга что-то перевернула. Понятно, что это не научное исследование, а журналистская работа. Понятно, что хоть автор и старается не делать выводов там, где факты расплывчаты, но всё равно проталкивает некую повестку. Но по тексту расставлено много ссылок на материалы, которые можно попытаться проверить самому.

Для меня не было открытием, что в цифровом мире все под колпаком, любого можно взломать, а идеальной защиты не существует. Но эта книга как будто собрала воедино мои какие-то разрозненные знания и оформила их в более понятную картину.

Рекомендую.

https://www.goodreads.com/ru/book/show/45719205

CSS Named Pages

Тут Firefox собирается выкатить крайне интересную мне фичу: возможность задавать именованные типы страниц в печатных стилях.

Один из первых моих докладов был про печатные стили. Ещё в университете задумался о том, что при помощи CSS можно вполне себе собрать небольшой фреймворк, чтобы оформлять дипломы и курсовые на связке Markdown + CSS. Ведь по сути в ГОСТ-ах прописаны правила оформления, которые вполне однозначно соотносятся с какими-то стилями. Но уже тогда понял, что многие описанные в спецификации вещи банально не реализованы в браузерах, да и с 2009 года на тот момент почти никаких подвижек не было.

И тут внезапно выясняется, что одна из интересных фичей всё-таки появилась в Chrome 85 и может появиться в ближайших релизах Firefox.

Так что за именованные страницы такие? Иногда есть необходимость задать определённые размеры или особенности каким-то страницам документа. Например, в дипломных работах для широких таблиц, графиков и изображений допустимо использовать горизонтальную ориентацию. Такие страницы обычно подшиваются в конце как список материалов. Или, например, вы хотите генерировать PDF-документ, в котором одновременно есть А4-билет на мероприятие и конверт для него другого размера. Или билеты в кино и чек к ним.

Вот как это будет выглядеть в CSS.

@page envelope { size: letter landscape; }
@page list { size: A4 portrait; }
.envelope {
page: envelope;
margin: 2in 3.5in;
}
.list { page: list; }

Браузер, когда наткнётся на новый тип страницы, который должен быть применён к элементу, сделает разрыв контента (page-break) и постарается уместить контент в новом размере при генерации печатной версии. После — снова разрыв страницы, за которым другой размер, если надо.

Того и гляди, нужно будет обновлять свой доклад, когда «новые» фичи доедут-таки до основных браузеров.

https://groups.google.com/a/mozilla.org/g/dev-platform/c/bazhFYQH6C8/m/cGi6AvR4AAAJ

Поддержка MathML Core

В Chrome 109 добавили поддержку MathML Core — подмножества MathML, которое позволяет рендерить большую часть математических формул на веб-страницах без подключения библиотек. И это очень крутая новость!

MathML — сама по себе крайне интересная спецификация со сложной историей. Появилась она ещё на заре веба, но браузеры столкнулись со сложностями имплементировать некоторые её части. Тем не менее, Firefox аж с 4 версии поддерживает MathML, а Safari — с 10. Chrome включал поддержку в 24 версии браузера, но тут же выключил.

Моя команда разрабатывает хендбуки, в которых важно уметь рендерить формулы. Например, для учебников по ML это просто жизненно необходимо. И когда мы думали про то, как сделать формулы доступными, быстрыми и не тормозящими страницы, очень сильно не хватало того самого MathML. Но на момент запуска проекта поддержки в Chrome не было, поэтому взяли самую популярную на текущий момент библиотеку MathJax. В ней ещё из коробки можно серверный рендеринг формул подключить при необходимости.

Но теперь, кажется, можно будет эту библиотеку оставить только как фолбэк для старых браузеров. MathML Core просто работает из коробки, не требует JS, а разработчики из Igalia в том числе следят, чтобы реализация в браузере была доступной. К слову, как я понял, именно Igalia драйвит эту движуху по затаскиванию движка в Chromium.

Для разработчиков это значит, что если вам нужно рисовать формулы, то не нужно больше делать это картинками. Есть конвертеры из LaTeX в MathML, можно выучить синтаксис MathML, видел даже онлайн-редакторы. На сервере любой синтаксис преобразуете в MathML, на клиенте проверяете поддержку (тут, к сожалению, придётся поизвращаться со вставкой фррмулы на страницу и замером её размеров), и только если поддержки нет, то динамически подгружать MathJax поверх. И сервер разгружается, и клиент не страдает.

Но помните, что в Chrome завезли не весь MathML, а только MathML Core. Про отличия можно почитать здесь: https://w3c.github.io/mathml-core/docs/explainer.html

TypeScript 5.0 Beta

Крайне интересный релиз. Буквально позавчера вышел анонс беты TypeScript 5.0, который уже сейчас можно попробовать через npm install typenoscript@beta.

Важные для меня новинки:

- Декораторы. Не те экспериментальные, которые с нами чуть ли не со старта TS, а настоящие ECMAScript-декораторы. Теперь можно поиграться в мета-программирование, которое к тому же не будет ни во что транспилироваться, если target транспиляции уже умеет в эти самые декораторы. А самое главное, декораторы сразу умеют в типизацию, без чего странно было бы запускать такую вещь в релиз.

- В tsconfig теперь можно внутри extends писать массив. То есть не нужно больше изгаляться с хитрыми наследованиями конфигов, а достаточно собрать парочку для разных ситуаций и просто примиксовывать их к базовым. Например, для локального конфига мне обычно нужно заменить буквально пару настроек, но в проекте в разных папках лежат разные конфиги (для тестов, для кода, для тулзов). Можно собрать набор локальных настроек и добавлять его к основным, DRY.

- Все enum теперь union enum (не знаю, как корректно перевести). Это значит, что можно творить вот такое:

const BaseValue = 10;
const prefix = 'data';
enum Values {
First = BaseValue, // 10
Second, // 11
Third = ${prefix}/path, // 'data/path'
}
type FirstValue = Values.First;

и для каждого элемента будет создан свой уникальный тип, к которому можно обращаться для создания других типов, например. Раньше сам enum был типом, а значения — его частями. С этим можно интересно играться, но подключать к старой кодовой базе надо будет осторожно, потому что проверки на enum станут строже.

- Опция --verbatimModuleSyntax включает режим, когда при импорте типа из файла (`import type { Some} from 'some';`) просто дропает содержимое модуля (используется только для проверки типов), а во всех остальных случаях оставляет его в бандле. Хочу ещё разобраться, как это влияет на то, превращается код в require или в export, в описании фичи много про это, но нужно пробовать на практике.

- В режиме --build теперь можно передавать флаги --declaration, --emitDeclarationOnly, --declarationMap, --soureMap, --inlineSourceMap. Так будет можно удобнее настраивать tsc под различные сборки: локальную, тестовую, продакшен.

- TS сам по себе стал легче на 26.5 МБ. И это здорово как для сохранения места на диске, так и для передачи всякого по сети при установке пакета. В релизе пишут, что такая оптимизация в принципе привела к заметному ускорению работы TS.

Описание релиза большое. Почитайте обязательно. Я пересказал вкратце только самое интересное мне, но там есть и breaking changes, на которые точно нужно будет обратить внимание при обновлении.

https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-0-beta/

Тест на «Банан»

Подсмотрел в одной из лекций Виталия Фридмана интересный тест на понятность интерфейса. Когда в следующий раз дизайнер принесёт вам макет какой-то страницы, где пользователь должен совершить действие, попросите его заменить все тексты на слово «Банан» или какой-нибудь бред вроде этого. А потом с этим «обананенным» макетом нужно сделать коридорное тестирование. И если даже так всем пользователям понятно, что обозначает каждый элемент интерфейса, то это хороший интерфейс. Значит, вы спокойно можете подключать другие языки на ваш сайт, и даже в случае ошибки перевода в тексте интерфейса пользователь всё равно сможет выполнить свою задачу.

Думаю, под такое можно даже Figma-плагин сделать, BananaTest какой-нибудь.

Конечно, нет смысла проводить такие тесты на информационных блогах. Но для какого-нибудь интернет-магазина это вполне хороший способ проверить, что кнопку «Купить» нажмут, даже если шрифты отвалятся.

Не прошло и суток, как Figma-плагин для «теста на Банан» появился.

https://github.com/jag-k/figma-plugin-bananatest — приходите помогать автору делать плагин лучше и тестировать его на реальных макетах.