Веб Мастерская | Веб разработка и программирование | ИТ | IT

JS:

Шаблонные литералы — это не только ${переменная}, но и нормальная многострочность без \n и бесконечных плюсов.

Раньше:

const msg = "Привет, " + name + "!\n" +
"Заказ №" + id + " готов.";

Теперь:

const msg = Привет, ${name}! Заказ №${id} готов.;

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

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

Но есть два подводных камня.

1. Лишние отступы из кода попадут в строку. Если шаблон выровнен по красоте, эти пробелы окажутся в тексте. Для писем и разметки это часто критично.

2. Если внутрь ${} попадает пользовательский ввод и строка идёт в HTML, шаблон не защищает от XSS. Экранируйте данные.

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

Совет из практики

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

Практика: видите склейку через + и \n — предлагайте рефакторинг на шаблонные литералы. Код становится короче, а читать его приятнее. Для больших шаблонов лучше шаблонизатор, но для простых задач литералы идеальны.

Вот так. Идем кодить дальше! 🚀

PHP:

Коллеги, кто хоть раз видел «Call to a member function on null», тот уже познал боль. Обычно это происходит так: запрос к MySQL вернул ноль строк, а код всё равно пытается вызвать метод у объекта.

Раньше писали так:





$phone = null;
if ($user !== null && $user->profile !== null) {
$phone = $user->profile->phone;
}

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

В PHP 8+ есть nullsafe оператор ?->:





$phone = $user?->profile?->phone;

Если $user равен null, цепочка не падает, а просто вернёт null. Дальше решаем сами: дефолт, бейдж, 404 или лог.

Где реально выручает:

— $user из репозитория: SELECT ... LIMIT 1 может вернуть пустоту;
— связи: $order?->customer?->email;
— DTO и сущности, где часть полей не заполнена.


Но нюансы из мастерской:

— ?-> хорош там, где «нет данных» — нормальный сценарий.

— Если объект обязан быть, не прячьте ошибку. Лучше исключение или проверка на уровне сервиса.

— Для массивов он не подходит: используем $data['phone'] ?? null.

— Не заменяет типизацию. ?User $user = null и строгие контракты всё ещё спасают.

— Если используете PDO, не путайте false и null. Удобнее, когда репозиторий возвращает ?User, а не сырой результат fetch().

Пример:





$user = $repo->findById($id);
$email = $user?->getContact()?->getEmail();
return $email ?? 'не указан';

Меньше лесенки из if, больше читаемости. Но помним: nullsafe — не магия, а аккуратный способ работать с пустыми результатами БД.

Вот так. Идем кодить дальше! 🚀

HTML:

Коллеги, хватит тянуть библиотеки ради одной всплывашки! В 2026 нативный Popover API уже спокойно живёт в продакшене, а многие всё ещё пишут велосипеды.

Раньше: плагины, z-index войны, слушатели на document, «а почему оно не закрывается?». Теперь достаточно двух атрибутов:





<button popovertarget="menu">Меню</button>
<div id="menu" popover>Я нативный поповер.</div>

Без JS. Браузер сам:

• поднимет элемент в top layer поверх всего;
• закроет его по клику вне и по Esc;
• возьмёт на себя базовую доступность;
• отдаст :popover-open и ::backdrop для стилей.

Если нужно не переключать, а явно открыть или закрыть:





<button
popovertarget="menu"
popovertargetaction="show"
>Открыть</button>

<button
popovertarget="menu"
popovertargetaction="hide"
>Закрыть</button>

Три режима:

1️⃣ popover="auto" — закрывается сам, вытесняет другие. Идеален для меню, фильтров, быстрых действий.

2️⃣ popover="hint" — мягкий режим для подсказок, которые не должны агрессивно всё закрывать.

3️⃣ popover="manual" — полный ручной контроль, без автозакрытия.

Из мастерской:

— Не делайте из поповера модальное окно. Для диалогов есть <dialog>.

— Не прячьте контент через display: none вручную — браузер сам управляет видимостью.

— Состояние стилизуйте через :popover-open, фон через ::backdrop.

— Для позиционирования у кнопки смотрите в сторону CSS Anchor Positioning.

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

Вот так. Идем кодить дальше! 🚀

КЕЙС:

Коллеги, небольшой клиент попросил внутреннюю CRM: клиенты, задачи, статусы, пара отчётов. Бюджет скромный, срок — две недели.

Стажёр предлагает: «Давайте честный MVC: роуты, контроллеры, модели, middleware, валидация, слои!» Звучит солидно. Но я посчитал: 15 сущностей, 3 экрана, 1 роль. Если строить дворец, не успеваем.

Выбрал классическое ООП: аккуратные классы, простые сервисы, тонкий слой БД. Без фреймворочной магии.


Что сделали:

— Client, Task, Status как сущности;
— ClientService и TaskService для логики;
— один входной файл с простым роутингом, PDO-обёртку и минимум зависимостей.


Почему это быстрее:

— меньше слоёв — меньше кода, который надо писать и отлаживать;
— не нужно спорить о «правильном» разделении ответственности там, где задача на один метод;
— правку в продакшене можно найти за 5 минут, а не блуждать по папкам.


Итог: рабочую версию отдали за 5 дней, поддержка занимает минуты, клиент доволен.

Спустя месяц клиент попросил экспорт в Excel. Добавили один метод в сервис и простой шаблон, а не переписывали половину проекта.

Важно: я не против паттернов. Для большого проекта с командой, ролями, API и сложными сценариями слои оправданы. Но для маленькой внутренней системы классическое ООП часто выигрывает у «архитектуры ради архитектуры».

Совет: выбирайте сложность под масштаб задачи. Лучше скучный рабочий код, чем красивый, но не сданный в срок.

Вот так. Идем кодить дальше! 🚀

ДАЙДЖЕСТ НОВОСТЕЙ:

Привет, коллеги! 👋 Пока одни паникуют из-за ИИ, мы с вами как всегда спокойно пилим проекты. Но следить за индустрией надо, поэтому я собрал для вас топ-5 новостей веб-разработки за эту неделю.

🚨 Срочный патч для Next.js и React!
Vercel выкатили внеочередное обновление безопасности, закрыв критические уязвимости в Next.js и React. Если у вас или ваших клиентов висят проекты на этом стеке, бегом обновляйтесь. Безопасность — это не шутки, коллеги.

🚀 Bun 1.4.3 залетел в прод!
Вышел новый релиз Bun 1.4.3, который снова хвастается космической скоростью установки пакетов. Если вы еще не пробовали заменить npm на Bun в своих пет-проектах или на фрилансе — самое время. Сэкономите кучу времени при CI/CD.

🎨 CSS и HTML в 2026 году
В нативном вебе активно закрепляются View Transitions, API Popover и Anchor Positioning. Это значит, что сложные попапы и плавные переходы между страницами теперь можно делать без тонны JavaScript. Фронтендерам на заметку — код станет чище, а клиенты будут в восторге!

🛠 Обновление Chrome DevTools
В Chrome DevTools добавили поддержку soft navigation в разделе Performance и улучшили работу с MCP-серверами. Теперь отлавливать просадки FPS и следить за производительностью SPA-приложений стало еще удобнее.

📝 WordPress 7.2 уже на подходе
Для тех, кто делает сайты для малого бизнеса: Beta 1 версии 7.2 выходит 20 октября. Это финальный крупный релиз года, так что готовимся обновлять клиентские сайты и тестировать новые фишки.

Какую из этих технологий вы уже щупаете в своих проектах? Делитесь в комментах! 👇

Вот так. Идем кодить дальше! 🚀

ФАКТЫ И ЦИФРЫ:

Сколько сайтов уже на HTTPS в 2026?

Коллеги, давайте без лирики — только цифры, которые заставляют задуматься.

По данным на осень 2026 года:

🔒 ~96–97% страниц, загружаемых в Chrome и Firefox, отдаются по HTTPS. Три года назад было 91%. Прогресс есть, но он замедлился.

🌐 Если смотреть на все зарегистрированные домены (включая заброшенные блоги 2014 года и лендинги, которые «потом доделаю»), картина скромнее — порядка 84–87%. То есть каждый 7-й сайт в интернете до сих пор встречает посетителя надписью «Не защищено».

📱 В мобильном трафике доля HTTPS ещё выше — ~98%, потому что браузеры на смартфонах просто пессимизируют и блокируют mixed-content агрессивнее.

🏢 Среди топ-10 000 сайтов мира — 99,2%. Тут без вариантов: нет сертификата — нет тебя в выдаче, нет в рекламных сетях, нет в доверии пользователя.


А теперь практический вывод, коллеги:

Если вы делаете сайт для малого бизнеса и клиент говорит «да ладно, у нас же не банк, зачем SSL» — покажите ему эти цифры. В 2026 году сайт без HTTPS — это как вывеска «Мы не заботимся о ваших данных». Конверсия падает на 12–18% просто из-за красного замка в адресной строке.

И да, бесплатный Let's Encrypt никто не отменял. Настройка — 15 минут. Автопродление — одна строчка в cron. Отмазка «дорого и сложно» умерла ещё в 2019-м.

Проверьте свои проекты сегодня. Особенно те, что «на поддержке с прошлого года». Один curl -I https://ваш-домен — и сразу видно, не протух ли сертификат.

Вот так. Идем кодить дальше! 🚀

ИЗ ПРОФЕССИИ:

Как задавать правильные вопросы на код-ревью

Коллеги, давайте честно: код-ревью у многих вызывает либо панику («сейчас меня разнесут»), либо скуку («опять формальность»). А всё потому, что мы не умеем задавать вопросы. Не отвечать на них — а именно задавать.


Из мастерской. Вот что реально работает:

❌ «Почему ты так написал?». Звучит как допрос. Собеседник сразу уходит в оборону.

✅ «Вижу, тут выбран подход X. Расскажи, почему не Y? Хочу понять контекст, вдруг я что-то упустил.». Вы не нападаете — вы учитесь. И даёте человеку пространство объяснить.

❌ «Это неправильно.». Точка. Без аргумента. Без альтернативы. Просто приговор.

✅ «А что будет, если сюда придёт null / пустой массив / юзер без токена? Давай разберём кейс.». Конкретный сценарий вместо абстрактного «неправильно».


Три правила, которые я вбил себе в голову за годы в продакшене:

1️⃣ Вопрос > Утверждение. «Может, здесь лучше вынести в хук?» работает в сто раз лучше, чем «Вынеси в хук». Вы предлагаете диалог, а не приказ.

2️⃣ Спрашивайте про «почему», а не про «что». Код вы видите сами. А вот контекст решения — нет. «Почему тут не useMemo? Есть причина?» — и вам ответят: «Да, ререндер тут дешевле, чем мемоизация». И вы станете чуть умнее.

3️⃣ Не копите вопросы в один комментарий-простыню. Лучше три коротких треда по делу, чем стена текста на 40 пунктов. Человеку физически тяжело это разгребать.

Бонус для джунов: не бойтесь спрашивать «глупое». Серьёзно. Я на ревью спрашивал, зачем нужен key в React-списке, хотя «уже должен был знать». И мне объяснили нюанс с реконсиляцией, которого нет ни в одном учебнике.

Код-ревью — это не экзамен. Это парное программирование, растянутое во времени. И чем лучше ваши вопросы, тем быстрее растёт вся команда.

Вот так. Идем кодить дальше! 🚀

БАЗА:

Тег <picture> и srcset: отдаём правильные картинки разным экранам

Коллеги, признавайтесь: кто до сих пор грузит один и тот же баннер 2560px и на десктоп, и на мобилку? 😅 А потом пользователь на 4G ждёт 8 секунд, пока страница «прогрузится». Знакомо?

Сегодня разберём два инструмента, которые решают эту боль раз и навсегда.


srcset — «выбери сам»

Когда у вас одна и та же картинка, но в разных размерах:

<img src="hero-800.jpg"
srcset="hero-400.jpg 400w,
hero-800.jpg 800w,
hero-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="Наш крутой проект"
>

Браузер сам смотрит на ширину экрана, плотность пикселей и выбирает оптимальный файл. Вы не управляете выбором напрямую — просто даёте варианты.


<picture> — «я решаю»

Когда нужна другая картинка для другого экрана (арт-дирекшн):

<picture>
<source
media="(min-width: 1024px)"
srcset="hero-desktop.webp"
type="image/webp">

<source
media="(min-width: 1024px)"
srcset="hero-desktop.jpg">

<source
srcset="hero-mobile.webp"
type="image/webp">

<img src="hero-mobile.jpg" alt="Проект">
</picture>

Здесь вы жёстко говорите: «на десктопе — одна, на мобилке — другая». Тег <img> внутри обязателен — это фолбэк для старых браузеров.


Когда что юзать:

→ srcset — одна картинка, разные размеры (оптимизация веса)
→ <picture> — разные кропы, форматы или вообще другие изображения под брейкпоинты


Из продакшена:

— Всегда указывайте width и height у <img>, чтобы не было скачков макета (CLS скажет спасибо)
— Формат WebP/AVIF через type в <source> — экономия 25–50% без потери качества
— Ленивая загрузка: loading="lazy" для всего, что ниже первого экрана

Коллеги, адаптивные картинки — это не «плюшка», а гигиена. Пользователь на бюджетном смартфоне не должен качать ваш 4K-хиро.

Вот так. Идём кодить дальше! 🚀

SEO:

Тонкости атрибута rel="canonical"

Коллеги, знакомая боль: пишешь годный контент, а в выдаче Google — тишина. А потом открываешь Search Console и видишь 300 «дублирующихся страниц без указанной пользователем канонической». Знакомо? Добро пожаловать в мир canonical 👇


Что это вообще такое?

<link rel="canonical" href="..."> — это шёпот поисковику: «Эй, оригинал вот тут, а остальное — копии, не распыляй вес». Простыми словами — страховка от дублей.


Кейс из мастерской

Делали редизайн интернет-магазину автозапчастей. Трафик упал на 40% после переезда. Причина? UTM-метки из рекламных кампаний плодили тысячи дублей вида ?utmsource=yandex&utmmedium=cpc.... Робот индексировал каждую. Поставили canonical на чистый URL — через 3 недели позиции вернулись, а вес сконцентрировался на нужных карточках.


5 тонкостей, о которых молчат учебники:

1️⃣ Самоссылающийся canonical — ставь даже на оригинальной странице. Это защита от паразитных параметров.

2️⃣ Пагинация ≠ главная. site.ru/blog?page=1 не должен каноникалиться на site.ru/blog/ — это разные интенты.

3️⃣ HTTPS и www. canonical должен указывать на ту версию, которую ты считаешь основной. Иначе权重 теряется.

4️⃣ Не путай с 301! Canonical — это «покажи, но учитывай оригинал». 301 — это «навсегда переехали». Для устаревших страниц — только редирект.

5️⃣ Кросс-доменный canonical работает, если ты syndicating контент на партнёрские сайты. Укажи источник — и вес останется у тебя.

Лучше генерировать чистый URL без query-параметров — так надёжнее.

⚠️ Фатальная ошибка: canonical, указывающий на 404 или заблокированную в robots.txt страницу. Поисковик это проигнорирует и решит сам. А его решения нам редко нравятся 😅

Проверяй свой сайт прямо сейчас: site:твой-домен.ru в Google — если выдача пестрит URL с параметрами, пора чинить.

Вот так. Идем кодить дальше! 🚀