JavaScript — редкий язык, который одновременно является «родным» для браузера и при этом давно вышел за пределы фронтенда: на нём пишут бэкенд, десктопные приложения, мобильные клиенты и даже игры. При этом вокруг JS всё ещё много путаницы — от «Java и JavaScript это одно и то же» до «фронтенд = кнопочки».

В этом интервью я, Александр Шулепов (телеграм-канал Shulepov Code), поговорил с Дмитрием Колотильщиковым — старшим разработчиком и автором канала «ИТ‑интроверт» — о том, как войти в профессию, почему Angular новичкам может навредить, зачем фронтендеру микрофронтенды, как устроены зарплаты и рынок за пределами России, и что на самом деле помогает дорасти до сеньора.

Путь в JavaScript: почему старт с Angular — сомнительная идея

Александр: Дмитрий, расскажите, как вы пришли в JavaScript.

Дмитрий: В JavaScript я пришёл скорее случайно. Я выбрал локальную школу программирования в родном Гомеле: там обещали и Java, и фронтенд, и «через год — фуллстек». С точки зрения процесса было не идеально, но нам попался сильный преподаватель-фронтендер. Он работал с Angular, мы договорились о небольшой группе — и он хорошо прокачал нас по фронтенду. Это и стало отправной точкой. При этом начинающим я не рекомендую стартовать с Angular: это может быть чрезмерно сложно. Нужно сразу знать TypeScript и понимать концепции фреймворка, где много встроенного «по умолчанию». Новичка это отвлекает от базы JavaScript, которую важно освоить в первую очередь.

В JS часто приходят «с фронтенда» — потому что в браузере он действительно базовый.

Angular новичкам может мешать: TypeScript + концепции фреймворка отвлекают от основы JavaScript.

Александр: У меня есть проект на Angular и ASP.NET. Сначала хотел сделать на React, но не получилось найти разработчика. Поэтому я тоже с Angular знаком.

Дмитрий: Тогда вы понимаете плюс разделения фронтенда и бэкенда: при необходимости фронтенд можно переписать на другой стек, а бэкенд оставить тем же. Это упрощает развитие системы.

Александр: А чем вы занимались до ИТ? Я видел, что у вас была видеография.

Дмитрий: Я занимался именно видеографией: снимал видео, в основном — свадьбы, потому что территориально это был самый понятный способ зарабатывать на видео. Были и рекламные ролики, и выпускные. Это была полноценная фуллтайм-работа. Параллельно я вёл YouTube-канал по видеографии; он существует до сих пор, но я его уже не развиваю. В какой-то момент я понял, что хочу двигаться дальше и делать более сложные технические вещи. Мне стало интересно попробовать себя в ИТ. На старте я вообще не понимал, что это такое: Java и JavaScript не различал. Я поставил себе простой критерий: «Понравится — продолжу, не понравится — уйду в другое». В итоге мне понравилось.

Александр: Какое у вас образование?

Дмитрий: Техническое и экономическое.

Александр: Профессия была не ИТ?

Дмитрий: Да, не ИТ.

Александр: Почему вы выбрали именно JavaScript, а не Python и другие языки?

Дмитрий: Я его почти не «выбирал». Когда я понял, что такое фронтенд, оказалось, что в веб-разработке JavaScript — монополист: на фронте он присутствует всегда. Плюс на старте это достаточно лёгкий язык для входа.

На старте работает простая стратегия: попробовать и честно решить, «ваше» это или нет.

Зачем разработчику блог: YouTube как ускоритель обучения

Александр: Как у вас возникла идея YouTube-канала по JavaScript?

Дмитрий: Идея появилась ещё на этапе обучения. У меня хорошо получалось, и я понимал, что в будущем хочу уделять часть времени обучению. У меня уже был опыт YouTube по видеографии, и я видел, что это перспективное направление и для саморазвития: ведение канала сильно «бустит». На ранних этапах я записал простые видео по HTML и CSS — так появился фундамент. Потом я пошёл в компанию набираться более «хардкорного» опыта и делать темы сложнее.

Александр: Я тоже замечал: когда готовишь курс или видео, внезапно выясняется, что тема гораздо шире, чем казалось.

Дмитрий: Именно. Я бы добавил: лучше воспринимать блог как хобби, а не как «вторую работу». Делать YouTube одному сложно; если подходить как к профессии — нужен сильный бэкграунд и часто команда. Но даже формат «постов» полезен: аудитория даёт обратную связь, приходится отвечать, искать решения, обновлять знания.

Лучше считать блог хобби, иначе он быстро превращается в перегруз.

Александр: У вас есть «стримы» — как вы к ним готовились? Это был анализ других авторов или вы строили свой формат?

Дмитрий: Это не прямые стримы: материалы готовились заранее и монтировались. В реалтайме так выступить сложно. В целом работает принцип «насмотренности»: вы смотрите разных авторов, берёте отдельные удачные приёмы подачи — и на их основе формируете свой стиль. Мне, например, нравится подход Владилена Минина, а у Ulbi TV — детализация и структура. При этом «полностью взять у одного» обычно не получается: всё равно получается своё.

«Насмотренность» помогает сформировать стиль, но итоговый продукт всё равно получается авторским.

Блог — инструмент обучения: чтобы объяснять, приходится разбираться глубже.

Проекты, которые «выносят мозг»: Grid на React и микрофронтенды

Александр: Был ли проект или задача, которые вас сильно «нагрузили»?

Дмитрий: Да. Когда я пришёл в текущую компанию, я попал на внутренний проект и получил возможность писать приложение на React с нуля — для новичка это редкий шанс и сильный челлендж.

Там нужно было реализовать Grid без сторонних библиотек: таблицу с данными, перетаскивание, изменение размеров ячеек, добавление/удаление, сохранение размеров, адаптивность. Плюс фильтры, сортировка, дерево элементов в фильтрах. Данные приходили с бэкенда. В некоторые моменты мне казалось, что это невозможно, но тимлид помогал разбирать и доводить до результата. Сейчас этим проектом можно гордиться: он внутренний, его используют сотрудники в реальном времени.

Сильные проекты обычно начинаются с «мы пишем с нуля» и заканчиваются зрелой архитектурой.

Grid «без библиотек» — хороший пример задачи, где растёшь на практике.

Александр: Похоже, это и есть проект, которым вы гордитесь.

Дмитрий: Да, это один из. Второй — коммерческий проект с заказчиком из Англии, где я работаю около двух лет. Там мы писали приложение с нуля на микрофронтендах: отдельные модули-приложения, которые подключаются к основному «хосту». Использовали Webpack. Пришлось решать вопросы производительности: ленивая загрузка, удаление неиспользуемого кода, оптимизация бандлов, работа в монорепозитории. Этот проект дал много опыта.

Микрофронтенды и оптимизация бандлов — типичная зона роста для старшего-фронтенда.

Деньги и «порог ожиданий»: как меняется восприятие дохода

Александр: Был ли у вас момент, когда вы «заработали первые большие деньги» (условно — 10 тысяч долларов)? Какие были эмоции и на что потратили?

Дмитрий: Когда вы не первый год в ИТ, такие суммы воспринимаются спокойнее. Сейчас они уже не звучат так «страшно», как раньше. В месяц я такие суммы не называю, чтобы никого не вводить в заблуждение, но за несколько месяцев это достижимо. Я обеспечиваю семью; важнее, что хватает на нормальную жизнь.

Доход в ИТ сильно зависит от компании, роли и темпа роста.

«Порог значимости суммы» со временем снижается: важнее стабильность и качество жизни.

Как попасть в международную компанию: собеседования, релокация и рабочий день senior’а

Александр: Расскажите про компанию: как вы туда попали, чем занимаетесь, сложно ли было пройти собеседование и как вы дошли до senior’а.

Дмитрий: В компанию я попал через человека, с которым пересекался в прошлой работе по видеографии. В тот момент я прошёл стажировку в другой ИТ-компании, сделал дипломный проект, но ещё не успел выйти на работу. Мы пообщались, и он сказал, что им нужны Фронтенд-разработчики. Он позвал меня на собеседование.

Техническое собеседование длилось около часа. Мне сказали, что я иду на начальную позицию, но на часть вопросов ответил на среднем уровне. В итоге взяли начинающим. Был блок по английскому: тогда он у меня был слабее, но в компании есть внутренние курсы, и это можно подтянуть.

Я работал в офисе в Минске (я из Гомеля), потому что хотел живого опыта и общения. В 2022 году встал вопрос релокации: многим предложили переехать. Я выбрал Ташкент: там уже был офис, это был удобный «хаб», не требовались визы. Семья приехала позже, мы жили там до весны 2023-го, затем вернулись. При этом я продолжаю ездить в командировки и поддерживать коммуникацию.

Александр: Зачем ездить, если всё можно решить онлайн?

Дмитрий: Бывают ситуации, где важно общение вживую. Например, приезжают заказчики из Англии: несколько дней вместе — обсуждения, совместные активности, тимбилдинг. Там английский реально нужен: разговорный и обсуждение деталей вживую. Ещё я приезжал, когда участвовал во внутренних обучающих программах и читал лекции стажёрам.

Релокация и международные команды резко увеличивают роль английского — хотя бы рабочего уровня.

Александр: Вы обучаете на английском или на русском?

Дмитрий: Могу и на английском, но внутри компании чаще обучал на русском: многие в Узбекистане хорошо понимают русский, поэтому барьера почти нет.

Александр: Как выглядит ваш обычный день?

Дмитрий: Примерно половина дня — созвоны: планерка, оценки, обсуждения. Кода пишу меньше, чем раньше, но пишу. Чувствую, что периодически «тянет» в лидерство: если тимлид в отпуске, коммуникаций становится больше. И тогда важно понять, что вам ближе — код или постоянные звонки.

Александр: Что выбираете вы?

Дмитрий: Пока стараюсь держать баланс, но мне ближе код. От общения устаёшь быстрее, плюс созвоны привязывают по времени: сложнее гибко строить день и уходить в отпуск. Когда вы в основном пишете код, график можно чуть лучше подстроить под себя.

Александр: О чём ваши созвоны — коллеги, клиенты, руководство?

Дмитрий: И клиенты, и команда. Сейчас, например, обсуждаем отдельное микро-приложение для оплат: приходится ежедневно разбирать требования, строить архитектуру фронта и бэка. В команде часть людей говорит по-русски, часть — нет (например, коллеги из Грузии), поэтому созвоны чередуются: один на русском, другой на английском. На неродном языке объяснять концепции энергозатратнее, но это и развивает.

Александр: Коротко: как вы росли в компании, предлагали ли вам рост по должности?

Дмитрий: Мне повезло с менеджерами: они видели результат и часто сами инициировали повышение, иногда я тоже просил. Начинал на внутреннем проекте (Grid), там показал себя, рос. В аутсорсинговых компаниях внутренние проекты не приносят денег напрямую, поэтому есть потолок по зарплате. Когда переходишь на коммерческий проект, где за вас платит заказчик, потолок выше. Плюс в аутсорсе вы можете менять проекты, проходить интервью внутри компании — это помогает не «застревать» на одном месте.

Александр: То есть вас могут «продавать» на аутсорс?

Дмитрий: Да. Компания продаёт либо целые команды, либо отдельных специалистов. Это распространённая модель: людей фактически «арендуют» под задачи заказчика.

Высокий уровень часто означает больше коммуникации; если вам важен код, баланс придётся защищать.

Кадровый рынок и аутсорс: почему текучка неизбежна

Александр: Как вы считаете, ваша компания ощущает проблему с кадрами? Сложно ли нанимать людей?

Дмитрий: Кадровый вопрос всегда актуален. Хороших специалистов сложно найти и сложно удержать. Текучка есть по разным причинам: кому-то не повезло с проектом и менеджером, кто-то долго сидит без проекта и чувствует деградацию, у кого-то конфликт в команде. Один из самых устойчивых сценариев — нанимать стажёров, обучать и выводить на проекты. Для аутсорса это ещё и экономически понятно: заказчик может платить за специалиста «как за старшего», а внутри компании он получает зарплату начинающего — компании выгодно, но и нагрузка на контроль растёт (код-ревью, сопровождение, обучение).

«Дефицит» чаще не в количестве людей, а в качестве и стабильности.

Для аутсорса стажёры — рабочая модель, но она требует сильных наставников и времени на ревью.

Как устроиться в компанию «как у вас»: LinkedIn, резюме и роль английского

Александр: Как устроиться в подобную компанию, если убрать фактор «знакомых»?

Дмитрий: Важно разделять «вас привели на собеседование» и «вас взяли без проверки». Первое возможно, второе — редко. Если вы попадёте в компанию через рекомендации, всё равно проявится ваш реальный уровень: вы работаете в команде, вас видят по задачам и коммуникации, даже по тому, есть ли у вас рабочий сленг или нет. Если говорить про поиск работы в целом: я не прыгаю по компаниям постоянно, поэтому не отслеживаю рынок ежедневно. Но из базового — LinkedIn остаётся ключевой площадкой. Там либо вы откликаетесь, либо чаще работает индивидуально: рекрутеры пишут напрямую или через посредника. Мне, например, регулярно пишут специалисты по персоналу с предложениями, часто с релокацией.

На входе важны стажировка, реальный проект и адекватное интервью — «накрутки» всё равно всплывают позже.

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

Александр: Что должно быть в LinkedIn-профиле?

Дмитрий: Кратко и по существу: стек и навыки, на которые вы претендуете. Если вы идёте во фронтенд, это JavaScript + фреймворк/библиотека (React/Angular) + HTML/CSS и сопутствующие навыки. Плюс хорошо, если есть практика: стажировка, проект, даже бесплатная — но в компании и с понятными задачами. И да: лучше делать профиль и резюме на английском. Английский «выглядит дороже» — проще воспринимается глобальным рынком.

Александр: Если английский слабый, можно ли использовать DeepL или ИИ для перевода профиля?

Дмитрий: Да. Я сам это использую: ИИ помогает оформить текст, фидбэк, блоки резюме, письма. Мы не native speakers, и это нормально — пользоваться инструментами, чтобы текст выглядел аккуратно.

LinkedIn — основной канал для международного рынка: профиль должен быть «про стек», а не «про биографию».

Английский — конкурентное преимущество; ИИ-инструменты можно использовать, чтобы не выглядеть неаккуратно.

Что такое JavaScript и почему он «монополист» в браузере

Александр: Что такое JavaScript и где он используется?

Дмитрий: JavaScript — интерпретируемый язык программирования: выполняется построчно, результат можно увидеть быстро. Браузеры нативно понимают JavaScript. Основное предназначение — веб-разработка, но на нём можно писать и мобильные приложения, и бэкенд, и десктоп, и даже игры.

JavaScript — базовый язык веба, потому что браузер понимает его нативно.

Александр: У меня есть ощущение диссонанса: вы творческий человек, а JavaScript — «техническая часть». Вам не наскучит программирование?

Дмитрий: Пока не наскучило. Когда пишешь код, постоянно сталкиваешься с задачами, где нужно подумать. В других областях у меня наступал момент, когда я уже делал всё, что умею, и становилось скучно. В разработке много «многогранности», и это удерживает интерес. Творчество полезно всем: оно расширяет мышление и помогает искать нестандартные решения. Программирование само по себе я бы не называл творчеством, но с творческим подходом оно может становиться «искусством».

Александр: Почему JavaScript так популярен уже много лет?

Дмитрий: Потому что в браузере он фактически монополист: нет другого языка, который вы пишете «напрямую» и который нативно выполняется в браузере без промежуточных шагов. Даже если вы используете другие технологии, в вебе всё в итоге сводится к JavaScript.

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

Есть и отдельный кейс — WebAssembly: вы можете писать вычислительно тяжёлые вещи на Rust/C/C++ и запускать в браузере через wasm, используя API (интерфейс программирования приложений) и интеграцию с JS. Это позволяет делать «тяжёлые» сценарии прямо в браузере — например, обработку медиа, редакторы, отдельные инструменты.

WebAssembly расширяет возможности: часть логики можно писать не на JS, но в браузере всё равно нужна связка.

С чего начинать новичку: дорожная карта, ресурсы, курсы и менторство

Александр: С чего начать новичку, который решил изучать JavaScript? Можете дать короткий план.

Дмитрий: Важно понимать: «JavaScript-вакансий» почти нет — есть фронтенд. А фронтенд — это больше, чем JavaScript: HTML, CSS, фреймворк/библиотека (React/Angular/Vue), Git и ряд дополнительных вещей. Если вы хотите именно фронтенд, логичный порядок такой: сначала HTML, затем CSS, потом JavaScript. В самом JavaScript — база: переменные и способы объявления, условия, циклы.

Для фронтенда сначала HTML/CSS, потом JS; «чистого JavaScript-разработчика» почти не существует.

Александр: Что лучше: видео «JavaScript за 10 часов», книги или курс?

Дмитрий: Видео может помочь, особенно если оно рассчитано на нулевой уровень. Часто лектор даёт список ресурсов, которые стоит читать параллельно. Мне формат видео нравится: я на нём во многом вырос. Плюс есть Udemy. Из текстовых ресурсов я бы выделил Learn JavaScript: есть англоязычная версия и хорошая русская. Там можно идти по шагам и решать задачи в конце разделов. Я сам периодически возвращаюсь, потому что некоторые концепции полезно перечитывать. Хорошая схема: посмотреть видео → повторить → затем закрепить в документации задачами.

Лучший формат обучения — микс: видео + документация + задачи.

Александр: Стоит ли покупать курсы?

Дмитрий: Смотря какие. Важно анализировать рынок: содержание, отзывы, наличие ментора. Кому-то ментор обязателен — людям сложно учиться самостоятельно. Я чаще учился сам: покупал недорогой курс и параллельно интересовался в интернете. Но можно сделать иначе: взять базовый курс и отдельно найти ментора, который будет «находить слабые места» и прокачивать.

Александр: Ментор нужен новичку с нуля или лучше сначала самим?

Дмитрий: Лучше сначала немного разобраться самостоятельно, чтобы быть в контексте. Иначе можно купить дорого то, что можно было бы закрыть дешевле. Когда вы уже знаете базу и приходите к ментору с запросом «я знаю HTML/CSS/JS, хочу React» — работать проще и вам, и ментору.

Курсы имеют смысл, если есть структура и обратная связь; ментор эффективнее, когда у вас уже есть база.

Александр: Низкий порог входа в JavaScript — это плюс или минус?

Дмитрий: Скорее плюс. В вебе много задач, специалисты нужны. И даже если вы уйдёте в бэкенд, JavaScript всё равно часто пригодится: много клиент-серверных приложений. Бэкендерам, которые вынужденно делают фронт, часто сложно со стилями и разметкой; у меня путь обратный — мне фронт даётся легко, а бэкенд интересен.

React, Angular, конкуренция и архитектура фронтенда

Александр: Что бы вы посоветовали выбирать: React или Angular (и вообще Vue)?

Дмитрий: Мне нравятся и Angular, и React. Vue я пробовал меньше. Если смотреть на рынок и бизнес-задачи, React сейчас наиболее универсален: гибкая архитектура, сильное сообщество, часто хорошая производительность. На нём можно относительно быстро делать приложения, особенно если выстраивать модульность (например, микрофронтенды).

Александр: Но React порождает огромную конкуренцию: устроиться сложнее.

Дмитрий: Конкуренция есть, но её качество разное. Есть поток выпускников онлайн-школ, которые «накручивают» опыт в резюме. На собеседовании и испытательном сроке это обычно видно — по уровню общения и по тому, как человек решает задачи. React как библиотека даёт гибкость — и это одновременно риск: если не задать архитектурный подход, можно получить «кашу». В Angular архитектура сильнее задана фреймворком, и проекты часто более однотипны по структуре, что упрощает вход в новый код. В React помогает дисциплина и паттерны (например, Feature Slice Design) и модульность. В микрофронтендах каждый модуль изолирован, поэтому сложнее «потеряться».

Александр: В вашей компании используют и React, и Angular, или только React?

Дмитрий: В компании в целом используется много технологий: разные команды под разные проекты. Внутри конкретного проекта стек обычно фиксирован: например, фронт на React, бэкенд на .NET/C# и т. д.

React сейчас чаще выигрывает на рынке за счёт гибкости и экосистемы, но требует дисциплины в архитектуре. Angular даёт более «предсказуемую» структуру, но кривая обучения выше.

Микрофронтенды — рабочий способ держать модульность и снижать хаос в больших фронтендах.

Java ≠ JavaScript: отличия, сильные и слабые стороны JS

Александр: Чем отличается JavaScript от Java?

Дмитрий: Java — компилируемый язык: перед запуском нужно собрать проект. JavaScript интерпретируется «на лету»: вы написали код и сразу видите результат. Java чаще ассоциируется с серверной разработкой и Android (хотя сейчас там активно используют Kotlin). JavaScript исторически про веб и визуальную часть, но на нём тоже можно писать бэкенд.

Александр: Что вам нравится в JavaScript?

Дмитрий: На нём приятно писать: он лаконичный, интуитивный, с хорошей документацией. Он легко интегрируется с браузером, не требует сложных настроек. Если вы знаете JavaScript, вы можете расширяться: Node.js для бэкенда, Electron для десктопа, React Native для мобильных решений.

Александр: А что не нравится?

Дмитрий: У гибкости есть обратная сторона: можно «выстрелить себе в ногу». Нет строгой типизации по умолчанию, можно смешивать стили (var/let/const), использовать старые API (интерфейс программирования приложений). В нагруженных сценариях можно ошибиться с циклом событий, памятью, производительностью. С этим можно жить, если вы понимаете принципы и используете TypeScript.

Java и JavaScript — разные языки с разной экосистемой и моделью исполнения.

Сила JS — в скорости обратной связи и универсальности. Слабое место — чрезмерная гибкость без дисциплины и типизации.

ECMAScript, Babel и JSON: «как это работает под капотом»

Александр: Как происходит версионирование JavaScript?

Дмитрий: Через ECMAScript — это стандартизация языка. Каждый год появляются обновления. Есть фичи, которые ещё не стандартизированы (условно ES Next). При этом старые возможности в JS часто продолжают работать, поэтому в реальном коде можно встретить смесь подходов.

ECMAScript — стандарт, по которому развивается язык; ES Next — «ещё не стандартизированное».

Александр: Что такое Babel?

Дмитрий: Babel — транспайлер: берёт новый JavaScript и конвертирует в более старый, чтобы код работал в старых браузерах. Проблема совместимости реальная: кто-то может сидеть на старой ОС и не обновлять браузер. Поэтому в сборке часто используют Babel и настраивают, насколько «старые» браузеры нужно поддерживать.

Александр: Babel давно существует?

Дмитрий: Достаточно давно, точный год я не называл.

Babel помогает поддерживать старые браузеры, превращая новый JS в старый синтаксис.

Александр: Что такое JSON и как он связан с JavaScript?

Дмитрий: JSON (JavaScript Object Notation) — формат обмена данными по сети. Вместо XML чаще используют JSON, потому что он удобнее и хорошо ложится на объекты в JavaScript: есть встроенные методы, чтобы парсить и сериализовать. Ограничения тоже есть: нельзя передать функции, комментарии, а undefined «не прилетает». Но для клиент-серверного обмена это стандарт.

JSON — стандарт обмена данными между клиентом и сервером, близкий JS по модели объектов.

Александр: Для новичка JavaScript как первый язык — нормальный выбор?

Дмитрий: Да, один из лучших. Для сравнения: я сейчас учу Rust — он очень мощный, но без опыта в других языках вход был бы тяжелее. В JS порог ниже.

Термины рынка: веб-девелопер, фронтенд, фуллстек и «синтаксический сахар»

Александр: В чём разница между веб-девелопером, JS-девелопером, фронтендом и фуллстеком? Сейчас в названиях много путаницы.

Дмитрий: Это похоже на «синтаксический сахар» в языке: по сути, делаете одно и то же, но называете по-разному. Термин «JavaScript-разработчик» в вакансиях звучит странно: есть фронтенд, бэкенд и фуллстек. «Чистых JS-ников» почти не бывает.

Названия ролей часто «маркетинговые»: ориентируйтесь на задачи и стек, а не на слово «JS- разработчик ».

Александр: Какие навыки обязательно нужны, чтобы быть фронтенд-разработчиком?

Дмитрий: Помимо базовой адекватности и усидчивости — нужен план. Можно смотреть маршрут обучения, но они часто пугают детализацией. Если упрощать, то базовый набор: HTML, CSS, JavaScript, React, TypeScript, Git. Дальше нюансы появятся по мере обучения.

База для фронтенда проста и конечна: HTML/CSS/JS + фреймворк + TS + Git.

Александр: Представим, к вам пришёл друг и сказал: «Хочу работать у вас JavaScript-программистом». Что бы вы посоветовали?

Дмитрий: Я бы дал план и не перегружал планами оббучения: HTML, CSS, JavaScript, React, TypeScript, Git. И отдельно подчеркнул бы: TypeScript стоит учить — он упрощает жизнь.

Roadmap полезен как карта, но вреден как «страшилка» на старте.

TypeScript: строгая типизация без мифов

Александр: Что выбрать: JavaScript или TypeScript? Строгая типизация — это плюс?

Дмитрий: TypeScript — это надстройка над JavaScript: тот же синтаксис, но добавлены типы. Типизация работает на этапе разработки/сборки: она проверяет код, но не «блокирует запуск» так жёстко, как компилируемые языки. В итоговом бандле TypeScript-кода уже нет — остаётся JavaScript.

Я считаю TypeScript очень полезным: код становится читаемее и защищённее, легче работать с моделями данных, которые приходят с бэкенда. Типы помогают не обращаться к несуществующим полям и ловить ошибки раньше.

TypeScript — это JavaScript + типы, которые помогают ловить ошибки до запуска. Он не отменяет необходимость думать, но сильно повышает читаемость и предсказуемость кода.

Для современного фронтенда TypeScript — практически must-have.

Наставничество, зарплаты и выгорание

Александр: Расскажите про наставничество: преподаёте ли вы сейчас, есть ли индивидуальные консультации?

Дмитрий: Я преподавал фронтенд в онлайн-школе примерно два-три года назад: HTML, CSS, JavaScript. Это интересный, но очень энергозатратный опыт. Сейчас в школах не преподаю — нет необходимости «добивать» доход, а времени стало меньше. Индивидуальное наставничество сейчас на паузе: есть люди, которых я доучиваю, но под новую нагрузку времени нет. В будущем — возможно.

Наставничество — сильная нагрузка по времени и энергии; его сложно совмещать с ролью старшего разработчика.

Александр: Дублируете контент в ВК или Рутубе?

Дмитрий: Нет, не дублирую.

Александр: Сколько зарабатывает фронтенд-разработчик: начинающий, среднего уровня, старший?

Дмитрий: Вилка зависит от страны, компании и того, как человек себя продаёт. Если очень грубо: начинающий — до 1000, среднего уровня — 2000–3000, старший — 2500–4000. Бывают кейсы, когда человек ведёт два проекта — тогда и доход выше, но это риск выгорания и вопрос баланса работы и личной жизни.

Зарплаты зависят от рынка и умения себя позиционировать; «два проекта» — деньги vs выгорание.

Александр: У вас такое было?

Дмитрий: Периодически бывает.

Александр: Как справляетесь с выгоранием?

Дмитрий: Стараюсь больше бывать на природе, меньше «залипать» в экраны, больше времени проводить с семьёй.

Александр: Я слышал, что вы меньше сидите в соцсетях.

Дмитрий: Да. Я оставляю личную жизнь личной и стараюсь держать коммуникацию в одном месте (условно в мессенджере). Плюс есть фактор безопасности: контент из соцсетей активно парсится, и при развитии ИИ это может использоваться для мошенничества. Поэтому мы с семьёй пришли к более осторожному подходу.

Восстановление часто упирается в простое: сон, природа, семья, меньше экранов.

Как дорасти до старшего: саморазвитие и выход из «зоны комфорта»

Александр: Как дорасти до старшего?

Дмитрий: В первую очередь — саморазвитие и проекты. Есть люди, которым комфортно «делать только то, что дали», и тогда рост останавливается. Когда вы чувствуете «зону комфорта», это часто означает, что развитие замедлилось. Если выходить из неё, можно расти до страшего, руководителя и выше.

Рост в грейде почти всегда связан с усложнением задач и расширением ответственности.

«Зона комфорта» — хороший индикатор того, что вы перестали расти.

ООП в JavaScript: классы, прототипы и «синтаксический сахар»

Александр: Как реализуется ООП в JavaScript?

Дмитрий: Через классы, но важно понимать: классы — синтаксический сахар для прототипов. Исторически всё построено на прототипах, а классы — более привычная запись. ООП-стиль возможен, но местами ограничен; при этом он удобен для структурирования логики.

Александр: Нужно ли знать классы в JavaScript?

Дмитрий: Да. Чтобы писать ООП, классы знать нужно, и полезно понимать прототипы как базу. Это несложно: выучить можно за пару вечеров, а дальше легче читать чужой код и работать с другими языками. Например, Angular во многом опирается на ООП-подход.

Классы в JS — удобная форма записи прототипной модели.

Понимание прототипов и классов упрощает чтение кода и работу с фреймворками.

«Фишки» JavaScript: от геолокации до async/await

Александр: Какие возможности JavaScript вам нравятся больше всего?

Дмитрий: JavaScript даёт разные парадигмы: можно писать и в ООП-стиле, и функционально. Плюс он позволяет работать с браузерными API (интерфейс программирования приложений): видео, аудио, плееры, интеграция с WebAssembly, получение информации о пользователе (например, геолокации).

Сила JS — в тесной связке с браузерными API и быстрой обратной связи.

Александр: Какая фича вас лично впечатлила? Вы упоминали геолокацию.

Дмитрий: Один из первых «вау-моментов» — самый первый код на JavaScript: я повторил по туториалу простую игру в духе Angry Birds, и она заработала в браузере. Тогда стало понятно, насколько быстро можно увидеть результат.

Александр: Что такое async/await?

Дмитрий: Это синтаксический сахар для работы с асинхронностью. Раньше чаще писали цепочки промисов (resolve/reject), сейчас async/await делает код более выразительным: вы «ждёте» результат асинхронной операции, а запись выглядит почти как синхронная.

«async»/«await» упрощает асинхронный код, делая его читабельнее.

Управление состоянием: Redux, MobX и «почему без этого иногда никак»

Александр: Зачем нужны Redux и MobX?

Дмитрий: Это state-менеджеры для веб-приложений. Они нужны, когда приложение разрастается и появляется сложное состояние. Например, проблема props drilling: когда данные приходится «прокидывать» через цепочки компонентов. Или когда есть независимые части интерфейса, которым нужно общее состояние (например, тема светлая/темная). Для этого и используют Redux/MobX/Zustand. В React есть и встроенный контекст, но внешние библиотеки дают больше возможностей для сложных сценариев.

State-менеджер нужен не «всем и всегда», а когда состояние становится большим и распределённым.

Александр: Чем вы пользуетесь чаще?

Дмитрий: Я бы выбрал Redux. Он требует больше «обвязки» и кода, но в крупных приложениях это нормально: зато выше настраиваемость и предсказуемость.

Redux часто выбирают за зрелость и контроль, даже ценой большего шаблонного кода.

Сборка фронтенда: Webpack и альтернативы

Александр: Что такое Webpack и как он помогает?

Дмитрий: Это сборщик. В реальном приложении много разных файлов: HTML, CSS, JavaScript, TypeScript, иконки, препроцессоры. Нужен итоговый бандл, который вы выкладываете на сервер. Webpack через loaders и plugins умеет превращать исходники в результат: tree-shaking (убрать неиспользуемый код), минификация, анализ веса бандла, разделение на несколько бандлов (lazy loading), чтобы ускорять первую загрузку приложения.

Webpack решает ключевую задачу фронтенда: превратить «зоопарк исходников» в быстрый, оптимизированный бандл.

Александр: Есть ли альтернативы?

Дмитрий: Есть: Vite, esbuild, варианты на Rust, rollup-подходы, Turbopack. Но для больших проектов Webpack часто остаётся лидером из-за конфигурационности, расширяемости и зрелости. Vite удобен для быстрых небольших проектов и обучения, где не хочется усложнять настройку.

Альтернативы удобны в простых сценариях, но на больших проектах ценится предсказуемая конфигурация и контроль.

CMS и «тильда-опыт»

Александр: Вы работали с WordPress, Bitrix и похожими CMS?

Дмитрий: Глубоко — нет. Когда-то хотел попробовать Joomla, но не сложилось. Зато был практический опыт с Tilda: в период видеографии я делал и поддерживал сайт для локальной танцевальной школы.

Даже «непрограммистские» инструменты вроде конструкторов могут дать полезный опыт, если вы решаете реальную задачу.

Node.js и бэкенд на JavaScript: где границы применимости

Александр: Что такое Node.js, и стоит ли новичкам его бояться?

Дмитрий: Node.js позволяет писать JavaScript вне браузера: там используется движок V8, как и в браузере. Чаще всего на Node.js пишут бэкенд. Плюс Node.js даёт NPM — менеджер пакетов, без которого сложно жить в экосистеме (React/Angular и т. д.).

Александр: Как организовать бэкенд-разработку на JavaScript?

Дмитрий: Обычно через Node.js и фреймворки/библиотеки вроде Express или Nest.js. Дальше всё зависит от требований проекта и архитектуры.

Александр: Как JavaScript справляется с высоконагруженными системами?

Дмитрий: Лично я не писал на Node.js высоконагруженные системы, но по опыту «матёрых» бэкендеров — у Node.js могут быть сложности с памятью и производительностью. Теоретически сильный разработчик может сделать всё качественно, но важно помнить о сопровождении: придут другие, и если система построена на хрупких местах, она может сломаться. Поэтому для высокой нагрузки часто выбирают более строгие и производительные языки (в качестве примера я упоминал Rust).

Node.js — нормальный инструмент для бэкенда на JS, особенно для типовых веб-сервисов.

Для высокой нагрузки важно не только «можно ли», но и «как это будут поддерживать через год».

Мобильные и десктоп-приложения на JavaScript

Александр: На чём пишут мобильные приложения с использованием JavaScript?

Дмитрий: Основной вариант — React Native (нужно знать React). Есть и другие подходы вроде Ionic и подобных решений, но у них больше ограничений. Для «быстро сделать» возможно, но для глубокого доступа к API лучше нативные языки: Swift для iOS, Kotlin/Java для Android.

Александр: Как создать десктопное приложение на JavaScript?

Дмитрий: Через Electron. Например, VS Code сделан на Electron.

React Native — самый практичный путь в «мобилку на JS», но нативные языки дают больше контроля.

Electron остаётся популярным способом делать десктоп на веб-стеке.

Тестирование и игры на JavaScript

Александр: Как тестируют JavaScript-приложения? Какие инструменты используют?

Дмитрий: В React-мире часто используют Jest для unit/integration и React Testing Library для тестов поведения. Для end-to-end — Cypress или Playwright. Есть и Mocha/Chai, но наиболее типичная связка — Jest + React Testing Library.

Александр: Игры на JavaScript — хорошая идея?

Дмитрий: Как идея — да, можно. Я сам начинал с учебного туториала по игре. Есть и 3D-возможности через библиотеки. Но у браузерных игр есть ограничения.

Тестирование в фронтенде — это обычно микс unit/integration и E2E, выбор зависит от требований.

Игры на JS возможны, но важно понимать ограничения платформы.

Безопасность: «одна папка на фронт и бэк» не делает систему защищённой

Александр: Правда ли, что единая система фронтенда и бэкенда на JavaScript делает её менее уязвимой?

Дмитрий: Безопасность не сводится к языку. Вопрос в архитектуре и в том, как написан код. Если вы смешали бэкенд и фронтенд и открыли доступ к внутренним API — риски очевидны. Если делать правильно: разделять контуры, хостить на разных платформах, иметь среды (dev/test/stage), применять практики защиты (вплоть до CORS-политик) — всё будет существенно лучше. Но «магической неуязвимости» нет.

Александр: В вашем большом проекте, которым вы гордитесь, это единая система или раздельная?

Дмитрий: Раздельная. И бэкенд там не на Node.js — там .NET/C#.

Уязвимость определяется практиками и архитектурой, а не тем, что «всё на одном языке».

Разделение контуров и окружений — базовая гигиена даже для небольших систем.

ИИ в разработке: где помогает, а где создаёт долг

Александр: Используете ли вы искусственный интеллект в работе?

Дмитрий: Да, это уже обыденность. Я не использую ИИ в режиме «напиши за меня весь код», потому что качество и ответственность пока не те, а переписывать потом дорого. Зато точечно — полезно: сгенерировать шаблон для настройки Redux, быстро оформить заготовку, подсказать варианты.

Александр: Чем вы пользуетесь: ChatGPT, DeepSeek, Qwen?

Дмитрий: У меня несколько инструментов: Copilot, Grok, Claude. DeepSeek тоже был, но в какой-то момент стал давать заметные ошибки.

Александр: Что скажете про Copilot? Многие недовольны.

Дмитрий: Есть Copilot-агент в редакторе и Copilot как чат. У меня к нему нет принципиальных претензий, но важные вещи я перепроверяю в нескольких инструментах. Особенно если вопрос не про код, а, например, про юридические формулировки.

Александр: ИИ заменит программистов?

Дмитрий: Думаю, нет. Он может «пошатать» рынок, но останется инструментом.

Александр: Вы видите влияние ИИ в работе — стало легче?

Дмитрий: Да, стало легче, если использовать разумно. Но есть риск: разработчики начинают массово генерировать код ИИ-агентами и перекладывают ревью на других. Это токсично: если вы сгенерировали — вы и проверяйте. Иначе в проект попадает «чужой» код без понимания, возникают поломки. Я допускаю сценарий, что бизнес сначала накопит много сгенерированного кода, потом столкнётся с ростом стоимости сопровождения и придёт к выводу: иногда проще переписать заново, чем чинить.

ИИ полезен как ускоритель рутины (шаблоны, подсказки, черновики), но не как «замена мышления».

Самая опасная практика — генерировать много кода и не понимать, что именно вы внесли в систему.

Проверка и ответственность остаются на разработчике.

Хобби, планы и «мечта про свободу»

Александр: У вас есть хобби?

Дмитрий: YouTube — хобби. Плюс прогулки и время с семьёй.

Александр: Если убрать программирование и видеосъёмку, чем бы вы могли заниматься?

Дмитрий: Интересы меняются. Сейчас я мог бы уйти в музыку или глубже в YouTube, но это упирается в финансы. Ещё как вариант — недвижимость. Скорее это набор направлений, а не один «вечный ответ».

Александр: И последний вопрос: у вас есть мечта?

Дмитрий: Да: жить более свободно — чтобы деньги зарабатывались, а вы могли заниматься тем, что вам действительно интересно, путешествовать и работать не «ради денег», а по желанию.

Сильная цель — не «ничего не делать», а иметь свободу выбора, чем заниматься и когда.

Хобби и семья — рабочие способы восстановиться, когда работа интеллектуально тяжёлая.

Глоссарий

Angular — фреймворк для фронтенда. Даёт много «из коробки», но требует больше знаний на старте.

API — интерфейс, через который программы общаются друг с другом. Например, фронтенд запрашивает у бэкенда данные через API.

async/await — удобный способ писать асинхронный код так, будто он синхронный: «ждать результат» и продолжать выполнение дальше.

Backend (бэкенд) — серверная часть приложения: хранит данные, обрабатывает запросы, выдаёт ответы.

Babel — инструмент, который «переводит» современный JavaScript в более старую версию, чтобы код работал в старых браузерах.

Bundle (бандл) — итоговый «собранный» набор файлов (JS/CSS/и т. п.), который выкладывают на сервер для запуска приложения.

Boilerplate — типовой шаблон/заготовка кода, без которого проект не стартует (настройки, структура папок, базовые файлы).

CORS policy — правила, которые ограничивают, какие сайты могут обращаться к вашему серверу из браузера. Одна из базовых мер защиты.

Daily meeting (дейли) — ежедневный короткий созвон команды: что сделали, что делаем, где блокеры.

Drag-and-drop — перетаскивание элементов мышью/пальцем.

Electron — технология, чтобы делать десктоп-приложения на веб-стеке (HTML/CSS/JS). Пример — VS Code.

End-to-end (E2E) тесты — тесты, которые проверяют приложение «как пользователь»: клик, ввод, переходы.

ES Next — условное название возможностей JavaScript, которые обсуждаются, но ещё не стали стандартом.

ECMAScript (ES) — стандарт, по которому развивается JavaScript (версии, новые возможности языка).

Express / Nest.js — популярные библиотеки/фреймворки для создания бэкенда на Node.js.

Feature Slice Design — подход к организации кода фронтенда, чтобы проект не превращался в хаос.

Frontend (фронтенд) — клиентская часть: интерфейс, который видит пользователь (браузер/приложение).

Fullstack (фуллстек) — специалист, который работает и с фронтендом, и с бэкендом (в разной глубине).

Git — система контроля версий: позволяет хранить историю изменений и работать командой.

Grid — «таблица-компонент» с данными, фильтрами, сортировкой, редактированием и т. п.

Highload (высоконагруженная система) — система, которая должна выдерживать очень много запросов/пользователей/данных без деградации.

Hook (хук) — механизм React для работы с состоянием и жизненным циклом в функциональных компонентах.

HTML / CSS — базовые технологии веба: структура страницы (HTML) и оформление/стили (CSS).

Interpreted language (интерпретируемый язык) — язык, который выполняется «сразу», без явного шага компиляции (в упрощённом объяснении).

Jest / React Testing Library / Cypress / Playwright — популярные инструменты тестирования фронтенда (юнит/интеграционные/E2E).

JSON — текстовый формат передачи данных (обычно между фронтом и бэком), похожий на структуру объектов в JavaScript.

Lazy loading — «ленивая загрузка»: подгружать тяжёлые части приложения только когда они реально понадобились.

LinkedIn — профессиональная соцсеть, где часто ищут работу и сотрудников (особенно для международного рынка).

Microfrontend (микрофронтенд) — подход, когда большой фронтенд разбит на маленькие независимые приложения-модули.

Monorepo (монорепозиторий) — один репозиторий, где живут сразу несколько приложений/пакетов проекта.

Node.js — среда выполнения JavaScript вне браузера (обычно для бэкенда).

NPM — менеджер пакетов Node.js: через него ставят зависимости (React, библиотеки и т. д.).

OOP (ООП) — объектно-ориентированное программирование: стиль, где логика организована в виде объектов/классов.

Props drilling — ситуация в React, когда данные приходится передавать через много уровней компонентов «вниз», что усложняет код.

Promise (промис) — объект, который описывает результат асинхронной операции (успех/ошибка) в JavaScript.

Redux / MobX / Zustand — инструменты управления состоянием в больших фронтенд-приложениях.

Relocation (релокация) — переезд в другую страну/город по работе.

Roadmap — «карта навыков»: список тем и технологий, которые обычно нужны для профессии.

Senior / Middle / Junior — уровни опыта разработчика (упрощённо: начинающий / уверенный / ведущий).

Syntax sugar (синтаксический сахар) — более удобная форма записи того же смысла (пример: async/await как удобная запись поверх промисов).

Tree-shaking — удаление из сборки кода, который не используется, чтобы уменьшить размер бандла.

TypeScript — JavaScript с типами: помогает ловить ошибки заранее и делает код более предсказуемым.

Unit / integration tests — тесты маленьких частей кода (unit) и их взаимодействия (integration).

V8 — движок, который выполняет JavaScript (используется и в Chrome, и в Node.js).

Vite / Rollup / esbuild / Turbopack — альтернативы/компаньоны Webpack для сборки проектов.

Webpack — мощный сборщик фронтенда: объединяет файлы, оптимизирует, минифицирует, поддерживает плагины.

WebAssembly (wasm) — формат, который позволяет запускать в браузере «тяжёлый» код, написанный на других языках (Rust/C/C++), с интеграцией через JS.