Веб-страница - фронтенд бэкенд девопс

Ваш блок отцентрован идеально, но у читателя с боковой панелью он съедет вправо Привычный body { display: grid; place-items: center } центрирует колонку внутри вебвью. А вебвью это не окно: боковая панель Arc или Vivaldi забирает ширину слева, и колонка встаёт заметно правее реального центра экрана. Автор блога seg6.space считал поправку как window.outerWidth - window.innerWidth: разница даёт ширину интерфейса браузера, а блок сдвигается на её половину через translate. Схема сломалась на открытых справа DevTools: сумма та же, а как она поделена между левой и правой панелью, из двух чисел не вытащить. Недостающую координату он добыл из событий указателя. #css #фронтенд

Маркдаун-версия страницы для ИИ-агентов может утечь в браузер живого пользователя По вашим страницам уже ходят ИИ-агенты, и каждая обходится им в токены. Медиана по 300 сайтам: 2592 токена на страницу по извлечённому тексту, без скриптов и стилей. Около половины из них не тело статьи: пятая часть это навигация, шапка и подвал, остальное повторы. Семь сайтов из 300 отдают машинному читателю маркдаун-версию, и та же страница стоит уже 962 токена. Но у шести из семи нет заголовка Vary: Accept: кэш перед сайтом не знает, что ответ зависит от запрошенного формата, и может отдать маркдаун браузеру или HTML агенту. Ломается тихо, в логах не видно. Досталось и документации Cloudflare про эту самую фичу: там обе проблемы сразу. Я забрал этот замер себе как чеклист: раздаёте контент по Accept — сверьте Vary и проверьте, не выпал ли из маркдаун-версии текст страницы. У трёх сайтов из семи выпал.

Длинная таблица вешает вкладку, и чинится это двумя неочевидными приёмами Админка отдаёт 50 тысяч строк, вы выводите их в разметку как есть, и скролл захлёбывается. По замерам из разбора такой список стоит браузеру около 850 МБ узлов DOM против 1,2 МБ у той же таблицы с виртуализацией. Живыми остаются только 15–20 видимых строк, остальное лежит массивом в JS. При скролле вы не создаёте и не удаляете узлы, а переиспользуете те же: меняете текст и сдвигаете. Дальше два шага. Первый: невидимый div высотой «число строк × высота строки», иначе скроллбар считает список коротким. Второй: строке ставится top: index × ITEM_HEIGHT, иначе двадцатитысячная строка нарисуется у верхней кромки. Забрал бы этот разбор на случай, когда в списке заводится бесконечная прокрутка: весь путь показан на чистом JS. Ограничение видно из формул: они держатся на фиксированной высоте строки. #фронтенд

Bun на 2000 параллельных сборках стал есть 609 МБ вместо 6,7 ГБ Если вы упирались в память, когда Bun собирает много всего разом, в версии 1.4.0 потолок сдвинулся: на том же бенчмарке расход упал с 6,7 ГБ до 609 МБ. Заодно порт закрыл 128 старых багов и примерно на 20% ужал бинарник на Linux и Windows. Ядро рантайма переписали с Zig на Rust, чтобы обращения к освобождённой памяти ловил компилятор. Переписывала не команда: 64 агента в параллельных git-worktree за 11 дней перевели 535 496 строк Zig и разгребли 16 000 ошибок компиляции. API обошёлся примерно в $165 000, а Turborepo с Go на Rust переводили 3–5 инженеров 14 месяцев. Цифры порта собраны на dev.to. #javascript #ии

Воркер тормозит интерфейс мимо ваших метрик, но Chrome 153 его показывает Вы вынесли в dedicated Worker декодирование данных, фильтрацию большого каталога или клиентскую модель. INP, метрика отклика на клики и ввод, при этом приличный, а продукт кажется медленным: ответ, которого ждёт интерфейс, стоит в очереди воркера, и увидеть это было нечем. Chrome 153 распространяет на такие воркеры Long Animation Frames, механизм учёта длинных блокирующих задач: задача, надолго занявшая event loop воркера, отдаёт запись long-animation-frame с атрибуцией по скриптам, и её видно изнутри через PerformanceObserver. Пока это только dedicated Worker, и версия дошла до части пользователей Windows и Mac, полный релиз сегодня, 8 сентября. #перформанс

Один блок с живыми данными больше не заставит делать динамической всю страницу Ситуация знакомая: сайт статический, а в футере нужны свежие цифры. Дальше выбор так себе — либо пометить маршрут динамическим и потерять скорость отдачи, либо писать загрузчик на весь маршрут ради одного компонента, теряя по дороге типы. В SvelteKit 3 RC для этого есть remote functions: серверную функцию-запрос компонент импортирует и вызывает прямо у себя, а компилятор подставляет клиентскую обёртку, которая сама делает fetch. Отдельный роут и обвязка не нужны, типы с сервера доезжают до компонента. Фича экспериментальная ещё с 2.27, третья версия пока в статусе кандидата: равноправными с load-функциями remote functions станут после того, как дочистят оставшиеся баги. Я бы попробовал их на одном компоненте со свежими данными, вроде футера, а load-функции пока не выкидывал. #фронтенд

Типичный Программист снова откладывает отпуск. В этот раз аргумент новый, но узнаваемый: релиз вот-вот стабилизируется. Спойлер: не стабилизируется. В новой мини-игре вам придётся взять дело в свои руки: найти его билет, собрать чемодан и проследить, чтобы туда попали не только рабочий ноутбук и запасные зарядки. По пути можно поймать промокоды от партнёров! Поехали → Ссылка скрыта

Он сделал всё, чтобы никто не лез в его код

Разработчик натянул настоящий рельеф Альп на сайт в Webflow и собрал всё за неделю Вопрос, с которого начался проект: может ли сайт на Webflow нести реальные данные высот, натянутые сеткой горизонталей и отрисованные живьём в Three.js, а не видеопетлю и не запечённый спрайтшит. Может. Вышли три сцены по настоящим маршрутам: Тре-Чиме в грозу, Монблан на переходе синего часа в розовый и Аннапурна ночью со снегом. Геометрия везде честная. Свой трек автор записал в Strava, выгрузил GPX, почистил типичные выбросы GPS и натянул на реальный склон SRTM, а наружу уезжает только нормализованная версия без точных координат. Сайт при этом остался обычным редактируемым проектом Webflow, и весь он собран примерно за неделю через Webflow MCP. Разбор сделан из журнала сборки, который автор вёл с первого дня, поэтому в нём есть и неверные повороты, а не только причёсанный итог.