React в 2026 году: вайб-кодинг, Next.js, рынок и фронтенд после прихода ИИ — интервью с Александром Ломковым

React давно перестал быть просто библиотекой для отрисовки интерфейсов. Вокруг него выросла огромная экосистема, а сама работа фронтенд-разработчика меняется под влиянием ИИ быстрее, чем успевают обновляться привычные roadmap. Нужно ли сегодня глубоко знать JavaScript, стоит ли учить Next.js «по умолчанию», чем React выигрывает у Angular, что не так с вайб-кодингом и останется ли вообще ручное написание кода через пять лет?

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Ломковым — фронтенд-разработчиком и автором YouTube-канала «Friendly Frontend». Обсудили рынок найма, переход из VK в Wildberries, нейросети в реальной разработке, React и его экосистему, серверный рендеринг и то, какие навыки становятся важнее самого умения писать код.  

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

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

Александр Ломков: Всё достаточно просто: я женился, несколько раз съездил в Японию и поменял работу. Всем этим доволен.

Александр: Как вам Япония?

Александр Ломков: Потрясающая страна. Мы с женой в неё влюбились и хотим возвращаться снова. Перелёт выматывает: дорога с пересадками занимает около суток. Но когда приезжаешь, понимаешь, ради чего всё это. Там действительно есть что посмотреть, и визуально это совершенно другой мир.

Александр: Чем вы сейчас по-настоящему увлечены? Что вас профессионально драйвит?

Александр Ломков: Сейчас – новая работа. Для меня это первая серьёзная профессиональная встряска примерно за три с половиной года. И в этом смысле она стала, пожалуй, лучшим, что могло произойти: я снова чувствую себя нужным на своём месте.

Александр: Расскажите о новой работе. Вы перешли в другую команду внутри VK или полностью сменили компанию?

Александр Ломков: Сначала я действительно поменял команду внутри VK. Проект, на котором я работал несколько лет, сворачивался, и мои компетенции там уже были не так востребованы. Мне предложили внутреннюю ротацию, я попробовал, но понял, что это не совсем моё. После этого я перешёл в Wildberries – на большой проект, которым сам пользуюсь. Это сильно повышает интерес к работе: понимаешь продукт не только как разработчик, но и как пользователь.

Александр: Почему решили всё-таки сменить компанию? В VK, насколько я понимаю, были хорошие условия.

Александр Ломков: Условия действительно были отличные, и к самой компании у меня претензий нет. Вопрос был скорее в проекте и в ощущении собственного места внутри процессов. При внутренней ротации у вас меняется практически всё: команда, проект, предметная область, процессы. Нужно заново погружаться в огромный объём информации, но при этом формально условия остаются прежними. Получается, что когнитивной нагрузки становится больше, а ощущения нового этапа может не возникнуть.

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

Александр: Как вы в целом относитесь к экосистеме VK? Есть ли вещи, которые, на ваш взгляд, можно было бы улучшить?

Александр Ломков: Вопрос немного провокационный. Я стараюсь смотреть на продукты прагматично. Если есть сервис, которым мне удобнее пользоваться, я продолжу им пользоваться независимо от того, отечественный он или зарубежный. При этом я понимаю людей, для которых продукты VK удобнее альтернатив, в том числе в видео. Хорошо, когда внутри страны существуют сильные конкурентные продукты. Я был бы рад, если бы платформы VK развивались дальше.

Что касается возможности что-то изменить изнутри: основные продуктовые команды достаточно хорошо укомплектованы. На тот момент перейти именно в тот продукт, который мне было бы интересно развивать, возможности не было. Я к этому отношусь спокойно.

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

Найм без магии: резюме, нетворкинг и почему рекомендации не отменяют собеседование

Александр: Почему вы выбрали именно Wildberries и насколько сложно вам было пройти найм? Сейчас регулярно говорят, что рынок IT перегрет и даже опытным специалистам приходится тяжело.

Александр Ломков: У меня исторически не было больших проблем с поиском работы. И дело не в медийности. Подписчики на YouTube или Telegram не освобождают от необходимости доказывать профессиональные компетенции. Мне, вероятно, помогает то, что я умею рассказывать о своей работе. За пять лет во фронтенде накопилось достаточно реальных кейсов, поэтому не нужно что-то придумывать. Я понимаю, что хочет услышать HR, что важно техническому специалисту и что в итоге требуется бизнесу.

Хорошее резюме и самопрезентация – это тоже навык. Причём важно не выдумывать достижения, а нормально объяснять то, что вы действительно делали: какую проблему решали, какая была ваша зона ответственности, какой результат получил проект.

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

В этот раз возможность действительно появилась через знакомых.

Александр: То есть работу вы искали через рекомендации?

Александр Ломков: Да, сработала достаточно длинная цепочка друзей и знакомых. Команде был нужен сильный фронтенд-разработчик, мне сказали: «Хотите попробовать?» Я согласился.

Но рекомендация – это только возможность попасть на следующий этап. Дальше мне всё равно понадобилось резюме, техническое собеседование и подтверждение компетенций.

Просто произошёл очень хороший мэтч. Первые три года в VK я работал над внутренним таск-трекером – чем-то похожим на Jira. В новой команде требовался специалист примерно с теми навыками, которые я за это время получил. Поэтому мы довольно быстро поняли, что можем друг другу подойти.

Это можно назвать удачей, но я воспринимаю такие ситуации скорее как возможность, которой вы либо пользуетесь, либо нет. Можно было сказать: «У меня и здесь всё хорошо, зачем что-то менять?» VK действительно предлагает очень комфортные условия. Но когда новый проект интереснее, финансовые условия лучше, а команда ближе по задачам, переход выглядит вполне органично.

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

Александр Ломков: Здесь появляется слово «нетворкинг». Его иногда воспринимают как что-то искусственное, хотя по сути это просто круг профессиональных знакомств, который вы сами формируете.

Если есть возможность посещать IT-мероприятия, общаться с разработчиками, участвовать в сообществах – этим стоит пользоваться. Чем больше вокруг вас людей из индустрии, тем больше вы знаете о компаниях, командах и проектах. Кто-то меняет работу, кто-то открывает вакансию, кому-то в команду нужен разработчик.

Когда я переехал из небольшого города в Москву, мне пришлось активно социализироваться и интегрироваться в профессиональную среду. Мне самому знакомиться с людьми всегда было непросто, несмотря на то что я много говорю. Но со временем сформировался круг знакомых из IT, и теперь при необходимости можно написать человеку и спросить, есть ли подходящая вакансия в его компании.

Второй момент – нужно уметь себя представить. Резюме стоит привести в порядок, но не превращать в идеально отполированный нейросетью текст, в котором уже не чувствуется человек.

И нельзя ограничиваться hh.ru. Есть сайты компаний, стажировки, профессиональные Telegram-каналы, агрегаторы, региональные компании. Особенно в начале карьеры я бы не зацикливался только на Big Tech.

Главная задача новичка – получить коммерческий опыт. Если у вас нулевой опыт и при этом ожидание сразу получать 200 тысяч рублей, поиск может затянуться надолго. На старте я бы хватался за разумную возможность поработать и получить практику. Когда опыт появляется, выбор становится шире.

Работа для хороших специалистов есть. Искать всё равно придётся, в том числе senior-разработчику, но возможностей у человека с сильным опытом значительно больше.

Рекомендация помогает открыть дверь, но не заменяет профессиональный уровень. Для новичка важнее всего получить реальный коммерческий опыт и искать возможности шире одного сайта с вакансиями.

«Работа есть» – но вход стал сложнее: что происходит с рынком IT

Александр: Вы сказали, что работа есть. Но мы постоянно слышим про сокращения, заморозку найма и тысячи кандидатов на одну вакансию. Действительно ли рынок настолько плох?

Александр Ломков: Я скептически отношусь к громким заголовкам о том, что «IT закончилось» и теперь всех увольняют. Сокращения происходили всегда. В компаниях одновременно идут два процесса: где-то людей сокращают, где-то нанимают, где-то команды объединяют или переводят на другие проекты.

Разработка сама по себе – живой процесс. Нельзя сказать: «Мы начали в точке А, дошли до точки Б, и больше ничего не изменится». С наймом то же самое. Меняются бюджеты, приоритеты и продукты, поэтому одним командам нужны люди, а другим – уже нет. При этом отрицать, что искать работу стало сложнее, тоже нельзя. Особенно тяжело junior-разработчикам. Я слышу об этом постоянно. Но две-три тысячи откликов на вакансию не означают, что перед вами две-три тысячи одинаково подготовленных кандидатов. Среди них много людей без необходимой подготовки, которые просто решили попробовать. Если вы действительно учились, получили практику, понимаете требования вакансии и можете объяснить, какую ценность принесёте бизнесу, ситуация уже другая. Нужно не просто знать технологию, а уметь закрыть конкретную потребность компании. Чем сложнее рынок, тем больше отсеивается людей, которые были готовы попробовать только при очень комфортных условиях. Поэтому настойчивый человек с реальными знаниями по-прежнему имеет шанс.

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

Александр Ломков: Здесь очень сложно рассуждать с позиции человека, у которого уже есть коммерческий опыт. Я могу сказать: «Не делайте так, проходите тот же путь, который прошёл я». Но понимаю, в каких реалиях находятся новички. Компании хотят видеть два-три года опыта, а человек без первой работы физически не может эти два года получить. Получается замкнутый круг.

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

Второй подход я считаю безответственным. Одно дело – преодолеть фильтр и затем доказать, что вы способны работать. Совсем другое – сознательно обманывать систему, не имея навыков.

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

Александр: То есть рекомендация знакомого в вашем случае не означала упрощённое собеседование?

Александр Ломков: Нет. Сначала был разговор с HR. Там практически не было технических вопросов: скорее проверка мотивации, адекватности и того, насколько наш предыдущий опыт вообще совпадает с вакансией. Потом было полноценное техническое собеседование с опытным фронтенд-разработчиком. Это уже был разговор двух технических специалистов с проверкой моих компетенций – без поблажек.

Мой YouTube-канал здесь ничего не давал. Я даже не делал на нём акцент. Нельзя прийти и сказать: «Не задавайте мне этот вопрос, я про него уже курс снял». Медийность и профессиональный найм – разные вещи.

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

Big Tech или маленькая компания: где начинать и почему зарплата в 300 тысяч – не стартовая точка

Александр: Насколько активно крупные компании вообще нанимают сейчас? Есть ли надежда у начинающих разработчиков?

Александр Ломков: В моём кругу много людей из банков, социальных сетей, маркетплейсов и других крупных компаний. И по тому, что я вижу, junior-специалистам действительно тяжело. Большие продукты требуют достаточно высокого уровня ответственности. Поэтому взять человека с практически нулевым опытом на сложный продукт трудно. Крупные компании набирают новичков через стажировки, университетские программы и другие форматы, где можно выбрать очень сильных людей. У человека с опытом ситуация проще. Я не говорю, что он найдёт работу за один день, но возможностей у него значительно больше.

Александр: Получается, если специалист действительно хорошо разбирается в своей области, проблем будет меньше?

Александр Ломков: Да, но я бы не формулировал это как «станьте лучшим – и всё будет легко». Искать всё равно нужно.

Александр: А стоит ли вообще рассматривать небольшие компании? Есть мнение, что надо сразу стремиться в Big Tech и не тратить несколько лет на веб-студии.

Александр Ломков: Я бы шёл по убывающей. Если можете сразу попасть в большую компанию – отлично. Если не получилось, снижайте планку и ищите следующий доступный вариант.

До VK я работал в digital-агентстве примерно на 80 человек. Там получил именно те компетенции, которые впоследствии понадобились в Big Tech. Многие мои коллеги потом тоже перешли в крупные компании. Даже совсем маленькая веб-студия может стать трамплином. Можно попробовать перепрыгнуть через десять ступеней сразу, но обычно проще идти последовательно.

Если бы в 2020 году мне сразу дали оффер в VK на хорошие деньги, конечно, я бы не стал принципиально отказываться ради того, чтобы обязательно сначала поработать в маленькой студии. Нужно брать лучшее из того, что доступно вам в конкретный момент.

Александр: Почему в публичных интервью об IT так много говорят о зарплатах в 300, 400 или 700 тысяч рублей? У новичка создаётся ощущение, что это обычная точка входа.

Александр Ломков: Здесь действительно возникает искажение. Я уже нахожусь в среде Big Tech и понимаю, что сам привык к определённым условиям: зарплате, ДМС, офису, корпоративным возможностям. Но так рассуждает человек с опытом. Если опыта нет, нужно смотреть не на чужие сотни тысяч, а на те возможности, которые доступны вам сейчас. Маленькая компания – абсолютно нормальный вариант для старта.

Когда у человека пять лет реальной коммерческой практики и он видит, что на сопоставимой позиции в другой компании платят в несколько раз больше, это повод пересмотреть собственную стоимость на рынке. Но если у вас три pet-проекта, нужно честно спросить себя, почему вам должны платить столько же, сколько специалисту, который пять лет разбирался с реальными продуктами, legacy-кодом, багами и требованиями бизнеса.

Высокая зарплата чаще всего является результатом последовательного роста. Истории о человеке, который за три месяца выучил несколько вопросов, «накрутил» опыт и сразу получил 300 тысяч, – это классическая ошибка выжившего. Такие случаи существуют, но из этого не следует, что тот же путь повторит каждый.

У меня самого доход рос постепенно: сначала совсем небольшие суммы, потом выше, затем произошёл более заметный скачок. Рост не обязательно линейный, но перед большой зарплатой обычно стоит определённый объём накопленного опыта.

IT давно перестало быть какой-то закрытой профессией для избранных инженеров. Мы решаем задачи бизнеса. Хорошие деньги можно получать и во многих других профессиях, если несколько лет системно развивать экспертизу.

Александр: Значит ли это, что «век IT» закончился и профессия перестала быть привилегированной?

Александр Ломков: Я бы вообще выбирал профессию не только по деньгам. Стоит идти туда, куда действительно лежит душа. Высокий доход возможен во многих областях, где требуются знания и опыт: медицина, строительство, инженерные специальности, программирование, работа с техникой. IT в этом смысле не уникально.

Само IT никуда не исчезнет. Оно будет трансформироваться. С появлением искусственного интеллекта правила игры уже меняются: часть задач становится доступна гораздо большему числу людей, снижается порог входа.Раньше требовалось больше точечных знаний. Сейчас всё чаще ценится широта: способность понять задачу бизнеса, формализовать требования, довести процесс от точки А до точки Б и выдать результат. Конкуренция поэтому действительно растёт. Но одновременно больше людей получает возможность работать в индустрии.

Big Tech – не обязательная первая ступень. Высокая зарплата обычно следует за коммерческим опытом, а не предшествует ему; для старта полезнее реальный проект в небольшой компании, чем ожидание «идеального» оффера.

Нейросеть как усилитель: где ИИ экономит часы, а где разработчик обязан оставить себе контроль

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

Александр Ломков: Я пришёл к ним относительно поздно. Сначала был скепсис: казалось, что нейросеть делает всё заметно хуже меня. Затем наступил период восхищения, когда кажется, что она невероятно умная и знает практически всё. Сейчас отношение стало более спокойным. Для меня это инструмент.

Главное преимущество нейросети – возможность быстро обработать большой объём информации. Вместо того чтобы несколько часов искать десятую страницу Google, проверять несколько гипотез и вручную читать огромное количество материалов, вы формулируете задачу, указываете направление поиска и затем проверяете результат. То же самое с кодом. Нейросеть может читать, анализировать и писать его. Она не отменяет разработчика, а усиливает его навыки. Причём специалиста с опытом она усиливает заметнее, чем человека без опыта. Если вы понимаете, что хотите получить, умеете проверять результат и знаете контекст проекта, эффект значительно выше.

Я по-прежнему люблю писать код руками. Мне нравится вёрстка, pixel perfect, оптимизация. Но моя работа уже не ограничивается тем, чтобы взять макет и сверстать страницу. Нужно глубже понимать бизнес и процессы. Если нейросеть помогает быстро разобрать большой документ, кодовую базу, найти ошибки или подготовить основу решения, отказаться от такого инструмента было бы странно. Для разработчика сознательно игнорировать ИИ сегодня – значит замедлять собственную работу.

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

Александр Ломков: Хороший пример – дебаггинг. Есть баг, причину которого вы не понимаете. При этом знаете инструменты: DevTools, Network, Sources, Performance, умеете выгрузить нужные логи. Для человека такой лог иногда выглядит как сотни строк JSON и данных, которые нужно довольно долго анализировать. Я могу передать этот объём нейросети, подробно объяснить контекст и проблему. Она анализирует данные и может обратить внимание, например, на event loop, утечку памяти или конкретный участок исполнения. Сам я искал бы такой баг гораздо дольше. Не потому, что не умею, а потому, что ручная обработка большого объёма логов занимает время. Приходится постоянно сужать контекст и итерационно проверять гипотезы. С нейросетью проблему, которая могла занять несколько часов, иногда удаётся локализовать за пять минут. Для меня именно такие сценарии наиболее впечатляющие: информация уже есть, я понимаю, что именно нужно анализировать, но машине намного проще быстро обработать этот объём.

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

Александр Ломков: На момент нашего разговора для разработки я в основном использую Claude и Codex от OpenAI. Для моих задач они идут достаточно близко по качеству. Пробовал также Gemini, DeepSeek и Grok. Чтобы понять разницу, полезно дать нескольким моделям одну и ту же задачу и сравнить результат. У Claude мне нравится качество, но он может быть дорогим с точки зрения лимитов и токенов. Codex для меня очень хорош по соотношению стоимости и результата. При этом для большинства фронтенд-задач современные модели уже достаточно сильны. Мы всё-таки работаем с вебом, а не пишем низкоуровневые драйверы для специфического оборудования.

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

Александр Ломков: Сейчас все компании находятся в процессе поиска правил. Нужно одновременно обеспечить эффективность, безопасность и соответствие внутренним требованиям. У некоторых есть собственные модели. Они могут быть обучены или донастроены на внутренних данных, документации и специфичных фреймворках. В конкретной предметной области такое решение потенциально может быть даже лучше общей модели.

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

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

Пароли нейросети не отдаём: где заканчивается удобство и начинается ответственность

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

Александр Ломков: Нет. Нельзя просто сказать: «Вот весь проект, все ресурсы, все токены, делайте работу за меня, а я буду только ставить approve». В репозитории могут быть чувствительные данные. Пароли, токены, ключи и другая конфиденциальная информация не должны уходить во внешнюю систему. Нужно понимать зону ответственности и давать модели только тот объём информации, который ей действительно необходим для конкретной задачи.

Правильное использование – когда вы контролируете контекст: вот этот файл можно прочитать, вот эти логи можно обработать, вот эту часть проекта нужно проанализировать. И вы понимаете, зачем предоставляете доступ. Идея «вот вам права администратора, сделайте всё красиво» – плохая и с точки зрения безопасности, и с точки зрения профессионального развития. Если полностью делегировать нейросети работу и отключить собственное мышление, через некоторое время возникает вопрос: а что вы вообще умеете без неё? Рано или поздно появится проблема, которую модель не решит автоматически. И тогда разработчику всё равно придётся разбираться самостоятельно.

Александр: Что вы думаете об отечественных решениях – Алисе, GigaChat?

Александр Ломков: Я рад, что такие продукты существуют и развиваются. Это показатель достаточно сильной IT-индустрии. Но как требовательный пользователь я хочу пользоваться лучшим инструментом независимо от страны происхождения. Мы и так живём в глобальной технологической среде: операционные системы, процессоры, библиотеки, сервисы создаются в разных странах. Поэтому мне не очень близка идея выбирать продукт исключительно потому, что он отечественный или зарубежный. Если Алиса лучше решает мою задачу – буду использовать Алису. Если другой сервис делает её лучше – выберу его.

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

Александр: При этом нейросети сами могут ошибаться.

Александр Ломков: Конечно. Особенно опасно воспринимать уверенный ответ как гарантию истины. Модель может не сказать: «Я не знаю», а сформулировать убедительно звучащую версию. Поэтому в юридических, финансовых и других чувствительных вопросах всё нужно дополнительно проверять. В коде принцип тот же: результат модели – не конечная истина, а материал, за который всё равно отвечает человек.

ИИ не отменяет базовую безопасность и проверку результатов. Разработчик должен контролировать, какие данные получает модель, и оставаться ответственным за всё, что попадает в продукт.

Вайб-кодинг: отличный способ собрать MVP и плохой способ перестать думать

Александр: Что вы думаете про вайб-кодинг? Сейчас с помощью Claude, Codex и других инструментов можно практически без подготовки собрать рабочий прототип. Стоит ли вообще меньше изучать код и больше – такие инструменты?

Александр Ломков: Мы часто обсуждаем эту тему с друзьями-разработчиками и постоянно приходим примерно к одному выводу: без понимания кода мы не смогли бы писать настолько качественные промпты и, главное, проверять результат. Преимущество нейросети не в том, что она «умнее человека», а в том, что способна выполнить огромный объём действий при относительно небольшом объёме входных данных. Для проверки гипотез это великолепный инструмент.

Допустим, у вас появилась идея MVP. Вы можете практически голосовым сообщением описать её нейросети, а через относительно короткое время получить сервис с фронтендом, бэкендом и каким-то визуалом. Он будет отличаться от полноценного продукта, сделанного по подробному ТЗ, но позволит очень быстро проверить саму идею. Для такого сценария ИИ – must have. Проблема начинается, когда вайб-кодинг превращается в подход «не хочу понимать, что происходит, просто говорю: сделай так, а теперь вот так».

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

Поэтому роль разработчика меняется. Мы становимся чем-то средним между программистом и техническим аналитиком. Получаем исходные требования и должны преобразовать их в форму, с которой эффективно сможет работать ИИ. Модели недостаточно сказать «сделай красиво». Ей нужно объяснить, что именно должно произойти, почему, какие в проекте используются паттерны, какие существуют ограничения. Если нейросеть просто «пишет как чувствует», поддерживать этот код впоследствии будет крайне сложно. Задача профессионального разработчика – не дать ИИ увести проект в яму, из которой потом дорого выбираться.

Александр: Тогда что именно имеет смысл делегировать?

Александр Ломков: Под рутиной я понимаю не только условный copy-paste. Представьте сложную задачу, которую раньше вы две недели анализировали бы самостоятельно. Теперь за день плотной работы с ИИ можно резко сузить контекст, сформулировать варианты, проверить гипотезы, подготовить вопросы и затем пойти обсуждать решение с командой. Разработчик становится связующим звеном. Он по-прежнему технический специалист, но работает не в вакууме. Нужно общаться с командой, понимать ожидания заказчика и отвечать за финальный результат.

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

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

Александр Ломков: Потому что продукт продукту рознь. Сгенерировать сервис – это одна задача. Создать и поддерживать продукт – другая. Не нужно думать, что весь IT-продукт вращается вокруг написания кода. Есть аналитика, дизайн, работа с пользователями, понимание требований заказчика, эксплуатация. Нейросеть пока не заменяет профессионального дизайнера в понимании того, как сделать интерфейс максимально удобным для конкретных пользователей. Она не заменяет аналитика в понимании бизнеса. Написание кода ей делегировать можно. Но чтобы код получился хорошим, этим процессом должен управлять человек, который понимает разработку. Не случайно на фриланс-биржах уже появляются задачи в духе «исправить проект после вайб-кодинга».

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

Почему React стал главным: простота, деньги, open source и миллионы строк legacy

Александр: Перейдём непосредственно к React. Почему он стал настолько популярным?

Александр Ломков: Если посмотреть на историю фронтенд-фреймворков примерно с середины 2010-х, нельзя сказать, что React всегда безусловно доминировал. Были разные периоды у Angular, Vue, React, появлялись Svelte, Ember и другие решения. Фреймворки и библиотеки постоянно перенимали удачные идеи друг у друга. Выходит новая версия одного инструмента и решает проблему конкурента. Затем конкурент выпускает следующую версию и отвечает уже на другую проблему. Но ретроспективно кажется, что React действительно большую часть времени оставался фаворитом, особенно если смотреть на рынок вакансий. Причин несколько.

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

Во-вторых, React – open source. Его могли использовать все, вокруг быстро сформировалось большое сообщество.

В-третьих, он довольно простой по сравнению, например, с Angular. React предложил относительно понятное решение проблем, которые до этого во фронтенде решались более сложно.

А дальше включился накопительный эффект. Чем больше приложений написано на React, тем больше специалистов его знают. Чем больше специалистов его знают, тем проще бизнесу выбирать React для следующего проекта.

Плюс сформировался огромный пласт legacy. Переписать большое приложение с React на Angular – это не то же самое, что заменить небольшую библиотеку для работы с датой. Придётся менять подходы, архитектуру, существенную часть кода. Фактически это может быть новый проект.

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

Александр: Я спрашивал нескольких разработчиков из США, что они выбрали бы – React или Angular, и большинство называли React.

Александр Ломков: Это логично. Вообще не так много разработчиков выбирают технологию исключительно идеологически: здесь производительность на десять процентов выше, поэтому буду использовать только это. Чаще вы продолжаете работать с тем инструментом, который первым хорошо освоили и за который вам впервые начали платить. Если человек нашёл первую работу на React, с большой вероятностью следующую он тоже будет искать в этой области. Так проще капитализировать уже накопленный опыт.

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

Александр: React всё-таки фреймворк или библиотека?

Александр Ломков: Изначально – библиотека. Но сегодня я чаще называл бы его экосистемой. Когда я говорю человеку «вам нужно выучить React», всегда добавляю: «и его экосистему». Сам React решает достаточно конкретную задачу, связанную с интерфейсом и DOM. Он позволяет эффективно обновлять нужные части интерфейса в зависимости от изменившихся данных. Раньше разработчикам приходилось заметно больше вручную манипулировать DOM, использовать тот же jQuery и самостоятельно следить за изменениями. React предложил более удобную модель. Но огромное количество вещей намеренно не встроено непосредственно в React. Он остаётся минималистичным и позволяет разработчику самому собирать окружение вокруг него. В этом его ключевое отличие от более монолитного фреймворка: вы сами выбираете часть инструментов под задачи проекта.

Популярность React объясняется не одной «лучшей технологией». Сработала комбинация простоты, поддержки крупной компании, open source, огромного рынка специалистов и колоссального количества уже написанного кода, который слишком дорого переписывать.

React – это не только React: что действительно входит в современный стек

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

Александр Ломков: Одним React современное приложение обычно не заканчивается. Первое – управление состоянием. Исторически одним из самых популярных решений был Redux. Сейчас существует много альтернатив: MobX, Zustand и другие инструменты. Они решают похожую задачу – позволяют удобнее работать с состоянием, когда данных становится много и они используются в разных частях приложения. Мне, например, нравится развитие в сторону более компактных решений. Zustand убирает значительную часть boilerplate, который раньше ассоциировался с Redux: можно написать небольшой конфиг и расширять его по мере роста приложения. Есть экосистема TanStack. Я сначала познакомился с TanStack Query – библиотекой для работы с запросами и кэшированием данных. Теперь вокруг неё уже существует набор инструментов: router, table и другие решения. За такими проектами полезно следить. Вокруг React постоянно появляются лидеры отдельных категорий. Нужен роутинг – есть React Router и альтернативы. Нужна работа с серверными данными – есть соответствующие библиотеки. Нужны готовые компоненты – подключаете UI-библиотеку. Поэтому экосистема React похожа на систему, где сама библиотека находится в центре, а вокруг неё существует большое количество инструментов, каждый из которых закрывает отдельный класс задач.

Александр: Можете обобщить стек, который стоит изучить человеку, ищущему работу с React?

Александр Ломков: Я бы не называл его «правильным». Скорее это набор, который с высокой вероятностью позволит соответствовать большому количеству вакансий. Сам React. Redux Toolkit – важно понять саму концепцию state management, а не обязательно выучить каждую деталь классического Redux. React Router как привычный вариант роутинга. Конечно, TypeScript. Дальше стилизация и UI. Tailwind – один из вариантов. Плюс стоит понимать принцип работы UI-библиотек: Material UI, Ant Design или аналогичных. Это готовые React-компоненты, которые можно использовать вместо того, чтобы каждый элемент интерфейса верстать с нуля. При этом конкретный набор библиотек может отличаться от компании к компании. Важно не столько выучить один «священный стек», сколько понимать задачи, которые решает каждая его часть.

Александр: А что вы думаете про Next.js? Его сегодня часто называют практически обязательной частью React-стека.

Александр Ломков: Я бы не называл Next.js обязательным.

Если упрощать, Next превращает экосистему React в более фреймворкную. Библиотека даёт вам отдельный инструмент, а фреймворк задаёт более собранную систему и определённые ограничения. Причём ограничения – не обязательно плохо. Они помогают команде действовать по понятным правилам.

Исторически одна из ключевых задач Next была связана с серверным рендерингом и SEO. Классическое клиентское React-приложение первоначально отдаёт браузеру довольно пустую HTML-основу, после чего интерфейс строится JavaScript. Для поисковых систем это создавало сложности. Next позволяет рендерить страницу на сервере и отдавать готовый HTML. Вы по-прежнему пишете React-компоненты, но получаете другую модель доставки страницы. При этом появляются собственные правила роутинга, получения данных и структуры приложения. Я не считаю, что Next нужно изучать как совершенно отдельную специальность. Нужно понимать, какую проблему он решает, и желательно сделать небольшой проект, чтобы получить практический опыт.

Александр: Но можно встретить мнение, что Next.js уже должен использоваться по умолчанию.

Александр Ломков: ИИ действительно часто генерирует именно такой стек: Next.js, TypeScript, Tailwind. Но то, что нейросеть выбирает его по умолчанию, ещё не означает, что он нужен каждому проекту. Можно попросить модель сделать простой лендинг из трёх секций и получить Next.js, Tailwind и множество килобайт лишней инфраструктуры при практически нулевой интерактивности. Это стрельба из пушки по воробьям.

Next нужен определённым проектам. Условно продукты можно разделить на внешние, доступные широкой аудитории и зависящие от индексации поисковиками, и внутренние корпоративные приложения. Для первого сценария SSR и SEO могут быть действительно важны. Для внутреннего сервиса, которым пользуются только сотрудники компании, поисковая индексация вообще не имеет значения. Там Next может просто добавить ограничения без заметной пользы. Нужно учитывать и рынок специалистов. React знают практически все React-разработчики, а коммерческий опыт с Next есть не у каждого. Если вам важна простая ротация людей в команде, это тоже фактор.

При этом Next – не что-то невероятно сложное. Если вы уже хорошо знаете React, разобраться можно достаточно быстро. Мне нравится ряд практик, пришедших из Next. Например, file-based routing: структура страниц соответствует структуре папок. Такой подход можно встретить и в других проектах.

Поэтому мой совет человеку, который ищет работу: познакомиться с Next обязательно, сделать проект и иметь возможность о нём говорить на собеседовании. А при выборе стека для реального продукта сначала понять требования. Если вам не нужны SSR и SEO, вполне возможно, что без Next можно обойтись.

«React-разработчик» на практике знает не одну библиотеку, а целый набор инструментов. Next.js полезен и востребован, но выбирать его стоит из требований проекта, а не потому, что он стал модным стеком «по умолчанию».

Что учить новичку: React, Angular или Vue

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

Александр Ломков: С появлением нейросетей я бы вообще предложил сначала быстро попробовать несколько основных решений. Возьмите React, Vue и Angular. Потратьте условную неделю на знакомство с каждым, соберите маленький проект, посмотрите, как устроены компоненты, состояние, роутинг. Сегодня ИИ сильно упрощает такой эксперимент. Появляется много новых инструментов, но в вакансиях по-прежнему чаще встречаются эти крупные экосистемы. Если после знакомства нужно выбрать один стек для серьёзного изучения, я бы всё-таки выбрал React. Он требует меньше стартовых знаний, чем Angular, а вакансий много. Да, конкуренция тоже высокая, потому что React изучает огромное количество людей. Но в целом это достаточно хорошая золотая середина. Angular больше подойдёт человеку, которому близка стандартизация и заранее определённый подход. Vue можно рассматривать как ещё один компромиссный вариант. Но с точки зрения соотношения объёма обучения и количества рыночных возможностей React, на мой взгляд, остаётся оптимальным.

Александр: Чем React лучше Angular и Vue, если не считать количества вакансий?

Александр Ломков: Его преимущество одновременно является его недостатком – гибкость. Angular заметно сильнее задаёт правила. Есть определённый flow разработки, и фреймворк заставляет двигаться в этом направлении. React позволяет выбирать намного больше: state manager, роутер, UI-библиотеку, архитектурные решения. Для разработчика это свобода. Для бизнеса – возможность проще подбирать специалистов и менять отдельные части стека.

Александр: То есть строгие правила Angular – это минус?

Александр Ломков: Не совсем. Скорее это другой компромисс. Порог входа выше, а разработчиков на рынке меньше. Значит, найти специалиста в команду потенциально сложнее. React-разработчик в этом смысле чаще привык адаптироваться. Сегодня один state manager, завтра другой; здесь одна UI-библиотека, в следующем проекте – другая. Задачи при этом остаются похожими. Для конечного пользователя вообще нет принципиальной разницы, написан сайт на React или Angular. Его волнует, насколько быстро и корректно работает продукт. Поэтому преимущество React скорее прагматичное: гибкая экосистема, большая база специалистов и возможность выбирать инструменты под конкретную команду.

Александр: А чем тогда React хуже? В Angular проект более стандартизирован, а два React-проекта могут быть организованы совершенно по-разному.

Александр Ломков: Здесь многое зависит от общего коммерческого опыта разработчика. За несколько лет во фронтенде вы встречаете огромное количество JavaScript-библиотек и перестаёте бояться каждой новой. Понимаете: у неё есть API, документация, входные данные, определённый результат. Вам уже не обязательно знать каждую внутреннюю механику. Вы можете сравнить две библиотеки по тому, какую задачу они решают, насколько увеличивают итоговый bundle, насколько подходят проекту, и выбрать нужную. Если вы умеете так работать, конкретный стек вокруг React перестаёт пугать. Но отсутствие стандартизации действительно раздражает.

Когда вы приходите в чужой React-проект, первое время можно очень долго разбираться, почему всё устроено именно так. В одной команде определённую архитектуру считают правильной, в другой тот же вопрос решают противоположным способом. Нет одного гайдлайна, который сказал бы: «Используйте только этот набор – и точка». На одну задачу может существовать десять библиотек. Сегодня популярна одна, через год другая. И разработчик постоянно испытывает муки выбора: нужно ли следить за очередной новой библиотекой, стоит ли менять старую, какие у неё преимущества? Это дополнительная когнитивная нагрузка. Иногда действительно думаешь: лучше бы разработчики React встроили больше решений внутрь, пусть bundle стал бы тяжелее, зато не пришлось бы каждый раз решать, какую очередную библиотеку подключать. Так что главный минус React для меня – отсутствие стандартизации и постоянные муки выбора.

Гибкость React удобна бизнесу и опытным разработчикам, но оплачивается дополнительной когнитивной нагрузкой. Angular сильнее стандартизирует проект; React оставляет больше решений на усмотрение команды.

React 19, SSR и Next.js: почему фронтенд постепенно заходит на территорию сервера

Александр: React 19 начал активнее двигаться в сторону серверных возможностей и SSR. Можно ли считать это признанием проблемы?

Александр Ломков: На мой взгляд, да. У меня есть ощущение, что люди, отвечающие за развитие React, увидели, какую большую роль начал играть Next, и решили закрывать часть этих задач внутри основной экосистемы. Next фактически стал отдельным фреймворком над React: вы устанавливаете его и получаете заранее определённый набор решений и правил. React исторически был гораздо более минималистичным. Поэтому появление серверных возможностей я воспринимаю как движение в сторону проблем, которые раньше преимущественно закрывались другими инструментами. Можно сказать, что это признание: некоторые вещи пользователям React действительно нужны на уровне самой платформы.

Александр: React идёт в сторону серверной архитектуры?

Александр Ломков: Я бы сказал, что постепенно размываются границы между фронтендом и бэкендом с точки зрения доступных возможностей. Для фронтенд-разработчика серверный рендеринг внешне не всегда выглядит революционно. Вы пишете похожие компоненты и ту же разметку, но меняется место выполнения части логики и способ получения данных. Вы становитесь немного ближе к серверу.

Александр: То есть теперь из фронтенда можно обращаться прямо в базу данных?

Александр Ломков: Технически определённые сценарии стали возможны, но я бы не формулировал это как «теперь фронтенд ходит в базу». Скорее часть традиционно серверной логики становится доступнее в той же экосистеме, где пишется интерфейс. Это новая возможность, а не новый обязательный стандарт. Да, появляются шутки о том, что теперь можно практически из фронтенд-кода удалить базу данных. Но это именно шутки. Сервер существует не только как прокси между интерфейсом и БД. Там находятся бизнес-логика, безопасность, права доступа, обработка данных и множество других задач. Можно собрать большую монорепу, где рядом находятся компоненты интерфейса и серверная работа с данными. Но это не означает, что такой подход всегда улучшит developer experience.

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

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

Фронтенд через пять лет: код обесценивается, умение формулировать задачу – дорожает

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

Александр Ломков: Думаю, изменится не только фронтенд, а разработка в целом. Из-за искусственного интеллекта она становится более высокоуровневой. Нам будет всё меньше нужно писать код именно так, как мы делаем сегодня. Код постепенно обесценивается как самостоятельный навык. Не в смысле, что он перестаёт быть нужен вообще, а в смысле, что ценность человека всё меньше определяется способностью вручную написать очередной цикл или условие. Код – не самоцель. Мы используем его, чтобы решить или автоматизировать какой-то процесс. Если вы способны человеческим языком, но технически точно объяснить нейросети, какой результат нужен, это тоже становится способом программирования. Через пять лет, скорее всего, мы будем гораздо реже вручную писать многие стандартные конструкции. Будем передавать модели большой объём требований и получать реализацию. Я допускаю, что со временем такой код в типовых задачах будет качественнее человеческого, просто потому что модель сможет учитывать огромное количество накопленных практик. Но в ближайшие годы знание кода всё равно останется серьёзным преимуществом. Причём ценность не только в самом синтаксисе. Программирование определённым образом формирует мышление.

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

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

Ручного кода, вероятно, станет меньше, но инженерное мышление никуда не исчезнет. Ценность смещается от синтаксиса к способности формализовать задачу, проверить решение и провести продукт через ограничения реальной системы.

Что учить в 2026 году: базовый стек плюс нейросети – одновременно, а не по очереди

Александр: Что нужно изучать в 2026 году человеку, который хочет заниматься фронтендом не только ради денег, а потому что ему действительно это нравится?

Александр Ломков: Код и работу с нейросетями. Если конкретизировать код, база осталась примерно той же: HTML, CSS, JavaScript и дальнейший фронтенд-стек, в том числе React и TypeScript. ИИ не отменяет фундамент. Но и относиться к нейросетям как к отдельной теме, которую когда-нибудь изучите после программирования, уже не стоит. Их нужно осваивать параллельно.

Александр: Вы много говорите о бизнес-задачах. Должен ли фронтенд-разработчик, бэкендер или Python-разработчик специально изучать бизнес?

Александр Ломков: Я бы не говорил «изучайте бизнес-процессы» в абстрактном смысле. Нужно понимать доменную область конкретного продукта. Если вы работаете в компании, связанной с такси, нужно понимать, как сервис выглядит с разных сторон. Есть пассажиры, есть водители, есть люди и системы, обслуживающие парк. У каждого свои сценарии. Если вы не понимаете эти процессы, делать работу хорошо будет трудно. Когда я только начинал, у меня было наивное представление: разработчик получает заранее идеально составленное техническое задание, где есть входные данные, выходные данные, а всё внутри просто нужно запрограммировать. На практике часто никаких идеально подготовленных входных данных нет. Разработчику самому приходится уточнять требования, задавать вопросы и собирать контекст. Нужно понимать, что именно требуется от вашего участка системы, почему это требуется и каким должен быть результат, чтобы клиент или внутренний заказчик остался доволен. Вы ответственны за свой код независимо от того, написали его руками или сгенерировали нейросетью. Главное, чтобы решение выполняло задачу и оставалось поддерживаемым.

Александр: Во что тогда имеет смысл углубляться? Не получится ли так, что через пять лет фронтенд вообще станет не нужен и лучше уже сегодня идти, например, в Python?

Александр Ломков: Я бы сказал наоборот: изучайте технологии вширь. Не нужно до бесконечности углубляться в какой-то один JavaScript и надеяться, что знание каждого подкапотного нюанса даст огромное конкурентное преимущество. JavaScript и TypeScript знать необходимо. Это база. Но множество редких внутренних механик сегодня можно быстрее разобрать с помощью нейросети именно в тот момент, когда они понадобились. Фронтендеры в определённом смысле становятся ремесленниками. Наша ценность давно не в том, что мы помним, как написать forEach. Стек постепенно расширялся и раньше. Сначала одного JavaScript было недостаточно – появлялись новые инструменты, библиотеки, инфраструктура. Теперь добавился ИИ, который забирает на себя ещё часть низкоуровневой работы. Поэтому акцент смещается на проблемы бизнеса. Если вам интересна конкретная сфера – банковский продукт, музыка, транспорт, e-commerce, что угодно, – полезно глубже понимать именно её.

Чем шире ваши знания вокруг продукта и чем вам интереснее предметная область, тем более сильным специалистом вы можете стать. Код – фундамент. Всё, что традиционно находится в roadmap фронтенд-разработчика, по-прежнему стоит изучать. Нейросети – следующий слой, но не тот, к которому нужно переходить только после завершения базы. Их стоит осваивать одновременно. И для этого необязательно проходить отдельный огромный курс по «правильной работе с ИИ». Нужно много практиковаться, пробовать разные способы формулировать запросы, понимать, какой контекст помогает модели, а какой мешает. Я воспринимаю это почти как знакомство с человеком. Вы впервые встретились и постепенно учитесь правильно друг с другом разговаривать.

Единого алгоритма нет. Разработчики со временем формируют собственные практики. И чем чаще вы используете ИИ в разных задачах – не только при написании кода, – тем лучше понимаете его возможности и ограничения.

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

Блог, TypeScript и работа без контент-гонки

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

Александр Ломков: Посты мне сейчас писать интереснее, потому что они требуют меньше ресурсов. Я всё чаще публикую достаточно свободные тексты без лишнего SEO-форматирования – просто выражаю мысль. Мне нравится, что так можно быть откровеннее и говорить о вещах, которые действительно кажутся полезными разработчикам, не пытаясь каждый раз превратить идею в большой контентный продукт. Что касается видео, сейчас активно готовлю курс по TypeScript. Также хочу возвращаться к регулярным рубрикам. Видеоформат мне всегда нравился: вы видите реакцию аудитории, получаете обратную связь, это мотивирует. Но в какой-то момент видео начало давить ощущением обязательства: нужно выпустить курс, потом следующую серию, потом ещё одну. Сейчас стараюсь относиться к этому спокойнее и делать контент тогда, когда действительно есть желание и что сказать. У меня нет жёстких обязательств перед спонсорами и нет задачи любой ценой поддерживать монетизацию. При этом останавливаться не планирую. Тем для постов и видео у меня ещё очень много.

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

Глоссарий

API (Application Programming Interface) – набор правил, с помощью которых одна программа или часть системы обращается к другой. Например, фронтенд получает данные с сервера через API.

Approve – подтверждение изменений. В разработке так часто называют одобрение кода после проверки, например в pull request.

Backend (бэкенд) – серверная часть приложения. Она отвечает за бизнес-логику, работу с данными, безопасность и взаимодействие с базами данных и другими сервисами.

Big Tech – условное название крупных технологических компаний с большими продуктами, командами и инфраструктурой.

Boilerplate – типовой повторяющийся код или настройки, которые нужны для работы системы, но сами по себе почти не относятся к бизнес-логике.

Bundle (бандл) – собранный набор файлов приложения, который в итоге загружается браузером. Чем он тяжелее, тем потенциально дольше может загружаться приложение.

Codex – семейство инструментов и моделей OpenAI, ориентированных в том числе на работу с программным кодом.

Claude – семейство ИИ-моделей компании Anthropic, которые могут работать с текстом, кодом и большим контекстом.

CSS – язык, который отвечает за внешний вид веб-страницы: цвета, размеры, расположение элементов, адаптивность и другое оформление.

DevTools – встроенные в браузер инструменты разработчика. С их помощью можно исследовать страницу, запросы к серверу, JavaScript, производительность и другие параметры приложения.

Developer Experience (DX) – удобство работы разработчика с технологией или проектом: насколько понятны инструменты, структура, документация, сборка и процессы.

DOM (Document Object Model) – представление HTML-страницы в виде структуры объектов, с которыми может работать JavaScript. React помогает управлять изменениями этой структуры.

Event loop – механизм JavaScript, который управляет выполнением синхронных и асинхронных задач. Ошибки в понимании его работы могут приводить к зависаниям и проблемам с производительностью.

File-based routing – подход, при котором адреса и страницы приложения определяются структурой файлов и папок проекта.

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

Framework (фреймворк) – готовая система разработки, которая задаёт структуру проекта и определённые правила. В отличие от отдельной библиотеки, обычно берёт на себя сразу несколько классов задач.

GigaChat – семейство российских генеративных ИИ-моделей и сервисов Сбера.

HTML – язык разметки, который задаёт структуру веб-страницы: заголовки, текст, ссылки, формы и другие элементы.

HR-скрининг – ранний этап собеседования с рекрутером. Обычно на нём обсуждают опыт, мотивацию, ожидания и общее соответствие вакансии, а не глубоко проверяют технические знания.

JavaScript (JS) – основной язык программирования для интерактивной логики в браузере. На нём строится значительная часть современной веб-разработки.

JSON – текстовый формат представления и передачи данных. Часто используется при обмене информацией между фронтендом и бэкендом.

Junior / Middle / Senior – условные уровни разработчиков: начинающий, самостоятельный специалист среднего уровня и опытный специалист с большой зоной ответственности.

Legacy-код – старый код, который продолжает использоваться и поддерживаться. Он может быть написан с использованием устаревших подходов, но переписывать его с нуля часто слишком дорого.

Material UI – популярный набор готовых UI-компонентов для React.

Memory leak (утечка памяти) – ситуация, когда программа продолжает удерживать память, которая ей уже не нужна. Со временем это может замедлить приложение или привести к сбоям.

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

MVP (Minimum Viable Product) – минимально жизнеспособная версия продукта. Её создают, чтобы быстро проверить идею и получить обратную связь, не разрабатывая сразу полноценную систему.

Networking (нетворкинг) – создание и поддержание профессиональных знакомств. Такие связи помогают обмениваться опытом и узнавать о новых проектах и вакансиях.

Next.js – фреймворк, построенный вокруг React. Добавляет серверный рендеринг, собственный роутинг и другие готовые возможности для создания веб-приложений.

Open source – модель разработки, при которой исходный код продукта открыт и доступен для изучения и, в зависимости от лицензии, использования и изменения.

Pet-проект – собственный учебный или экспериментальный проект разработчика, который обычно создаётся вне основной работы.

Pixel perfect – подход к вёрстке, при котором разработчик стремится максимально точно воспроизвести дизайн-макет.

Prompt (промпт) – инструкция или запрос, который пользователь передаёт нейросети. Чем точнее сформулирована задача и контекст, тем выше вероятность получить полезный результат.

React – библиотека JavaScript для создания пользовательских интерфейсов. На практике вокруг неё существует большая экосистема дополнительных инструментов.

React Router – библиотека маршрутизации для React-приложений. Определяет, какой интерфейс должен отображаться по конкретному адресу.

Redux – популярный инструмент для централизованного управления состоянием приложения.

Redux Toolkit – современный рекомендуемый набор инструментов для работы с Redux, который сокращает объём типового кода и упрощает настройку.

Roadmap – карта навыков и технологий, которые рекомендуется изучить для определённой профессии или специализации.

Routing (роутинг, маршрутизация) – механизм сопоставления адресов приложения с конкретными страницами или интерфейсами.

SEO (Search Engine Optimization) – оптимизация сайта для поисковых систем, чтобы его страницы корректно индексировались и могли появляться в результатах поиска.

Server-side rendering (SSR) – серверный рендеринг. HTML страницы формируется на сервере и уже готовым отправляется пользователю, а не создаётся полностью в браузере после загрузки JavaScript.

State (состояние) – данные, от которых зависит текущее отображение и поведение интерфейса. Например, авторизован ли пользователь, какие товары лежат в корзине или какая тема выбрана.

State manager – инструмент для управления состоянием приложения. Особенно полезен, когда данные используются множеством компонентов, и простого локального состояния становится недостаточно.

Stack (стек) – совокупность технологий, которые используются в проекте: языки, библиотеки, фреймворки, базы данных и другие инструменты.

Tailwind CSS – подход и набор CSS-классов для стилизации интерфейса непосредственно в разметке.

TanStack Query – библиотека для получения, кэширования и обновления серверных данных в клиентских приложениях.

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

Token (токен) – в контексте ИИ условная единица текста, которую модель обрабатывает. Лимиты и стоимость многих ИИ-сервисов зависят от количества токенов.

TypeScript – расширение JavaScript, которое добавляет систему типов. Помогает обнаруживать часть ошибок ещё во время разработки и делает большие проекты предсказуемее.

UI (User Interface) – пользовательский интерфейс: визуальные элементы, с которыми взаимодействует человек.

UI-библиотека – набор готовых компонентов интерфейса: кнопок, таблиц, форм, окон и других элементов, которые можно использовать в приложении.

Vibe coding (вайб-кодинг) – подход, при котором разработчик или пользователь описывает желаемый результат ИИ естественным языком, а нейросеть генерирует значительную часть кода. В крайнем варианте человек почти не разбирается в реализации и управляет разработкой через последовательность запросов.

Vue – популярный JavaScript-фреймворк для создания пользовательских интерфейсов, одна из основных альтернатив React и Angular.

Angular – крупный фронтенд-фреймворк с более строгой и заранее определённой архитектурой, чем у React.

Zustand – компактная библиотека управления состоянием для React-приложений, которую часто рассматривают как более лёгкую альтернативу Redux.

Вайб-кодер – неформальное название человека, который создаёт значительную часть программного продукта с помощью ИИ и запросов на естественном языке, зачастую почти не работая с кодом вручную.

Дебаггинг – поиск причины ошибки в программе и её исправление.

Доменная область – предметная область бизнеса, для которого создаётся продукт. Например, для сервиса такси это поездки, водители, пассажиры, тарифы, заказы и связанные с ними процессы.

Кэширование – сохранение уже полученных или вычисленных данных, чтобы не запрашивать и не рассчитывать их заново каждый раз.

Рендеринг – процесс превращения данных и компонентов приложения в интерфейс, который видит пользователь.

Техническое задание (ТЗ) – описание требований к системе или конкретной задаче: что должно быть реализовано, как должен вести себя продукт и какие ограничения нужно учитывать.