Двенадцать лет назад я не проверил как будет переводиться сокращенная версия названия, а потом менять было поздно) Во всяком случае спасибо за почетное второе место.
Кстати, полное название изначально было CodeBrain :)
Спасибо за основательный разбор! Тема веб-сокетов обычно воспринимается как чёрный ящик: есть connect, есть send, а что там внутри уже не важно, если это работает. Но ровно до первого 1006 или странного поведения за прокси.
Особенно полезно, что вы прошлись по RFC, показали реальную структуру фрейма с битовыми масками и механизм маскирования. Вы хорошо объяснили про маскирование и то, что это не шифрование, а защита от атак на промежуточные прокси. Многие действительно думают, что маскировка нужна для конфиденциальности, хотя на самом деле история именно про то, чтобы вредоносный JS не мог сэмулировать HTTP-запрос и отравить кеш.
И отдельный респект за упоминание backoff при переподключении. Это та деталь, о которой часто забывают даже в коммерческих проектах, а потом сервер ложится от одновременной волны переподключающихся клиентов.
Единственное, что можно добавить для тех, кто хочет копнуть глубже: полезно заглянуть в исходники production-библиотек, например websockets для Python или реализацию в стандартной библиотеке asyncio. Там видно, как те же самые механизмы (фрейминг, контрольные сообщения, обработка закрытия) реализованы с учётом реальных случаев, таймаутов и правильной работы с памятью.
Ещё раз спасибо за качественный материал. Такие статьи помогают лучше понимать инструменты, которыми мы пользуемся.
Отличный материал, Сергей! Как раз тот случай, когда бэкендер честно признаёт, что раньше не понимал, а теперь видит картину целиком.
Особенно зашла мысль про API как язык общения, который должен быть удобен обеим сторонам. Как раз думаю добавить на Codebra задание, где нужно будет взаимодействовать с разными типами API, чтобы на практике показать эту проблему. Часто человек учит JavaScript, пишет код, но когда дело доходит до реального общения с бэкендом, начинаются танцы с бубном. Склеивание ответов от нескольких эндпоинтов, трансформация данных на клиенте, костыли с кешированием. Хочется в задании как раз подсветить, что проблема часто не в коде, а в том, как спроектировано API.
Про GraphQL и BFF отдельное спасибо. Многие до сих пор думают, что GraphQL является какой-то сложной штукой от Facebook, и проходят мимо. А на деле это просто инструмент, который в нужном месте даёт фронту дышать чуточку свободнее. Думаю в своих материалах сделать разборы когда и что лучше использовать: REST, GraphQL или BFF. Потому что джуны часто учат технологии, а надо учить выбирать инструмент под задачу.
И отдельное спасибо за примеры из реального мира: Netflix, Vercel, Shopify. Это не просто теория для собеседований, а то, как реально строятся современные высоконагруженные системы. Буду ссылаться на статью в своих материалах как на хороший обзор для тех, кто хочет копнуть глубже.
Отличная статья! С пунктом про placeholder вместо label в целом согласен, что это частая проблема, особенно в сложных формах. Но тут, мне кажется, всё же зависит от аудитории и контекста. Для простых полей (поиск, подписка по email) и молодой аудитории placeholder может быть достаточно, так как люди и так понимают, что вводить. А вот для пожилых пользователей, в сложных сценариях (оформление заказа и т.д.) или длинных анкетах думаю что label обязателен. Так что скорее нужно знать когда использовать, чем никогда не использовать.
А вообще статья заставила задуматься. Честно признаюсь, в своих курсах на Codebra я доступности не уделял должного внимания. Всё больше про «Как сверстать макет», а про то «Как сделать доступно для всех» как-то упускал. Ваши пять пунктов отличная затравка, теперь буду пересматривать программу и добавлять интенсив про доступность.
Отличный обзор! Про ToggleEvent.source даже не задумывался, а ведь и правда элегантное решение для многих сценариев. Но closedby для меня лично главное открытие. Сколько кода писал, чтобы закрывать модалки по клику на оверлей, а тут просто атрибут в HTML и готово.
Такие статьи особенно ценны, когда показывают, как современные API сокращают код и убирают зависимость от JS.
Кстати, вдохновившись твоим примером, теперь думаю добавить на Codebra небольшое практическое задание как раз на отработку closedby и ToggleEvent. Хочется сделать пример, где нужно переделать старую модалку, которая висела на JS-костылях, на чистый HTML с новыми атрибутами и через событие toggle выводить, какой именно кнопкой её закрыли.
Спасибо за статью, буду ссылаться на неё в пояснениях к заданию, когда сделаю!
Автору спасибо за разбор. Особенно за специфику современных псевдо-классов :where() и :is(), о которых реально многие забывают.
Судя по комментариям, главная проблема сейчас не в формулировке ответов, а в перенасыщении рынка. Люди годами учат теорию, проходят собесы, но так и не могут попасть на хорошие позиции. Просто заучить правильные ответы на 20 вопросов не поможет.
Сейчас проходят только те, кто может не просто дать определение «специфичности», а сразу объяснить, как она поведет себя в реальном проекте с :nth-child и :has(), и зачем это вообще нужно.
Я последнее время вообще пришел к выводу, что заучивать теорию вообще нет смысла, главное знать как ее применить на практике. Что касается верстки, чтобы человек не просто прочитал про гриды, а сразу руками покрутил, как меняется распределение высоты при grid и при flex, и закрепил это на практике.
Если очень хочется на собеседовании проверить глубину знаний в верстке, то лучше, например, предложить сверстать интерактивную карту солнечной системы на чистом HTML/CSS. Это намного лучше покажет, на что способен человек.
Статья полезная. Но тем, кто реально хочет пройти собес в 2026 году, советую не читать ответы, а идти писать код.
Двенадцать лет назад я не проверил как будет переводиться сокращенная версия названия, а потом менять было поздно) Во всяком случае спасибо за почетное второе место.
Кстати, полное название изначально было CodeBrain :)
Полностью согласен. Думаю чтобы не объяснять коллегам, им нужно хотя бы раз попробовать реализовать модалку на dialog, чтобы понять всю их простоту.
На основе вашей статьи сделал небольшой интенсив, в котором нужно переписать модалку без использования JavaScript.
Будем вместе искоренять страх перед новыми возможностями)
Спасибо за основательный разбор! Тема веб-сокетов обычно воспринимается как чёрный ящик: есть connect, есть send, а что там внутри уже не важно, если это работает. Но ровно до первого 1006 или странного поведения за прокси.
Особенно полезно, что вы прошлись по RFC, показали реальную структуру фрейма с битовыми масками и механизм маскирования. Вы хорошо объяснили про маскирование и то, что это не шифрование, а защита от атак на промежуточные прокси. Многие действительно думают, что маскировка нужна для конфиденциальности, хотя на самом деле история именно про то, чтобы вредоносный JS не мог сэмулировать HTTP-запрос и отравить кеш.
И отдельный респект за упоминание backoff при переподключении. Это та деталь, о которой часто забывают даже в коммерческих проектах, а потом сервер ложится от одновременной волны переподключающихся клиентов.
Единственное, что можно добавить для тех, кто хочет копнуть глубже: полезно заглянуть в исходники production-библиотек, например
websocketsдля Python или реализацию в стандартной библиотекеasyncio. Там видно, как те же самые механизмы (фрейминг, контрольные сообщения, обработка закрытия) реализованы с учётом реальных случаев, таймаутов и правильной работы с памятью.Ещё раз спасибо за качественный материал. Такие статьи помогают лучше понимать инструменты, которыми мы пользуемся.
Отличный материал, Сергей! Как раз тот случай, когда бэкендер честно признаёт, что раньше не понимал, а теперь видит картину целиком.
Особенно зашла мысль про API как язык общения, который должен быть удобен обеим сторонам. Как раз думаю добавить на Codebra задание, где нужно будет взаимодействовать с разными типами API, чтобы на практике показать эту проблему. Часто человек учит JavaScript, пишет код, но когда дело доходит до реального общения с бэкендом, начинаются танцы с бубном. Склеивание ответов от нескольких эндпоинтов, трансформация данных на клиенте, костыли с кешированием. Хочется в задании как раз подсветить, что проблема часто не в коде, а в том, как спроектировано API.
Про GraphQL и BFF отдельное спасибо. Многие до сих пор думают, что GraphQL является какой-то сложной штукой от Facebook, и проходят мимо. А на деле это просто инструмент, который в нужном месте даёт фронту дышать чуточку свободнее. Думаю в своих материалах сделать разборы когда и что лучше использовать: REST, GraphQL или BFF. Потому что джуны часто учат технологии, а надо учить выбирать инструмент под задачу.
И отдельное спасибо за примеры из реального мира: Netflix, Vercel, Shopify. Это не просто теория для собеседований, а то, как реально строятся современные высоконагруженные системы. Буду ссылаться на статью в своих материалах как на хороший обзор для тех, кто хочет копнуть глубже.
Отличная статья! С пунктом про placeholder вместо label в целом согласен, что это частая проблема, особенно в сложных формах. Но тут, мне кажется, всё же зависит от аудитории и контекста. Для простых полей (поиск, подписка по email) и молодой аудитории placeholder может быть достаточно, так как люди и так понимают, что вводить. А вот для пожилых пользователей, в сложных сценариях (оформление заказа и т.д.) или длинных анкетах думаю что label обязателен. Так что скорее нужно знать когда использовать, чем никогда не использовать.
А вообще статья заставила задуматься. Честно признаюсь, в своих курсах на Codebra я доступности не уделял должного внимания. Всё больше про «Как сверстать макет», а про то «Как сделать доступно для всех» как-то упускал. Ваши пять пунктов отличная затравка, теперь буду пересматривать программу и добавлять интенсив про доступность.
Спасибо за пинок в правильную сторону!
Отличный обзор! Про
ToggleEvent.sourceдаже не задумывался, а ведь и правда элегантное решение для многих сценариев. Ноclosedbyдля меня лично главное открытие. Сколько кода писал, чтобы закрывать модалки по клику на оверлей, а тут просто атрибут в HTML и готово.Такие статьи особенно ценны, когда показывают, как современные API сокращают код и убирают зависимость от JS.
Кстати, вдохновившись твоим примером, теперь думаю добавить на Codebra небольшое практическое задание как раз на отработку
closedbyиToggleEvent. Хочется сделать пример, где нужно переделать старую модалку, которая висела на JS-костылях, на чистый HTML с новыми атрибутами и через событиеtoggleвыводить, какой именно кнопкой её закрыли.Спасибо за статью, буду ссылаться на неё в пояснениях к заданию, когда сделаю!
Автору спасибо за разбор. Особенно за специфику современных псевдо-классов :where() и :is(), о которых реально многие забывают.
Судя по комментариям, главная проблема сейчас не в формулировке ответов, а в перенасыщении рынка. Люди годами учат теорию, проходят собесы, но так и не могут попасть на хорошие позиции. Просто заучить правильные ответы на 20 вопросов не поможет.
Сейчас проходят только те, кто может не просто дать определение «специфичности», а сразу объяснить, как она поведет себя в реальном проекте с :nth-child и :has(), и зачем это вообще нужно.
Я последнее время вообще пришел к выводу, что заучивать теорию вообще нет смысла, главное знать как ее применить на практике. Что касается верстки, чтобы человек не просто прочитал про гриды, а сразу руками покрутил, как меняется распределение высоты при grid и при flex, и закрепил это на практике.
Если очень хочется на собеседовании проверить глубину знаний в верстке, то лучше, например, предложить сверстать интерактивную карту солнечной системы на чистом HTML/CSS. Это намного лучше покажет, на что способен человек.
Статья полезная. Но тем, кто реально хочет пройти собес в 2026 году, советую не читать ответы, а идти писать код.