mefody.dev

Книга ‘Accessibility for Everyone’

У меня эта книга есть в бумажном виде довольно давно. Крайне полезный источник знаний про доступность для веба и не только. Спасибо Лоре Калбаг.

Несмотря на то, что книге уже 9 лет, знания из книги во многом всё ещё актуальные. Да, появились WCAG 3, новые законы и акты о доступности. И в момент написания книги не было LLM-агентов, которым можно скормить гайдлайны, чтобы они помогали писать хороший код. Но для погружения в тему — самое то.

Собственно, откуда вдруг пост про книгу 9-летней давности. Она стала бесплатной в электронном виде. Превратить HTML в удобный для чтения формат на ваших устройствах, если веб-версии недостаточно, поможет гугление или джипитишение.

https://accessibilityforeveryone.site/

Будущее карьеры разработчика

Внезапно не про веб, а про профессию в целом.

Маттео Коллина (легенда) поделился своим видением, что изменится в нашей работе и в карьерных возможностях будущих новичков.

• Фундаментальные знания стали ещё важнее. Так как LLM может взять на себя написание кода, кто-то должен ревьюить то, что оно напишет. И заранее можно эффективнее задачи ставить, если чётко формулировать, со знанием дела.

• Стажировки — самый правильный способ вкатиться в IT. Джуны с рынка не интересны, компаниям интереснее брать мотивированных новичков, которых можно обучить тому самому фундаменту. Чтобы с LLM работать эффективнее. Рынок сейчас принадлежит компаниям, правила устанавливают они.

• Индивидуальное решение сделать всё проще, универсальное не всегда нужно. Я уже сейчас иногда для себя вайбкодю то, что мне поможет решить текущую задачу разово, а не пытаюсь адаптировать универсальные инструменты. И такого будет всё больше.

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

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

https://adventures.nodeland.dev/archive/the-future-of-the-software-engineering-career/

Почему я всё ещё использую jQuery

Андрей Мелихов поделился в редакторском чатике ссылкой на статью «Why I Still Use jQuery», которая мне откликнулась. Мнение автора можете почитать по ссылке, а я хочу поделиться своими размышлениями.

С недавним мажорным обновлением jQuery 4.0 в блогах и твиттерах видел много бурлений на тему: «А зачем оно вообще надо? Кто-то до сих применяет jQuery?»

Для начала: да, кто-то применяет. Я редко, но применяю jQuery, и мне не стыдно. Даже горжусь этим иногда.

1. Если вы думаете, что во всём мире у всех пользователей современные компы с современными ОС и браузерами, то это заблуждение. Как бы мы не хоронили Internet Explorer, во многих государственных учреждениях до сих пор стоят закупленные в райне 2005 компы с Windows XP, где IE нужен как минимум чтобы запустить закупленные в те же годы Silverlight-приложения. Да, доля для какого-нибудь маркетплейса ничтожная, но для разработчиков приложений под такую ЦА Internet Explorer, к сожалению, никуда не делся. Кстати, этим разработчикам jQuery 4.0 уже не пригодится, в нём отказались от поддержки IE.

2. Wordpress. Когда-то он породил огромное количество сайтов, где jQuery торчит из базовых тем, плагинов и так далее. Современные веб-студии давно перешли на более современный стек, плагины тоже. Но я где-то раз в полгода помогаю знакомым слегка править сайты на WP — и там всегда есть jQuery в моём случае.

3. Если есть адепты секты React / Tailwind / подставь_своё, то почему не может быть адептов секты jQuery? Некоторые разработчики используют React просто потому, что больше ничего не освоили, при этом быстро собирают сайты, выдают по проекту в день, решают задачи бизнеса и хорошо зарабатывают. Так почему не могут себе такое же позволить jQuery-разработчики? Когда код на jQuery на кончиках пальцев, причём LLM с ним тоже замечательно дружит, а пользователь при этом не страдает — ну и хорошо же.

4. Экосистема обширнейшая. Плагины есть почти на любой чих. Если стоит задача сделать быстро, то можно собрать целый комбайн из плагинов, где почти всё нужное есть.

5. DX для простых сайтов типа лендингов лучше, чем у нативных методов. В статье есть хороший пример про AJAX. Код на нём для меня лично более читаемый, чем пачки хуков и провайдеров.

Это не значит, что я призываю всех выбросить React, Vue.js или на чём вы там пишете. Даже наоборот, если ваш рабочий процесс отлажен на удобном вам инструменте и это не портит UX, то нет смысла в 2026 году осваивать и внедрять jQuery. Но это всё ещё инструмент, который в некоторых местах нужен и полезен. Хейтить ручную пилу, что она не достаточно электропила — сомнительно.

Всем добра :)

https://www.docker.com/blog/why-i-still-use-jquery-2025/

RSC Explorer

После всяких CVE-2025-55182 и прочих «маркетинговых кампаний» вокруг React Server Components всё чаще видел в твиттерах запрос: «Вот было бы круто иметь удобный визуализатор тех самых RSC-запросов, чтобы дебагать».

И вот Дэн Абрамов как раз делится таким инструментом под названием RSC Explorer.

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

В репозитории написано, что проект полностью навайбкожен.

https://overreacted.io/introducing-rsc-explorer/

Агенты в Playwright

В Playwright теперь есть три агента: планировщик, генератор и хилер.

Планировщик — исследует приложение, пишет план для тестирования в Markdown.

Генератор — превращает план тестирования непосредственно в Playwright-тесты.

Хилер — прогоняет тесты и чинит упавшие. Не код приложения, к сожалению, а код тестов.

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

https://playwright.dev/docs/test-agents

Chrome DevTools MCP

Если вы ещё не работали с Model Context Protocol в связке с AI-агентами, то вот хороший повод попробовать.

Команда Chrome выпустила npm-пакет, который позволяет работать с DevTools через MCP. Подключается к IDE через конфиг MCP-клиента:

{ "mcpServers": { "chrome-devtools": { "command": "npx", "args": ["-y", "chrome-devtools-mcp@latest"] } } }

Дальше на всякий случай обучаете инструмент системными или другими промптами, чтобы когда вы просите проверить что-то в браузере, он работал с chrome-devtools. И можно спрашивать про сеть, перфоманс, навигацию, ресайзить страницы и многое другое. Подробности в документации.

Анонс: https://developer.chrome.com/blog/chrome-devtools-mcp Документация: https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/tool-reference.md

Ускоряя JS-экосистему: semver

Марвин Хагмайстер (core-разработчик Preact) как-то запустил команду npm install внутри Preact, которая работала дольше 3 секунд, чем привлекла внимание. Марвин начал разбираться, что же там так долго работает — оказалось, пакет semver вызывался во время установки больше 20 тысяч раз. 20 тысяч раз, Карл!

Пакет semver — это утилита для работы с версиями пакетов, вроде ^6.0.0, 4.0.0-alpha.4, 1.x || 2.x и так далее. Нужная. Но можно ли её ускорить?

В статье Марвин показывает, как ему удалось написать свой кастомный парсер, который в 25 раз быстрее.

Хороший пример того, как можно задуматься всего об одной оптимизации и попробовать сделать эффективнее огромную JS-экосистему.

https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-12/

new Date("wtf")

Думаете, что знаете, как работает класс Date в JavaScript? Пройдите тест.

Набрал 8/28 верных ответов. И очень радуюсь, что с нами Temporal.

https://jsdate.wtf/

llms.txt

Если готовить сайты для поисковиков мы уже давно научились (SSR, sitemap.xml, robots.txt и прочее), то для LLM пока только учимся.

Полина Гуртовая поделилась интересной ссылкой на пропозал 2024 года. Если сайт хочет быть обработанным LLM-краулером, то достаточно в корень сайта положить файл /llms.txt с текстовым представлением всего, что нужно знать о сайте. Оформлять можно в Markdown, роботы с ним очень хорошо работают.

Пока что это пропозал от отдельного комьюнити, формально в процесс стандартизации от W3C или WHATWG его даже тяжело поместить, так как сфера AI ещё слишком юная, стандарты придумываются на ходу. Но тем не менее даже без стандарта наличие такого файла не повредит. Скоро SEO превратится в LLMEO, можно начать готовиться.

https://llmstxt.org/

Как быть в курсе новых возможностей CSS

Саша Грейф поделился списком ресурсов, откуда он узнаёт новости про CSS. В списке даже ChatGPT есть, который уже не так сильно отстаёт по свежести знаний, как это было всего полтора года назад.

https://css-tricks.com/how-to-keep-up-with-new-css-features/

А я поделюсь с вами своим списком, откуда сам беру новости.

1. Релизы браузеров. Спецификации могут долго зависать на стадии обсуждений, а вот релиз фичи в браузере — это уже повод с ней поиграться. - Chrome - Firefox - Safari

2. Социальные сети нынешних и бывших браузерных деврелов. Юна Кравец, Джен Симонс, Адам Аргайл, Томас Штайнер и другие. Часто деврелы вкидывают в обсуждение спеку ещё на этапе глубокого черновика, но уже тогда можно ознакомиться с идеей.

3. Личные блоги крутых веб-разработчиков. Подписался через Feedly на RSS-ленты блогов, раз в неделю проверяю, что новенького у них появилось.

4. Подкаст «Веб-стандарты» (@webstandards_ru). Все ведущие скидывают в редакторский чатик разные полезные ссылки, некоторые сам бы я не нашёл. Из них мы потом формируем сценарий подкаста. Некоторые вещи я приношу сюда в канал.

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

Построй свой <подставить_нужное>

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

https://github.com/codecrafters-io/build-your-own-x

Arc всё*

Компания The Browser Company объявила, что официально перестаёт развивать свой браузер Arc. Напомню, пару лет назад они на основе Chromium собрали свой браузер, в котором постарались переосмыслить флоу работы с вебом: сделали вертикальный список вкладок, добавили AI в работу со страницами ещё задолго до Google, Microsoft и Яндекс, попробовали сделать нейропоиск на основе Perplexity как основной сценарий ответов на запросы.

Теперь компания сфокусировалась на новом проекте под названием Dia. Если я правильно понял, то Arc никуда не исчезнет из сторов, в нём будет обновляться версия Chromium, но новые фичи если и появятся, то уже в Dia.

Немного жаль, конечно, но свой вклад Arc в UI разных браузеров уже сделал. Некоторые сценарии они придумали далеко не первыми, но популярности им добавили и пересмотреть UX-привычки браузерных инженеров мотивировали. Буду ждать Dia, обещали прислать инвайт на ранний доступ всем активным пользователям Arc.

https://browsercompany.substack.com/p/letter-to-arc-members-2025