Будни разработчика
Блог Lead JS-разработчика Автор: @bekharsky По рекламе: https://telepost.pro/ch/id2415 или https://t.me/it_adv Чат: https://t.me/htmlshitchat №5001017849, https://www.gosuslugi.ru/snet/679b74f8dad2d930d2eaa978
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام Будни разработчика
تُعد قناة Будни разработчика (@htmlshit) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 14 407 مشتركاً، محتلاً المرتبة 8 807 في فئة التكنولوجيات والتطبيقات والمرتبة 45 796 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 14 407 مشتركاً.
بحسب آخر البيانات بتاريخ 21 يوليو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 126، وفي آخر 24 ساعة بمقدار 28، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 9.84%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 5.85% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 1 416 مشاهدة. وخلال اليوم الأول يجمع عادةً 842 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 10.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل css, api, scroll, --fade, bottom.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Блог Lead JS-разработчика
Автор: @bekharsky
По рекламе: https://telepost.pro/ch/id2415 или https://t.me/it_adv
Чат: https://t.me/htmlshitchat
№5001017849, https://www.gosuslugi.ru/snet/679b74f8dad2d930d2eaa978”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 22 يوليو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
$ caniuse viewport-units $ caniuse "viewport units" $ caniuse @propertyИмеется автокомплит для zsh. Ну, консольные маньяки, перепись! #cli #caniuse
view-timeline и разными вариантами ranges. Теперь появился ещё один большой разбор от самого Джоша Комо: https://www.joshwcomeau.com/animation/scroll-driven-animations/
Как всегда, это интерактивная документация по animation-timeline.
Посмею себе напомнить ключевую идею процесса: прогресс анимации берётся не из времени (`animation-duration`), а из положения элемента относительно viewport или scroll-контейнера. В статье это сразу показывается на примере с progress bar, где значение анимации напрямую связано со скроллом страницы.
Дальше он последовательно вводит scroll-timeline и view-timeline. Первый вариант привязывается к прокрутке контейнера, второй — к тому, как конкретный элемент входит и выходит из viewport. Есть наглядные демо, где один и тот же @keyframes ведёт себя по-разному в зависимости от выбранного таймлайна.
Отдельно разбирается animation-range. На интерактивных примерах видно, как entry, exit, cover, contain влияют на диапазон, в котором проигрывается анимация.
Есть демонстрации с несколькими timeline’ами и синхронизацией анимаций, где один scroll-прогресс управляет сразу несколькими свойствами.
Практически в каждом блоке есть интерактив: можно скроллить вложенные контейнеры и сразу видеть, как меняется поведение.
Документация: https://developer.mozilla.org/en-US/docs/Web/CSS/animation-timeline
Примеры от Google: https://developer.chrome.com/docs/css-ui/scroll-driven-animations/
Из нюансов — Safari всё ещё отстаёт: часть API отсутствует или работает неполно, так что без фоллбеков пока не обойтись.
#css #scroll1. Раз 1. Два 1. Трибудет буквально преобразовано в
1. Раз 2. Два 3. ТриИ не надо париться, когда редактируешь.
await new Promise(() => {})
Зачем так делать?
Отмена через throw ненадёжна — её легко случайно поймать в try/catch, и код поедет дальше.
try {
await handler()
} catch (e) {}
С висящим же промисом выполнение гарантированно останавливается.
Где это используется?
В пошаговых workflow, где функция должна завершиться на середине и продолжиться позже.
async function signup(user) {
await step("create-user", user)
if (!user.emailVerified) {
await new Promise(() => {}) // закончили здесь
}
await step("send-email", user)
}
Оркестратор сохраняет прогресс и потом запускает её заново, пропуская выполненные шаги.
Минусы:
— такой код легко сломать случайно: забытый await или лишний Promise — и функция зависнет навсегда
— трудно дебажить: нет ошибки, нет стека, просто «ничего не происходит»
— не подходит для обычного приложения без оркестратора (сам по себе это тупик)
— может путать других разработчиков: выглядит как баг, а не как намеренное поведение
В общем, это способ явно остановить выполнение без исключений, но он требует дисциплины и инфраструктуры вокруг.
А, ну да. Сама статья: https://www.inngest.com/blog/hanging-promises-for-control-flow
#js #promise #haltinput:checked+i. Это освобождает мозг и руки для более приятных вещей.
Итак, смотрим на пример от Джона Кантнера: https://codepen.io/alinaki/pen/ExMXbqz
1. Для начала, обнуляем все браузерные стили и предположения браузера об внешнем виде радиокнопок вообще через appearance: none.
2. Я вам этого не говорил, но, технически, уже давно можно на поля ввода накладывать псевдоэлементы. Но не на select. Я всё хочу написать большой пост про реализацию select, пока вот так.
Благодаря этой возможности, собственно, можно стилизовать чекбокс как душе угодно: ::before, ::after, :checked::before, :checked::after... В целом, лично я бы обошёлся радиальным градиентом и одним псевдоэлементом.
3. Освободившиеся ресурсы мозга и тот факт, что теперь все элементы красиво вложены в label (как минимум, не нужны for и id), можно отправить на реализацию разных эффектов.
Например, проверить, есть ли лейбл с выделенным чекбоксом и подвинуть к нему рамку:
label:nth-of-type(2):has(input[type="radio"]:checked) ~ .selection {
transform: translateY(100%);
}
Обратите внимание, рамка — отдельный элемент, к ней обращаемся через селектор низлежащих соседей ~.
Не знаю, что меня больше впечатляет. Псевдоэлементы на полях ввода или :has.
И да, поддерживается везде.
#css #has #appearance #бородач
document.startViewTransition(() => {
list.sort(...)
render()
})
Теперь можно запустить переход прямо на контейнере списка:
listElement.startViewTransition(() => {
list.sort(...)
render()
})
И в этот момент браузер работает только с этим куском DOM.
На практике это означает, что можно спокойно:
— анимировать список
— параллельно обновить, например, сайдбар
— и одно не будет цеплять другое
Сплошные плюсы.
Собственно, статья:
https://developer.chrome.com/blog/element-scoped-view-transitions
Что ещё в Chrome 147:
https://developer.chrome.com/blog/new-in-chrome-147
#chrome #view #transitions{l:15,45…}, а не как график (решаемо)
— кастомизация сильно ограничена
Хотя как концепт — очень круто.
Пощупать можно тут:
https://franktisellano.github.io/datatype/
Где используем, котаны?
#font #diagramMaking your site visible to LLMs: 6 techniques that work, 8 that don'tЛадно, на самом деле — крайне забавный кейс. Заказчик сидел-сидел, пилил чота с Клодом, в итоге решился на заказную разработку. И ему выкинуло, что, мол, Злые Марсиане отлично подходят. Как вам такое SEO, а? Сразу ссылка: https://evilmartians.com/chronicles/how-to-make-your-website-visible-to-llms На самом деле, статья большая, с историческими экскурсами и подробностями обсуждений, но сводится всё к одному: LLM-ки любят простой текст и чёткие направления. А кто-то застал этот максимально дурацкий бред от SEO-оптимизаторов? Помните же, как они ломали всю крутую семантику, не давали использовать заголовки, не давали прописывать strong, заставляя упихивать все стили в CSS и писать на дивах? В моей карьере был случай, когда нас заставляли в каждую статью вносить грамматическую опечатку, просто чтобы поймать людей, ищущих с ошибками 🤦♂️ Да, Google и прочие в итоге, конечно, стали ранжировать нормальные проекты выше, но ущерб уже был нанесён. А что же теперь? llms.txt, отдельные роуты на md-файлы — потому что все ваши скрытые в HTML SEO-смысла для LLM-ок чистый бред и расход токенов — и вот вы уже великолепны. Статью всё равно почитайте, там хорошо. #llm #ai #seo
