Заметка короткая и практическая. Сначала — краткий вывод, потом полный текст Julia.

• Что в посте: рабочий минимум для тестирования Vue-компонентов в браузере без Node, Deno и сборки. Тесты запускаются на отдельной странице через QUnit (тестовый фреймворк, который рендерится прямо в браузере), компоненты экспортируются в window._components, рендерятся через mountComponent в скрытый div вне viewport.
• Как ждать DOM: Julia пишет свою функцию waitFor(), которая раз в 20 мс проверяет условие и сдаётся через 2 секунды. Без sleep()-затычек, обычным опросом DOM — паттерн, к которому рано или поздно приходит любая фронтенд-команда.
• Заполнение форм требует событий: в Vue недостаточно присвоить value или checked — нужно диспатчить событие (input для текстов, change для чекбоксов), иначе реактивность Vue не отслеживает изменение.
• Test coverage — Chrome это умеет из коробки: панель Coverage показывает покрытие JS и CSS-кода. Чтобы хорошо работало, Julia рекомендует выключить sourcemaps в DevTools и смотреть покрытие по бандлу.
• Открытые вопросы: как запускать те же тесты в CI, как уйти от привязки к CSS-классам в селекторах (правильнее — getByRole или data-testid), и стоит ли переехать на Testing Library/Vue Test Utils.

Контекст: я хочу тестировать без Node

Привет! Один из моих долгосрочных проектов — выяснить, как писать frontend-JavaScript без Node и любого другого серверного JS-рантайма.

Главная проблема, в которую я постоянно упираюсь в своих frontend-проектах: я не знаю, как писать для них тесты. Раньше я пробовала Playwright, но он казался медленным и неуклюжим — всё время приходилось запускать новые browser-процессы, и оркестрация требовала Node-кода.

В итоге я просто не тестирую свой frontend, и это неприятно. Обычно я и не обновляю проекты особо часто, поэтому болезненность не сильно проявляется, но было бы хорошо вносить изменения с большей уверенностью!

Так что подходящий способ frontend-тестирования давно лежит у меня в списке желаний.

Идея: просто запускать тесты во вкладке браузера

Alex Chan когда-то написал отличный пост — «Testing JavaScript without a (third-party) framework» — в ответ на одну из моих предыдущих заметок этой серии. Там он показал, как сделать крошечный фреймворк юнит-тестирования, который запускается прямо со страницы в браузере.

Мне тогда очень понравился подход, но в посте речь шла только про unit-тесты, а мне нужны были end-to-end интеграционные тесты для моих Vue-компонентов, и я не знала, как это сделать.

Поэтому, когда на днях знакомый Marco в разговоре сказал «знаешь, ты же можешь просто запускать тесты Vue-компонентов в браузере», я подумала: «эй, надо попробовать ещё раз!»

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

Это было слегка непросто: документация Vue обычно предполагает, что вы используете Node как часть build-процесса (там много «шаг 1: npm install ЧТО-ТО»), а я не хотела использовать Node, Deno и так далее. Но на практике оказалось не очень сложно.

Проект, который я буду здесь тестировать, — это сайт фидбэка по моим зинам, который я написала в 2023.

Тестовый фреймворк: QUnit

Я использовала QUnit — тестовый фреймворк для JavaScript, который умеет запускаться прямо со страницы в браузере без Node-окружения (когда-то именно его использовала команда jQuery). Он отлично работает, но рассказать про его внутреннее устройство мне особо нечего — поэтому ограничусь этим. Думаю, подход Alex с самописным фреймворком тоже сработал бы. Я следовала официальной инструкции.

Что я оценила в QUnit — кнопка «rerun test», которая запускает только один конкретный тест. У меня в тестах много network requests, поэтому возможность запустить только один тест сильно облегчает дебаг.

Шаг 1: подготовить компонент к тестированию

Первое, что я сделала — настроила свои Vue-компоненты для тестового окружения.

В основном приложении я положила все компоненты в window._components, примерно так:

Затем смогла написать функцию mountComponent, которая делает то же самое, что мой обычный mount-код в production (рендерит крошечный шаблон с нужным компонентом).

Отличия только два:

• Можно опционально передать дополнительные данные, чтобы использовать их как props.
• Компонент монтируется во временный невидимый div, который удаляется из DOM по завершении теста. Div позиционирован за пределами viewport (position: absolute; top: -10000, ...), так что его не видно.

Вот как выглядит вызов mountComponent:

А вот её код. Здесь qunit-fixture — это служебный div, который QUnit добавляет в тестовую страницу и автоматически очищает после каждого теста (его id зашит в QUnit, нужно только положить <div id="qunit-fixture"></div> в HTML тестовой страницы):

Результат — div, в котором можно программно кликать, заполнять формы, проверять, что появился нужный контент, и так далее. (Примечание переводчика: в оригинальной версии у Julia функция возвращала просто div, но дальше во всех вызовах используется const {div} = mountComponent(...). С return div такая деструктуризация даст undefined — поэтому мы поправили на return {div}. И добавили явный app.mount(div), который тоже опущен в оригинале.)

Шаг 2: добавить fixture-данные

Поскольку я писала end-to-end интеграционные тесты, в которых клиентский JS должен работать в связке с сервером, в БД нужны были тестовые данные. Я написала ~25 строк SQL для подготовки тестовых данных и добавила endpoint в dev-сервер, который запускает этот SQL и сбрасывает тестовые данные в известное состояние.

Затем просто вызываю await reset() в начале каждого теста, которому нужны тестовые данные.

Моя reset() на самом деле не всегда полностью сбрасывает всё — не очень хорошо, но для старта рабочий вариант, и его всегда можно улучшить.

Шаг 3: базовый тест

Так выглядит базовый тест! По сути мы рендерим div и проверяем, что в нём есть приблизительно правильные данные.

Это все базовые кирпичики! А теперь — несколько проблем, на которые я наткнулась по ходу.

Как ждать рендера: проблема и waitFor()

В моих тестах много сетевых запросов, и нужно время, чтобы они завершились, а Vue потом сделал с результатами своё дело и обновил DOM.

Думаю, мы давно усвоили: вставлять sleep()-затычки и надеяться, что тайминги совпадут, — медленно, нестабильно и доводит до бешенства. Поэтому нужен другой способ.

Насколько я понимаю, обычный путь — найти способ по DOM понять, можно ли двигаться дальше. Что-то вроде «если эта кнопка видна — значит, можно действовать».

Поэтому я написала маленькую функцию waitFor(), которая опрашивает условие каждые 20 мс. Таймаут — 2 секунды.

Версия в посте Julia не показана прямо — приведём свою, минимально работающую (и идейно соответствующую её описанию):

Использование выглядит так:

Похоже, существует много реализаций этой идеи, и они продуманы лучше моей (беглый поиск в Google: qunit-wait-for, Playwright expect.poll).

Понять, чего именно ждать, — нетривиально

Иногда мне казалось, что я нашла правильную точку для ожидания в DOM («просто дождись, пока появится этот textarea!»), но на практике из-за внутренних деталей программы нужно было ждать чего-то другого, что было сложно зацепить.

В итоге я добавила в один компонент произвольное значение в DOM, когда он завершал важное действие (вроде data-this-thing-is-ready=true). Это не очень-то красиво.

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

Добавлять CSS-классы для селекторов? Спорный вопрос

В итоге я добавила несколько классов на HTML-элементы — нужно было их находить в тестах, чтобы кликать или ждать появления в DOM.

Я могу позже изменить этот подход — тестовые фреймворки для frontend обычно советуют избегать CSS-классов и использовать что-то вроде getByRole (выбор по семантической роли элемента, например «кнопка» или «поле формы») или, в крайнем случае, data-testid (специальный data-атрибут, который добавляют исключительно ради тестов и игнорируют в production-стилях).

Похоже, миграция на getByRole решает обе проблемы сразу: и приложение становится более доступным для скринридеров, и тесты — устойчивее к рефакторингу разметки.

Заполнение форм — отдельная боль

Чтобы заполнить форму, недостаточно просто выставить value — нужно ещё диспатчить событие, чтобы Vue понял, что элемент изменился. И для checkbox, и для textarea нужны разные события.

Это слегка раздражает — и заставляет понять, зачем вообще могут понадобиться UI-тестовые библиотеки. Например, Testing Library (набор фреймворк-агностичных утилит для тестирования UI с упором на доступность) и Vue Test Utils (официальная библиотека Vue для unit-тестов компонентов). Их подходы к формам выглядят иначе:

• Пример заполнения формы из Testing Library выглядит совершенно иначе, чем то, что делаю я.
• У Vue Test Utils раздел про работу с формами выглядит так, будто сильно упрощает всё это.

Test coverage — Chrome это умеет из коробки

Мне хотелось понять, какое у меня test coverage, и оказывается, в Chrome есть встроенная функция code coverage для JS и CSS!

Мой JS собирается в один файл bundle.js через esbuild — поэтому я могу просто посмотреть на bundle.js и увидеть, какие строки не покрыты тестами.

Процесс получился чуть капризный: пришлось выключить sourcemaps в Chrome DevTools, чтобы заработало, и есть специфическая, не самая очевидная последовательность действий, чтобы увидеть данные покрытия.

Это было прикольно

Как обычно с такими постами: я никогда особо не работала frontend- или backend-разработчиком (кроме как для себя!) и чувствую, будто постоянно учусь делать совсем базовые штуки.

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

Что я ещё обдумываю:

• Пока писала пост, нашла frontend-библиотеку Testing Library — у неё много рекомендаций, как писать тесты, которые сильно отличаются от моих первоначальных идей. Я попробовала переписать всё на Testing Library — получилось неплохо, посмотрим, что из этого выйдет. Они распространяют .umd.js файл, который работает без Node.
• Не до конца понимаю, как относиться к тому, что эти тесты никак не запускаются из командной строки. Может быть, есть простой способ работать в основном в браузере, но иметь возможность погонять и в CI, если нужно?

Что забрать с собой

Мои frontend-проекты всегда кажутся хрупкими, потому что они без тестов. Может быть, однажды у меня появится тест-сьют, в котором я буду уверена.

Главный вывод поста: для маленьких персональных или библиотечных проектов «тестовая страница в браузере» — совершенно рабочий путь. Не нужно тащить Node, build-сервер и jsdom только ради того, чтобы у вас были тесты. Чек-лист минимальной настройки:

1. Положить компоненты в window._components (или другое глобальное пространство имён).
2. Подключить QUnit (или другой фреймворк, который умеет запускаться прямо со страницы) в HTML-файл с тестами.
3. Написать mountComponent(template, data), которая создаёт временный div и монтирует туда Vue-app.
4. Опционально (если у компонента есть бэкенд): сделать endpoint /api/reset_test_data на dev-сервере для сброса БД к фикстуре.
5. Реализовать waitFor(condition, timeout=2000) для ожидания DOM-условий вместо sleep().
6. Для форм диспатчить input (текстовые поля) и change (чекбоксы) после изменения свойств элементов. Для кликов хватит обычного .click() на элементе.
7. Для покрытия — Chrome DevTools, вкладка Coverage; sourcemaps выключить.

Оригинал поста Julia Evans — на jvns.ca. Альтернативы для тех, кто хочет больше готового: Vue Test Utils (через jsdom в Node), Testing Library (с UMD-сборкой работает без Node).

React — JavaScript-библиотека для создания пользовательских интерфейсов, разработанная Meta (ранее Facebook). Vue.js — прогрессивный фреймворк для создания UI, созданный Эваном Ю (Evan You). Оба инструмента используют компонентный подход и виртуальный DOM, но различаются в философии, синтаксисе и экосистеме.

— React лидирует по npm-загрузкам (429 млн/мес против 47 млн у Vue) и рынку вакансий

— Vue проще в освоении и имеет более целостную экосистему «из коробки»

— React 19.2 принёс Activity, Performance Tracks и useEffectEvent

— Vue Vapor Mode обещает производительность без виртуального DOM

— Для крупных корпоративных проектов React остаётся безопасным выбором

— Для быстрого старта и небольших команд Vue даёт преимущество в скорости разработки

React в 2026 — что нового

React продолжает эволюционировать. В 2025–2026 годах произошло несколько значимых событий, которые определили направление развития библиотеки.

React 19 и Server Components

React 19 стал самым масштабным обновлением со времён хуков. Server Components (RSC) — компоненты, которые рендерятся на сервере и не увеличивают клиентский бандл — перешли из экспериментального статуса в стабильный. Это позволяет снизить объём JavaScript, отправляемого клиенту, на 30–50% в типичных приложениях.

Ключевые нововведения React 19:

• Actions — встроенная обработка форм с серверными и клиентскими экшенами
• useOptimistic — хук для оптимистичных обновлений UI
• use() — новый хук для чтения промисов и контекста в рендере
• Нативная поддержка метаданных — title, meta, link можно рендерить прямо в компонентах
• Улучшенная поддержка Web Components — полная интеграция с кастомными элементами

React 19.2 и Compiler v1.0

Вышедший в 2026 году React 19.2 добавил экспериментальные фичи: Activity (управление жизненным циклом скрытых компонентов), React Performance Tracks (интеграция с DevTools для профилирования) и useEffectEvent.

Отдельное событие — выход React Compiler v1.0. Компилятор автоматически мемоизирует компоненты, устраняя необходимость ручного использования useMemo, useCallback и React.memo. По данным Meta, это сократило количество ре-рендеров в их приложениях на 40%.

React Foundation и Linux Foundation

В 2025 году React перешёл под управление React Foundation при Linux Foundation. Это означает более открытое управление проектом и снижение зависимости от одной компании. Для разработчиков это сигнал долгосрочной стабильности.

Vue в 2026 — что нового

Vue тоже не стоит на месте. Хотя темп обновлений ниже, чем у React, каждый релиз Vue приносит продуманные и обратно совместимые улучшения.

Vue 3.5 — стабильность и производительность

Вышедший в сентябре 2024 года Vue 3.5 ("Tengen Toppa Gurren Lagann") сфокусирован на внутренних улучшениях производительности. Реактивная система была оптимизирована для более точного отслеживания зависимостей, а потребление памяти снижено на 56% по данным бенчмарков команды Vue.

Ключевые улучшения Vue 3.5:

• useTemplateRef() — типобезопасные ссылки на элементы
• Deferred Teleport — телепортация контента с отложенным рендерингом
• Lazy Hydration — ленивая гидратация для SSR-приложений
• useId() — генерация стабильных уникальных ID для SSR
• Улучшенный watch — deep watch с поддержкой паузы и возобновления

Vapor Mode — будущее без виртуального DOM

Vapor Mode — экспериментальный режим компиляции Vue, который генерирует код без виртуального DOM. Вместо создания виртуального дерева и его сравнения (diffing) Vapor Mode компилирует шаблоны в прямые DOM-операции. Это аналог подхода Svelte, но с сохранением API Vue.

По предварительным бенчмаркам, Vapor Mode показывает прирост производительности в 2–3 раза на операциях обновления. Проект находится в активной разработке на GitHub (2400+ звёзд), но пока не рекомендован для продакшена.

Nuxt 4 — полная переработка

Nuxt 4 вышел в 2025 году и уже добрался до версии 4.4. Это полная переработка мета-фреймворка для Vue с улучшенной архитектурой, нативной поддержкой серверных компонентов и обновлённым Nuxt UI v4. Для Vue-экосистемы Nuxt 4 — это то же, что Next.js для React.

Сравнение по критериям

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

Критерий / React / Vue

Производительность

В стандартных бенчмарках (js-framework-benchmark) React и Vue показывают сопоставимые результаты. React с Compiler v1.0 автоматически оптимизирует ре-рендеры, Vue 3.5 имеет более эффективную реактивную систему. На практике разница в производительности редко становится решающим фактором — оба фреймворка достаточно быстры для подавляющего большинства задач.

Реальная разница появляется в экстремальных сценариях: Vue Vapor Mode (когда выйдет из эксперимента) обещает преимущество за счёт отказа от виртуального DOM, а React Server Components снижают нагрузку на клиент, перенося логику на сервер.

Порог входа

Vue традиционно считается более дружелюбным к новичкам. Однокомпонентные файлы (SFC) с секциями <template>, <script> и <style> интуитивно понятны. Документация Vue — одна из лучших в индустрии.

React требует понимания JSX, хуков и однонаправленного потока данных. С приходом Server Components и Compiler порог входа вырос — нужно разбираться, какие компоненты серверные, а какие клиентские. По данным State of JS 2024, React назвали "избыточно сложным" чаще других фреймворков.

Экосистема

React обладает самой большой экосистемой в мире фронтенда. Next.js, Remix, React Native, тысячи UI-библиотек (Material UI, Ant Design, Chakra UI, shadcn/ui) — для любой задачи найдётся готовое решение. Обратная сторона — проблема выбора: для одной задачи существует десяток конкурирующих библиотек.

Vue предлагает более целостный подход. Официальные решения покрывают большинство потребностей: Vue Router, Pinia (стейт-менеджмент), Nuxt (SSR/SSG), Vuetify и PrimeVue (UI). Меньше выбора, но меньше и головной боли.

Рынок вакансий

По данным npm, React скачивают 429 млн раз в месяц против 47 млн у Vue — разрыв примерно в 9 раз. На GitHub суммарно у React 244 000 звёзд, у Vue — 263 000 (с учётом Vue 2 и Vue 3 репозиториев). Однако звёзды на GitHub не отражают реальное использование в продакшене.

На рынке труда React доминирует. По данным Stack Overflow Developer Survey 2024, React используют на работе значительно чаще, чем Vue. На hh.ru и LinkedIn вакансий с React в 3–4 раза больше, чем с Vue. Это важно для тех, кто строит карьеру.

Размер бандла

Минифицированный и сжатый (gzip) размер:

• React (react + react-dom): ~44 КБ
• Vue 3: ~33 КБ

Vue компактнее на ~25%. С React Server Components часть кода не попадает в клиентский бандл вовсе, что может нивелировать эту разницу. Vue Vapor Mode в будущем обещает ещё меньший размер за счёт tree-shaking рантайма виртуального DOM.

Поддержка TypeScript

Оба фреймворка отлично работают с TypeScript, но подходы различаются.

Vue 3 написан на TypeScript и предоставляет первоклассную типизацию «из коробки». <script setup lang="ts"> в SFC — лаконичный и типобезопасный способ писать компоненты. IDE-поддержка через Volar (теперь часть Vue Language Tools) значительно улучшилась.

React исторически использует .tsx файлы и имеет зрелую систему типов через @types/react. Типизация хуков и контекста может быть многословной, но хорошо документирована. React Compiler v1.0 полностью поддерживает TypeScript.

Когда выбрать React

React — оптимальный выбор в следующих ситуациях:

• Крупный корпоративный проект — максимальная экосистема, проще найти разработчиков
• Нужен React Native — единая кодовая база для веб и мобильных приложений
• Server-side rendering — Next.js с React Server Components даёт лучший в классе SSR
• Большая команда — огромное сообщество, много документации и готовых решений
• Карьерные перспективы — React-вакансий на рынке в 3–4 раза больше
• Сложные интерактивные интерфейсы — дашборды, real-time приложения, графические редакторы

React подходит тем, кто готов инвестировать время в изучение экосистемы и не боится "усталости от выбора" (framework fatigue). Если команда уже знает React — смена на Vue ради смены не имеет смысла.

Когда выбрать Vue

Vue — лучший выбор, когда:

• Быстрый старт проекта — от идеи до прототипа за минимальное время
• Небольшая команда — целостная экосистема снижает время на принятие решений
• Постепенная миграция — Vue можно внедрять по частям в существующий проект
• Обучение фронтенду — низкий порог входа, отличная документация
• Проекты на Laravel/Django/Rails — Vue традиционно хорошо интегрируется с серверными фреймворками
• Китайский рынок — Vue крайне популярен в Китае (Alibaba, Baidu, Xiaomi используют его)

Vue идеально подходит для команд, которые ценят прагматичность и хотят сфокусироваться на продукте, а не на выборе инструментов. Если проект не требует React Native или React-специфичных библиотек — Vue даст результат быстрее.

Выводы

В 2026 году и React, и Vue — зрелые, стабильные инструменты с активным развитием. Спор «что лучше» не имеет универсального ответа — выбор зависит от контекста проекта, команды и задач.

React и Vue решают одну задачу разными способами. Важен не фреймворк, а то, как вы его используете. Выбирайте инструмент под задачу, а не задачу под инструмент.

Выбирайте React, если вам нужна максимальная экосистема, React Native, Server Components или вы ориентируетесь на рынок труда. Выбирайте Vue, если цените скорость разработки, целостный developer experience и низкий порог входа.

Оба фреймворка продолжают развиваться: React движется в сторону серверного рендеринга и компиляции, Vue — в сторону максимальной производительности через Vapor Mode. Следите за обновлениями обоих проектов и выбирайте то, что делает вашу команду продуктивнее.

Я провела анализ около 70 учебных программ от онлайн-школ. В результате я отобрала 34 наиболее эффективных курса, разбила их на три блока: мой личный топ-10, ещё 16 курсов для углубления в специализацию и 8 бесплатных стартовых уроков для начала обучения.

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

ТОП-10 лучших курсов Vue.js в 2026 году

1. Vue.js от Skillbox — TypeScript и Vue.js через создание трех сложных проектов: каталога фильмов, аудиоплеера и блога с пожизненным доступом к материалам.
2. Vue.js разработчик от OTUS — профессиональное освоение Vue.js с персональным проектом на выбор: панель управления рассылками или модернизация CRM-системы.
3. Фронтенд-разработчик от Skillbox — 17 реальных проектов в портфолио, включая задания от Газпромбанк.Тех с гарантией трудоустройства или возвратом средств.
4. Frontend-разработчик с нуля до Middle от GeekBrains — полный стек технологий от HTML до Vue.js с развитием soft skills и стажировкой у партнеров.
5. Интенсив по программированию от SkillFactory — освоение JavaScript и Vue.js с возможностью очного обучения в Москве и налоговым вычетом.
6. Vue.js от html.academy — интенсивная практика с реальными задачами от IT-компаний и персональной карьерной консультацией.
7. Vue.js от Loftschool — два готовых проекта в портфолио: таск-менеджер и виртуальная пиццерия с поддержкой учебного центра.
8. Vue.js от Level Up — интенсив с созданием SPA-приложения и персональными воркшопами от преподавателя.
9. Vue.js от Learn.Javascript — комбинированное изучение Vue.js и Nuxt.js с проектом приложения доставки еды и онлайн-трансляциями.
10. JavaScript от Специалиста — сертификат на двух языках с еженедельными вебинарами.

Программы подойдут фронтенд-разработчикам, которые хотят освоить современный стек технологий для создания интерфейсов. Также курсы будут ценны для fullstack-специалистов, стремящихся углубить знания клиентской части приложений. Начинающим айтишникам Vue.js предлагает мягкий вход в профессию благодаря продуманной архитектуре и понятной документации.

Онлайн-курсы Vue.js

1. Vue.js | Skillbox

Используйте промокод kursfinder, чтобы получить скидку 50%

Получить скидку >>>

Курс последовательно познакомит вас с TypeScript, а затем с Vue.js. Вы приобретете навыки создания сложных интерактивных веб-приложений и систем, свободных от багов и программных ошибок. В программе — разработка проектов различной сложности: каталоги фильмов, стриминговые сервисы и блог-платформы. Вы освоите написание понятного структурированного кода, что сократит время разработки и тестирования приложений. Полученные знания дополнят вашу базу в верстке и JavaScript, позволив создавать сложные веб-приложения профессионального уровня.

• Стоимость: 99 672 рубля
• Длительность: 2 месяца
• Формат обучения: видеолекции, практика, тренажеры
• Сертификат: сертификат установленного образца

Кому подойдет:

• фронтендерам.

Преимущества:

• портфолио с тремя крупными проектами: каталог фильмов, аудиоплеер и блог;
• решение реальных задач от партнеров курса во время практики;
• пожизненный доступ ко всем материалам и будущим обновлениям;
• персональная обратная связь по всем работам;
• мобильная версия платформы с синхронизацией прогресса;
• беспроцентная рассрочка на оплату;
• налоговый вычет до 13% от стоимости обучения.

Недостатки:

• ограниченное количество мест на курс.

Программа обучения:

• Работа с TypeScript и современными инструментами разработки
• Фундаментальные принципы Vue на практических примерах
• Организация взаимодействия между компонентами
• Управление состоянием страниц и приложений
• Настройка хранилища Pinia для данных
• Методы тестирования Vue-компонентов
• Построение архитектуры и структуры проекта
• Освоение Nuxt и серверного рендеринга
• Анализ различий между Vue 2 и Vue 3
• Дополнительные практические занятия и кейсы

Ознакомиться с полной программой >>>

2. Vue.js разработчик | OTUS

Курс позволяет освоить Vue.js на профессиональном уровне, уделяя внимание архитектуре компонентов, синтаксису фреймворка и принципам реактивности. По завершении обучения вы сможете самостоятельно разрабатывать масштабируемые веб-приложения с нуля. В рамках программы предусмотрена работа над персональным проектом по выбору: создание панели управления для email-рассылок, модернизация CRM-системы или другие практические задачи. Готовый проект пополнит ваше портфолио и станет весомым аргументом при трудоустройстве в IT-сфере.

• Стоимость: 71 000 рублей
• Длительность: 3 месяца
• Формат обучения: онлайн-трансляции, домашние задания, проектная работа, общение с экспертами на вебинарах
• Сертификат: сертификат установленного образца

Кому подойдет:

• новичкам в Vue-разработке;
• JavaScript-разработчикам с навыками CSS и HTML;
• backend-разработчикам, которые хотят освоить fullstack.

Преимущества:

• две онлайн-трансляции в неделю для прямого общения с преподавателями;
• множество заданий и масштабный проект для портфолио;
• детальный анализ кода от профессиональных разработчиков;
• возможность начать карьеру у партнеров площадки еще во время обучения;
• возврат средств при несоответствии содержания курса ожиданиям;
• выбор наиболее интересной темы для проектной работы.

Недостатки:

• необходимо ждать начало обучения;
• чтобы поступить на курс, необходимо пройти обязательное тестирование.

Программа обучения:

• Работа Vue с GraphQL
• Подключение WebSockets во Vue-приложениях
• Освоение TypeScript
• Создание десктопных приложений на Electron
• Серверный рендеринг с помощью Nuxt
• Работа с библиотеками в экосистеме Nuxt
• Выбор темы и организация проектной работы
• Реализация интерактивных интерфейсов и Web Components
• Организация кода и паттерны проектирования во Vue

Ознакомиться с полной программой >>>

3. Фронтенд-разработчик | Skillbox

Используйте промокод kursfinder, чтобы получить скидку 60%

Получить скидку >>>

Курс построен на практическом подходе, максимально приближенном к реальной работе. Обучение включает изучение теоретических основ с интерактивными материалами и выполнение 17 проектов для портфолио. Вы освоите полный стек технологий для создания сайтов любой сложности: HTML, CSS, Vue.js, TypeScript, JavaScript. Параллельно с техническими навыками развиваются soft skills: работа в команде, планирование задач, решение нестандартных проблем. После завершения программы карьерные консультанты помогут сформировать портфолио и подготовиться к собеседованиям в компаниях-партнерах.

• Стоимость: 152 150 рублей
• Длительность: 7 месяцев
• Формат обучения: видеоуроки, текстовые материалы, тесты, интерактивные тренажеры, проекты
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• тем, кто хочет построить карьеру в IT;
• тем, кто хочет зарабатывать на фрилансе.

Преимущества:

• интеграция ИИ-инструментов в рабочие процессы разработчика;
• реалистичные проектные задания от компаний «Газпромбанк.Тех», WhiteMark и платформы «Маруся»;
• до 17 завершенных проектов с реальными кейсами партнеров;
• гарантированная помощь в поиске работы или возврат оплаты;
• проверка домашних заданий в течение суток;
• годовое обучение английскому для веб-разработчиков.

Недостатки:

• не выявлено.

Программа обучения:

• Подготовка материалов к публикации
• Верстка интерактивных элементов
• Создание адаптивных стилей
• Верстка адаптивных блоков интерфейса
• Разработка динамических интерфейсных решений
• Подготовка верстки к запуску в продакшен
• Углубленная работа с объектной моделью документа
• Обработка и валидация пользовательского ввода

Ознакомиться с полной программой >>>

4. Frontend-разработчик с нуля до Middle | GeekBrains

Используйте промокод kursfinder, чтобы получить скидку 7%

Получить скидку >>>

Каждое занятие включает практические задания по ключевым направлениям веб-разработки. Через несколько месяцев обучения вы освоите адаптивную верстку на HTML и CSS, создание интерактивных элементов на JavaScript, проектирование макетов в Figma и работу с фреймворком Vue.js. Курс дополнен реальными задачами от компаний-партнеров — вы сможете выбрать подходящие проекты и расширить портфолио новыми работами.

• Стоимость: 142 128 рублей
• Длительность: от 6 месяцев
• Формат обучения: видеоуроки, онлайн-занятия по расписанию, тренажеры, мини-кейсы, персональная обратная связь
• Сертификат: сертификат установленного образца

Кому подойдет:

• людям, которые хотят освоить веб-программирование с нуля;
• IT-специалистам из смежных сфер.

Преимущества:

• персональная консультация менеджера с дополнительной скидкой;
• помощь в поиске работы и стажировки у компаний-партнеров;
• решение реальных задач от «Газпромбанк.Тех»;
• 15+ завершенных проектов с кейсами известных компаний;
• индивидуальные комментарии наставников по домашним заданиям;
• доступ к эксклюзивной базе предложений работы.

Недостатки:

• в базовом тарифе нет помощи наставника и содействия в трудоустройстве.

Программа обучения:

• Принципы работы компьютера и интернета
• Освоение профессионального окружения разработчика
• Эффективное взаимодействие в команде
• Подготовка материалов к публикации
• Создание контентных блоков и гибких компонентов
• Верстка частей страницы и форм ввода
• Разработка responsive-разделов и анимаций
• Подготовка верстки к промышленной эксплуатации
• Основы верстки в React-окружении
• Реализация бизнес-логики в React-компонентах
• Управление состоянием и информацией в приложении

Ознакомиться с полной программой >>>

5. Интенсив по программированию | SkillFactory

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

• Стоимость: от 104 940 рублей
• Длительность: от 4 месяцев
• Формат обучения: видеоуроки, вебинары, тренажеры
• Сертификат: сертификат и диплом

Кому подойдет:

• новичкам без опыта в IT.

Преимущества:

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

Недостатки:

• в базовом тарифе нет курса английского для IT.

Программа обучения:

• Создание веб-страниц
• Изучение JavaScript
• Освоение TypeScript и вспомогательных средств разработки
• Разработка приложений на React.js
• Проектирование приложений и основы бэкенда
• Профессиональное ориентирование и подготовка к трудоустройству

Ознакомиться с полной программой >>>

6. Vue.js | html.academy

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

• Стоимость: от 53 760 рублей
• Длительность: от 3 месяцев
• Формат обучения: теоретические материалы, практические задания, проектные работы
• Сертификат: нет

Кому подойдет:

• IT-специалистам с навыками программирования на JavaScript;
• людям, которые хотят погрузиться в веб-разработку с нуля.

Преимущества:

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

Недостатки:

• отсутствие документа об окончании курса;
• нет возможностей для онлайн-взаимодействия с преподавателем.

Программа обучения:

• Ключевые особенности фреймворка Vue.js
• Начало работы с Vue.js
• Отображение компонентов в интерфейсе
• Создание компонента счетчика
• Реализация функций компонентов
• Конструкции: условная отрисовка и работа со списками
• Типы и обработка взаимодействий
• Способы связи между компонентами
• Использование слотов и динамического контента
• Организация двустороннего обмена данными
• Обзор Vue Test Utils и Vitest
• Разработка через тестирование

Ознакомиться с полной программой >>>

7. Vue.js | Loftschool

Шестинедельная программа развивает компетенции веб-программирования и дополняет портфолио авторским SPA-проектом. В рамках курса изучается Vue.js для одностраничных приложений, продвинутый JavaScript, методики End-to-End и Unit-тестирования, технологии внедрения анимации. Еженедельный план содержит групповые сессии по развитию профессиональных и личностных навыков, цикл персональных воркшопов под руководством преподавателя, активную фазу реализации собственного приложения.

• Стоимость: по запросу
• Длительность: 6 недель
• Формат обучения: теоретические материалы, практические задания, проект, групповая работа с наставниками
• Сертификат: сертификат установленного образца

Кому подойдет:

• опытным IT-специалистам.

Преимущества:

• насыщенный учебный план с упором на практические задания;
• сопровождение наставника от начала обучения до выпуска;
• готовое SPA-приложение с админ-панелью для портфолио;
• безлимитное использование учебных материалов;
• совместная работа с группой над развитием гибких навыков;
• активность в Telegram-чате с преподавателем и студентами;
• помощь в старте профессионального пути в веб-разработке.

Недостатки:

• не указана стоимость.

Программа обучения:

• Представление наставника и участников группы
• Создание макета дипломного проекта с использованием webpack
• Размещение работы на GitHub для проверки наставником
• Доработка верстки для разных устройств
• Подключение данных из админ-панели к лендингу
• Проверка компонентов приложения
• Групповая разработка под руководством наставника
• Финальная корректировка проекта
• Сдача работы на итоговую проверку
• Внесение результатов в дипломные документы

Ознакомиться с полной программой >>>

8. Vue.js | Level Up

Комбинированный курс по Vue.js и Nuxt.js демонстрирует возможности фреймворков для разработки интерфейсов и веб-решений. Вы выполните практикумы, включая проект приложения доставки еды. Доступны онлайн-обучение на платформе или занятия в петербургском образовательном центре. Программа создана специально для начинающих frontend-разработчиков, которые хотят углубить знания в веб-программировании и повысить свою квалификацию.

• Стоимость: 38 990 рублей
• Длительность: 1,5 месяца
• Формат обучения: очные занятия с преподавателем в Санкт-Петербург или онлайн, практические задания
• Сертификат: нет

Кому подойдет:

• новичкам с базовыми знаниями JavaScript;
• IT-разработчикам с опытом.

Преимущества:

• интенсивные занятия под руководством преподавателя;
• глубокое освоение расширенного стека современных инструментов;
• три приложения на Vue.js и одно на Next.js;
• несколько дополнительных мини-приложений для пополнения кейсов;
• ведение курса опытным веб-программистом с многолетней практикой;
• детальный разбор всех практических заданий.

Недостатки:

• нет сертификата;
• фиксированное расписание.

Программа обучения:

• Знакомство с возможностями Vue.js
• Переход к полноценной работе с Vue-cli
• Изучение продвинутых концепций Vue
• Применение роутинга и менеджеров состояний
• Работа с Vuex и Pinia
• Освоение Nuxt.js для production-проектов

Ознакомиться с полной программой >>>

9. Vue.js | Learn.Javascript

Курс посвящен веб-разработке на Vue 3. Вы изучите функционал фреймворка, освоите различные подходы к решению профессиональных задач и реализуете проект. В работе будут применяться как готовые UI-компоненты с изменяемой конфигурацией, так и созданные самостоятельно. Помимо Vue 3, программа включает JavaScript и TypeScript. Консультации по практическим заданиям проходят на еженедельных вебинарах.

• Стоимость: 24 700 рублей
• Длительность: 2 месяца
• Формат обучения: онлайн-занятия, домашние задания, проектные работы
• Сертификат: сертификат на двух языках

Кому подойдет:

• IT-разработчикам со знанием основ программирования на JavaScript, CSS и HTML.

Преимущества:

• курсовая и итоговая работы для пополнения портфолио;
• документ об окончании на русском и английском языках;
• регулярные онлайн-встречи с преподавателями два раза в неделю;
• обширная база вводных уроков для начинающих;
• групповой чат с возможностью задавать вопросы эксперту;
• рецензирование домашних заданий с обратной связью;
• возврат оплаты при несоответствии курса ожиданиям.

Недостатки:

• редкий набор групп на обучение;
• онлайн-трансляции проводятся в фиксированное время.

Программа обучения:

• Изучение Vue и создание компонентов
• Современные подходы к веб-программированию
• Знакомство с Composables, библиотеками VueUse и Pinia
• Продвинутые техники разработки на Vue
• Принципы реактивного программирования и рендеринга
• Практическое использование inject и provide
• Применение Vue Test Utils и Vitest для тестирования приложений

Ознакомиться с полной программой >>>

10. JavaScript | Специалист

Программа повышает уровень владения JavaScript для разработки реактивных веб-форм, включая применение Vue.js. После обучения вы сможете управлять состоянием приложения, создавать сложные формы, проектировать UI-компоненты и строить сайты на Vue.js. Доступны форматы онлайн-обучения на платформе или очного посещения московского образовательного центра.

• Стоимость: 31 990 рублей
• Длительность: 36 ак.часов
• Формат обучения: очно и онлайн, практика
• Сертификат: сертификат установленного образца

Кому подойдет:

• IT-специалистам, обладающим навыками веб-разработки на JavaScript;
• веб-дизайнерам;
• менеджерам frontend-проектов.

Преимущества:

• несколько форматов обучения – очно, онлайн или по индивидуальному плану;
• 12 академических часов бесплатно для занятий в компьютерных классах образовательного центра;
• дополнительная скидка до 30% при изучении курса в рамках дипломных программ;
• возможность бесплатных занятий в компьютерном классе образовательного центра;
• частый набор групп на очное и онлайн-обучение.

Недостатки:

• небольшое количество практических заданий.

Программа обучения:

• Основы программирования на Vue.js: компоненты, шаблоны, свойства
• Продвинутая работа с компонентами
• Создание анимаций и переходов
• Разработка веб-сайтов и работа с реактивностью

Ознакомиться с полной программой >>>

Еще 16 дополнительных курсов Vue.js

Погрузиться в мир современной фронтенд-разработки можно с разных сторон. Обучение Vue.js открывает перед разработчиками множество путей для профессионального роста. В подборке собраны программы, которые помогут освоить фреймворк через практику и живые примеры. Каждый найдет подходящий формат — от коротких интенсивов до фундаментальных курсов.

• Vue JS от itProger. Оформив подписку на сайте, вы получите полный доступ к курсу по Vue JS, где научитесь создавать компоненты и собирать из них современные веб-сайты. К каждому заданию школа подготовила подробную методичку решения, готовый проект-пример и ответы для самопроверки — это поможет осваивать материал в комфортном темпе и сразу видеть, как должен выглядеть итоговый результат.
• Игра на Vue.js от Stepik. На курсе вы создадите полноценную игру на Vue.js — от проектирования интерфейса до программирования игровой логики на JavaScript, а затем опубликуете готовое приложение в каталоге ВКонтакте; в процессе работы вы разработаете интерактивное приложение, сгенерируете идею через чат-бот и выполните самостоятельный проект для своего портфолио.
• Фреймворк Vue.JS от Frontendblock. Если ваша цель — за 4 недели разобраться во всех возможностях и опциях третьей версии Vue.js, этот экспресс-курс для вас. Все уроки записаны заранее и построены по принципу «теория + практика». Ваши работы будут проверяться, а кураторы предоставят обратную связь. В процессе вы сделаете два проекта разной сложности, и они автоматически пополнят ваше портфолио. Есть три формата участия: можно учиться самостоятельно, с поддержкой куратора или выбрать полностью индивидуальный план.
• Vue.js 3, Vue Router и Pinia от Stepik. В этом курсе вам предстоит освоить Vue, Vue Router и Pinia на практике, создавая два полноценных приложения. Вы разработаете сервис для отображения прогноза погоды и SaaS-платформу для хранения веб-закладок. Курс идеально подойдет тем, кто уже уверенно чувствует себя в основах HTML, CSS и JavaScript и готов погрузиться в изучение одного из самых востребованных фронтенд-фреймворков — Vue.js.
• Frontend разработчик на HTML, CSS и JavaScript от Stepik. Вы изучите HTML, CSS, JavaScript, Figma, Photoshop, VS Code, Emmet, BEM, Bootstrap, Vue, Git, GitHub, Gulp. Также на курсе вам расскажут, как составить портфолио, резюме и взять первый заказ на фрилансе.
• Курс Vue.js от CyberBionic Systematics. Начните свой путь во Vue.js с уверенностью! Этот курс создан для новичков, которые хотят освоить востребованный фреймворк для быстрой и качественной разработки. Вы научитесь работать с формами, компонентами, динамическими данными и анимациями. А после успешного завершения курса получите именной сертификат — ваше первое официальное подтверждение новых навыков.
• Frontend Junior (JavaScript + HTML/CSS + Vue.js) от Stepik. На курсе вы освоите веб-разработку с полного нуля: вы не только изучите основы HTML и CSS, но и глубоко познакомитесь с JavaScript, научитесь работать с популярным фреймворком Vue.js и сможете писать чистый, структурированный код, который ценят в профессиональной среде.
• Vue JS и Vuex - пишем реальный проект с нуля от Udemy. Очень практический курс, который учит веб-разработке на Vue JS и Vuex через создание настоящего проекта. Вы пройдете весь путь — от пустой папки до полностью рабочего приложения. Поймете, как правильно структурировать программу, создавать компоненты и модули, которые легко масштабировать, и дробить код на небольшие, удобные части. В каждом уроке есть доступ к готовому исходному коду, так что вы всегда сможете свериться и найти свои ошибки.
• Vue.js 2.5 Создаем сайт на Vue.JS с Firebase, Vuex и Router от Udemy. Это практическое руководство по созданию сайта с использованием мощной связки технологий: Vue.js, Vuex и Router. Вы научитесь делать динамические и многофункциональные веб-приложения, прокачаете свои навыки в структурировании кода, работе с большими массивами данных и проектировании интерфейсов разной степени сложности. Материал курса разделен на тематические блоки, и каждый включает в себя практическую часть.
• Игра на Vue.js от Udemy. Интересный видеокурс по основам Vue.js, где вы будете создавать настоящую игру. Обучение разделено на две большие части. Первая посвящена интерфейсу: вы с нуля, используя HTML и CSS, сверстаете визуальную часть игры. Во второй части вы займетесь фреймворком Vue.js: напишете структурированный код, добавите алгоритмы и свяжете их с игровой механикой. В финале преподаватель посоветует, куда двигаться дальше и в каком направлении развиваться в IT.
• Vue.js 2 с нуля до про от Tocode. Этот курс поэтапно проведет вас по всем ключевым концепциям и возможностям фреймворка. Он предназначен для подготовки сильных разработчиков и содержит множество практических заданий разного уровня с комментариями и советами от экспертов. В итоге вы получите актуальные знания и навыки для создания динамичных и масштабируемых проектов.
• JavaScript. Программирование от основ до веб-приложений(+Vue.js) от Stepik. На курсе вы освоите JavaScript через решение практических задач, с которыми сталкиваются разработчики в реальной работе. Вам предстоит создать собственное веб-приложение с интерактивными интерфейсами, работой с API и хранением данных, а также познакомиться с React и GitHub. В завершение вы изучите современные фреймворки, включая Vue.js, что позволит вам уверенно работать с самыми востребованными технологиями в веб-разработке.
• Vue Level 2 от Дмитрия Лаврик. Здесь вас ждет полное погружение в разработку одностраничных приложений. Вы не просто изучите теорию, а на практике разберетесь с реальными challenges — от построения архитектуры до обработки серверных ошибок и настройки прав доступа. После каждого занятия — домашняя работа с персональной проверкой автора курса. Всегда можно задать вопрос лично Дмитрию во время живых занятий или в закрытом комьюнити, где собираются такие же увлеченные разработчики.
• Vue.js - Разработка клиентских приложений от Учебного центра «Шифт». Если вы уже работаете с веб-разработкой, но хотите вывести свои навыки на новый уровень, этот курс станет вашим надежным проводником в мир Vue.js. Вы глубоко поймете философию фреймворка и научитесь применять его для создания сложных интерфейсов — от концепции до реализации. Здесь дают именно те знания, которые сразу можно перенести в рабочие проекты.
• Фронтенд - разработчик на Vue.js от Специалист.ru. Это ваш шанс не просто изучить технологии, а полноценно освоить профессию. Начнете с верстки, постепенно перейдете к JavaScript и Git, а затем глубоко погрузитесь во Vue.js. В финале — два ценных документа: государственный диплом о повышении квалификации и международный сертификат. Идеальный вариант для тех, кто хочет не просто научиться программировать, но и получить официальное подтверждение своих знаний.
• Vue.js от Ильи Кантора. На основе проекта вы освоите возможности Vue, различные подходы к решению практических задач и ключевые библиотеки экосистемы. В процессе работы вы разработаете компактную библиотеку переиспользуемых UI-компонентов. Параллельно с изучением Vue будут рассмотрены смежные темы фронтенд-разработки: создание одностраничных приложений, работа с инструментами сборки, освоение Vite, основы тестирования и другие важные аспекты современной веб-разработки.

Бесплатные курсы Vue.js

Начать знакомство с фреймворком можно без финансовых вложений. Хорошие курсы по Vue.js бесплатно познакомят с основами и помогут оценить перспективы дальнейшего углубленного изучения. Такие программы идеально подходят для знакомства с технологией и понимания ее возможностей. Практические задания и понятные объяснения сделают старт в разработке комфортным и интересным.

1. Vue.js — webDev. Вы рассмотрите работу с JavaScript фреймворком Vue JS актуальной второй версии, а также изучите все необходимые темы и понятия, которые нужны, чтобы начать разрабатывать на Vue.
2. Уроки по Vue.js — ITDoctor. Курс состоит из двух глав, в которых вы научитесь работать с различными директивами на Vue.js, создавать циклы, методы и вычисляемые свойства. Плейлист подойдет для веб-разработчиков, которые уже имеют опыт в работе с языками HTML, CSS, JS и желательно понимающих, как работать с гитом.
3. Бесплатный курс по Vue.js — JavaScript.Ninja. Курс по Vue.js от сообщества @vuejs_club, с помощью которого вы узнаете о компонентах, двустороннем связывании и еще о многих темах. Для наглядности автор рассматривает примеры разработки веб-приложений на демонстрации экрана. Дополнительно в содержании курса представлено несколько практикумов для самостоятельной работы.
4. Уроки Vue.js для начинающих — Гоша Дударь. В этом видеокурсе вы изучите основные моменты, которые позволят создавать приложения и сайты на Vue.js. Спикер расскажет, как создавать базовые сайты и веб-приложения с нуля.
5. Постигаем Vue js: урок 0 - установка и основные понятия — JAVA И SКРИПТЫ. Подборка обучающих видео, направленная на обучение разработчиков, которые имеют опыт программирования на JavaScript. Автор подробно рассмотрит темы по отрисовке графических объектов, подбора стилистики для проекта, работе с реактивностью, пользовательскими событиями и так далее.
6. Vue 3 фундаментальный курс от А до Я — Ulbi TV. В этом ролике вы разберете основные концепции Vue 3 и пройдетесь по нему от А до Я. Разработаете приложение с основными кейсами, которые встречаются везде: CRUD, сортировка, поиск, пагинация, динамическая пагинация. Также вы сделаете mixins, directives, изучим vuex и composition api.
7. Vue 3 — AVIS TV. Теоретический курс, автор которого рассказывает о ключевых особенностях фреймворка Vue.js и его применении в среде веб-разработке. Вы узнаете, как установить программное обеспечение на компьютер и использовать его для создания проектов разной сложности.
8. Vue 3 для начинающих / Разработка интернет-магазина Vue Sneakers — Archakov Blog. Курс по Vue 3 для начинающих, в котором вы будете разрабатывать полноценный проект Vue Sneakers, а хранить данные будете на бесплатном сервисе Mokky.

Что такое Vue.js и каковы его ключевые преимущества перед другими фреймворками

Vue.js — это как умный помощник для создания веб-интерфейсов. Представьте, что нужно сделать страницу динамической: добавить всплывающие окна, сортировку таблиц или обновляемые формы. Vue делает это постепенно — можно начать с малого, добавив пару-тройку строк кода в проект, а потом развивать до полноценного сложного приложения.

Понятный без долгого изучения

Фреймворки напоминают сборку мебели по запутанной инструкции — приходится постоянно сверяться со справочником. Vue же работает интуитивно: свяжите поле ввода и данные одной строкой v-model, организуйте цикл элементов через v-for, настройте реакцию на события через v-on. Код читается как обычное предложение — это ценится в командах, где важно быстро понимать друг друга.

Не требует революционных изменений

Если уже есть рабочий проект на чистом JavaScript или jQuery, Vue не заставит все переписывать. Можно внедрять его точечно — например, сделать интерактивным только фильтр товаров в каталоге или форму обратной связи. Это спасает, когда нужно модернизировать интерфейс без остановки основного функционала.

Сам заботится о скорости

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

Единая экосистема

Для типовых задач уже есть проверенные решения: Vue Router для навигации, Pinia для управления состоянием, Nuxt.js для сложных приложений. Они созданы одной командой, поэтому стыкуются друг с другом. Например, Nuxt.js из коробки решает проблемы с SEO — генерирует страницы так, что их сразу видят поисковики.

Сообщество, которое помогает

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

В чем разница между Vue 2 и Vue 3

Архитектура и реактивность

Изменение скрыто «под капотом». Vue 2 использовал систему реактивности на основе Object.defineProperty. Это означало, что фреймворк мог автоматически отслеживать изменения только в тех свойствах, которые были в объекте с самого начала. Vue 3 перешел на современный стандарт JavaScript — Proxy. Теперь Vue отслеживает изменения, включая добавление или удаление свойств объекта и даже работу с массивами, без костылей. Для вас, как для разработчика, это означает предсказуемость и меньше скрытых ошибок.

Composition API — новый способ организации кода

Vue 2 предлагал только один способ структурировать логику компонента — Options API. Вся логика должна была быть разложена по «полочкам»: data, methods, computed и так далее. Это было просто для понимания новичкам, но в больших компонентах логика, относящаяся к одной задаче, оказывалась разбросана по разным разделам. Vue 3 представил Composition API — более гибкий подход, где вы группируете код по его функциональному назначению, а не по типу. Это похоже на написание обычных JavaScript-функций. Такой код легче организовать, переиспользовать и тестировать, особенно в сложных компонентах.

Производительность и размер

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

Лучшая поддержка TypeScript

Если Vue 2 с TypeScript работал, но иногда вызывал головную боль из-за сложной типизации, то Vue 3 был изначально написан на TypeScript. Это означает, что поддержка типов стала первоклассной. Теперь ваша среда разработки (IDE) будет гораздо лучше понимать, что происходит в коде, предлагая умные подсказки и сразу находя многие ошибки. Это огромный плюс для поддержки и масштабирования больших проектов.

Фрагменты и телепортация

В Vue 2 каждый компонент должен был иметь один корневой элемент. Это часто приводило к появлению лишних div-оберток в разметке. Vue 3 позволяет компонентам возвращать несколько корневых элементов — так называемые Фрагменты (Fragments). Это делает DOM-дерево чище. Также появилась директива <Teleport>, которая позволяет «вырвать» кусок кода из одного места в компоненте и отрендерить его в другом месте DOM, что невероятно удобно для модальных окон, уведомлений и тултипов.

Важно понимать, что Vue 3 — это не разрыв с прошлым. Options API никуда не делся и по-прежнему поддерживается. Вы можете использовать старый добрый подход для компонентов и подключать Composition API там, где это нужно. Vue 3 предлагает больше возможностей, улучшенную производительность и современную основу для разработки, сохраняя при этом главную философию — постепенное внедрение и удобство для разработчика.

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

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

1. TabNine

Если вам важна скорость — TabNine стоит попробовать хотя бы ради этого. Расширение — лёгкий AI-ассистент, который работает как умный автодополнитель кода, непохожий на аналоги вроде Codeium или Copilot.

TabNine обучен на миллионах строк открытого кода и умеет предсказывать, что вы напишете дальше, с учётом контекста проекта и языка. Отлично справляется с рутинными вещами: автозавершает функции, переменные, конструкции — всё быстро и чаще всего в тему.

Кому подойдёт: тем, кто хочет ускорить набор кода, но не готов передавать весь проект в облако или открывать чат с Copilot. Поддерживает офлайн-режим и локальное обучение модели.

Плюсы:

• Работает из коробки, не требует тонкой настройки;
• Есть локальная версия — удобно для закрытых проектов;
• Поддерживает большинство языков и фреймворков.

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

2. GitLens

GitLens встраивает историю изменений прямо в VSCode — и делает это максимально удобно. Показывает, кто и когда изменил строку, коммит-месседж, хэш, ветку и другие детали. Можно не уходить в консоль или отдельный Git-клиент для поиска информации.

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

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

Плюсы:

• Информация о коммитах отображается прямо в редакторе под строкой;
• Есть таймлайн изменений файла;
• Удобный diff по коммитам, авторам, веткам и даже фрагментам кода.

Чем полезен: помогает быстрее разбираться в чужом коде, искать причины бага или откатывать ошибки. Особенно ценится за то, что делает Git прозрачным и доступным прямо в процессе разработки.

3. Error Lens

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

Можно настроить отображение: выделять ошибки цветом, добавлять иконки или даже показывать краткие подсказки с предложениями по исправлению. Поддерживает большинство языков и линтеров, включая ESLint, TypeScript и других.

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

Плюсы:

• Ошибки и предупреждения отображаются прямо в редакторе, рядом со строкой кода;
• Гибкая настройка стилей и уровня детализации сообщений;
• Ускоряет процесс отладки, особенно при работе с большими файлами.

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

4. Path Intellisense

Path Intellisense — одно из тех расширений, которое просто работает и экономит кучу времени. Оно автоматически подсказывает пути к файлам, папкам и модулям в вашем проекте, как только вы начинаете их набирать. Поддерживает абсолютные и относительные пути, учитывает структуру проекта и форматирует предложения так, как это принято в выбранном языке.

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

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

Плюсы:

• Подсказки появляются автоматически при наборе пути;
• Поддерживает большинство языков и фреймворков;
• Учитывает jsconfig.json и tsconfig.json при работе с alias-ами.

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

5. TODO Highlight

TODO Highlight подсвечивает комментарии с задачами (например, TODO, FIXME, NOTE) прямо в коде, делая их заметными и удобными для отслеживания. Расширение помогает не терять важные заметки, которые вы оставляете в коде, и быстро находить места, требующие доработки.

Можно настроить ключевые слова, цвета подсветки и даже добавить свои собственные метки. Работает с любыми языками программирования и интегрируется с панелью задач VSCode для удобного обзора всех TODO в проекте.

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

Плюсы:

• Яркая подсветка TODO-комментариев прямо в редакторе;
• Гибкая настройка ключевых слов и стилей;
• Интеграция с панелью задач для быстрого обзора.

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

6. Prettier – Code formatter

Prettier — расширение, которое автоматически приводит ваш код к единому стилю, избавляет от ручной правки отступов, кавычек и переносов. Оно поддерживает множество языков (JavaScript, TypeScript, CSS, HTML и другие) и интегрируется с линтерами, чтобы ваш код был не только красивым, но и консистентным.

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

Кому подойдёт: разработчикам, которые хотят экономить время на форматировании, и командам, стремящимся к единообразию кода.

Плюсы:

• Автоматическое форматирование при сохранении или по хоткеям;
• Поддержка множества языков и кастомных настроек;
• Интеграция с ESLint и другими инструментами для проверки кода.

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

7. Live Server

Live Server запускает локальный сервер прямо из VSCode, позволяя просматривать изменения в HTML, CSS и JavaScript в браузере в реальном времени. После сохранения файла страница автоматически обновляется, что исключает необходимость ручного перезапуска или обновления браузера.

Поддерживает кастомные порты, HTTPS, и работает с любыми фронтенд-проектами, от простых HTML-страниц до сложных приложений на React или Vue. Можно настроить, чтобы сервер открывался автоматически при запуске проекта.

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

Плюсы:

• Автоматическое обновление страницы при изменении кода;
• Простая настройка и поддержка HTTPS для безопасного тестирования;
• Лёгкий запуск сервера прямо из редактора.

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

8. Project Manager

Если работаете над несколькими проектами одновременно — это расширение сэкономит вам часы. Project Manager позволяет создавать список избранных проектов и открывать их в один клик, без ручного поиска папок и недавних вкладок.

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

Кому подойдёт: разработчикам, которые ведут сразу несколько проектов, часто переключаются между ними и устали искать нужный путь через File > Open Folder.

Плюсы:

• Быстрое переключение между проектами через интерфейс или хоткеи;
• Поддержка избранного и тэгов;
• Можно автоматически подтягивать все папки из заданной директории.

Чем полезен: избавляет от рутинных действий при переходе между проектами — особенно когда важно не терять фокус и не сбиваться с рабочего темпа.

9. Code Spell Checker

Code Spell Checker выявляет орфографические ошибки в комментариях, строках и именах переменных прямо в редакторе VSCode. Расширение подчёркивает опечатки волнистой линией и предлагает варианты исправления через Ctrl+. или Cmd+., что позволяет быстро исправить ошибки.

Поддерживает множество ЯП и словари для разных языков (английский, русский, немецкий — с дополнительными расширениями). Можно добавлять свои слова в пользовательский словарь или игнорировать определённые термины, чтобы адаптировать проверку под проект. Работает с camelCase и snake_case, не помечая их как ошибки.

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

Плюсы:

• Мгновенное обнаружение ошибок с подсказками для исправления;
• Гибкая настройка словарей и игнорируемых слов;
• Поддержка технических терминов и различных стилей написания кода.

Чем полезен: экономит время на поиск и исправление опечаток, особенно в документации или пользовательских сообщениях, которые могут повлиять на восприятие проекта.

10. REST Client

REST Client позволяет отправлять HTTP-запросы и просматривать ответы непосредственно в VSCode. Достаточно создать файл с расширением .http или .rest, написать запрос в простом текстовом формате, и вы увидите кнопку Send Request для моментального выполнения.

Поддерживает все типы запросов (GET, POST, PUT, DELETE и другие), авторизацию (Basic, OAuth, JWT), переменные окружения и даже генерацию кода на разных языках. Запросы можно сохранять в репозиторий, что удобно для командной работы. Расширение также позволяет использовать динамические переменные по типу {{$timestamp}} или {{$guid}}, всё для гибкой настройки запросов.

Кому подойдёт: тем, кто работает с REST API и хочет тестировать эндпоинты прямо в VSCode, сохранять запросы в проекте и почти не переключаться между инструментами.

Плюсы:

• Простая отправка запросов через .http или .rest файлы с кнопкой Send Request;
• Поддержка переменных окружения и авторизации для сложных API;
• Возможность сохранять запросы в репозитории для совместной работы.

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

А какими расширениями пользуетесь вы? Пишите в комментариях!

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

• Узнаете, какие крупные изменения произошли в React, Vue и Angular за последние 5-10 лет.
• Поймёте, стоит ли учить новые фреймворки без виртуального DOM или лучше углубиться в проверенные решения.
• Разберётесь, почему компании продолжают требовать знание React, хотя Solid.js работает быстрее.

Тимлид и разработчики рассказали, как они видят будущее профессии. Объяснили, почему джуну недостаточно знать только JS, какие навыки помогут вам зарабатывать больше и оставаться востребованным специалистом.

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

Как изменились React, Vue и Angular за последние 5-10 лет?

React

До 2019 года разработчики писали объёмные классы с методами жизненного цикла. Они управляли состоянием через setState и передавали данные через пропсы. Потом появились хуки — с тех пор логику помещают в функции, состоянием управляют через useState и useReducer, побочные эффекты контролируют через useEffect.

Серверные компоненты решили проблему первой загрузки. Тяжёлые части приложения обрабатывает сервер и отправляет клиенту уже готовыми. Конкурентный режим разбивает отрисовку на части и расставляет приоритеты для обновлений — интерфейс не виснет, когда нагрузка возрастает.

Vue

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

Компилятор научился оптимизировать шаблоны на этапе сборки. Телепорты решили проблему с модальными окнами и всплывающими подсказками — компоненты отрисовываются в нужном месте DOM-дерева независимо от родителя.

В какую сторону развивается Vue и есть ли ему современные альтернативы

Angular

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

Строгая типизация и декораторы сделали код более предсказуемым. Встроенные инструменты покрывают все потребности крупных проектов: формы с валидацией, маршрутизация с ленивой загрузкой, HTTP-клиент с перехватчиками.

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

Пока большая троица занималась «работой над ошибками», появился запрос на что-то более лёгкое и быстрое.

Фронтенд-фреймворки кажутся избыточными — возвращаемся к ванильному JS?

Тот, кто попробовал фреймворки, никогда не вернется к чистому ванильному JS 🙂 Меняются и развиваются сами фреймворки, но тренда на отказ от них точно нет.

Несмотря на тенденцию упрощения, разработчики сходятся во мнении, что полного отказа от фреймворков не произойдёт.

В моде решения на основе концепции «исчезающих фреймворков», которые на выходе выдают почти чистый императивный JS-код. Дело в том, что это общий тренд в IT, где вся сложность и расчёты уходят в инфраструктуру, собирая минимальный бандл, где нет ничего лишнего для клиентов.

Фреймворки — это ещё и способ стандартизации разработки в командах.

Фреймворки никогда не будут избыточными. Один из первых вопросов на собеседовании — инструмент, с которым ты умеешь работать. Больший пласт знаний сегодня — это фреймворк. Остальное, чаще всего, бизнес-логика того или иного проекта.

Из-за критики традиционных фреймворков появился новый класс решений. Больше всего ругают VDOM и гидратацию, хотя они считались неотъемлемой частью современных SPA.

Стоит ли переходить на фреймворки без VDOM и гидратации?

Solid.js и Svelte уже несколько лет развивают концепцию тонкой реактивности. В 2021 году появился Qwik, который вообще отказался от гидратации.

SolidJS хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Qwik отлично подойдёт, если вы создаёте сайт, куда пользователь приходит за контентом, и важно показать ему этот контент мгновенно.

При этом массового перехода на новые фреймворки пока не происходит. Компании продолжают искать React и Vue разработчиков — проекты на Solid.js и Qwik остаются экспериментальными.

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

Проблема новых фреймворков — это отсутствие экосистемы. React и Vue окружены тысячами готовых библиотек для любых задач. На Solid.js и Qwik большинство решений придётся писать самостоятельно.

Без поддержки сообщества пользователей ни один инструмент не сможет стать массовым. Даже если работаешь в заказной разработке и есть возможность расширить кругозор команды, сомнительно брать на тест инструмент, под который придётся писать до 30% базового функционала.

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

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

Технологии развиваются циклично. То, что сейчас кажется инновацией, переосмысливает старые подходы.

Во времена DDR/DDR2 было сложно выполнять клиентский рендеринг, а вот серверам ресурсов хватало. Разработчики как могли воплощали подход, который сейчас называется SSR, и возвращали на клиент готовую разметку для компонентов. И никакого тебе VDOM.

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

Как изменится роль фронтенд-разработчика в 2026 году?

В 2020 году джуниор находил работу, если знал HTML, CSS и основы JS. Сегодня работодатели требуют от новичков React или Vue, TypeScript, системы сборки — и это не конец списка. Ещё и вакансий на всех начинающих не хватает, компании сразу ищут мидлов.

Инструменты с искусственным интеллектом — Copilot, ChatGPT, Cursor — ускоряют работу. Они же повышают планку: если джун с помощью ИИ работает как мидл, то мидл должен демонстрировать более глубокие знания. Работодатели стали больше ценить тех, кто понимает принципы работы кода, а не просто копирует готовые решения.

Зная JavaScript и любой инструмент даже не из большой тройки, с использованием AI можно быстро погрузиться в другой нужный инструмент.

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

Какие навыки развивать разработчику, чтобы оставаться востребованным?

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

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

По мне так лучше быть фреймворк-агностиком, нежели фанатом одного, которого легко чем-то обидеть.

Архитектурное мышление отличает «сильного» разработчика:

• Как организовать код, чтобы его легко поддерживать?
• Как спроектировать API, чтобы оно не ломалось при изменениях?
• Как построить систему, которая выдержит рост нагрузки?

Те, кто решают эти вопросы, получают офферы с космическими зарплатами.

Софт-скиллы тоже влияют на карьерный рост:

• Объясните техническую проблему менеджеру простыми словами.
• Проводите код-ревью так, чтобы не обидеть коллегу, но улучшить код.
• Оценивайте сроки и управляйте ожиданиями.
• Аргументируйте выбор технологии.

Когда вы понимаете бизнес, вы становитесь партнёром. Почему мы делаем эту фичу? Как она повлияет на метрики? Какие есть альтернативы? Разработчик, который мыслит категориями бизнеса, становится незаменимым.

Рынок вынуждает постоянно учиться, потому что индустрия меняется каждый год. Кто застревает в зоне комфорта — отстаёт.

Как ChatGPT повлиял на ценность вашего труда? Успеваете подстраиваться под требования рынка, параллельно работать и пробовать новые технологии? Делитесь в комментариях.

Дмитрий Борцов — руководитель разработки клиентских интерфейсов в PREMIER.ONE. В его подчинении более 60 инженеров, распределённых между вебом, Android, iOS и SmartTV. В индустрии он уже 15 лет: прошёл путь от фриланса и собственной студии до руководства крупными командами. Такой опыт, как он сам говорит, позволяет видеть рынок «с двух сторон» — понимать, что нужно бизнесу и какие компетенции позволяют разработчику стоить дороже. Сегодня Дмитрий совмещает управленческую роль с менторством: вместе с техлидом PREMIER.ONE Андреем Автушенко он развивает платформу Frontend Alliance, где в формате парного наставничества помогает фронтендерам — от джунов до тимлидов — прокачивать хард и софт скиллы, готовиться к собеседованиям и строить карьеру с опорой на реальную практику.

Фронтенд под давлением: рынок стал жёстче, но не умер

Сегодня фронтенд-разработчикам всё чаще приходится отвечать на вопрос: «А рынок-то живой или всё?» Картинка действительно изменилась. Ещё несколько лет назад компании практиковали агрессивный найм: быстро расширяли команды, нанимали десятки разработчиков сразу, а через полгода без сожалений сокращали половину штата. Это было дорого, но при низкой ключевой ставке позволительно: деньги горели, но продукт успевал расти.

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

Тем не менее, говорить о «смерти» фронтенда было бы ошибкой. Спрос не исчез, он просто сузился до тех, кто способен приносить реальную ценность. И здесь проявляется давний раскол: 95% специалистов ограничиваются задачами уровня интерфейсной косметики, а оставшиеся 5% умеют проектировать системы, предлагать архитектурные решения и смотреть шире макета. Именно за этих людей компании будут бороться при любых условиях.

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

Что должен уметь фронтендер в 2025 году и как попасть в «5% из 95»

Уровень middle и senior во фронтенде больше не определяется знанием пары фреймворков. Базовый «джентльменский набор» очевиден: HTML, CSS, JavaScript и хотя бы один современный фреймворк — React, Vue, Angular или Svelte. Сегодня к нему де-факто добавился TypeScript: без него в резюме вы рискуете выглядеть устаревшими, даже если на проекте TS практически не используется. Работодатели хотят видеть уверенную работу с ним, потому что это напрямую ассоциируется со стабильностью и предсказуемостью кода.

Дальше идут надстройки, которые начинают выделять кандидата. Это метафреймворки вроде Next.js или альтернативы с упором на SSR и SSG, понимание разных паттернов рендера и умение применять их под конкретный продукт. Сюда же — юнит-тесты. Никто не будет устраивать экзамен на знание Jest, но сам факт владения тестированием сразу повышает ценность инженера.

Самый заметный маркер — архитектурные практики. Фронтендер, который мыслит архитектурно, понимает FSD, может объяснить, зачем нужны микрофронты (и когда они не нужны), сразу выделяется на фоне тех, кто «просто собирает фичи». Настроить приложение так, чтобы через два года его не пришлось переписывать, — это компетенция, которая превращает разработчика в дорогого специалиста.

При этом стек сам по себе не делает из мидла сеньора. Настоящее отличие — в мышлении. Сеньор умеет общаться с соседними командами, отстаивать нужные изменения в API или инфраструктуре, учитывать долгосрочные риски продукта. Это опыт, который не заменят ни курсы, ни туториалы. И именно он отличает того, кто «пишет код», от того, кто создаёт систему.

Найм и подготовка кандидата: где спотыкаются фронтендеры

Первое, что бросается в глаза при просмотре резюме фронтендеров, — это ошибки самопрезентации. Человек может написать «переписал приложение на новый фреймворк» и не уточнить, что это сократило время загрузки на 30% или сняло половину багов в проде. Для HR выглядит как рядовая строчка, хотя на деле это серьёзное достижение. Добавим сюда непонимание того, как работает HeadHunter: большинство кандидатов просто игнорируют логику поиска и фильтров, и их резюме тонет в выдаче. В итоге, 85% проблем — это не недостаток скиллов, а то, как они упакованы.

Работа ментора начинается именно с этого: помочь собрать рабочее резюме и научить играть по правилам площадок. Но это лишь малая часть. Основная работа — скорректировать харды и софты, довести знания до актуального уровня, натренировать коммуникацию. Ведь первое собеседование с HR часто решает, попадёте ли вы вообще на технический этап. Поэтому вместе с резюме разбирается поведение: как отвечать рекрутеру, какие вопросы задавать, как «продавить» интерес к себе.

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

Отдельный вызов — мотивация. Когда человек месяцами безуспешно ищет работу, у него закономерно опускаются руки. Но ментор — не коуч по вере в себя. Его задача — показать ошибки, дать направление, поддержать обратной связью. А вот сама мотивация должна рождаться внутри. Часто оказывается, что проблема банальна: кандидаты игнорируют рекомендации. Например, используют автокликеры, которые рассылают сотни откликов без сопроводительных писем. Конверсия такого «спама» очевидна: нулевая. Настоящая работа требует внимания к деталям, дисциплины и готовности честно исправлять свои ошибки.

Кейс «Кода найма»: как Ярослав Грачёв выбил оффер в 380К

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

Первое, что пришлось менять, — резюме. Вместо сухого «работал три года» появилось описание проектов и секция «Обо мне». Ярослав даже перефотографировался, чтобы профиль выглядел живым. Параллельно он учился работать с алгоритмами HeadHunter и GPT: HH поднимал резюме в выдаче, а бот имитировал собеседования. Через две недели у кандидата уже был первый оффер.

Ситуация была интересной: предложение на 300 тысяч выглядело заманчиво, но ментор настоял не торопиться. Аргументы были простыми: поток откликов и приглашений уже пошёл, значит, офферы будут и дальше. Они вместе придумали безопасную отговорку для HR и договорились ждать неделю. Ставка сыграла — скоро пришёл новый оффер на 360 тысяч.

И тут началась работа с переговорами. Дмитрий считал, что Ярослав стоит дороже, и предложил сыграть на личных обстоятельствах: «Переезд, ипотека, второй ребёнок — дайте больше». Обычно такой прямолинейный запрос не работает, но в этот раз HR пошёл навстречу и поднял ставку ещё на 20 тысяч. Сработало сочетание доверительной коммуникации и того, что за спиной у кандидата был запасной оффер.

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

А дальше начинается игра на рынке: один оффер на 250 можно держать как «аварийный», второй на 300 использовать для торга, третий — поднять до 350. Главное — не зажиматься на звонках с HR: «их мотивация — провести тебя дальше, деньги они получают за закрытых кандидатов», — напоминает Дмитрий. Поэтому правило простое: дружелюбие, открытость и готовность разговаривать.

Итог кейса Ярослава показал, как за 14 дней можно пройти путь от шаблонного резюме до оффера выше ожиданий. Но за этим стояла системная работа: переписанное CV, домашка с тренировками, переговорные сценарии и дисциплина кандидата.

Советы начинающим фронтендерам

Дмитрий выделяет несколько аспектов, которым стоит уделять внимание в вопросе оффера мечты:

Не рассчитывайте только на ментора

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

Начинайте с основы, а не с фреймворка

Ключевой навык фронтендера — JavaScript. «Все есть JavaScript», — как сказал Илья Климов. React, Vue, Angular, Svelte — это лишь надстройки. Если понимаете сам язык и то, как он работает под капотом, вы сможете писать на чем угодно, хоть в фронте, хоть на Node.js в бэке.

Не ведитесь на быстрые рецепты успеха

Онлайн-школы и ютуберы любят обещать: «выучишь React — и всё в шоколаде». Но без знания JS никакой React не спасёт. На собеседованиях почти всегда спрашивают именно JavaScript, а не то, как вы намагичили интерфейс на очередном фреймворке.

Думайте о том, зачем работает код

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

История Дмитрия Борцова и Ярослава Грачёва — это иллюстрация того, что даже в перегретом и избирательном рынке фронтенда можно найти своё место. Ключ к успеху — не только в технической базе, но и в умении правильно упаковать опыт, показать насмотренность и держать фокус на том, что важно работодателю. Для джунов это часто означает вложиться в JavaScript, а не в очередной модный фреймворк. Для мидлов и выше — развивать софты и стратегически подходить к собеседованиям. А для всех уровней — не замыкаться в одиночном обучении, а искать наставников и сообщество, которые помогают расти быстрее.

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

Последний рубеж React и Vue

Согласны, что VDOM превратился в бюрократическую прослойку? Изменили состояние в одном месте — получите полный пересчёт дерева компонентов. Фреймворки заставляют загружать всё сразу, тащат багаж служебного кода. И пока этот код не загрузится, пользователь смотрит на белый экран.

SSR ускоряет загрузку страницы: сервер рендерит HTML, пользователь видит контент и пытается с ним взаимодействовать. Но пока JavaScript не загрузится, ничего не заработает.

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

Системные проблемы не исправить очередным хуком или новой версией фреймворка, поэтому появление SolidJS и Qwik — было вопросом времени.

Поиск новых решений — здоровый признак развития фронтенда. В конце концов, и Vue был создан потому, что Эвану Ю не хватало облегченной альтернативы AngularJS. Большая тройка фреймворков решает огромный спектр задач, имеет колоссальную поддержку сообщества, но их нельзя назвать идеальным инструментом на все случаи жизни.

Обзор SolidJS

SolidJS во многом похож на React. Самое интересное — его подход к обновлению интерфейса:

• Отсутствие виртуального DOM — Solid напрямую обновляет только те DOM-узлы, которые действительно изменились.
• Компоненты как функции инициализации — каждый компонент вызывается только один раз для настройки реактивности.
• Сигналы вместо хуков — состояние управляется через createSignal(), который возвращает геттер/сеттер пару.

Например, когда срабатывает счётчик, Solid не перерисовывает весь компонент. Он точечно обновляет только текст внутри <p>, где используется count():

Преимущества SolidJS

👍 Производительность и размер бандла

Благодаря отсутствию виртуального DOM и мелкозернистым обновлениям, приложения работают быстрее аналогов на React.

👍 Простота освоения

Синтаксис SolidJS похож на React. Функциональные компоненты, JSX, концепции вроде Suspense и Error Boundaries — всё это есть в Solid. Изучение основ займёт 1-2 дня, если есть опыт с MobX/effector/RxJS.

👍 Стабильность

Фреймворк находится на стабильной версии 1.x. Это означает отсутствие кардинальных изменений API, в отличие, например, от ситуации со Svelte, где сосуществуют версии 4 и 5 с разными подходами.

👍 Совместимость с React

SolidJS совместим с экосистемой React. Можно переиспользовать дизайн-системы и компоненты в legacy-приложениях.

👍 Удобное управление состоянием

Функционал сигналов и сторов покрывают 90% потребностей в управлении состоянием без необходимости подключать внешние библиотеки.

Минусы SolidJS

👎 Ограниченная экосистема

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

👎 Кривая обучения

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

• Избегать условных конструкций непосредственно в компонентах.
• Не деструктурировать пропсы и сторы, чтобы сохранить реактивность.
• Не использовать асинхронный код внутри createEffect.

👎 Проблемы с инструментарием

Возникают сложности с настройкой компилятора в нестандартных окружениях — монорепозиториях, при запуске тестов или интеграции с другими инструментами. DevTools не дотягивает до аналога у React.

👎 SolidStart всё ещё развивается

SSR-решение SolidStart пока не достигло зрелости Next.js или Nuxt. Разработчики сообщают о проблемах с гидратацией и других сложностях при работе с серверным рендерингом.

Обзор Qwik

Qwik — это проект Мишко Хевери (создателя Angular). Идея фреймворка заключается в возможности возобновить работу приложения на клиенте без повторного выполнения кода, который уже был выполнен на сервере.

В Qwik радикально решили проблему гидратации — полностью отказались от неё. Время до интерактивности (TTI) падает в разы. Пользователь может кликать на кнопки сразу после загрузки HTML, без ожидания разогрева всего приложения.

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

Плюсы Qwik

👍 Мгновенная загрузка

Практически нулевой JavaScript при первоначальной загрузке, следовательно отличные показатели Core Web Vitals.

👍 Автоматическая оптимизация

Оптимизация на уровне компилятора, умная предзагрузка критических ресурсов. Не нужно думать о разделении кода — Qwik делает это автоматически.

👍 Знакомый синтаксис

👍 Спасибо за SEO

Быстрая загрузка улучшает ранжирование за счёт полноценного SSR из коробки.

Минусы Qwik

👎 Молодая экосистема

Ограниченное количество библиотек, мало готовых решений и компонентов. Небольшое сообщество разработчиков (если сравнивать с React/Vue).

👎 Кривая обучения

Придётся изучать новые концепции. Из-за ленивой загрузки усложняется отладка.

Qwik — это радикально новая ментальная модель. У фреймворка высокий порог входа: вас ждёт переобучение команды и сложности ручной оптимизации. Чтобы Qwik работал идеально, разработчик должен вручную указывать, что можно лениво загружать, а что нет.

👎 Сложность интеграции

Трудно интегрировать существующие React/Vue компоненты и ограниченная поддержка сторонних библиотек. Скорее всего, придётся с нуля переписывать код существующего проекта.

Экосистема и готовность к продакшену

Если сравнивать с React, то экосистема — самое слабое место обоих фреймворков.

SolidJS имеет SolidStart — метафреймворк с роутингом, SSR и серверными функциями. Документация качественная, сообщество активное. Большинство React-библиотек можно адаптировать без особых проблем, для популярных UI-китов есть готовые порты.

Qwik развивается в связке с Qwik City, который покрывает типовые задачи веб-разработки. Builder.io активно инвестирует в экосистему, регулярно выходят обновления и новые интеграции.

Риски есть, но они управляемые. Меньший размер сообщества означает меньше готовых решений и ответов на Stack Overflow. Если не боитесь изучать новое, то выигрыш в производительности перевесит неудобства.

Сравнение SolidJS и Qwik

SolidJS повышает производительность обновлений. Если данные меняются часто и непредсказуемо — графики, мониторинги, редакторы — Solid даст максимальную отзывчивость.

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

Медиа, блоги с жёсткими требованиями к TTFB/TTI/INP будут лучше работать на Qwik. Пользователи смогут читать и скроллить без задержки. Интерактив добавляется дозированно — это лучшая стартовая стоимость.

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

Сложный SPA или дашборд с живыми виджетами и апдейтами будет лучше работать на SolidJS. Точечная реактивность упростит жизнь и снизит цену апдейтов. Solid сияет в проектах, где происходят сотни мелких изменений в секунду.

Solid хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Также Solid будет хорош там, где важна плавность анимаций.

Лэндинги, мобильные приложения, визитки — здесь Solid даст сверхбыструю реактивность и облегчит сборку.

Оба фреймворка умеют SSR/SSG и стриминг. Solid снижает стоимость обновлений, Qwik — стоимость старта. Для LCP/TTI/INP в контентных сценариях выигрывает Qwik. Для интенсивных интерактивных сценариев Solid удерживает FPS и снижает CPU.

Оба дружат с серверными платформами. SolidStart имеет адаптеры для Vercel/Netlify, Qwik City — тоже.

Выбирайте Solid.js, если вы создаете сервис, куда пользователь заходит надолго, и ему важна отзывчивость после загрузки. Выбирайте Qwik, если вы создаете сайт, куда пользователь приходит за контентом, и важно показать ему этот контент мгновенно.

Немного выводов:

• Solidjs быстрее Qwik при рендеринге. Qwik быстрее Solidjs при загрузке страниц.
• У Solidjs документация лучше, чем у Qwik.
• С нуля код на Qwik писать проще и быстрее, чем на SolidJS.
• Typescript в SolidJS может быть головной болью, в Qwik об этом можно не беспокоиться.

Практические рекомендации по переходу на SolidJS и Qwik

1. Начните с аудита текущих проблем. Посмотрите метрики сайта: сколько времени занимает гидратация? Тормозят ли обновления интерфейса? Где именно проблема — на старте или в процессе работы?
2. Выберите изолированную часть проекта. Возьмите один виджет, одну страницу, один компонент и реализуйте его на новом фреймворке. Измерьте разницу в производительности и удобстве разработки.
3. Если проблема в медленной загрузке — попробуйте Qwik. Соберите прототип лендинга или каталога, включите SSG с resumability и протестируйте на медленном соединении.
4. Если проблема в тормозах интерфейса — попробуйте Solid. Перепишите самый страдальный компонент с частыми обновлениями, уберите мемоизации и посмотрите на результат.

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

Тенденция отказа от React/Vue

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

А вы что думаете? Готовы попробовать модные фреймворки SolidJS и Qwik в следующем проекте?

Почему старые модели больше не работают

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

Как данные превращаются в рекомендации

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

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

Главная задача эмбеддингов — отобрать подходящий контент из миллионов вариантов.

1. Всё начинается с отбора кандидатов. При помощи поиска ближайших соседей ANN (approximate nearest neighbor search), реализованного через FAISS или аналоги, за миллисекунды находятся тысячи кандидатов, которые хотя бы примерно соответствуют интересам пользователя.
2. После этого идёт этап предранжирования. Из тысячи кандидатов нужно выбрать пару сотен наиболее перспективных. Здесь уже работают алгоритмы градиентного бустинга, например, CatBoost или другие, выбор зависит от инфраструктуры. Они учитывают дополнительные признаки: насколько свежа публикация, насколько популярен автор, как часто пользователь взаимодействовал с похожим контентом.
3. Затем наступает финальное ранжирование. Применяются глубокие нейросети, включая нейросетевые версии коллаборативной фильтрации, которые учитывают интересы похожих пользователей. Они прогнозируют, что пользователь будет делать дальше: досмотрит ли видео, поставит ли лайк или репостнёт. Здесь каждому кандидату уделяется особое внимание, ведь нужно выдать самые релевантные.

Всё это работает на единой DataPlatform, которая собирает сигналы от пользователей и обучает модели. В VK для этого есть единая Discovery-платформа, которая собирает клики, лайки, поисковые запросы и обновляет эмбеддинги.

Нейросетевой зоопарк: что стоит под капотом

В финальном ранжировании работает целая экосистема нейросетей. Это и многослойные перцептроны (MLP), и более сложные — сверточные (CNN), рекуррентные (RNN) и трансформеры.

1. Трансформеры и большие языковые модели (LLM)

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

С помощью механизма self-attention он находит связи между элементами и понимает контекст. Это позволяет строить контекстные эмбеддинги — векторные представления, которые учитывают не только содержание, но и значение слов в конкретной ситуации. Так модель понимает, что в фразе «я ем Кафку» речь идёт о еде, а не о литературе.

В рекомендациях трансформеры анализируют действия пользователя как последовательность. Например, модель SASRec (Self-Attentive Sequential Recommendation), которая используется в VK, предсказывает, что может заинтересовать человека дальше, и уже даёт прирост точности на 2,5–3%.

Сильная сторона трансформеров — в умении распознавать связи между действиями пользователя, а не просто фиксировать каждое событие. Если человек будет стабильно взаимодействовать с определённым контентом, модель «поймёт», что это не случайность, и придаст этому интересу больший вес. При этом случайные действия, вроде одного нерелевантного клика, не исказят общую картину — механизм self-attention помогает отличать устойчивые паттерны от шумовых всплесков.

Трансформеры активно применяются в ранжировании, но изначально разрабатывались как универсальные архитектуры для работы с последовательностями. А вот LLM, например, T5 или GPT, обучены на текстах. Они более гибкие: их можно настраивать также через текст и встраивать в диалог. Но они пока медленнее, требуют больше ресурсов и уступают в производительности на больших потоках.

2. Мультимодальные модели

Прорывной подход в рекомендательных системах. Они обрабатывают сразу несколько форматов: текст, изображения, звук. Всё это кодируется в векторы и сводится в общее пространство — часто тоже с помощью трансформеров. Так система понимает не только ключевые слова, но и смысл контента в разных форматах. По такому принципу работает Zelda — семейство моделей и фреймворк, лежащий в основе рекомендаций VK.

Раньше всё сводилось к матрице «пользователь × объект», где система пыталась предсказать оценки. Это работало, пока человек смотрел однотипный контент. Если пользователь смотрит обзоры гаджетов, то старая модель начинает искать похожие видео — с теми же тегами. Но если видео не помечено как «техника», система может его пропустить. Когда интересы меняются, алгоритм не понимает, почему пользователь внезапно увлёкся музыкой или историей.

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

3. Диффузионные модели

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

Диффузионные модели особенно полезны при работе с разреженными и шумными данными — например, для новых пользователей. Такие модели, как DiffRec, показывают до 10% прироста точности на сложных датасетах и постепенно начинают конкурировать с трансформерами.

Система рекомендаций продолжит меняться

Следующим этапом в развитии нейросетевых методов может стать переход к сквозным (end-to-end) архитектурам, когда одна большая нейросеть берёт на себя все функции сразу. Некоторые платформы, например, TikTok и YouTube, уже частично внедряют end-to-end пайплайны. Это снижает ошибки на промежуточных этапах и учитывает цели платформы — вовлечение и удержание.

Новички, когда сталкиваются с пет-проектами, бросаются в две крайности. Создают очередной To-Do list, который ничем не выделяется, либо пытаются сделать что-то слишком сложное, например, убийцу Notion, и забрасывают работу на полпути. Так как же выбрать идею, которую получится довести до конца?

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

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

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

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

Как-то я пришёл на хакатон — занимался рекомендательными системами. Тогда был пик популярности Word2Vec — это модель, которая переводит слова в векторы и позволяет находить между ними смысловую близость. Я посмотрел на статистику и увидел: на одном из сайтов 25% запросов не давали результатов. Тут возникла идея, как это улучшить.

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

За неделю допилил прототип до презентабельного состояния, показал коллегам и руководителю. Они дали «зелёный свет», через 2 месяца была первая MVP, которую уже начали продавать существующим клиентам. Ещё через месяц — первый клиент, интеграция, запуск.

Спустя ~5 лет количество клиентов уже измерялось сотнями :)

Подумайте, какие навыки хотите показать

Если делаете проект для портфолио, то можно выбрать несколько вакансий, на которые вы претендуете. Какие там требования к стеку, какие нужны навыки?

Например, если хотите работать фронтенд-разработчиком в онлайн-школе, то почему бы не сделать простое образовательное приложение на React и заточить его под себя? Смотрите, кого ищет рынок, и подстраивайтесь под его запросы.

Не затягивайте со сроками

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

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

Основная ошибка — это незаконченные, «сырые» решения. HR смотрят на проекты, в том числе, как на способность завершать начатое. Если в портфолио много таких работ, это наводит на мысли, что разработчик быстро теряет интерес, плохо планирует время или бросает задачи при первых трудностях.

Не используйте учебные работы, либо используйте их правильно

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

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

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

Всё равно не могу ничего придумать, что делать?

Если самостоятельно не получается что-то придумать, то можно спросить у ИИ.

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

Пример промпта для идеи пет-проекта:

Возьмите задачу с фриланса

Зайдите на любую фриланс-биржу и полистайте разделы с небольшими заказами. Часто там попадаются простые, но жизненные — например, сделать мини-сервис для бронирования столиков или инструмент для учёта личных трат. Никто не обязывает брать заказ — достаточно посмотреть, что нужно заказчикам, и сделать что-то подобное для портфолио.

Спросите друзей или аудиторию в соцсетях

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

У меня был разработчик, уставший от хаоса в списках фильмов, которые он хочет посмотреть. Сделал пет-проект — личный медиапланировщик с нейтральным UI. Проект не стал стартапом, но в портфолио смотрелся отлично. Если сложно — можно взять существующую идею и улучшить. Например, сделать привычный To do-лист с уклоном в UX, нейросети или интеграции. Главное — показать свою силу, а не сделать ещё один клон.

Как довести пет-проект до конца и не забросить его

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

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

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

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

Разбейте проект на задачи и подзадачи. Например, дизайн плеера, его вкладок, основная логика, подключение API, отладка.

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

Определитесь со сроками. Пусть они будут примерными — главное, чтобы был ориентир. Например, дать себе месяц на MVP, неделю на запуск базовой версии, пару дней на исправление багов. Без сроков любая задача может растянуться, а когда есть конечная точка, появляется стимул не бросать начатое.

Один из основных критериев — полезность продукта. Нет смысла изобретать велосипед. То, что вы создаёте, должно быть либо лучшего того, что уже есть, либо вообще уникальным. И тут не важно, в какой сфере вы решите это всё произвести, главное, чтобы было чёткое понимание, зачем это делается и какой будет итог. Проще говоря, без плана не нужно начинать, иначе велик риск всё забросить. Большая часть тех, кто начал и не закончил, как раз не прорабатывали свои идеи.

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

Конечно, это правило не абсолютное, использовать новые для вас технологии можно, просто это надо делать дозировано.

Если очень грубо, то ориентир выглядит так: 80% кода — это знакомый нам стек, 20% — место для экспериментов и обучения. Такой подход позволяет прокачать новые навыки и довести проект до финала без выгорания.

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

Лучше постараться выработать привычку и заниматься петом, например, каждый день по 30 минут. Не можете соблюдать эту привычку по каким-то причинам? Не проблема, вместо 30 минут найдите 5. Да, за это время вы ничего не успеете, но сохраните «регулярность» — на следующий день будет проще.

Делитесь результатами. Не держите всё в столе, делитесь ходом работы и результатом. Покажите ваш MVP друзьям, обсудите его на форуме, заведите репозиторий на GitHub. Без обратной связи можно легко что-то упустить.

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

А вот ещё несколько советов от Анастасии Егоровой — фронтенд-разработчика, автора программы курса SkillBox по Vue 3 и ведущей ютуб-канала CosyFrontend.

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

У некоторых разработчиков количество таких заброшенных и недоделанных проектов — десятки штук. Что можно придумать для того, чтобы большинство ваших домашних проектов доводились бы до конца?

1. Фиксировать прогресс, например, на доске Trello, чтобы самому видеть продвижение по проекту. Не забывать коммитить в гит. Некоторым разработчикам помогает отписываться о состоянии проекта в личный блог.

2. Избегать перфекционизма — сначала сделать рабочую версию, а потом постепенно ее улучшать.

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

P.S. Когда мы обсуждали тему пет-проектов и их забрасывания в одном из айтишных чатов, один из разработчиков отметил: «А никак не нужно доводить их до конца — пет-проекты для того и существуют, чтобы попробовать на них новую идею и забросить». Так что такое мнение тоже есть, но справедливо ли оно для вас — решайте сами 😀

Как оформить пет-проект

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

Поработайте над UI/UX. Приятный и удобный интерфейс — ваш первый плюс в глазах работодателя. Потратьте время на то, чтобы кнопки, цвета и структура приложения были понятны с первого взгляда.

Чтобы убедиться, что пользователям удобно использовать сервис — запросите обратную связь у знакомых, коллег и родственников. Учтите их замечания.

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

Сделайте подробное описание readme — в паре абзацев расскажите, что это за проект, для кого, какие проблемы решает. Добавьте описание стека архитектуры. Чем подробнее, тем лучше.

Добавьте скриншоты, гифки, видео работы сервиса. А ещё лучше его демоверсию.

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

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

Опишите результаты по конкретным метрикам, если, конечно, это возможно. Опубликовали приложение в Google play и получили хорошее удержание пользователей? Расскажите об этом. Вашу фичу оценили в социальных сетях? Поделитесь приятным фидбеком. Метрик нет, делали проект только под себя? Расскажите, как он помог вам решить проблему.

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

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

Распишите проект как кейс. Подготовьте шпаргалку. Это мини-история, где вы рассказываете о проекте. Какая проблема побудила вас его сделать, какие возникли трудности на этапе разработки, как их решали, какой получили результат. У вас получится подробное описание пути разработки от идеи до финала.

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

Главное, не делайте проект ради проекта, старайтесь принести какую-то пользу и здраво оценивайте свои возможности.

Как всё устроено обычно и что в этом не так

Если вы хоть раз писали современное веб-приложение, то наверняка шли по классической схеме: фронт на Vue или React, бэк на Laravel, Express или чем-то подобном. Между ними REST API. Иногда вместо REST используют GraphQL. Вроде всё по канону, но на практике возникает куча лишних проблем.

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

Плюс техническая возня. CORS, токены, CSRF-защита — всё это надо настраивать, поддерживать и отлаживать. А ещё ведь хочется, чтобы проект нормально индексировался поисковиками. Тогда подключаются Nuxt, Next, пререндеринг, мета-теги и куча других инструментов.

Inertia.js — простое решение, которое сработало

В какой-то момент я наткнулся на Inertia.js, и это был очень приятный сюрприз. Inertia — это не библиотека или фреймворк в привычном смысле. Это клей, который соединяет Laravel и Vue (или React), позволяя строить полноценные интерфейсы без отдельного API.

Фронтенд работает как обычное SPA, а бэк продолжает жить как Laravel-приложение: маршруты, контроллеры, middleware — всё привычно. Вместо return view() используем Inertia::render(), передаём данные, и они попадают напрямую во Vue-компонент как props.

То есть вы работаете в едином стеке. Валидация, авторизация и маршрутизация на сервере, без дублирования. Нет проксей, CORS и прочих сложностей. Просто Laravel отдаёт Vue-компоненты, и всё это отлично работает вместе. Интерфейс ведёт себя как SPA, но архитектура проще.

Если сравнивать с Livewire, то подход другой. В Livewire основной акцент на рендеринг HTML на сервере и обмен данными через AJAX. В случае с Inertia весь интерфейс строится на Vue или React, но без отдельной REST-инфраструктуры.

Пример на практике

Вот как это выглядит в реальном коде.

В контроллере Laravel просто пишем:

На фронте есть компонент Users/Index.vue, который принимает данные как props. Это всё. Не нужно писать отдельный API, сериализовывать данные, обрабатывать запросы вручную. Просто работаем с контроллером и компонентом.

Адреса страниц остаются стандартными, как в Laravel. Например, по маршруту /users Laravel отдаёт страницу, где Vue-компонент рендерит список пользователей. Переходы происходят быстро и без перезагрузки, как в SPA.

Что я получил в реальной работе

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

API как таковой просто исчез. А вместе с ним исчезли и проблемы с CORS, CSRF, токенами и заголовками. Всё работает как в монолите. Если возникает ошибка, ты сразу видишь, где именно она произошла. Не нужно прыгать между фронтом и бэком, выискивая источник бага.

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

С SEO и SSR тоже стало проще. Поскольку рендер идёт на сервере, контент виден поисковикам, а настройка метатегов и пререндеринг выполняются привычными средствами Laravel.

И, пожалуй, главный плюс — всё работает единообразно. Авторизация, сессии, валидация, ошибки — всё в одной системе, без дублирования. Это упрощает отладку и снижает количество багов.

Когда Inertia может не подойти

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

Но если у вас фронтенд и бэкенд разделены по командам и живут в разных проектах — лучше выбрать REST или GraphQL. Inertia для такой архитектуры не подходит.

Также он не заменяет полноценный API. Если вам нужен мобильный клиент или вы планируете отдавать данные сторонним приложениям — API придётся реализовать отдельно.

И ещё один момент. Если вы собираетесь использовать Nuxt или Next.js для SSR — Inertia здесь не поможет. У него свой подход, который не интегрируется с этими фреймворками.

Так что всё зависит от задач.

Итог

Если вы фуллстек-разработчик и работаете в Laravel, очень советую попробовать Inertia. Он позволяет писать фронт и бэк в одном стеке, без лишней головной боли. Вы продолжаете использовать привычные инструменты Laravel — контроллеры, middleware, сессии, валидацию — но при этом создаёте интерфейс с Vue или React. Компоненты, реактивность, быстрые переходы — всё это на месте.

И главное — не нужно прыгать между двумя мирами. Порог входа очень низкий. Начать можно хоть с одной страницы.

Мой совет: попробуйте Inertia на небольшом проекте. Например, сделайте личный кабинет, блог или список задач. Скорее всего, вам понравится. Мне — точно зашло.

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

Обучение программированию в этот период кардинально отличалось от современных подходов. Онлайн-курсы практически отсутствовали. Основными источниками знаний служили бумажные книги:

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

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

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

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

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Техническая уязвимость идентификаторов — не единственная проблема. Защита API-ключей требует комплексного подхода, сочетающего технические решения и организационные меры. Практика показывает, что большинство утечек происходит не из-за направленных атак, а по причине пренебрежения базовыми принципами безопасности.

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

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

Основные причины утечек

API-ключи обеспечивают доступ к критически важным системам — от платежных шлюзов до облачных хранилищ данных. Их компрометация может привести к катастрофическим последствиям — утечке конфиденциальных данных, финансовым потерям и даже к полному захвату контроля над системой.

Разберем основные причины утечек.

Хардкодинг ключей в исходном коде

Пожалуй, самая распространенная и опасная практика — прямое внедрение API-ключей в исходный код приложения. Разработчики часто делают это для удобства тестирования, забывая удалить секретные данные перед релизом.

Особенно критично, когда ключи остаются:

• в конфигурационных файлах (config.php, .env);
• в закомментированных блоках кода;
• в тестовых сборках, которые по ошибке попадают в продакшен;
• в шаблонах и примерах кода.

Яркий пример — инцидент с Microsoft в 2023 году, когда утечка ключа MSA (Microsoft Account) через устаревший код позволила хакерам получить доступ к почтовым ящикам правительственных организаций США, включая Министерство торговли. Как показало расследование Microsoft Security Response Center, проблема возникла из-за ключа подписи, который продолжал использоваться в legacy-системах и попал в руки злоумышленников.

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

Случайные коммиты в публичные репозитории

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

Типичные сценарии:

• временное добавление ключа для отладки с последующим «удалением»;
• позднее добавление .env-файла в .gitignore;
• слияние веток с чувствительными данными;
• автоматические коммиты IDE и инструментов разработки.

В публичные репозитории GitHub ежедневно попадают сотни активных ключей — некоторые из них даже предоставляют доступ к платежным системам и базам данных.

Ошибки в настройке CI/CD

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

• передача ключей через аргументы командной строки;
• попадание секретов в логи сборки;
• неправильная настройка переменных окружения;
• хранение ключей в незащищенных артефактах;
• избыточные права доступа для CI-сервисов

Особенно опасны ситуации, когда CI-пайплайн настроен на публикацию артефактов сборки, включающих конфигурационные файлы с ключами.

Логирование чувствительных данных

Разработчики часто добавляют отладочный вывод, который затем забывают удалить:

• console.log (“API Key: “, secretKey);
• погирование полных HTTP-запросов с заголовками авторизации;
• дампы ошибок с конфиденциальными данными;
• журналирование параметров запросов.

Такие записи могут попасть в системные логи, инструменты мониторинга (Kibana, Grafana), браузерную консоль (для фронтенд-приложений) и облачные сервисы хранения логов.

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

Неправильное управление доступами

Часто проблема кроется не в технических решениях, а в процессах управления:

• отсутствие ротации ключей — некоторые из них используются годами;
• использование одних ключей для разных сред (dev/stage/prod);
• избыточные права доступа — принцип минимальных привилегий не соблюдается;
• хранение ключей в общих хранилищах и чатах;
• отсутствие аудита использования ключей.

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

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

Безопасное хранение и использование API-ключей

API-ключи — это критически важные элементы инфраструктуры, и их утечка недопустима. Чтобы минимизировать риски, важно соблюдать несколько принципов.

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

Сканер секретов GitHub ежедневно обнаруживает сотни случайно залитых ключей, несмотря на предупреждения. Переменные окружения позволяют отделить конфиденциальные данные от кода, но важно убедиться, что файлы .env не попадают в билды или логи.

Для более сложных сценариев стоит рассмотреть специализированные хранилища секретов, такие как HashiCorp Vault, AWS Secrets Manager или Doppler. Они не только обеспечивают безопасное хранение, но и добавляют функции ротации ключей, аудита доступа и интеграции с системами мониторинга.

• Vault динамически генерирует временные ключи для отдельных сервисов, сводя к нулю риск их повторного использования. Однако такие решения требуют настройки и контроля — при некомпетентном подходе компании сталкиваются с ошибками конфигурации при внедрении.
• AWS Secrets Manager — инструмент, который позволяет централизованно хранить конфиденциальную информацию, извлекать ее, управлять доступом, ротировать и мониторить.
• Doppler — кроссплатформенное решение с удобным интерфейсом и историей изменений. Особенно популярно среди стартапов.

Главное преимущество таких систем — централизованное управление. При увольнении сотрудника или компрометации ключа его можно отозвать мгновенно для всех сервисов.

Шифрование обязательно как при передаче, так и при хранении. Даже если злоумышленник получит доступ к базе данных или логам, зашифрованные ключи останутся бесполезными без расшифровки. Современные стандарты, такие как AES-256 или алгоритмы на основе PQC (постквантовой криптографии), уже встроены в большинство облачных провайдеров. Но важно не забывать про управление ключами шифрования (KMS): их утечка сведет на нет всю защиту.

Ограничение доступа — еще один уровень безопасности. Даже корректно хранимый ключ должен работать только с определенных IP-адресов, в заданные промежутки времени и для конкретных методов API. Например, ключ для чтения данных не должен разрешать запись. Cloudflare рекомендует комбинировать геофильтрацию, ограничение частоты запросов и сигнатурный анализ запросов для блокировки аномальных действий.

Наконец, мониторинг помогает обнаружить утечку до того, как ею воспользуются. Инструменты вроде AWS GuardDuty или открытый вариант Falco отслеживают подозрительные операции: неожиданные запросы из новых регионов, аномальную частоту вызовов API или попытки доступа к заблокированным эндпоинтам.

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

Лучшая практика работы с ключами

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

Вот самые эффективные практики:

• Первое правило — никогда не оставлять ключи в коде. Даже если репозиторий приватный, всегда существует риск случайной публикации или утечки через резервные копии. Инструменты вроде pre-commit хуков помогают предотвратить подобные инциденты, автоматически проверяя изменения перед отправкой. Например, скрипт может сканировать коммиты на наличие строк, похожих на ключи, и блокировать их сохранение.
• Регулярная ротация снижает потенциальный ущерб от возможной компрометации. Ключи, которые не обновлялись годами, представляют особую опасность. Современные системы, такие как HashiCorp Vault или AWS Secrets Manager, позволяют автоматизировать этот процесс.
• Принцип минимальных привилегий должен применяться ко всем ключам. Если токен нужен только для чтения данных, он не должен иметь прав на запись или удаление. Ограничение области действия каждого токена — простой, но эффективный способ снизить риски.
• Мониторинг использования помогает выявлять аномалии в реальном времени. Неожиданные всплески активности, запросы из новых регионов или попытки доступа к неиспользуемым методам API — все это сигналы потенциальной компрометации. Инструменты типа AWS CloudTrail или Elastic SIEM позволяют отслеживать подобные события и оперативно реагировать на угрозы.
• Обучение команды не менее важно, чем технические меры. Регулярные тренинги и чек-листы помогают поддерживать уровень осведомленности.

Централизованное управление упрощает контроль за ключами. Когда все токены хранятся в одном защищенном месте, проще отслеживать их использование, вовремя обновлять и отзывать при необходимости. Это также облегчает аудит, который часто требуется для соответствия стандартам вроде PCI DSS или ГОСТ Р 56939-2024.

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

Автоматическое выявление утечек

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

Эффективный мониторинг начинается с проверки исходного кода. Такие инструменты, как GitGuardian и TruffleHog, сканируют git-репозитории, включая историю коммитов, на наличие случайно оставленных ключей. Они используют комбинацию шаблонов и энтропийного анализа, что помогает находить даже замаскированные секреты. Интеграция этих проверок в CI/CD-пайплайны позволяет перехватывать потенциальные утечки до их попадания в основную ветку.

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

При выявлении компрометации критически важна оперативная реакция. Первый шаг — немедленный отзыв скомпрометированного ключа. Современные системы управления секретами позволяют делать это автоматически, одновременно инициируя процесс генерации замены. Задержки в этом процессе создают опасное окно уязвимости.

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

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

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

Как реализовать безопасный доступ на фронтенде

Основная проблема фронтенд-разработки в контексте работы с API — невозможность полностью защитить клиентский код. В отличие от серверной части, JavaScript остается открытым для анализа, а сетевые запросы легко перехватываются. Однако существуют проверенные подходы, позволяющие минимизировать риски утечки ключей.

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

Вместо этого рекомендуется использовать архитектурный паттерн Backend-for-Frontend (BFF), когда фронтенд общается с промежуточным сервером, а тот уже взаимодействует с основными API. Так ключи остаются на защищенной стороне, а клиент получает только временные токены с ограниченным сроком действия.

Для аутентификации пользователей оптимально подходит OAuth 2.0 с расширением PKCE (Proof Key for Code Exchange). Этот механизм обеспечивает безопасный обмен токенами даже в публичных клиентах. В отличие от обычного потока авторизации, PKCE добавляет дополнительный уровень защиты через одноразовые ключи верификации, что предотвращает перехват кодов злоумышленниками.

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

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

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

Последний рубеж безопасности — верификация среды выполнения. Современные библиотеки анализируют параметры браузера, выявляя признаки эмуляции или автоматизации. Это позволяет блокировать запросы от ботов и скриптов, пытающихся массово собирать данные через API. Такой подход особенно важен для финансовых сервисов и платформ с ценной информацией.

Главный вывод: фронтенд действительно представляет угрозу для безопасности API-ключей, но грамотная архитектура и продуманные механизмы авторизации позволяют снизить риски до приемлемого уровня. Ключевой принцип защиты API — минимализм в правах доступа и максимальное делегирование ответственности серверной части.

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

База и теория

1. Event loop для чайников: простыми словами о сложном механизме браузера — В статье разбираем, что такое Event Loop, очередь задач и стек вызовов. Простыми словами о том, как браузер выполняет JavaScript-код и обрабатывает события.
2. Чек-лист по Node.js для новичков: обработка ошибок — Показываем основные подходы к обработке ошибок для Node.js. Рассматриваем пошаговую инструкцию и практические примеры.
3. Что нужно учить JavaSript-разработчикам в 2024 году — Разбираем, какие технологии и навыки нужно знать JS-разработчику, в том числе и в 2025. От фреймворков до подходов к архитектуре.
4. Декларативные языки на примерах с JavaScript — Рассказываем, что значит декларативный стиль программирования. Сравниваем с императивным на примерах JavaScript.
5. JavaScript localStorage: Полное руководство — Разбираем, как работает localStorage. Учим сохранять данные на клиенте с помощью JavaScript.
6. Как работает режим strict в JavaScript — Объясняем, что делает режим strict и почему он помогает писать более безопасный код на JavaScript.
7. Как бесплатно выучить JavaScript и не идти в онлайн-школы — Рассказываем, как самостоятельно освоить JavaScript. Бесплатные ресурсы, полезные советы и личный план обучения.
8. Какие JS-библиотеки использовать для анимаций на сайте в 2024 году — Актуальные JavaScript-библиотеки для веб-анимации. Рассматриваем лучшие инструменты для красивых и быстрых интерфейсов.

Практикуемся

1. 10 реальных вопросов с собеседования JavaScript-разработчика с ответами — Подборка реальных вопросов с собеседований для JavaScript-разработчиков. Даем ответы и объясняем, как правильно мыслить на интервью.
2. Приложение прогноза погоды с использованием Vue JS — Пошаговое руководство по созданию погодного приложения на Vue.js. Обучаем взаимодействию с API и построению интерфейса.
3. Математика в программировании: реализуем уравнения на JavaScript — Объясняем, как реализовать математические уравнения на JavaScript. Практика для программистов, которые не боятся формул.
4. Регулярные выражения в JavaScript: разбираемся в создании — Учим создавать и использовать RegExp в JavaScript. Поясняем синтаксис, паттерны и типовые ошибки.
5. Решаем популярные задачи с асинхронным кодом на JavaScript: часть первая — Практика асинхронного программирования на JavaScript. Решаем задачи с API, задержками и промисами.
6. Асинхронный JavaScript: изучаем Async/Await, Callbacks и Promises — Учим писать асинхронный код в JavaScript: от колбэков до современного async/await. Понятно, на примерах и без лишнего.
7. Задачи по асинхронному программированию на JS — Упражнения на асинхронный JavaScript. От простых примеров до сложных сценариев.

Предыдущие подборки лежат здесь: React, мобильная разработка, С++, инструменты.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Больше новостей — в нашем тг-канале «Представляешь»

Он просто хотел заменить phpMyAdmin чем-то более безопасным и понятным для клиентов. Сегодня у его проекта — более 30 000 звезд, клиенты из списка Fortune 500 и команда из 50 человек.

10 лет в одиночку

Первые 10 лет инструмент был сугубо личным. Без сообщества, без поддержки, без амбиций. Только PHP, MySQL и Бен. Когда-то он просто поставил на стол счетчик звезд с GitHub — и каждая новая звезда ощущалась как маленькая победа.

10 000 звезд: первая волна

Где-то в 2015 году о проекте начали говорить — в Reddit, Slack, GitHub Explore. К проекту присоединился Рейк ван Зантен, будущий со-основатель.

Вместе они вычистили кучу спагетти-кода, переписали все с PHP на Node и Backbone на Vue. Тогда же их позвали в Сан-Франциско — крупная компания хотела внедрить проект, но испугалась, что за ним стоит всего два человека без юрлица.

20 000 звезд: время становиться бизнесом

Хейнс закрыл имевшееся у него агентство и оформил компанию. Поднял $1 млн, собрал команду, запустил облачный сервис.

Затем, после сотни встреч с инвесторами и обвала венчурного рынка, нашел партнера, который понял ценность OSS. Удалось закрыть $8 млн — и с этого момента встал вопрос устойчивости: как зарабатывать, не предавая open-source?

Ответ — собственная лицензия с бесплатным использованием для всех, кроме корпораций. Работали даже с Брюсом Перенсом, сооснователем OSI.

30 000 звезд: устойчивость

Сегодня проект — это компания из 50 человек. Впервые на горизонте — прибыль. Продуктом пользуются правительственные агентства, крупнейшие компании, стартапы.

И да, недавно они тихо подняли еще $9 млн — на новый архитектурный рефакторинг.

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

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

AI — не замена разработчику, а новый хард-скилл. Те, кто осваивает нейросети, в 10 раз продуктивнее коллег, все еще верстающих каждый элемент вручную.

Pixel perfect по запросу: как фронтендеры генерируют интерфейс в 2025 году

*Дизайнер прислал макет в 23:45. Дедлайн — завтра в 10:00*

Знакомо? Раньше это означало ночь без сна. Но что делают ваши коллеги — просто скармливают макет нейронке и идут спать. Утром правят готовый код и укладываются даже в безумный дедлайн без вреда для здоровья.

Что изменилось?

AI-генерация интерфейсов становится рабочим инструментом. Можно конвертировать текст и даже рисунок от руки в готовый HTML/CSS/JS код. Без выравнивания пикселей и утомительной верстки однотипных элементов.

Вы вводите «Создай карточку товара с изображением, названием, ценой и кнопкой “В корзину”» — и получаете код компонента. То, что раньше занимало до 30 минут, теперь можно делать за секунды.

3 причины делегировать рутинную работу на ИИ

AI-генерация компонентов

Помните, как в 100-й раз писали карусель или модалку? Есть инструменты, которым достаточно описания результата — нейросеть сгенерирует компонент с нуля.

GitHub Copilot, Anthropic Claude и AI-плагины для VSCode превращают текстовый запрос в рабочий интерфейс. Причем не просто работающий, а соблюдающий ваши стандарты оформления кода.

Адаптив на автопилоте

Дебаг мобильной верстки не доставляет удовольствие?

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

Дизайнер с «Глазом Бога»

«Кажется, кнопка должна быть правее» — нет, ИИ выдает конкретные рекомендации.

Например:

«При ширине экрана 375px карточки товаров перекрывают друг друга на 12px. Причина: отрицательный margin в классе .product-card, который не учитывает падение грида на мобильных устройствах».

ИИ анализирует верстку и сравнивает ее с лучшими практиками UI/UX. Еще нейронка «видит» проблемы, которые не заметны до первых жалоб на баг.

Популярные модели и технологии

GPT, Claude и Gemini

Нейросети последних версий при четкой постановке задачи сразу пишут хороший код. В 2025 году это относится ко всем популярным моделям.

О том, как правильно составлять запросы для ИИ, рассказывали в статье «Продвинутый промтинг в ChatGPT».

На качество кода влияет выбор между «тяжелыми» и «легкими» версиями.

Например, GPT-4o генерирует код лучше, чем Claude 3, но обходится значительно дороже.

Релизы свежих версий ИИ сопровождаются отчетами с бенчмарками. На 100% доверять этой информации не стоит — если в тестах нейросеть показала хороший результат, не факт, что она эффективна в реальных условиях.

Если нужно сравнить несколько моделей, но времени на самостоятельные тесты нет, обратите внимание на Arena Leaderboard. Этот рейтинг имеет хорошую репутацию в профессиональных кругах. Люди делают одинаковые запросы двум нейросетям и сравнивают ответы. Рейтинг формируется на основе оценок от реальных пользователей.

GPT-Engineer, Smol Developer

Если ChatGPT действует как советчик, то GPT-Engineer и Smol Developer участвуют как полноценные члены команды.

GPT-Engineer трансформирует текстовое описание в готовый проект. Разработчику достаточно сформулировать задачу — AI создаст структуру проекта с файлами, настроит окружение и сгенерирует код.

Smol Developer предлагает иной подход — персонального AI-разработчика. С аудиторией более 10,000 пользователей на GitHub, этот инструмент отличается интуитивным интерфейсом и поддержкой E2B SDK.

No-code/Low-code платформы

Uizard превращает идею в интерактивный прототип быстрее, чем команда дизайнеров набрасывает первые эскизы. За 7 лет инструмент эволюционировал в no-code платформу для создания UI/UX без дизайнерского бэкграунда.

Ключевые функции:

• Автодизайнер 2.0 — генерирует многоэкранные интерфейсы по текстовому описанию.
• Дизайн по эскизу — сфотографируйте рисунок с салфетки, и Uizard трансформирует его в редактируемый прототип.
• Клонирование интерфейсов — загрузите скриншот существующего сайта, и AI превратит его в настраиваемый макет, сохранив структуру и компоновку.
• Экспорт в PNG, PDF и генерация AI базового React-кода (требует доработки).

Locofy пригодится на следующем шаге после создания дизайна — превращении макетов в рабочий код.

Преимущества:

• Генерация кода для React, Angular, Vue.js и других фреймворков.
• Распознавание кнопки, поля ввода, слайдеры для создания динамического элемента.
• Платформа анализирует дизайн и автоматически добавляет медиа-запросы.

Связка Uizard + Locofy формирует конвейер от идеи до кода:

1. Создание прототипа в Uizard по текстовому описанию или наброску.
2. Экспорт в Figma для детальной проработки.
3. Преобразование в код через Locofy.
4. Доработка и интеграция с бэкендом.

Бесплатные тарифы позволяют оценить возможности платформ, но для полноценного использования в работе потребуется платная подписка — от 12$ в месяц.

AI-плагины в Figma

Фигма преобразилась с появлением AI-плагинов. В коллекции десятки дополнений на базе нейросетей.

AI Design by Figma — официальный ИИ-помощник для генерации интерфейсов, встроенный прямо в редактор.

Функционал:

• Создание элементов по текстовому описанию.
• Генерация нескольких вариаций компонентов.
• Трансформация простых фигур в иллюстрации.
• Предложение альтернативных цветовых решений.

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

Режим AutoLayout автоматизирует верстку элементов. Функция анализирует расположение объектов и предлагает наиболее логичную систему компоновки.

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

Путь от запроса к интерфейсу: этапы работы с AI

Шаг 1: Формулировка промпта

Качество сгенерированного интерфейса зависит от точности запроса. ИИ-модели считывают структурированные инструкции лучше, чем набор общих фраз.

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

Шаг 2: Генерация кода

ИИ превращает текст в код, анализируя миллиарды строк из репозиториев и документации. Процесс включает:

• Разбор запроса на технические требования.
• Определение структуры компонента/интерфейса.
• Генерацию HTML/JSX элементов.
• Формирование стилей и интерактивных элементов.
• Оптимизацию согласно паттернам.

Стандартный запрос для генерации компонента пользовательского интерфейса занимает 3-15 секунд.

Шаг 3: Визуализация и проверка

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

Варианты визуализации:

• Встроенные рендереры в IDE (VS Code + GitHub Copilot).
• AI-платформы с предпросмотром (V0, Figma Dev Mode).
• Локальные песочницы (CodeSandbox, StackBlitz).

Шаг 4: Человеческая доработка — финальный штрих

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

Типичные улучшения:

• Добавление проверок на доступность (ARIA-атрибуты).
• Оптимизация производительности (lazy loading).
• Интеграция с реальными данными и API.

Стоит отметить, что ИИ успешно генерирует компоненты для React-приложения, включая:

• Функциональные компоненты с хуками.
• Context API для хранения состояния.
• Мемоизацию через useMemo/useCallback.

Генерация для Vue отлично работает с Composition API. ИИ автоматически применяет ref и reactive для состояния, computed для производных значений и методы для обработчиков.

В процессе создания UI с помощью ИИ не обойтись без проверки качества полученного результата. Тестировать сгенерированное веб-приложение приходится в несколько подходов:

• Визуальный просмотр — проверка соответствия дизайна требованиям и ожиданиям пользователя.
• Кросс-браузерная совместимость — тестирование работы интерфейса в различных браузерах и устройствах.
• Проверка доступности — оценка соответствия стандартам WCAG для обеспечения доступности для всех пользователей.
• Валидация HTML/CSS/JS — использование линтеров и валидаторов для проверки качества кода.
• Юзабилити-тестирование (E2E) — оценка удобства использования интерфейса реальными пользователями.

Плюсы и минусы AI для генерации пользовательского интерфейса

Подводные камни

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

— Шаблонность. ИИ тяготеет к стандартным решениям. Бесполезно пытать нейросеть запросами по типу «нужен уникальный и креативный дизайн». В ответ вы получите очередной шаблон.

— Усредненный UX вместо продуманного. ИИ ориентируется на паттерны, которыми был обучен. Результат часто напоминает интерфейс из 2021 года без учета новейших трендов в UX.

— Зависимость от контекста. Чем сложнее и нестандартнее требование, тем выше шанс, что ИИ не справится с задачей.

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

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

Преимущества AI frontend

— Быстрое прототипирование. ИИ выдает рабочий код за секунды. Полноценный скелет интерфейса появляется по первому запросу: «Создай страницу профиля пользователя с аватаром, статистикой активности и настройками».

— Улучшения на ходу. ИИ вносит изменения мгновенно. Разработчик лишь направляет процесс.

— Поддержка компонентного подхода. ИИ генерирует компоненты, соответствующие архитектурным паттернам.

— Дизайн-варианты с A/B-тестированием. Тестирование гипотез ускоряется в несколько раз. Запрашивайте несколько вариантов UI без дополнительных затрат.

Кейсы и примеры: что реальные разработчики говорят про ИИ

Согласно исследованию Cloud.ru, 62% российских IT-специалистов доверяют AI как коллеге. Российские разработчики активно интегрируют ИИ в рабочие процессы — 73% используют его для работы с кодом, а 39% применяют ежедневно.

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

Рассмотрим три популярных сценария применения ИИ во frontend-разработке.

1. Создание панели администратора за 5 минут

AI-ассистенты значительно ускоряют разработку типовых интерфейсов. Опишите требуемые функции админ-панели (управление пользователями, статистика, редактирование контента), и нейросеть сгенерирует базовую структуру, HTML-разметку и CSS-стили.

2. Быстрое создание дизайна лендинга по описанию продукта

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

3. Адаптация UI под разные разрешения и аудитории

Нейросеть упрощает создание адаптивных интерфейсов и персонализацию UX для различных пользовательских сегментов.

Интересно, что 46% разработчиков отдают предпочтение именно российским AI-сервисам, что говорит о росте доверия к отечественным ИИ-решениям. Еще исследование Cloud.ru выявило, что в 70% вакансий работодатели упоминают навык владения AI-инструментами.

Будущее AI во frontend-разработке

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

Финальная стадия эволюции — создание интерфейсов без интерфейса проектирования.

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

Вопрос не в том, заменит ли ИИ фронтендеров, а в том, заменят ли фронтендеры с ИИ тех, кто продолжает работать по старинке.

Кстати, забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами.

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

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

Container + Presentational Components

На первом месте работы ещё во время разработки на Vue мы с подачи нашего тимлида решили ввести этот паттерн. Глобально у нас были так называемые «умные» и «тупые» компоненты (или как я тактично называл их на демо — визуальные). Как вы наверняка догадались, роль Container у нас исполняли «умные» компоненты, а роль Presentational — «тупые». В чём, собственно, суть этого паттерна? Слышали выражение «разделяй и властвуй»? Паттерн Container & Presentational Components (контейнерные и презентационные компоненты) ровно об этом: он разделяет логику (данные и взаимодействие с ними) и отображение (UI) на разные компоненты.

Presentational Components отвечают только за то, как что-то выглядит. Они получают данные через props и отображают их, больше ничего. Это, как правило, чистые функциональные компоненты, часто без собственного состояния (ну разве что мелкий UI-стейт типа «раскрыт ли dropdown»). Им всё равно, каким образом взять список пользователей — они просто ожидают условный props.users и отображают его в соответствии с дизайном.

Container Components, напротив, знают, что показать и откуда это взять, но не занимаются тем, как это отображается. Они содержат в себе всю логику: могут загрузить данные, подписаться на store или контекст, хранить состояние, а рендерят в презентационных компоненты, передавая им готовые данные. Контейнер может вообще не иметь собственного HTML, кроме того, что приходит от дочернего презентационного компонента. Его задача — это взаимодействие с данными.

Зачем же нужен такой подход? Во-первых, лучшая разделённость ответственности (UI отдельно, данные отдельно) упрощает понимание и поддержку приложения. Во-вторых, улучшается переиспользование: один визуальный компонент вероятно использовать с разными источниками данных через разные контейнеры. Дизайнеры могут менять внешний вид компонента в одном месте, не затрагивая бизнес-логику. И тестировать тоже проще: можно отдельно протестировать логику контейнера (без верстки) и отдельно визуальный компонент (с моком данных).

В этом примере UserList не содержит никакого стейта, не подписан на store или контекст, лишь отображает список. Ему всё равно, как и где получают пользователей — просто принимает проп users и выводит его. Контейнер UserListContainer же занимается работой с данными: делает fetch, сохраняет результат в useState, и потом рендерит UserList, прокидывая в него данные. Благодаря такому делению компонент UserList легко переиспользовать — хоть для локальных данных, хоть для данных из Redux или context — достаточно написать другой контейнер.

Конечно, не всегда нужно городить пару компонентов вместо одного. Этот паттерн полезен, когда приложение растёт: вы начинаете замечать, что пропсы идут через несколько уровней просто транзитом, или один компонент слишком перегружен логикой. Тогда вы «вытаскиваете» логику в контейнер, а UI — в презентационный компонент, и код сразу становится чище. Это не обязательное правило, а приём для рефакторинга по мере необходимости.

Стоит отметить, что с появлением React-хуков граница между логикой и отображением несколько размылась. Теперь можно выносить логику в кастомные хуки и вызывать их прямо внутри компонента, вместо того чтобы создавать отдельный контейнер-класс, как это делали до 2018 года. Тем не менее, принцип «держи логику отдельно от представления» по-прежнему полезен. Даже с хуками можно структурировать код, разделяя функциональность: написать хук useUsersData() для получения пользователей и применять его в разных компонентах (вместо дублирования запроса).

Плюсы: чёткое разделение обязанностей, возможность переиспользовать и заменять части независимо (UI-компонент можно переиспользовать с разными данными), облегчение тестирования.

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

Higher-Order Component (HOC)

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

Зачем это может понадобиться? Представим, у нас есть несколько разных компонентов, и всем им нужно что-то общее: например, обработка ошибок или подписка на внешние данные. Можно было бы скопировать этот код в каждый из компонентов, но куда элегантнее написать HOC один раз и применить ко всем. Классический пример — Redux-функция connect: вы пишете export default connect(mapState)(MyComponent), и ваш компонент получает пропсы из глобального стейта.

connect — как раз и есть HOC, который инъектирует данные из Redux в компонент, не требуя от вас переписывать все под Redux вручную.

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

Здесь withCounter — HOC, он возвращает новый функциональный компонент WithCounter, который внутри себя использует useState и передаёт состояние и функцию увеличения внутрь WrappedComponent. В итоге EnhancedButton — это улучшенная версия ClickButton, которая умеет считать клики, даже если исходный ClickButton об этом не знал.

Плюсы: один HOC может добавить функциональность множеству компонентов сразу — не надо копировать код везде. Логику обновляется в одном месте (внутри HOC) — и все обёрнутые компоненты получают изменения. HOC можно комбинировать: например, обернуть компонент сначала в HOC, добавляющий тему оформления, потом в HOC, добавляющий логирование, и т.д. В итоге получим компонент, обладающий сразу несколькими дополнительными возможностями.

Минусы: за такую магию мы платим усложнением структуры. Когда компонентов обёрток становится много, React-дерево раздувается, и возникает эффект «матрёшки». В DevTools вы могли видеть что-то вроде: Connect(withRouter(WithTheme(MyComponent))) — разобраться, что к чему, становится сложнее. Дебаг таких цепочек — тоже удовольствие то ещё, приходится пробираться через несколько уровней абстракций. Кроме того, HOC часто прокидывают пропсы во внутренний компонент, что чревато конфликтами имён (нужно следить, чтобы, например, prop.title от HOC не перезаписал пропс title, который вы передали самому компоненту). Ещё нюанс — HOC усложняют типизацию в TypeScript (надо правильно описывать generic для пропсов), но это выходит за рамки нашей темы.

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

Паттерн Render Props

Следующий паттерн я бы назвал «перевёрнутый HOC». Render Props — это подход, когда компонент сам не рендерит что-то внутри себя, а принимает функцию (часто через проп render или просто используя детей как функцию) и вызывает её, чтобы получить содержимое. То есть мы передаём компоненту инструкцию, что именно отрендерить, а он сам обеспечивает, когда и с какими данными вызвать эту инструкцию.

Представьте компонент <MouseTracker> для отслеживания положения курсора. Классически он может хранить x, y в своём состоянии и отрисовывать, скажем, <p>Mouse at (x, y)</p>. Но что, если мы хотим переиспользовать эту логику уже с другим UI? Паттерн Render Props предлагает сделать компонент <Mouse>, который не определяет жёстко JSX внутри себя, а вызывает функцию, переданную через проп (или children функцию), передавая ей координаты. Эта функция сама решит, что рисовать. Таким образом, <Mouse> инкапсулирует логику (слежение за мышкой), а отображение делегирует наружу.

Пример: реализуем компонент-утилиту <FilteredList items={...} filter={...}>, который отображает список на основе передаваемого фильтра. Вместо того чтобы жёстко прописывать разметку элемента списка, сделаем его с render проп через children:

Здесь <FilteredList> знает, как отфильтровать массив (items.filter(filter)), но не знает, как отрисовать каждый элемент. Вместо этого он вызывает функцию, которую мы передали в качестве дочернего элемента (children), для каждого элемента списка. Эта функция возвращает <li> для каждого item. В результате логика фильтрации инкапсулируется внутри FilteredList, а конкретное отображение списка задаётся извне. Мы могли бы так же использовать этот компонент для массива объектов, отрисовывая, например, товары — достаточно передать другую children-функцию.

Паттерн Render Props здорово повышает гибкость компонентов. Мы можем переиспользовать <FilteredList> для списков чего угодно — чисел, пользователей, товаров — просто изменяя функцию отображения. Другой пример: компонент <Mouse> может предоставлять координаты курсора, а внешний код решит, просто вывести текст, нарисовать по координатам картинку или вызвать какую-то совершенно другую логику — не нужно делать несколько вариаций компонента для каждого кейса.

Плюсы: Render Props позволяет компоненту-провайдеру (в примере выше FilteredList является провайдером данных) быть максимально универсальным, а конкретную разметку делегировать наружу. Многие библиотеки воспользовались этим паттерном: например, React Router (до версии 6) позволял вместо компонента страницы передать проп render в <Route> — функцию, которая отрисует JSX на основе параметров маршрута. Formik предлагал компонент <Formik> с функцией-ребёнком для рендеринга формы. Downshift (библиотека для автокомплитов) — тоже классический пример паттерна render props.

Минусы: главное неудобство — излишний шум в JSX. Код с вложенными функциями бывает тяжело читать. В нашем простом примере всё компактно, но представьте, если у вас будет несколько уровней таких компонентов: <Foo>{foo => ( <Bar>{bar => ( ... )}</Bar> )}</Foo> — легко получить «оберточный ад» из стрелочных функций прямо в разметке. Это значительно затруднит отладку такого кода при возникновении каких-либо проблем. К тому же, каждый раз при рендере создаётся новая функция, что может негативно сказаться на производительности, если таких компонентов много (React конечно оптимизирует функции в пропсах через механизм сравнения, но всё же). Также возникает неявная связь: внешний код должен знать, какие аргументы ожидает функция. TypeScript конечно помогает, но при чтении кода не сразу видно, что children, например, это не просто элемент, а функция.

Как и HOC, паттерн Render Props сейчас используется реже. Многие задачи, решаемые через него, теперь элегантнее с точки зрения кода решаются хуками, в официальной документации это также отмечено. Но всё же понимать его нужно, потому что легаси-код и некоторые библиотеки всё ещё работают на нём. Если видите, что компонент принимает функцию в виде пропса (чаще всего называется render или передаваётся через детей), знайте — это он, Render Props.

В следующей части расскажу про хуки и кастомные хуки, а также про Compound Components и Серверные компоненты и Suspense.

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

Шаг 1. Готовимся к миграции

Посмотрите структуру проекта, чтобы выявить слабые места.

Архитектура далека от идеала, если проект вырос на хаотичных добавлениях новых функций.

Проанализируйте:

• Вид проекта. Ваша разработка — это монолит, модульная система, API, микросервис?
• Зависимости. Определите, какие библиотеки использует проект. Совместимы ли они с Laravel?
• Базу данных. Если в БД встречаются дубли, отсутствуют ограничения, это нужно исправить заранее.

В качестве теста на совместимость перепишите небольшую часть на Laravel. Возьмите один простой модуль и посмотрите, насколько это жизнеспособно.

Стратегии перехода

Выберем стратегию перехода:

• Big Bang,
• Поэтапный перенос.

Стратегия Big Bang — это полная остановка текущего проекта и создание новой версии на Ларавел с нуля.

Подход идеален для устаревших и запутанных систем.

Из минусов — высокие риски. Во время разработки текущая версия может растерять пользователей. К тому же сроки реализации могут затянуться.

Стратегия с постепенным переходом выглядит надежнее.

Система продолжает работать, а вы поэтапно меняете ее «под капотом».

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

Выбор подхода зависит от проекта

Если систему легко поддерживать, то более безопасен постепенный переход.

Проект напоминает спагетти-код? Плохие новости — Big Bang неизбежен.

Шаг 2. Разворачиваем новое окружение на Laravel

Чтобы установить фреймворк, выполните команду:

Прежде чем работать с кодом, настроим окружение.

В корне проекта для этого есть файл конфигурации .env:

• APP_NAME: имя приложения, чтобы оно отображалось в логах и заголовках.
• APP_URL: адрес, на котором приложение будет доступно (например, http://localhost).

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

Подключение БД

Laravel использует Eloquent ORM для взаимодействия с базой.

Настройка БД выполняется в том же разделе .env:

Для тестирования подключения запустите команду:

Настройка маршрутов

Маршруты изначально хранятся в файлах routes/web.php (для страниц) или routes/api.php (для REST API).

В качестве примера добавим базовый маршрут приветствия:

Если у вас проект с десятками пользовательских маршрутов, интегрируйте их постепенно.

Шаг 3. Переносим модели данных и бизнес-логики

Eloquent ORM работает с классами, представляющими таблицы в базе данных.

Чтобы перенести существующую таблицу, нужно создать модель:

Этот класс автоматически подключается к таблице с именем products.

Когда название таблицы не соответствует модели, это можно указать явно:

Если в таблице есть нестандартные поля (например, столбцы с именами вроде created_time вместо created_at), их тоже можно легко обработать:

Переносим схему БД

Laravel использует механизм миграций для управления таблицами в базе и сиды для внесения данных.

Перенос структуры БД выполняется командой:

Миграция создается в папке database/migrations.

Переносим данные

Если текущая БД уже содержит данные, их можно перенести через сиды: файлы, которые заполняют таблицы данными.

Создаем сид:

Внутри метода run описываем данные:

Переводим бизнес-логику в сервисы и фасады

Старый проект состоит из функционала, размазанного по контроллерам? Улучшим структуру и сделаем код независимым. С этим помогут сервисы и фасады.

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

Например, если проект выполняет расчеты цен и скидок, можно создать класс:

В этом классе описана бизнес-логика:

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

Фасады — это статический интерфейс к сервисам, который делает вызовы более читаемыми.

Например:

С фасадом вызов становится простым:

Шаг 4. Перенос маршрутов и контроллеров

Начнем с маршрутов. Они определяют, как пользователи будут взаимодействовать с приложением.

Если в старом проекте использовались API-запросы для работы с внешними сервисами или мобильными приложениями, перенесем их в api.php и добавим префикс api для маршрутов:

Теперь про контроллеры. Они отвечают за логику обработки запросов и взаимодействие с моделями. В Laravel контроллеры работают по правилам MVC (Model-View-Controller).

Пример обычного метода контроллера:

Laravel определяет маршруты групповыми методами — по префиксам, middleware или зонам авторизации.

Middleware — это посредники, которые обрабатывают запросы до их поступления в приложение.

Навесим middleware на маршруты, требующие авторизации пользователя:

Политики контролируют доступ к определенным ресурсам, например, правку или удаление записей.

Пример метода политики:

Политики можно подключать к маршрутам или напрямую вызывать в контроллерах.

Шаг 5. Перенос фронтенда и представлений

Если ваш старый проект использует обычные HTML-файлы, они легко преобразуются в Blade.

Blade — это встроенный механизм шаблонов. С его помощью создают пользовательские интерфейсы.

Например, перенесем главную страницу сайта:

Blade-версия:

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

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

Интегрируем Vue.js или React

Vue.js/React подключают, когда нужен динамичный и интерактивный интерфейс. Например, для SPA, реалтайм-функционала, сложных форм или фильтров.

Blade и JavaScript можно комбинировать: используйте Blade для рендеринга начального интерфейса и Vue.js/React для обработки интерактива.

Динамический интерфейс без JS

Livewire — это инструмент для создания интерфейсов без необходимости обращаться к внешним библиотекам JavaScript. Преимущество в том, что весь код пишется на PHP.

Livewire пригодится для динамических форм, фильтрации таблиц, уведомлений. Он упрощает код, сохраняя гибкость.

Шаг 6. Оптимизируем и тестируем проект

Отправная точка улучшения производительности — работа с Blade-шаблонами. Laravel сам их оптимизирует, но есть практики по дополнительному ускорению:

• Минимизация логики в представлении. Злоупотребление PHP внутри Blade замедляет рендеринг страниц. Вместо описания сложной логики в шаблонах ее лучше перенести в контроллер.
• Кэширование шаблонов. Работу приложения можно ускорить за счет запуска кэширования всех шаблонов, сокращая время компиляции — «php artisan view:cache».
• Переиспользование. Если фронтенд состоит из повторяющихся фрагментов, рекомендуется использовать Blade-компоненты.

В приложениях SPA оптимизируем фрагменты JavaScript.

Laravel Mix генерирует минифицированные CSS и JS. Проверьте размер этих файлов в папке public/js. Если их вес больше 1 МБ:

• Удалите лишние пакеты.
• Используйте динамическую загрузку маршрутов или компонентов.

Для Vue можно использовать динамическую загрузку, чтобы не грузить весь фронтенд сразу:

Тестирование

Убедимся, что приложение работает корректно.

Проверим, например, что страница приветствия открывается и показывает нужный текст:

Если используете Vue.js или React, для проверки компонентов применяйте Jest или Mocha.

Тест, который проверяет, что компонент отобразил нужный текст:

Если приложение работает с API:

Для проверки приложения под нагрузкой можно использовать Artillery или JMeter.

Шаг 7. Разворачиваем и запускаем проект

Перенесли данные, создали маршруты и контроллеры, внедрили представления, оптимизировали приложение и протестировали его. Остался последний шаг — развернуть проект на сервере и запустить его.

Выбор сервера зависит от предпочтений и нагрузок:

• Если важна скорость и масштабируемость, выбирайте Nginx. Он быстрее работает под высокой нагрузкой.
• Если важен простой подход, используйте Apache. Он интегрируется с большинством систем.

Фоновые задачи можно связать с Supervisor. Инструмент автоматически запускает воркеров при сбоях, обеспечивая бесперебойную обработку задач.

Автоматизация развертывания

Чтобы релиз прошел безболезненно, нужен рабочий процесс CI/CD. Например, в GitHub Actions можно настроить сценарий, который:

1. Проверит качество кода.
2. Установит зависимости.
3. Выполнит миграции.
4. Зальет проект на сервер.

Предусмотрите откат, например, через Spatie Laravel Backup. Если что-то пойдет не так, у вас должна быть возможность вернуть предыдущую версию.

Инструмент Sentry поможет отслеживать ошибки, а New Relic — оценивать производительность.

Заключение

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

На типичные вопросы Junior-разработчик должен легко ответить. Вместе с Альбертом Халимовым, TeamLead Frontend Developer в Группе М.Видео-Эльдорадо и ментором Эйч Навыки, разбираемся в тех же вопросах, но смотрим на них под другим углом и узнаем самое главное — готовы ли быть мидлом.

1. Что такое оператор typeof?

Вызов typeof x возвращает строку с именем типа:

2. Что вернет typeof null, typeof new Date, typeof alert?

Date — это встроенный объект, который содержит дату и время, а также предоставляет методы управления ими.

Результатом вызова typeof null является "object". Это официально признанная ошибка в typeof, берущая начало еще со времен создания JavaScript и сохраненная для совместимости. Конечно, null — не объект. Это специальное значение с отдельным типом.

Вызов typeof alert возвращает "function", потому что alert — функция. Функции относятся к объектному типу. Но typeof обрабатывает их особым образом, возвращая "function". Так тоже повелось с момента создания JavaScript. Формально это неверно, но может быть удобным на практике.

Интересный факт: информация об операторе typeof — это последний пункт главы «Типы данных» на https://learn.javascript.ru/.

3. Что такое NaN? Какого типа это значение? Как можно узнать, равно ли значение переменной NaN?

NaN расшифровывается как "Not A Number", это "false" (ложное) значение. Будьте аккуратны: выражение typeof NaN возвращает тип Number. Чтобы проверить значение переменной на соответствие NaN, нужно воспользоваться встроенным методом isNaN() или оператором тройного равенства ===.

4. Какие есть способы объявления функций? В чем их отличия? Что такое стрелочная функция?

Ниже рассмотрим ключевые отличия Function Declaration от Function Expression.

Во-первых, синтаксис: Function Declaration — функция объявляется отдельной конструкцией function… в основном потоке кода.

Function Expression — функция, созданная внутри другого выражения или синтаксической конструкции. В данном случае функция создается в правой части «выражения присваивания» =:

Более тонкое отличие появляется тогда, когда функция создаётся движком JavaScript. Так, Function Expression появляется в то время, как выполнение доходит до него, и затем уже может использоваться.

После того, как поток выполнения достигнет правой части выражения присваивания let sum = function…, функция считается созданной и может быть использована (присвоена переменной, вызвана и т.д. ).

С Function Declaration всё иначе. Она может быть вызвана раньше, чем объявлена. Другими словами, когда движок JavaScript готовится выполнять скрипт или блок кода, прежде всего, он ищет в нём Function Declaration и создаёт все такие функции. Можно считать этот процесс «стадией инициализации».

Только после того, как все объявления Function Declaration будут обработаны, продолжится выполнение. В результате функции, созданные как Function Declaration, могут быть вызваны раньше своих определений.

Например, будет работать так:

Функция sayHi была создана, когда движок JavaScript подготавливал скрипт к выполнению, и такая функция видна повсюду в этом скрипте.

Если бы это было Function Expression, то такой код вызвал бы ошибку:

Функции, объявленные при помощи Function Expression, создаются тогда, когда выполнение доходит до них. Это случится только на строке, помеченной звёздочкой (*). Слишком поздно.

Ещё одна важная особенность Function Declaration заключается в её блочной области видимости.

В строгом режиме, когда Function Declaration находится в блоке {...}, функция доступна везде внутри блока, но не снаружи.

Для примера давайте представим, что нам нужно объявить функцию welcome() в зависимости от значения переменной age, которое мы получим во время выполнения кода. И затем запланируем использовать её когда-нибудь в будущем.

Если мы попробуем использовать Function Declaration, это не заработает так, как задумывалось:

Это произошло, так как объявление Function Declaration видно только внутри блока кода, в котором располагается.

Вот ещё один пример:

Что можно сделать, чтобы welcome была видна снаружи if? Верным подходом будет воспользоваться функцией, объявленной при помощи Function Expression, и присвоить значение welcome переменной, объявленной снаружи if, что обеспечит нам нужную видимость.

Такой код заработает, как ожидалось:

Или мы могли бы упростить это ещё сильнее, используя условный оператор:

Так когда использовать Function Declaration, а когда Function Expression?

Как правило, если нам понадобилась функция, нужно рассматривать синтаксис Function Declaration, который мы использовали до этого. Он даёт больше свободы в том, как мы можем организовывать код. Функции, объявленные таким образом, можно вызывать до их объявления.

Также функции вида function f(…) {…} чуть более заметны в коде, чем let f = function(…) {…}. Function Declaration легче «ловятся глазами».

…Но если Function Declaration нам не подходит по какой-то причине или нам нужно условное объявление (мы рассмотрели это в примере выше), то следует использовать Function Expression.

5. Что такое функции высшего порядка? Приведите примеры.

Функции высшего порядка — это функции, которые могут:

1. Принимать функции в качестве аргументов.
2. Возвращать функции как результат своей работы.

Вот встроенные функции высшего порядка в JavaScript:

• map() — применяет функцию ко всем элементам массива.
• filter() — фильтрует элементы массива на основе условия.
• reduce() — сводит массив к одному значению, применяя функцию.

6. Что такое Promise и какие бывают состояния?

Promise — объект в JavaScript, который представляет результат асинхронной операции. Промис позволяет обрабатывать результат операции, когда он станет доступным, вместо того, чтобы блокировать выполнение кода и ожидать завершения операции.

Промис может находиться в одном из трех состояний:

• Pending — исходное состояние промиса. Он находится в ожидании выполнения или отклонения операции.
• Fulfilled — промис переходит в это состояние, когда операция успешно завершается.
• Rejected — промис переходит в это состояние, когда операция завершается с ошибкой. Здесь промис возвращает причину ошибки.

Пример:

7. Как сравнивать в JS? Как сравнить два массива?

Когда вы сравниваете примитивные типы (числа, строки, булевы значения и т.д.), используются операторы == (нестрогое сравнение) и === (строгое сравнение).

== проверяет равенство значений после приведения типов.

=== проверяет как равенство значений, так и типов (без приведения типов).

При сравнении массивов в JavaScript важно помнить, что массивы — это объекты, и сравнение происходит по ссылке. То есть два массива будут равны только в том случае, если они указывают на одну и ту же ссылку в памяти.

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

Для более точного сравнения массивов (в том числе с вложенными структурами) можно пройтись по каждому элементу массива с помощью цикла for или методов every/some.

8. Чем отличаются any, unknown и never?

Основные различия:

• any: можно присваивать любые значения, без проверки типа.
• unknown: можно присваивать любые значения, но необходимо проверять тип перед использованием.
• never: тип для значений, которые не могут существовать, например, функции, которые не возвращают ничего.

9. Что такое CORS и как его можно решить на фронтенде?

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

• На фронтенде можно использовать прокси-серверы для разработки.
• В продакшн-окружении необходимо настроить CORS на сервере.
• Если вы не контролируете сервер, то решением будет обращение к разработчикам API или использование серверного прокси для обхода ограничений.

10. Что такое Progressive Web Apps (PWA)? Зачем нужно?

Progressive Web Apps (PWA) — тип веб-приложений, который использует современные веб-технологии для предоставления пользователям опыта, схожего с нативными мобильными приложениями, но через обычный веб-браузер. PWA можно использовать в любом браузере, который поддерживает стандарты веба. Такие приложения могут работать оффлайн, присылать пуши, быстро загружаться и подстраиваться под любой браузер, который поддерживает эти фичи. Из примеров — банковские веб-приложения, которые можно установить на экран.

Вот главные особенности PWA:

• Работа в оффлайн-режиме (Offline-first). PWA используют Service Workers, которые позволяют веб-приложению работать даже без интернета. Это значит, что приложение может кешировать данные и ресурсы, обеспечивая доступность контента в оффлайн-режиме или при плохом интернет-соединении.
• Установка на устройство (Installable). PWA можно устанавливать на устройства как нативные приложения. При этом скачивать их из магазина пользователю не нужно.
• Push-уведомления. PWA могут отправлять push-уведомления — так пользователь может получать информацию, даже если приложение закрыто.
• Обновления. Приложения могут автоматически обновляться в фоновом режиме.
• Мгновенная загрузка. PWA загружаются быстрее, так как они используют кэширование ресурсов и данных через Service Workers — это улучшает производительность даже при медленном интернете.
• Универсальность. PWA работают на всех платформах (мобильные устройства, десктопы, планшеты) и в любых браузерах, которые поддерживают современные веб-стандарты (например, Chrome, Firefox, Safari, Edge и т.д.).

11. Lifecycle во Vue: когда использовать хуки жизненного цикла?

В Vue 2 жизненный цикл выглядит следующим образом:

beforeCreate → created → beforeMount → mounted → beforeUpdate → updated → beforeDestroy → Destroyed

В Vue 3 жизненный цикл был немного изменен и улучшен. Некоторые хуки переименованы:

beforeDestroy → beforeUnmount

destroyed → unmounted

Кроме того, в Vue 3 появилась возможность использовать Composition API, который предоставляет более гибкий способ организации жизненного цикла компонентов. Теперь можно создавать компоненты с помощью функции setup().

Когда использовать хуки жизненного цикла?

• beforeCreate и created используются для настройки данных, свойств или методов компонента до и после его создания.
• beforeMount и mounted полезны для операций, которые необходимо выполнить при рендере компонента (например, вызов API, настройка сторонних библиотек, или выполнение начальной логики).
• beforeUpdate и updated можно использовать для наблюдения за изменениями данных или для манипуляций с DOM до или после его обновления.
• beforeDestroy и destroyed (или beforeUnmount и unmounted в Vue 3) полезны для очистки ресурсов перед уничтожением компонента.

12. В каком компоненте отработает mounted вначале — дочернем или родительском?

В Vue.js хук mounted вызывается для компонента, как только его DOM вставляется в дерево DOM. Когда компонент — часть иерархии (например, родительский и дочерний компоненты), хуки жизненного цикла выполняются в определенном порядке.

Хук mounted будет вызван для дочернего компонента перед родительским.

Объяснение: родительский компонент инициирует рендеринг и монтирование дочернего компонента. Когда Vue монтирует компоненты, он сначала монтирует все дочерние компоненты, а потом родительский компонент. Это связано с тем, что родительский компонент ждет завершения монтирования дочерних компонентов, чтобы их правильно вставить в DOM.

13. Как изменить commit message

1. Изменить последний коммит

Если нужно изменить сообщение только последнего коммита, используйте команду:

git commit --amend

После этого Git откроет редактор, где вы сможете изменить сообщение коммита. Сохраните изменения и выйдите из редактора.

2. Изменить старый коммит

Если нужно изменить сообщение не последнего коммита, а более старого, можно воспользоваться rebase:

git rebase -i <commit_id>

Здесь <commit_id> — идентификатор коммита, сообщение которого вы хотите изменить. Можно использовать git log для получения ID нужного коммита. В открывшемся файле замените слово pick на reword напротив коммита, который хотите изменить, и сохраните файл. Git откроет редактор для изменения сообщения этого коммита. После редактирования сохраните и выйдите.

Завершите процесс rebase:

git rebase --continue

3. Изменить сообщение в уже отправленном коммите (Push)

Если коммит был уже отправлен в удаленный репозиторий, а вы хотите изменить сообщение коммита, то вам нужно будет форсировать пуш.

Измените коммит с помощью git commit --amend или git rebase -i.

После изменения выполните принудительный пуш:

git push --force

Пожалуйста, перед собеседованием повторите CSS. Многие разработчики усиленно готовятся к технической сессии по JS, TS, своему фреймворку, но забывают о верстке. Если вам повезет работать над новым продуктом, то верстка будет занимать больше половины времени.

14. Что такое псевдоклассы в CSS? Как обратиться к псевдоклассу в JS?

Псевдоклассы в CSS — стили, которые применяются к элементам в зависимости от их состояния или структуры в документе.

В JavaScript нельзя напрямую изменить псевдоклассы, но можно использовать селекторы CSS для выбора элементов с псевдоклассами. Это делается с помощью методов по типу querySelector и querySelectorAll.

15. Что такое dvh, lvh, em и rem в CSS? Когда и почему лучше использовать каждую из этих единиц измерения?

Эти единицы были введены в спецификации CSS, чтобы улучшить работу с адаптивным дизайном и обеспечить корректное отображение на мобильных устройствах.

• dvh (dynamic viewport height) — единица измерения, которая учитывает динамические изменения в размерах окна, например, высота при открытии клавиатуры на мобильных устройствах.
• lvh (large viewport height) — единица измерения, которая использует максимальную высоту вьюпорта, независимо от динамических изменений (например, не учитывает изменения, связанные с клавиатурой на мобильных устройствах).

Когда использовать:

• dvh полезен, когда нужно учитывать изменения размера окна при взаимодействии с мобильными устройствами (например, при открытии клавиатуры).
• lvh полезен для работы с мобильными устройствами, когда нужно обеспечить стабильный дизайн, не зависящий от изменения высоты вьюпорта из-за динамических изменений.
• em — это единица измерения, которая зависит от размера шрифта родительского элемента. 1em равен текущему размеру шрифта родительского элемента. Если в родительском элементе установлен шрифт размером 16px, то 1em будет равен 16px.
• rem — это единица измерения, которая зависит от размера шрифта корневого элемента (<html>). 1rem равен размеру шрифта, установленному на корневом элементе (по умолчанию в большинстве браузеров это 16px).

Когда и зачем использовать каждую из этих единиц?

• dvh/lvh: Используйте, если вам нужно учитывать динамическое изменение высоты вьюпорта (например, на мобильных устройствах при открытии клавиатуры) или если вам нужно работать с максимальной высотой вьюпорта, независимо от динамических изменений.
• em: Используйте, когда размеры элементов должны зависеть от размера шрифта родительского элемента. Это полезно для создания гибких и адаптивных макетов, которые изменяются с размером шрифта.
• rem: Используйте, когда нужно, чтобы размеры были относительно размера шрифта корневого элемента. Так проще поддерживать единообразие и легко масштабировать весь интерфейс.

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

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

В нашем обзоре — 10 библиотек JavaScript, которым в 2025 году пора сказать «До свидания». Для каждого продукта из антирейтинга мы подобрали альтернативные варианты.

Фреймворки, которые утратили актуальность в 2025 году

jQuery

Это одна из первых библиотек JavaScript, которая из-за инерционного мышления все еще входит в некоторые списки самых популярных инструментов разработки. Пользователи ценят jQuery за кроссбраузерную поддержку, лаконичный синтаксис и простые алгоритмы взаимодействия с DOM.

Почему прогеры продолжают пользоваться библиотекой? Чисто технически jQuery присутствует во множестве сайтов, сделанных 10-15 лет назад (тогда этот код стал альтернативой VanillaJS). Библиотека создавалась, чтобы сделать язык более гибким и удобным в разработке.

Сегодня многие преимущества jQuery утратили свою актуальность — например, создание кода, работающего на всех браузерах. Теперь платформы стандартизированы, что делает кроссбраузерные решения библиотеки ненужными.

Кроме того, современные нативные API JavaScript серьезно улучшились — для подавляющего большинства задач, которые раньше выполнял jQuery, достаточно ванильного JS. Новейшие методики обеспечивают все манипуляции с DOM и взаимодействие веб -страницы с сервером (AJAX-запросы), поэтому необходимость в библиотеке отпадает.

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

Чем заменить

Нативного API JavaScript в ряде случаев будет достаточно для разработки, а для всех остальных ситуаций есть новые версии высокопроизводительных фреймворков React, Vue и Angular.

Lodash

Когда-то эта универсальная библиотека утилит считалась почти обязательной для каждого проекта на JavaScript. Здесь есть String — функция преобразования для обрезки и переноса в верхний регистр; Object — утилита для расширения и слияния; Array — для сжатия и изменения; многие другие фичи, включая глубокое клонирование объектов и манипуляции с массивами данных.

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

Чем заменить

Сегодня многие функции, представленные в Lodash, есть в новой спецификации JavaScript E56. Оператор spread (…), методы Array (map, reduce, filter и прочие) решают те же задачи, которые некогда решал Lodash. В число главных недостатков библиотеки входит также ее большой вес — импорт всего одной функции увеличивает накладные расходы проекта.

Moment.js

Долгое время эта библиотека была основным инструментом для работы с датами. Ее сильными сторонами были:

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

Сейчас эта библиотека стала слишком тяжелой — даже в мини-формате она занимает 66 КБ, что излишне нагружает устройства, отражается на производительности и быстрой работе UX-функций. Есть более легкие пакеты с теми же функциями.

Чем заменить

Современная альтернатива — date-fns — набор функций для работы с датами на JavaScript, который не входит в библиотеки и работает независимо. Предусматривает модульный импорт — вы можете взять из пакета только то, что требуется для работы, тем самым снижая нагрузку.

Ещё один вариант — Luxon — новая библиотека для работы с датами, созданная командой Moment. Этот инструмент изначально позиционировался как замена предыдущему продукту компании как более мощное, современное и удобное средство. Здесь работа с часовыми поясами реализована без дополнительных расширений, применяется современный подход к написанию кода.

Кроме того, JavaScript Temporal API позволяет работать с датами и временем напрямую, не используя сторонние библиотеки. Поэтому любое из указанных трех решений делает применение Moment.js избыточным и ненужным.

RequireJS

Долгое время библиотека была для JavaScript-разработчиков основным инструментом для управления зависимостями. Технология асинхронного определения модулей (AMD) обеспечивала эффективную асинхронную загрузку файлов. Модульный принцип не использовался в других библиотеках и инструментах, что создавало ощущение эксклюзива.

Это был самый эффективный способ взаимодействия с зависимостями, особенно ценный в работе с большими приложениями. Совместимость со всеми популярными браузерами, включая Firefox, Safari, Chrome, Opera, а также веб-продуктами на Node, была еще одной сильной стороной библиотеки.

С появлением модулей в ES6 RequireJS утратила статус уникального инструмента. В новой спецификации JavaScript реализован нативный способ определения и импорта модулей. Такой подход делает синтаксис более интуитивным, ускоряет и упрощает разработку.

При этом RequireJS в сравнении с более свежими аналогами слишком сложен в настройке и применении. Он требует от прогеров ручной настройки загрузчика и управления путями зависимостей, что повышает риск ошибок и отнимает кучу времени. Современные загрузчики более расторопные и автоматизированные.

Чем заменить

Помимо ES6, с модулями успешно работает сборщик Webpack, компилируя их в единый файл. Это еще более эффективный инструмент, совместимый с TypeScript и Node.js. При запуске программа обрабатывает модули, выстраивает граф зависимостей между ними и на его основе генерирует общий файл.

У этого бендлера есть дополнительные продвинутые возможности — например, разделение кода, горячая замена модулей в реальном времени, а также операция tree shaking (встряхивание дерева), то есть удаление мертвого кода из продукта. Webpack делает работу с зависимостями более рациональной и полностью заменяет тяжелый и устаревший RequireJS.

Backbone.js

Одна из первых библиотек JS (выпущена в 2010), основанная на шаблоне проектирования Model-View-Controller. Предназначена, в основном, для разработки пользовательских интерфейсов и структурирования веб-приложений.

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

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

Кроме того, в Backbone.js нет собственного шаблонизатора, что вынуждает применять другие библиотеки типа Handlebars.js.

Чем заменить

Достойных вариантов замены достаточно. Это React с его архитектурой, основанной на компонентах, и виртуальным DOM. Это и Vue.js с двусторонней привязкой данных и гибкой архитектурой. Это также универсальный Angular с теми же функциями.

Modernizr

Библиотека обнаружения особенностей HTML5 и CSS3 в браузере пользователя. В свое время была крайне полезной и обеспечивала работу приложений в разных браузерах.

С появлением транпислеров (программ, которые переводят части кода с одного языка программирования на другой) необходимость в Modernizr существенно снизилась. Более того, использование этого инструмента чревато увеличением расходов на приложения. Разработчикам приходится задействовать множество тестов на обнаружение функций, что замедляет загрузку.

Чем заменить

Компилятор (транспилер) JavaScript Babel успешно решает задачу преобразования современного кода в формат, совместимый со старыми версиями браузеров. Кроме того, Babel — полифил, то есть способен заполнять пробелы в скрипте с целью добавления новых функций.

MooTools

Объектно-ориентированный фреймворк, некогда популярный и безальтернативный. MooTools содержит комплект утилит для работы с DOM, событиями и AJAX-запросами. Сильными сторонами библиотеки был объектно-ориентированный подход и лаконичный синтаксис. Разрабы, предпочитающие писать элегантный и ясный код, были от MooTools в восторге.

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

Чем заменить

В современной версии Vanilla JavaScript реализована большая часть функций, представленных в MooTools, в том числе методы для работы с DOM и для обработки событий.

Что касается полноценных библиотек, то MooTools без проблем заменят React или Vue.js. Это простые в освоении и использовании прогрессивные фреймворки для разработки пользовательских интерфейсов.

Script.aculo.us

Библиотека визуальных эффектов и методов управления пользовательским интерфейсом. Была популярна у разработчиков, работающих с анимацией и интерактивными опциями в приложениях. Сильные стороны Script.aculo.us — простота в применении, обширный ассортимент возможностей — перетаскивание, сортировка, слайдеры и т.д.

Отсутствие значительных обновлений и большой вес были факторами, которые ослабили позиции Script.aculo.us в сообществе. Если в 2025 году в мире еще остались программисты, которые пользуются этой библиотекой, им точно пора осваивать новые инструменты.

Чем заменить

GreenSock — более мощная, быстрая и универсальная библиотека анимации с огромным выбором эффектов и элементов управления. Работает на стороне клиента и сервера, совместима со всеми браузерами.

Anime.js — еще один гибкий и адаптивный инструмент. Подходит новичкам, поскольку его просто настраивать и легко использовать.

Underscore.js

Библиотека утилит, которая годами удерживала лидирующие позиции в разработке на JavaScript. Эксперты называли ее «швейцарским ножом разработчика» за большой выбор функций и массу возможностей.

Однако с этим инструментом произошло то же, что и другими библиотеками утилит. Большинство функций, которые были представлены в Underscore.js, теперь реализованы в ES6.

Чем заменить

Новая спецификация JavaScript E56+ поддерживает методы функционального программирования, позволяет манипулировать объектами и массивами данных. Таким образом, все функции Underscore.js доступны непосредственно на JavaScript без всяких посредников. Вывод — переносите код на E56+, он станет чище и проще в поддержке.

Axios

Библиотека для отправки запросов HTTP из браузера или Node.js. Поддерживает множество методов запросов (Get, Put, Delete и другие), загрузку и отправку файлов. Сильные стороны — удобный интерфейс, поддержка Promise API (способ организации асинхронного кода).

Несмотря на популярность Axios и его относительную свежесть, эта библиотека стремительно теряет позиции, поскольку появились новые инструменты с более расширенным функционалом.

Чем заменить

Fetch API превосходит конкурента по простоте и гибкости. Он выполняет те же задачи, но оснащен дополнительными функциями — потоковой передачей, отменой запросов, улучшенной обработкой ошибок.

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

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

Делитесь в комментариях, на какие библиотеки перешли! Ну а если хотите детальнее разобраться во всех аспектах Java и JavaScript, заходите в наш тг-канал.

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

Фреймворки и библиотеки для разработки интерфейсов

Создание фронтенда, то есть клиентской части программного продукта — неотъемлемый этап разработки сайтов и приложений. Фронтендеры работают с с HTML, CSS, JavaScript, а также используют многочисленные библиотеки с готовыми решениями. Даже новички в курсе, что без фреймворков проекты сегодня не пишутся — это долго, тяжело и непродуктивно. Ниже — наиболее эффективные фреймворки для разработки UI.

React.js

Созданная Джорданом Валке, ведущим программистом самой известной в мире соцсети, библиотека React остается лидером в сфере разработки инфраструктуры на JavaScript UI. На React.js написаны такие проекты, как Skype, PayPal, Airbnb, Dropbox и многие другие.

Популярность библиотеки объясняется вполне объективными причинами:

• Обширное комьюнити. Только на GitHub вы найдете больше 110 тыс. публикаций с тегом «react». Библиотекой пользуются во всем мире, а тысячи профессиональных программистов постоянно обновляют инструменты и актуализируют данные. Если у разработчика появится вопрос, он обязательно найдет на него ответ в сообществе.
• Технологический бэкграунд. Библиотеку создали профи из FB для себя — такие проекты делаются максимально качественно и надежно. Тот факт, что технологии доверяют крупнейшие мировые корпорации, говорит сам за себя.
• Активное взаимодействие с TypeScript. Этот инструмент представляет собой продвинутую версию JS, который со временем стал слишком тяжелым в плане кода. TypeScript лишен многих недостатков Java, поэтому активно применяется в React.js. В общем, в 2025 году фреймворк точно не умрет.
• Версионность. В React, в отличие от Angular или Vue, код, написанный даже несколько лет назад, без проблем запустится на новейшей версии. А если там есть неактуальный элемент, программа сама подскажет, как его исправить.

В React 19 появились новые, еще более мощные компоненты, повышающие производительность и пользовательский опыт:

• Улучшенная поддержка Server Components, с которой более удобно работать с серверным рендерингом и загружать контент в больших проектах;
• Новый API — Actions, который делает более простой и продуктивной работу с формами и интерактивными элементами;
• Директивы preload и preinit обеспечивают предварительную загрузку важных ресурсов, что ускоряет работу приложений;
• Новый канал релизов React Canaries позволяет протестировать некоторые опции React еще до их официального выпуска.

Улучшения произошли и в экосистеме React. Упрощается работа с Redux — библиотекой, которую все чаще используют в связке с React. Инструменты для работы с таблицами и интерфейсами React Table 8 более доступны и производительные.

Vue.js

Еще один мощный, но при этом простой и гибкий в применении инструмент для фронтенд-разработчиков — Vue.js. Согласно экспертным прогнозам, он сохранит свои позиции в топе-3 фреймворков для JavaScript в 2025 году.

Относительно недавно создатели Vue радикально обновили движок и архитектуру. При этом доля TypeScript кода в репозитории приближается к 99%, что расценивается профессиональными прогерами крайне позитивно.

Команда разработчиков Vue.js, возглавляемая Эваном Ю, в свое время заявила, что фреймворк станет самым простым и удобным инструментом из всех существующих. По мнению экспертов, их слова полностью подтвердились.

В числе главных преимуществ фреймворка:

• Подходит для новичков. Для освоения достаточно знания HTML, CSS, JavaScript;
• Небольшой вес. Размер новой заархивированной библиотеки runtime меньше 10 kb;
• В пакет входит виртуальный DOM — объектная модель документа;
• Активное крутое сообщество. Профессионалы помогут, если у разработчика возникнут проблемы.

Количество полноценных приложений, сделанных на Vue.js, превышает 36 тысяч. Это число постоянно растет, и в 2025 году тренд обязательно продлится. В экосистему внедряются новые технологии, например, Vapor Mode, — инструмент, открывающий новые горизонты для разработки высокопроизводительного софта.

Подход, заданный Composition API, позволяет создавать компоненты через импорт функций вместо обновления опций. На выходе получаем более чистую архитектуру, что особенно важно для продуктов со сложной логикой.

Появление высокоуровнего фреймворка Nuxt 4 принесет важные улучшения в плане производительности и гибкости разработки. Поддержка Vue 3.3+ в Nuxt 4 улучшает работу с анимацией и межкомпонентные переходы. Пользовательский интерфейс становится более динамичным и плавным.

На фреймворке Vue созданы сайты Ozon, Zoom, Chess (сайт для шахматистов с посещаемостью 20 млн пользователей в месяц), Livestorm — платформа для запуска вебинаров, и многие другие ресурсы.

Angular

Этому мощному фреймворку доверяет Google, что уже говорит само за себя. Множество десктопных и мобильных приложений создано на AngularJS — это крутой инструмент с минимальным риском критических ошибок. На сайте фреймворка создатели призывают разработчиков сосредоточиться на приложениях, а код Angular берет на себя.

И хотя профи считают этот фреймворк более сложным в освоении, чем Vue и React, его функциональность оправдывает все трудности учебного процесса. В 2025 году эволюция Angular продолжится: его последние версии показывают существенные изменения в подходах к реактивности ПО и управлению состоянием.

Новые решения, на которые стоит обратить внимание:

• К числу ключевых нововведений фреймворка относится технология Signals, которая делает взаимодействие с реактивными данными более простым. «Сигналы» актуальны в том случае, когда требуется синхронное обновление UI и оптимизация производительности приложения.
• В Angular 19 компоненты Standalone стали новым стандартом. Теперь они могут использоваться без добавления в модуль. Такое решение упрощает архитектуру приложений и делает подход к коду более прямолинейным.
• Внедрение зависимостей (DI, Dependency Injection) дополнено новой функцией inject() — она заменяет стандартный конструктор, что также упрощает код и делает его более гибким.
• Автоматическая миграция продуктов к новому API — еще один шаг к упрощению и сокращению кода. Это напрямую отражается на производительности современных приложений, в первую очередь, на больших и логически сложных.

Прежние плюсы Angular остались неизменными — расширяемость, взаимодействие с другими фреймворками и инструментами, множество надстроек и дополнений — Auto Validate, Complete, Grid и т.д.

На фреймворке написан сайт британской газеты The Guardian, интерактивные элементы PayPal, самый посещаемый сайт мониторинга погоды Weather.com, фронтенд музыкального ресурса VEVO и многие другие продукты.

Svelte

В свое время фреймворк предложил принципиально новый подход к разработке пользовательских интерфейсов. Концепция создателей Svelte — делать больше с минимальными затратами. Некоторые разработчики считают Svelte больше компилятором, чем фреймворком, что по сути соответствует действительности.

В чем основные фишки Svelte:

• При меньшем весе проекты более производительны — им не требуется виртуальный DOM;
• Фреймворк прост в освоении, поэтому подходит начинающим разработчикам;
• Опытные прогеры обращают внимание на быстроту и стабильность инструмента;
• Анимации в Svelte доступны прямо из коробки — сторонние библиотеки не требуются.

На текущем этапе этот фреймворк рано ставить на одну ступень с React и Vue, но его рейтинг на GitHub постоянно повышается, и в 2025 году растущий тренд точно сохранится.

Фронтенд-разработкой с фреймворком Svetle пользовались такие компании, как Spotify, Ikea, Finance.yahoo, Music.apple и многие другие.

Solid.js

Минималистичный фреймворк, который по производительности и быстроте превосходит все остальные фреймворки из топа. Solid напоминает React, но вместо виртуального DOM использует компиляцию. Проект без проблем компилируется в JavaScript-код, что обеспечивает быстрый рендеринг страницы (трансформацию кода в картинку для пользователя).

В чем плюсы:

• Тонкая реактивность обеспечивает оптимизацию рендеринга в реальном времени;
• Есть бесшовная интеграция со всеми актуальными библиотеками на JS;
• Компоненты фреймворка — стандартные JavaScript-функции: они выполняются однократно для настройки представления, после чего автоматически обновляют интерфейс.

Solid.js, по состоянию на 2025, — идеальный инструмент для одностраничных приложений и продуктов с максимальной интерактивностью (чат-ботов, мессенджеров, панелей управления).

Фреймворк используют такие ресурсы, как 1c.ru, криптовалютная биржа Ape.pro, маркетплейс Майнкрафт Waypoint Studios и другие.

Инструменты для сборки и разработки

По мнению большинства экспертов, в 2025 году ведущим трендом в сборке и разработке на JavaScript будет работа с универсальными мета-инструментами, совместимыми с любыми фреймворками.

Топ наиболее эффективных инструментов этого направления:

• Vite. Локальный сервер разработки от Эвана Ю. В новой версии Vita 6 возможности существенно расширились, в том числе в плане поддержки других фреймворков, помимо Vue. Благодаря модульной архитектуре и новой системе плагинов, улучшилась кастомизация сборки (процесс внесения изменений). С Vite можно использовать несколько фреймворков в одном проекте — для сложных приложений это актуальная опция. Обновления в реальном времени происходят быстро и стабильно.
• Webpack. Сборщик модулей, который компилирует части кода в единый файл. Работает с JavaScript и TypeScript. Несмотря на появление новых инструментов сборки, в 2025 году Webpack останется обязательным инструментом, особенно для работы с масштабными проектами. Он оптимизирует размер и скорость загрузки ресурсов, эффективно выстраивает процессы разработки, в том числе HMR — горячую замену модулей. Плюс обеспечивает совместимость продуктов с различными версиями браузеров.
• Parcel. Главная фишка этого инструмента в том, что его не нужно настраивать и конфигурировать — это делается автоматически. Parcel применяет воркеры — скрипты для многоядерной компиляции, и содержит кэш файловых систем для ускоренной сборки. Есть поддержка из коробки JS, CSS, HTML, поэтому соответствующие плагины не требуются. Модули, которые меняются в процессе разработки, обновляются автоматически.

Тестирование и отладка

В 2025 году в тестировании и отладке продуктов наиболее востребованы следующие инструменты:

• Jest. Самый популярный фреймворк для тестирования кода на JavaScript. Работает с синхронным и асинхронным кодом, интегрируется с React и Vue. В числе основных плюсов — простая настройка и удобное применение. Подходит для проверки и отладки сложных приложений.
• Cypress. Инструмент для автоматизации тестирования, который подходит новичкам. Использует тест end-to-end, покрывая весь путь пользователя, и внедряется в CI/CD — процессы непрерывной доставки и развертывания. Благодаря подробной документации подходит для новичков.
• React Testing Library. Библиотека эффективных инструментов для тестирования пользовательских интерфейсов UI. RTL позволяет абстрагироваться от внутренней логики компонентов и проверяет состояние реального DOM, то есть имитирует действия пользователей, руководствуясь только данными браузера.
• Storybook. Позиционируется как максимально простое средство тестирования и разработки. Создает изолированную программную среду для ускоренного и эффективного процесса.

Инструменты для контроля версий

Актуальные в 2025 средства для контроля созданных разработчиками версий:

• Git. Распределенная VCS (система управления версиями) отслеживает изменения в исходном коде и файлах в совместных проектах. Позволяет править и контролировать версии в процессе разработки. Обладает расширенными возможностями работы с репозиториями.
• GitHub/GitLab. Службы управления репозиториями, которые используются и для управления изменениями в опенсорс-проектах. Оба репозитория обладают полным набором инструментов для контроля и интеграций, обеспечивая эффективную совместную разработку и неограниченное сотрудничество. Обладают встроенными опциями безопасности, которые разработчики могут в любой момент активировать.
• Bitbucket. Аналог GitHub с бесплатным доступом к контролю команды до пяти разработчиков. Подходит для написания частных проектов, обладает гибкостью, совместим со множеством других инструментов, в том числе с Jira, — средой для управления проектами. Интеллектуальный семантический поиск JQL сканирует код по запросу пользователя.

CSS-процессоры и CSS-фреймворки

Инструменты для первичной трансляции кода, актуальные в 2025 году:

• Sass. Препроцессор упрощает написание кода, исключая одинаковые участки или заменяя ключевые элементы синтаксиса одним знаком. Sass считается самым надежным языком расширений CSS, содержит средства импорта и множество других функций.
• Less. Этот препроцессор поддерживает CSS и позволяет разработчикам применять его методы для улучшения и дополнения веб-приложений. В Less встроены логические, строковые, математические функции, а также функции списков.
• Bootstrap. Классический фреймворк для ускоренной верстки со множеством встроенных компонентов. Более 20% всех сайтов в мире создано с его помощью. Автоматически выстраивает адаптивную сетку на базе Flex-модели, создает изображения, поставляется с панелями навигации и другими компонентами.
• Tailwind CSS. Фреймворк, который пользователи называют прогрессивной версией Bootstrap. Содержит обширный каталог утилитарных классов и инструментов для прототипирования, стилизации сайтов и приложений. Легко настраивается, работает с собственными служебными шаблонами, создает сложные адаптивные макеты, в том числе с ориентацией под мобильные устройства.

Инструменты для работы с API и серверной логикой

Эффективная работа с API обеспечивает надежность при обработке информации в приложениях.

В 2025 году топ таких инструментов выглядит следующим образом:

• GraphQL. Язык, описывающий взаимодействие клиента с сервером. Рассматривается как альтернатива стандартного инструмента REST. В сравнении с последним, более удобен в применении, содержит обширный инструментарий.
• Apollo Client. Язык запросов, созданный разработчиками FB. Интегрируется с GraphQL и React для управления состоянием приложения. Предоставляет эффективные инструменты в виде поддержки кэширования, управления состоянием и исправления ошибок. Интегрируется с библиотекой Redux и другими фреймворками.
• Axios. JS-библиотека для работы с HTTP-запросами, а по сути — клиент для работы в браузере и с платформой Node.js. Помогает настроить взаимодействие между frontend и backend.

UI и UX-дизайн

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

Эти инструменты сохраняют свою актуальность в 2025 году:

• Figma. Графический редактор, который остается самым популярным инструментом для проектирования интерфейсов, прототипирования и тестирования. Также это среда взаимодействия команды разработчиков, доступная непосредственно в браузере. Содержит удобные инструменты, может работать в режиме многозадачности.
• Adobe XD. ПО для работы с интерфейсами, анимированием, прототипами сайтов, сервисов и приложений от лидера индустрии. Основной инструмент UX-дизайнеров, желающих создавать юзабельные и современные макеты и делиться результатами работы с командой. Содержит многочисленные инструменты для рисования, создания 3D-эффектов, добавления интерактивных функций и анимации.
• Sketch. Выбор многих профессионалов индустрии UI/UX дизайна. Упрощает разработку интерфейсов благодаря множеству встроенных полезных функций — артбордов, редакторов, поддержкой командной работы в режиме онлайн. Работает только с macOS.

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

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

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

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

Узнаем, есть ли альтернативы у фреймворка Vue, каковы его особенности и преимущества и как использовать Vue.js с максимальной эффективностью.

Что такое Vue.js и зачем он нужен

Разработка современных интерфейсов и веб-приложений практически невозможна без фреймворков. Эти инструменты используются для оптимизации процессов и включают в себя наиболее востребованные сценарии и функции. Vue.js стабильно входит в рейтинг лучших фреймворков и широко используется крупными компаниями для разработки своих продуктов.

Vue создан программистом из Google Эваном Ю в 2012 году — это был его пет-проект, то есть продукт для личного пользования, которым он занимался в свободное от основной работы время. Доступной для широкой публики технология стала только в 2015 году.

Эван Ю решил разработать этот фреймворк после того, как попытался поработать с Backbone.js и Angular — инструментами аналогичного назначения. Их функциональные возможности показались программисту недостаточными.

Когда коллега Эвана по ИТ-отрасли Тейлор Отвелл, создатель другого популярного продукта Laravel, заявил в соцсети, что изучает Vue, считая его более удобным, чем другие инструменты, популярность фреймворка кратно возросла. Другие разработчики стали активно использовать Vue.js для разработки пользовательских интерфейсов.

Интересный факт. Название фреймворка происходит от английского слова «view» в переводе на французский язык, что указывает на связь модели и отображения.

Это бесплатный опенсорс-проект (с открытым кодом), которым могут пользоваться все желающие. Улучшением и доработкой компонентов Vue занимаются программисты всего мира — у фреймворка очень обширное и доброжелательное сообщество. Несколько лет подряд Vue.js даже держался в топе на GitHub по количеству звезд. И в 2025 году популярность фреймворка все еще остается высокой.

Сферы применения Vue

Востребованность Vue.js объясняется его широкой сферой применения. Фреймворк используется для разработки:

• быстрых сайтов и веб-приложений;
• веб-ресурсов с повышенной нагрузкой — онлайн-магазинов, информационных порталов;
• лендингов — одностраничных сайтов с интерактивным содержанием;
• социальных сетей, сервисов CMS и других;
• адаптивных интерфейсов;
• личных кабинетов и страниц пользователей;
• интерфейсов для авторизации, интерактивных чатов, форм заявки и прочих функциональных блоков.

Vue пользуется популярностью не только в среде рядовых пользователей, но и в профессиональном сообществе. Продуктом пользуются такие компании, как Alibaba, EuroNews, Zoom, Ozon, Xiaomi и многие другие. Фреймворк считается одним из самых перспективных и адаптивных — новые версии выходят регулярно.

Многие компании используют Vue.js в своих внутренних проектах. Например, такие гиганты индустрии как Apple и Google в качестве основных инструментов разработки применяют другие фреймворки, но периодически привлекают и разработчиков на Vue.js. Компания Яндекс в основном пользуется React, но проект «Едадил» полностью сделан на Vue.

Основные преимущества Vue

Список плюсов у фреймворка довольно внушительный.

Реактивность

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

Декларативность

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

Низкий порог входа

Если вы знакомы с JavaScript, знаете основы CSS и HTML, вы без труда освоите Vue. Концепции фреймворка просты для понимания: программисты пишут код уже на первых неделях освоения.

Подробная документация

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

Обширное сообщество

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

Небольшой вес

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

Простое внедрение

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

Более того, ядро на Vue.js можно без труда внедрить в действующий проект, созданный на другом фреймворке. Сайт продолжит работу, а его модули можно переписывать постепенно без остановки проекта.

Минусы

Несмотря на многочисленные плюсы, Vue.js, как и любая другая технология, несовершенна. Опытные разработчики выделяют следующие недостатки.

Сложности в освоении при углубленном изучении

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

Производительность

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

Совместимость

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

Как развивается Vue

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

Эксперты выделяют ряд трендов в развитии фреймворка:

• Дальнейшая поддержка TypeScript. Этот язык программирования был создан с целью расширить возможности Java. Интеграция с Vue.js открывает новые перспективы для разработчиков.
• Оптимизация производительности. Ведутся работы по ускорению приложений на фреймворке и повышению эффективности, что крайне важно для пользовательского опыта.
• Работа над API. Предложены более гибкие варианты организации кода, что облегчает его сопровождение и повторное применение.
• Расширение экосистемы. Библиотека плагинов пополняется новыми продуктами и инструментами — участники сообщества постоянно работают над обогащением ресурсной базы разработчиков.
• Ориентация на инновации. Используются новейшие решения для работы над сложными проблемами.

Сейчас разработчики применяют версии Vue 3.0 и 3.5. Эти продукты по ряду параметров превосходят предыдущие итерации:

• Улучшенная реактивность. Фреймворки нового поколения внедряются в действующие проекты еще быстрее и потребляют меньше ресурсов.
• Упор на Composition API. Инновационный подход к организации компонентов фреймворка — отличный способ распространять логику приложения на другие продукты. Такая схема существенно упрощает повторное использование кода.
• Применение Vue CLI — полноценной системы для ускорения разработки. Обеспечивает бесперебойную работу компонентов сборки, отвечает за настройку приложения и быстрое прототипирование.
• Быстрота и мощность. Новые версии проще использовать для нативных приложений за счет модульности и оптимизации библиотек (автоматического удаления лишнего кода).
• Повышенная производительность рендеринга — преобразования трехмерных образов из программ в изображения, которые видит пользователь.
• Более эргономичный синтаксис. Экономия ресурсов и времени, потраченного на разработку.
• Внедрены новые алгоритмы для сравнения виртуального DOM с «настоящим», что ускоряет рабочие процессы.

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

Альтернативы и конкуренты: сравнение Vue с другими фреймворками

Ближайшие конкуренты Vue — это React, Angular, Svelte. Рассмотрим альтернативные фреймворки в сравнении с Vue.js.

Vue.js vs React

Библиотека с открытым кодом React — не менее популярный инструмент для разработки, чем Vue. Технически ее нельзя назвать полноценным фреймворком, при этом выбор решений для создания сайтов и веб-приложений довольно обширный.

Спор о том, что лучше, Vue или React, ведется уже несколько лет — стороны до сих пор не пришли к консенсусу. Оба инструмента обладают гибкой архитектурой, высокой производительностью, обширным функционалом. У каждого обширное сообщество пользователей, готовых привести сотни аргументов в защиту своего выбора.

Однако руководствоваться стоит исключительно объективными различиями:

• Изучение React занимает больше времени. Это факт, с которым согласны обе стороны. Если вы новичок в разработке, вам больше подойдет Vue — он проще по синтаксису, его концепция более понятна.
• Различный подход к реактивности. В React такие сайты создаются через виртуальный DOM — это усложняет изменение исходного хода. В Vue программист может работать с DOM напрямую, что ускоряет процесс изменений и упрощает работу программиста.
• Vue лучше взаимодействует со сложно-синхронизированной анимацией. Это фреймворк более удобен для дизайнеров, которые могут виртуально представить шаблон. В React это реализуется только через JSX. Но зато такой код короче, что в некоторых ситуациях тоже важно.
• Документация. У Vue она более подробная, со множеством ответов на сложные вопросы. Однако React компенсирует этот недостаток за счет более обширного сообщества, в котором можно найти ответ на любой вопрос.

В числе преимуществ React — наличие совместимой с библиотекой платформы React Native, которая позволяет создавать кроссплатформенный мобильный софт на Android и iOS. В экосистеме Vue специальных продуктов для разработки приложений для смартфонов нет.

Vue.js vs Angular

Разработка компании Google для одностраничных веб-приложений Angular работает на Java, TypeScript, Dart. Как и Vue.js, это фреймворк с открытым исходным кодом с репозиторием на GitHub.

Ключевые отличия Angular и Vue.js:

• С помощью Angular пишут код, который можно легко адаптировать под другие среды — например, для мобильных ОС. В Vue такие задачи реализовать гораздо сложнее.
• При этом Vue.js более гибок в применении. Его можно использовать как дополнительный инструмент для создания отдельных модулей. Angular потребуется внедрять целиком в весь проект.
• Как и в случае с React, обучение на Vue проще. Angular требует более глубоких познаний в программировании, сам процесс освоения и внедрения в практику занимает больше времени.
• Angular использует ajax — встроенную технологию взаимодействия с сервером без необходимости перезагружать страницу. Это упрощает передачу и получение данных. Реализован и механизм маршрутизации. В Vue эти функции реализуются только через сторонние библиотеки.
• Vue больше подходит для динамических веб-продуктов, ориентированных на UI/UX и пользовательские интерфейсы.

Выбор между фреймворками во многом зависит от целей и задач программиста, а также особенностей самого проекта. Для корпоративных и масштабных проектов Angular считается лучшим выбором, но у Vue преимущество в скорости и простоте применения.

Vue.js vs Svelte

Фреймворк Svelte использует иной подход к разработке веб-интерфейсов, нежели React и Vue. У него другая организация кода и свой алгоритм реализации проектов.

Ключевые отличия Vue.js и Svelte:

• Реактивность в Svelte стала частью языка. С этим фреймворком обновлять контент при изменении состояния гораздо проще.
• Svelte превосходит другие фреймворки по скорости и легкости. Поскольку логика обновлений полностью перемещена в код, нет необходимости использовать Virtual DOM, что делает приложения более быстрыми.
• Сообщество Svelte не такое обширное, поэтому у малоопытных прогеров могут возникнуть проблемы с решением необычных задач.
• Документация у Vue.js тоже более подробная. У Svelte доки лаконичные и содержат только основную информацию о функционале.

В целом Svelte менее популярный фреймворк, поскольку проект относительно молодой и пока больше распространен в профессиональной среде, нежели в любительской.

Итоги

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

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

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

Frontend фреймворки

React

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

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

React обращается к DOM только для обновления изменившихся компонентов. За счет этого повышается производительность приложения.

Пример простого React компонента:

Преимущества фреймворка:

• Облегчает повторное использование кода и поддержку приложений;
• Имеет множество дополнительных библиотек и инструментов;
• Виртуальный DOM снижает прямые манипуляции с DOM и повышает производительность приложения;
• Фреймворк пользуется популярностью в сообществе. Как результат  —  множество учебников, разборов документации и сторонних библиотек.

Недостатки фреймворка:

• Концепции JSX и управления состоянием могут быть сложны для новичков;
• Плохая кроссбраузерная поддержка;
• Требует дополнительных библиотек для маршрутизации и управления состоянием.

Vue.js

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

Преимущество Vue в его простоте и низком пороге входа. При этом фреймворк сохраняет статус мощного инструмента для разработки сложных веб-приложений.

Vue автоматически отслеживает зависимости между блоками и обновляет DOM при их изменении, как React.

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

Пример простого компонента Vue:

Экосистема Vue включает множество библиотек и плагинов, расширяющих возможности фреймворка. Например, Vuex для управления состоянием, Vue Router, Nuxt.js и другие.

Преимущества фреймворка:

• Понятный синтаксис и подробная документация;
• Может использоваться как библиотека или цельный фреймворк в зависимости от проекта;
• Есть поддержка серверного рендера;
• Автоматически обновляет интерфейс при изменении данных;
• Имеет небольшой вес файлов.

Недостатки фреймворка:

• Меньше ресурсов и сторонних библиотек по сравнению с React и Angular;
• Неполная документация на русском языке.

Angular

С помощью Angular разрабатывают клиентские части веб-приложений. Этот фреймворк сложнее Vue и React.

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

По аналогии с Vue и React, фреймворк разбивает приложение на независимые, переиспользуемые блоки кода. Компоненты: шаблон; класс, описывающий поведение; стили.

Освоение Angular требует больше времени и усилий по сравнению с Vue и React из-за архитектуры и специфических концепций. Нужны углубленные знания по внедрению зависимостей, декораторам и модулям.

Пример простого Angular-компонента:

Преимущества фреймворка:

• Богатый выбор инструментов, шаблонов, которые сокращают сроки реализации сложных приложений;
• Angular CLI расширяется за счет shematics, поэтому его легко доработать под конкретные задачи;
• Есть поддержка TypeScript: статическая типизация улучшает качество кода;
• Встроенная утилита для обновления проекта при переходе на новую версию Angular.

Недостатки фреймворка:

• Ангуляр сложнее, чем Вью и Реакт. Его изучение занимает больше времени, если это первый фреймворк в карьере разработчика.

Backend фреймворки

Django (Python)

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

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

Django следует архитектурному шаблону Model-View-Controller (MVC). Модели определяют структуру данных, представления обрабатывают логику и взаимодействие с моделями, а шаблоны отвечают за представление данных пользователю.

Сильная сторона Django — его ORM (Object-Relational Mapping). Интерфейс для работы с базой данных на Python используется для написания сырых SQL-запросов. Django поддерживает PostgreSQL, MySQL, SQLite, Oracle.

Если ищете универсальный фреймворк для бэкенд-разработки на Python, Django определенно заслуживает вашего внимания.

Пример модели Django:

В примере определяем модель Article с полями title, content и published_at. Метод __str__ возвращает строковое представление объекта:

Представление article_list получает объекты Article из базы данных и передает их в шаблон для отображения.

Преимущества фреймворка:

• Широкий набор инструментов: включает ORM, аутентификацию и админ-панель;
• Фреймворк задаёт структуру проекта — помогает разработчикам понимать, как и где добавлять новую функцию;
• Защищен от SQL-инъекции и подделки межсайтовых запросов;
• Подходит для высоконагруженных приложений.

Недостатки фреймворка:

• Django ORM уступает последней SQLAlchemy.

Ruby on Rails (Ruby)

Rails подходит для быстрого прототипирования и проектов, ориентированных на работу с базами данных. Его используют для SaaS-платформ, CRM-систем, CMS, маркетплейсов и многого другого.

Rails применяет архитектурный паттерн MVC (Model-View-Controller). Фреймворк хорош с точки зрения бизнес-логики и взаимодействует с базой данных с помощью ActiveRecord ORM.

Rails поставляется со встроенными инструментами и библиотеками. Например, ActiveRecord для работы с базами данных, ActiveStorage для управления файлами, ActionMailer для отправки email.

В сообществе Rails огромное количество гемов (библиотек), расширяющих функциональность фреймворка.

Пример модели Rails (с использованием ActiveRecord):

Пример контроллера Rails:

В примере определяем модель Article с валидациями и связями. Контроллер ArticlesController содержит экшены для списка статей, отображения отдельной статьи, создания новой статьи. Приватный метод article_params используется для фильтрации параметров.

Преимущества фреймворка:

• Продуманная структура, которая продвигает стандарты качества и лучшие практики веб-разработки;
• Active Record ORM упрощает взаимодействие с базой данных;
• Vue, Angular.js и React легко интегрируются с Ruby on Rails.

Недостатки фреймворка:

• Ruby on Rails js медленнее Django и Node.js.

Node.js с Express (JavaScript)

Express — фреймворк Node.js с набором функций для разработки веб-приложений и API. В нем реализован простой интерфейс для HTTP-запросов и маршрутизации.

Node.js + Express используется для сервисов, серверных приложений (например, чатов или игр).

Преимущество Node.js и Express состоит в возможности писать на JavaScript как клиентскую, так и серверную сторону. Можно вести разработку на одном языке и делиться кодом с фронтендом и бэкендом.

Пример простого приложения на Express:

Преимущества фреймворка:

• JavaScript на всем стеке — один язык для фронтенда и бэкенда;
• Имеет минимальные ограничения, можно строить архитектуру как удобно.

Недостатки фреймворка:

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

Full-Stack фреймворки

Laravel (PHP)

Laravel — фреймворк для веб-разработки на PHP. Он использует архитектуру MVC: разделяет логику приложения и улучшает организацию кода.

Laravel выбирают для разработки CMS, SaaS-платформ, электронной коммерции и др. Встроенные библиотеки ускоряют работу.

В фреймворке реализована:

• Система миграций для управления структурой базы данных;
• Eloquent ORM для работы с данными;
• Система шаблонизации Blade;
• Встроенная поддержка аутентификации и авторизации;
• Очередь заданий и планировщик для выполнения асинхронных задач.

Пример определения маршрута в Laravel:

Пример контроллера Laravel:

Пример модели Eloquent:

В примерах выше определяем маршрут, который принимает id и возвращает строку с идентификатором. Контроллер UserController методом show получает пользователя из базы данных по id и передает его в представление user.profile. Модель User представляет таблицу пользователей в базе данных и определяет заполняемые атрибуты.

Преимущества фреймворка:

• Шаблонизатор Blade упрощает создание представлений;
• ORM Eloquent облегчает работу с базами данных;
• Есть автоматизация задач с помощью встроенных инструментов и командной строки.

Недостатки:

• Сложности с долгосрочной поддержкой версий.

Spring Boot (Java)

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

Фреймворк имеет встроенный контейнер сервлетов (Tomcat, Jetty), чтобы запускать приложение как автономный JAR-файл без развертывания на внешнем сервере.

Фреймворк также предлагает:

• Автоконфигурацию библиотек (JPA, JDBC);
• Встроенные метрики мониторинга;
• Поддержку внешней конфигурации;
• Интеграцию с базами данных.

Преимущества фреймворка:

• Есть встроенные серверы Tomcat, Jetty и Undertow;
• Облегчает управление зависимостями с помощью стартовых пакетов;
• Оснащен встроенным контейнером сервлетов;
• Автоматическая конфигурация экономит время на старте проекта.

Недостатки:

• Spring Boot создает множество неиспользуемых зависимостей и увеличивает размер файла развертывания.

Meteor (JavaScript)

Особенность Meteor в том, что он синхронизирует данные в реальном времени. Фреймворк автоматически обновляет пользовательский интерфейс при изменении данных на сервере. Это возможно благодаря протоколу DDP (Distributed Data Protocol) и реактивным источникам данных, таких как MongoDB.

На JS + Meteor можно писать код, который работает как на клиенте, так и на сервере. Фреймворк также предоставляет интегрированную систему сборки, которая автоматически объединяет ресурсы приложения.

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

Преимущества фреймворка:

• Архитектура и синтаксис с понятным кодом упрощают обучение новичков и повышают производительность команды;
• Есть мгновенная синхронизация данных между клиентом и сервером;
• Возможна интеграция базы данных MongoDB.

Недостатки фреймворка:

• Не предлагает широкого функционала для масштабирования и разделения логики на модули;
• Сложности с масштабированием при увеличении числа пользователей из-за обработки данных в реальном времени.

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

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

Узнаем, какие фреймворки JavaScript наиболее востребованы для разработки в 2025 году, каковы их сильные стороны и особенности, и как правильно выбрать продукт для своего проекта.

Преимущества фреймворков

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

В числе основных преимуществ фреймворков для разработки:

• Эффективность. Применение уже готовых функций шаблонов повышает качество разработанных проектов. Программисты пишут меньше кода, он более чистый, а сама задача выполняется оперативнее.
• Стоимость. Разработка веб-приложений обходится дешевле за счет сокращения ресурсов, при этом фреймворки JavaScript доступны всем желающим.
• Скорость. У большинства фреймворков JavaScript отличная документация, в которой подробно описана работа всех функций. По каждому продукту существует обширная группа поддержки, работает множество форумов для профи и любителей. Все это предоставляет разработчикам массу дополнительной информации, что упрощает задачу.
• Масштабирование. При необходимости дальнейшего развития программных продуктов фреймворки JavaScript используются для их адаптации под более широкую аудиторию пользователей или дополнительные опции.

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

React

Когда профессиональные разрабы говорят о лучших фреймворках JavaScript, они обязательно называют в первых рядах React. По сути не совсем фреймворк, а обширная библиотека, предназначенная для создания наиболее сложных пользовательских интерфейсов для веб- и нативных приложений. В 2025 году React остается в топе актуальных инструментов отрасли.

Основные преимущества React:

• Изолированность компонентов. Это свойство позволяет разработчикам разделять пользовательские интерфейсы и работать с каждым модулем по отдельности. Это обеспечивает платформам стабильную работу — если в одной из опций возникают сбои, это никак не сказывается на статусе остальных.
• Декларативный подход. Несмотря на использование кода на JavaScript, фреймворк React работает в декларативном режиме. То есть разработчик описывает желаемое содержание интерфейса, а библиотека реализовывает эту задачу. Поэтому программировать и настраивать продукты на React проще, чем писать классический код на JS.
• Наглядность. Это качество — прямое следствие декларативности. Поскольку на React сразу указывается итоговое состояние конкретного объекта, разработчику при написании кода заранее известно, как элемент будет смотреться на странице.
• Утилитарность компонентов. Созданные на React элементы можно не прописывать каждый раз заново при добавлении новых опций. Эти части можно копировать и вставлять в другие разделы. При этом в каждом компоненте содержатся все необходимые сведения и методы для реализации конкретных функций.
• Использование JSX. Это расширение JavaScript, в котором сочетается язык программирования и HTML. Инструмент предназначен для работы с разными компонентами на странице независимо от состояния прочих объектов. При этом части, которые выглядят в строке как HTML, сохраняют синтаксис JSX.
• Отзывчивость. React работает с DOM — объектной моделью документа. В копии есть все элементы веб-приложения и данные об их взаимодействии. Когда пользователи совершают действия, сначала реагирует виртуальная копия, затем реальная. То есть пользователь видит результат действий мгновенно, даже если сама платформа «тяжелая».
• Дополнительные инструменты. По причине популярности React разработчики-энтузиасты создали десятки совместимых с фреймворком инструментов. Один из них — React Native для развертывания продуктов в разных ОС и на любых устройствах с помощью стандартных протоколов.

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

Vue.js

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

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

Основные плюсы Vue:

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

Vue поддерживает расширение JSX и технологию TypeScript, но одновременно остается верен стандартам разработки на HTML и CSS. Такая универсальность упрощает процесс работы над проектом и его поддержку после реализации.

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

Svelte

Этот фреймворк практикует принципиально иной подход, чем Vue и React: вместо виртуального объекта DOM он использует компиляцию. То есть вместо работы в браузере Svelte компилирует компоненты в предельно оптимизированный и легкий код на JavaScript, что положительно сказывается на быстроте и эффективности созданных на Svelte приложений.

Не случайно такие компании, как Avast, 1Password и другие используют для создания своих продуктов именно этот фреймворк.

Ключевые преимущества:

• Простой и минималистичный синтаксис, похожий на HTML, который легко освоить и использовать. Благодаря простоте фреймворк вполне доступен для начинающих.
• Использование реактивной модели программирования. Такой подход строится на реагировании на события и асинхронности.
• Высокая производительность. По этому параметру Svelte благодаря уникальному подходу значительно опережает другие фреймворки.
• Быстрота. За счет скорости Svelte настоятельно рекомендуется для создания быстрых, масштабируемых и интерактивных веб-страниц.
• Универсальность. Svelte бесшовно интегрируется с другими востребованными инструментами.

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

Next.js

Фреймворк Next.js предназначен для серверного рендеринга (SSR), при котором код веб-приложений генерируется на сервере, а не в браузере. Это сокращает время реакции и ускоряет интерактивность приложений.

Библиотека подходит для создания масштабируемых приложений и пользовательских интерфейсов на основе React. Благодаря наличию Node.js и возможности аутсорсить некоторые опции на сторону сервера Next.js можно использовать в качестве бэкенд инструмента.

В списке других достоинств, которые отмечают программисты:

• Автоматическое разделение кода. Next самостоятельно дробит код на небольшие, более управляемые части, что позволяет работать только с необходимыми компонентами и сокращает время первичной загрузки страницы.
• Фреймворк без проблем интегрируется с библиотеками CSS на JavaScript, что существенно упрощает стилизацию, при этом нет необходимости использовать сторонние инструменты.
• Горячая замена модулей. Благодаря этой опции разработчики видят изменения в состоянии в реальном времени без обновления страницы. Это делает разработку более эффективной и удобной.
• Роутинг на базе файловой системы. На платформе Next.js создание роутов (построение оптимального маршрута в структуре папок и файлов) упрощено, что делает более эффективной интеграцию внутренних и внешних функций приложения.
• Наличие собственных плагинов для работы непосредственно с фреймворком. Благодаря этому свойству программист может адаптировать рабочую среду под свои конкретные запросы.

При этом нельзя считать Next.js дополнением к React. Это полноценный фреймворк, в котором имеется набор оригинальных инструментов и алгоритмов. Однако разработчику перед освоением Next.js придется изучить основы React.

Nuxt.js

Еще один инструмент для серверного рендеринга, но уже на базе Vue.js. В первую очередь Nuxt.js — это фронтенд-фреймворк для разработки передовых динамичных веб-приложений с интерактивными функциями.

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

Главные плюсы Nuxt.js:

• Быстрый и простой процесс разработки. Скрипты на JS используются не только на серверной, но и на клиентской стороне, что упрощает процесс написания кода.
• Автоматическая разбивка кода. Фреймворк генерирует статическую версию сайта, используя специализированную конфигурацию Webpack. При этом за каждый статически генерируемый роут отвечает отдельный файл с кодом для запуска.
• Качественная структура. Фреймворк по умолчанию предлагает упорядоченную структуру для всего проекта, что позволяет начать разработку на более выгодных стартовых условиях.
• Принцип «конвенция вместо конфигурации». В структуре минимум конфигурационных файлов, что ускоряет разработку и минимизирует ошибки. Встроенная маршрутизация существенно упрощает разработку сложной навигации.
• Удобство. Nuxt.js часто обновляется и совершенствуется. Разработчикам доступна подробная документация, а благодаря стандартным настройкам освоить фреймворк относительно легко.

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

Remix

Относительно новый фреймворк для разработки клиент-серверных продуктов на JavaScript. Основан на библиотеке React, имеет встроенную поддержку TypeScript. Разработчики часто используют Remix для создания одностраничных веб-приложений с перспективой масштабирования.

Преимущества использования фреймворка:

• Вложенные страницы. Все страницы внутри папок выступают вложенными роутами, а не отдельными. По этой причине компоненты можно добавить непосредственно на родительскую страницу, что ускоряет загрузку.
• Граничный метод обработки ошибок. Error Boundaries — наиболее эффективный способ исправления ошибок в компонентах библиотеки React. Это особенно удобно для сборки, поскольку исключает блокировку целой страницы из-за незначительной ошибки.
• Автоматическая обработка. В Remix состояния загрузки обрабатываются самостоятельно, разработчику нужно лишь указать, что будет отображаться в процессе загрузки приложения. Это встроенная возможность фреймворка, для которой не потребуются сторонние библиотеки.
• Универсальность. Remix подходит для работы на всех платформах и взаимодействует с любыми интерфейсами. Фреймворк обрабатывает запросы непосредственно на HTTP-сервере.

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

Другие перспективные фреймворки

В зависимости от целей разработки можно использовать и другие инструменты для сценариев на JavaScript. В 2025 году опытные разработчики рекомендуют обратить внимание на следующие фреймворки и библиотеки:

• Solid.js. Декларативная библиотека для быстрой разработки пользовательских интерфейсов. Здесь, как и в Svelte, нет виртуального DOM, а есть компиляция шаблонов в реальные узлы и их обновление через детализированные реакции. У фреймворка достаточно обширная документация, в том числе русскоязычная. Есть все основания полагать, что фреймворк в ближайшем будущем будет активно набирать популярность.
• Astro. Еще один проект с большим потенциалом. Ориентирован на создание веб-продуктов с объемным контентом (информационные сайты, блоги, интернет-магазины и т.д.). Фреймворк практикует серверный рендеринг, поддерживая HTML, CSS и при необходимости TypeScript. Производительность и ориентирование на контент обеспечивает высокую конверсию. Сайты и приложения на Astro загружаются быстро, при этом разработчики используют на порядок меньше сценариев.
• Qwik. Еще один относительно новый фреймворк с улучшенной архитектурой и преимуществами в виде ускоренной загрузки сайтов независимо от уровня их сложности. Поскольку скорость загрузки ресурса уже учитывается поисковыми системами, это свойство приобретает особую ценность для коммерческих проектов. В Qwik строгая иерархия компонентов и улучшенные функции за счет применения техник SSR или SSG.

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

1. Норман Бейтс («Психо»)

Почему Python?

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

Его путь в IT

Норман начинал как сисадмин в семейном мотеле "Бейтс". Ручное управление серверами быстро ему надоело — ну сколько можно делать одно и то же? Он начал писать скрипты на Python, автоматизируя бэкапы, мониторинг и деплой. Затем подсел на Docker и Kubernetes, завернул всю инфраструктуру в контейнеры и настроил CI/CD пайплайны.

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

Но позже выяснилось, что он сделал это под влиянием своего "второго я", не осознавая последствий.

2. Майкл Майерс («Хэллоуин»)

Почему C?

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

Его путь в IT

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

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

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

3. Пеннивайз («Оно»)

Почему JavaScript?

Пеннивайз — мастер иллюзий и обмана. JavaScript для него — как волшебная палочка: можно творить что угодно и где угодно. Он любит удивлять пользователей неожиданными эффектами и нестандартными решениями. Вездесущность JS позволяет ему быть везде и сразу, играя с восприятием и ожиданиями.

Его путь в IT

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

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

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

4. Гостфейс («Крик»)

Почему Ruby?

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

Его путь в IT

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

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

5. Кожаное лицо («Техасская резня бензопилой»)

Почему C++?

Кожаное лицо любит работать с железом напрямую. C++ дает ему мощь и гибкость, позволяя писать эффективный код для микроконтроллеров. Он ценит контроль над памятью и возможность выжать максимум из ресурсов. Для него код — это инструмент, как и бензопила, которым он мастерски владеет.

Его путь в IT

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

Коллеги знают: если нужно что-то спаять, запрограммировать и заставить работать — это к нему. Хотя он не особо разговорчив и может показаться грубоватым.

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

6. Акула («Челюсти»)

Почему Go?

Акула — воплощение скорости и эффективности. Go для нее — идеальный инструмент для создания высокопроизводительных сервисов. Простота синтаксиса и мощные возможности конкурентности позволяют ей строить системы, которые не тонут под нагрузкой. Go — это язык для хищников, которые не терпят рутинных задач.

Ее путь в IT

Начинала с Java, но быстро поняла, что Go лучше подходит для ее целей. Стала экспертом в микросервисной архитектуре, разворачивая кластеры, способные обрабатывать миллионы запросов в секунду. Ее код оптимизирован на все 100%, как и она сама в погоне за добычей.

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

7. Существа из «Тихое место»

Почему Rust?

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

Их путь в IT

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

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

8. Сара Фир («Улица страха»)

Почему Kotlin?

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

Ее путь в IT

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

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

9. Джейсон Вурхиз («Пятница, 13-е»)

Почему Java?

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

Его путь в IT

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

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

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

Ознакомление с созданным приложением предполагает наличие предварительных знаний о фреймворке Vue.js.

Сайт прогноза погоды создавался с помощью использования фреймворка Vue 3. Предварительно устанавливается Vue CLI, который позволяет быстро создать шаблон нового проекта. Среда разработки - Visual Studio Code.

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

Интерфейс пользователя

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

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

Структура проекта

После открытия данного проекта с помощью редактора кода, будет видна следующая структура:

Пояснение к наиболее важным файлам и папкам:

• src – основной код проекта

• папка js – javascript – файлы, содержащие повторяющиеся функции, методы и миксины в проекте

• node_modules – исходный код, подключенных библиотек и сервисов проекта

Основные файлы папки src:

• App.vue – корневой компонент интерфейса, в нем отображаются все остальные компоненты и страницы
• main.js – файл, который монтирует и собирает приложение
• components – папка, где находятся компоненты для создания пользовательского интерфейса
• pages – здесь содержатся компоненты маршрутизации, к которым происходит навигация
• router – содержит файл router.js, который описывает правила построения маршрутов к компонентам в папке pages

Сторонние библиотеки, ресурсы, используемые в приложении

Получение списка стран, городов, населенных пунктов

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

Список ООН можно найти по ссылке https://unece.org/trade/uncefact/unlocode. Здесь можно получить список в различных форматах: csv, txt, mdb. Данные в этих файлах представлены в формате UN/LOCODE — международной системе классификации географических объектов. Необходимые данные из этих файлов для проекта: коды стран согласно ISO 3166-1 alpha-2, наименование населенного пункта и координаты.

Столбец географических координат местоположения содержит широту/долготу, если таковые имеются. Используется следующее стандартное представление: 0000lat 00000long (lat - широта: N или S ; long - долгота: W или E)

Библиотека Papa Parse

Для обработки полученных данных из CSV-файла городов и стран, в проекте используется библиотека Papa Parse, доступная по ссылке https://www.papaparse.com/. Данная библиотека позволяет как считывать и обрабатывать данные из CSV, так и преобразовывать информацию к CSV-формату. Ее можно установить с помощью следующей команды npm:

Пример асинхронной функции получения данных из CSV в компоненте CountriesCodes.vue:

Сервис OpenWeatherMap

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

Чтобы начать пользоваться API, необходимо перейти по ссылке https://openweathermap.org/, создать учетную запись и получить свой API-ключ. Согласно документации, бесплатно можно получить прогноз на текущий момент и прогноз на 5 дней в 3-х часовом формате.

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

Вызов API: https://api.openweathermap.org/data/2.5/weather?lat={lat}&lon={lon}&appid={API key}. Возвращаемые данные можно получить в XML или JSON формате.

Документация по вызову API

Если вам нужно автоматически преобразовать названия городов в географические координаты и наоборот, можно воспользоваться API геокодированием.

Пример геокодирования: api.openweathermap.org/data/2.5/forecast?q={city name}&appid={API key}

Пример подключения к OpenWeatherMap и получения данных можно найти в основном компоненте App.vue:

Параметры place, code передаются из CountriesTextBox.vue – наименование населённого пункта, код страны согласно ISO 3166-1 alpha-2.

Сервис OpenStreetMap

OpenStreetMap (OSM) – это бесплатный, открытый и глобальный общественный проект карты мира. Подобно Википедии, данные OSM могут быть добавлены, отредактированы и использованы всеми желающими.

OSM представляет собой базу картографических объектов. Картинка формируются на её основе. Эту базу объектов можно посмотреть и самостоятельно изменить. Все объекты на карте делятся на четыре типа: точка, линия, полигон и составной объект.

Чтобы подключить и интегрировать OSM-карты на веб-сайт можно использовать различные картографические библиотеки JavaScript, такие как: Openlayers, Leaflet, Mapbox. В данном проекте используется библиотека Openlayers.

OpenLayers – это многофункциональная библиотека на JavaScript для встраивания карт. Она распространяется под лицензией BSD для программного обеспечения с открытым исходным кодом. OpenLayers поддерживает OpenStreetMap и другие карты. Доступа по ссылке.

Openlayers и набор расширений можно установить помощью следующих команд npm:

Пример кода Vue JS для отображения карт OpenStreetMap через Openlayers:

Описание компонентов, маршрутизации приложения

Компонент App.vue

Основной компонент App.vue собирает вместе все приложение. В нем подключается OpenWeatherMap API и располагаются компоненты для поиска населенных пунктов, маршрутизация для выбора типа погоды и карта OpenStreetMap.

Компоненты CountriesCodes.vue, CountriesTextBox.vue

CountriesCodes.vue – отдельный компонент, который загружает и обрабатывает CSV-данные о населенных пунктах и странах. Загрузка данных происходит в методе beforeMount. Родительскому компоненту загруженные данные передаются через $emit:

В App.vue данные передаются так:

CountriesTextBox.vue – компонент, который создает текстовое поле для ввода и поиска местоположения. При вводе текста появляется выпадающий, отфильтрованный список для выборки местоположения. Выпадающий список визуально формируется на основе манипуляций css-свойств для контейнеров HTML.

CountriesTextBox.vue принимает CSV-данные из App.vue:

После обработки данных, компонент возвращает найденное место, страну и координаты для передачи сервису прогноза погоды в App.vue следующим образом:

Далее получение данных в App.vue от CountriesTextBox.vue происходит в методе getLocation:

Маршрутизация в приложении

С помощью маршрутов в приложении происходит навигация к различным компонентам. Для этого подключается необходимая библитека:

Разным типам погоды прогноза погоды соответствуют свои компоненты: прогноз сейчас, на сегодня и на 5 дней. Все компоненты маршрутизации находятся в папке src/pages: ForecastNow.vue, ForecastToday.vue, ForecastFiveDays.vue. Для описания маршрутов в файле src/router/router.js создается массив с описанием объектов к страницам роутера.

Фрагмент кода router.js :

Для выбора типа прогноза погоды пользователь сайта должен нажать на соответствующей вкладке в правой части экрана. За создание вкладок отвечает отдельный компонент ForecastTypeTabs.vue, который в цикле обрисовывает кнопки навигации. При нажатии кнопки/вкладки для определенного прогноза через $emit родительскому компоненту App.vue передаются данные о выбранном типе погоды.

Фрагмент кода ForecastTypeTabs.vue:

В свою очередь в родительском компоненте App.vue находится сам роутер <router-view> и происходит навигация к необходимой странице через метод getForecastType.

Пример навигации к компоненту ForecastNow.vue, ответственному за прогноз погоды на данный момент:

Компоненту ForecastNow.vue передаются данные в формате JSON от сервиса OpenWeatherMap, которые компонент отображает в требуемом формате.

Итоговый результат

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

Ссылка на исходный код:

Настройка сборки

• клонировать проект
  

• войти в папку проекта

• установить зависимости

• запустить локальный сервер разработки
  

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

Чтотакое фреймворк и чем он отличается от библиотеки

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

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

Часто фреймворки путают с библиотеками.

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

Работая с фреймворком, вы можете использовать много разных библиотек. Во фронтенде это jQuery, Lodash, Moment.js, D3.js и другие.

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

Популярные JS-фреймворки

Чтобы выбрать фреймворки для этой статьи, мы заглянули на HeadHunter и проанализировали, какие технологии наиболее востребованы у работодателей.

На первом месте с 3 371 результатом оказался React, на втором — Angular (1 361 вакансия), на третьем — Vue.js с 1 161 упоминанием. Поэтому о них сегодня и пойдёт речь.

React

React — фреймворк/библиотека JavaScript для разработки пользовательских интерфейсов. Это универсальное решение для создания небольших приложений.

Преимущества React:

• синтаксис JSX (JavaScript XML) делает код более читаемым и понятным
• виртуальный DOM повышает скорость отрисовки компонентов
• удобно создавать отдельные компоненты и переиспользовать их в других частях программы
• используется направленный поток данных (дочерние элементы не влияют на родительские), за счёт чего в коде реже возникают баги

Недостатки React:

• может показаться сложным для новичков, которые не знакомы с синтаксисом JSX
• для создания сложных приложений необходимо использовать дополнительные библиотеки, что может усложнить поддержку проекта
• для оптимальной работы с фреймворком надо знать такие инструменты, как Babel, Webpack, Redux

Как выглядит программа Hello, world! на React:

Angular

Angular — фреймворк от компании Google для работы с интерфейсами.

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

Преимущества Angular:

• использует TypeScript, который добавляет статическую типизацию к JavaScript, что упрощает обнаружение ошибок
• предоставляет всю необходимую инфраструктуру для разработки веб-приложений, включая маршрутизацию, управление состоянием, HTTP-запросы, валидацию форм и другие инструменты
• включает в себя инструменты для оптимизации производительности, что улучшает скорость отрисовки интерфейса
• удобный синтаксис для тех, кто переходит из бэкенда во фронтенд или фулстек-разработку

Недостатки Angular:

• сложность освоения TypeScript для новичков в программировании, из-за этого высокий порог входа во фреймворк
• не подходит для небольших приложений, так как весит 550-600 Кб
• предлагает только один способ построения архитектуры ПО

Как выглядит программа Hello, world! на Angular:

Vue.js

Vue.js — фреймворк для создания интерактивных пользовательских интерфейсов от разработчика Эвана Ю, более простая и лёгкая альтернатива другим фреймворкам и библиотекам.

Преимущества Vue.js:

• обладает интуитивно понятным синтаксисом, что делает его лёгким в освоении даже для новичков в веб-разработке
• компонентная архитектура способствует переиспользованию кода, модульности и упрощает разработку
• небольшой размер библиотеки (для архивированной версии — до 20 Кб), что обеспечивает быструю загрузку и меньшие требования к пропускной способности сети
• подробная и понятная документация, в том числе на русском языке

Недостатки Vue.js:

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

Как выглядит программа Hello, world! на Vue.js:

Какой фреймворк подойдёт вам

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

Так вы сможете понять, что же вам ближе: React, Angular или Vue.js. Но не спешите и помните про базу — прежде чем переходить на фреймворки, хорошо разберитесь в работе JavaScript. Эти знания и умение гуглить правильные вопросы помогут разобраться в любой технологии.

Вот, о чём идёт речь в видео:

1. 2023 год оказался бурным: обвал банка, покупка Twitter Илоном Маском, увольнения друзей автора, аресты крипто-энтузиастов, выпуск Cybertruck Tesla и замена ChatGPT на рабочих местах.
2. В JavaScript произошли значительные изменения: почти каждый фреймворк решил обновиться в 2023 году.
3. Новая функция ECMAScript ‘object group by’ позволяет группировать объекты по определенному признаку, например, по возрасту.
4. Добавлены методы ‘array to sorted’, ‘to spliced’ и ‘to reversed’, которые не изменяют исходный массив, в отличие от ‘sort’ и ‘reverse’.
5. В HTML появились новые элементы, такие как тег ‘search’ для поисковых форм и элемент ‘dialogue’ для модальных диалогов.
6. iOS наконец разрешила веб-приложениям отправлять push-уведомления.
7. Next.js обновился до версии 13.4 с новой функцией ‘app directory’, позволяющей получать данные непосредственно в React-компонентах.
8. Фреймворк Nuxt.js в экосистеме Vue.js обновил свои инструменты разработчика и предложил компоненты через унифицированную экосистему JavaScript-инструментов.
9. Svelte ввел новую функцию ‘Runes’, изменяющую подход к реактивным переменным и управлению состоянием.
10. Angular представил новый синтаксис шаблонов, сигналы и ‘deferrable views’ для ленивой загрузки, а также обновил свой логотип.
11. Node.js улучшил модель разрешений и добавил собственный WebSocket клиент.
12. Bun — новая среда выполнения JavaScript, написанная на Zig, обещает улучшенный опыт разработки и высокую производительность.
13. HTMX получил награду ‘JavaScript Framework of the Year’, предлагая подход, сокращающий использование JavaScript.

Ниже представлен транскрибированный перевод ролика на русском языке.

2023 год был диким. Мой банк обанкротился, Илон купил Твиттер, почти все мои друзья были уволены, все мои любимые крипто-братья попали в тюрьму, Tesla успешно скрестила DeLorean с Pontiac Aztec, создав Cybertruck, и ChatGPT сделал меня устаревшим. Но все эти хорошие новости блекнут на фоне изменений, которые увидели веб-разработчики в мире JavaScript за последний год, когда почти каждый фреймворк решил переосмыслить себя в 2023 году. В сегодняшнем видео мы рассмотрим 10 недавних изменений в JavaScript, которые вы могли пропустить.

Обновления ECMAScript: группировка объектов

Каждый год в ECMAScript стандартизируются новые языковые возможности, после чего они реализуются в браузерах. Одна из моих любимых новых возможностей в этом году – это группировка объектов. Представьте, у вас есть массив объектов, в котором объекты имеют похожую схему. Это могут быть записи из базы данных, где каждый объект имеет поле возраста.

Вы можете использовать группировку, чтобы разделить детей и взрослых, определив функцию, которая группирует всех, кто моложе 21 года, в детей, и всех, кто старше, во взрослых. В результате получается объект, организованный в группы. Это хорошая маленькая утилита, но когда я чаще всего использую – это array to sorted, вместе с to spliced и to reversed. В JavaScript уже были методы sort и reversed, но проблема в том, что они изменяют исходный массив на месте. И это сбивает с толку, потому что другие методы, такие как map и filter, этого не делают. Вместо этого они копируют массив и возвращают новый.

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

Новые элементы HTML

Веб-разработчики также получили несколько крутых обновлений в виде совершенно новых элементов HTML. Например, тег search – это более семантический способ определения поля поиска на веб-сайте, который может заменить более общий тег form.

Это хорошо, но элемент dialogue намного мощнее, что позволяет создавать фактические модальные диалоги и управлять ими с помощью JavaScript с использованием встроенных методов, таких как showModal и close. Еще одна хорошая утилита, но это приводит нас к пункту три.

iOS позволил веб-приложениям делать push-уведомления

После многолетних умолчаний и умолений Apple, iOS наконец позволяет веб-приложениям отправлять уведомления push.

И это огромная победа для 0,0001% пользователей веб-сайтов, которые фактически разрешают веб-сайтам отправлять им уведомления push, что, скорее всего, ваш дедушка, который случайно нажал кнопку разрешения и теперь не знает, как ее отключить. Но теперь пришло время поговорить о веселых вещах, фреймворках.

Обновился Next.js

Самый популярный фреймворк JavaScript, Next.js, совершенно отличается от прошлого года благодаря каталогу приложений, который стал стабильным в мае с версией 13.4. Самое заметное отличие в том, что теперь вы можете получать данные непосредственно внутри компонентов React благодаря серверным компонентам, которые являются компонентами React, способными работать на сервере.

Отзывы о каталоге приложений были в какой-то степени противоречивыми. С одной стороны, у него много потрясающих новых функций и он может упростить ваш код, но многие жаловались, что он кажется спешным и недоделанным, как и способ, которым сейчас запускают видеоигры, где просто выпускают что-то на рынок, а затем исправляют его в течение следующих нескольких лет. Люди жаловались на необходимость использования директивы use client везде из-за нарушения существующих библиотек React.

Люди жаловались на медленный dev-сервер, который работает на Rust, что странно, потому что все, что работает на Rust, должно быть быстрым. И люди сравнивали его новую функцию серверных действий с PHP. Одно из самых оскорбительных оскорблений, которое можно сделать в отношении фреймворка JavaScript, но самая большая проблема заключается в том, что запуск Next.js довольно сложно сделать правильно вне Vercel, и это привело к проектам, таким как OpenNext, которые берут на себя утомительную задачу запуска его везде. Next по-прежнему является доминирующим мета-фреймворком, но Nuxt.js и экосистема Vue также имели много крутых обновлений в 2023 году, таких как его инструменты разработчика.

Эти инструменты запускаются непосредственно в браузере и значительно упрощают понимание структуры сложного приложения. Но одна вещь, которую вы, возможно, не знали о Nuxt, – многие из его компонентов доступны через унифицированную экосистему инструментов JavaScript. Например, если вам не важен Vue.js и вы просто хотите веб-сервер, вы можете использовать Nitro для создания быстрого сервера с обычным JavaScript. Забавно, что я думаю, что экосистема Vue.js изменилась меньше всего в 2023 году, и как следствие, она кажется наиболее стабильной и предсказуемой экосистемой.

Новая функция в Svelte

С другой стороны, Svelte был разрушен в 2023 году. В шокирующем заявлении несколько месяцев назад Svelte объявил о новой функции под названием Runes, которая кардинально изменит опыт разработчика в пятой версии. Вместо определения реактивных переменных с помощью let, теперь есть такая штука, как рун, которая по сути является макросом компилятора, сообщающим компилятору Svelte, что это значение является реактивным.

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

Но с другой стороны, многие люди любят эти изменения и видят их как необходимые для развития фреймворка в правильном направлении. Как активный пользователь Svelte, я жду выхода окончательной версии 5, прежде чем сформировать свое мнение.

Обновления Angular

Награду за наиболее измененный фреймворк в 2023 году, однако, получил Angular. У него длинный список новых функций, но наиболее заметные изменения для ненавистников Angular – это новый синтаксис шаблонов, который предоставляет более чистый способ обработки условий и циклов, заменяя вещи вроде ngf и ng4.

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

Улучшился Node.js

Много сумасшедших изменений на фронт-энде, но на бэк-энде Node.js тихо стал лучше. С версией Node.js 20 была выпущена новая модель разрешений, которая улучшает безопасность, контролируя, к каким функциям имеет доступ скрипт. Очень похоже на то, что сделал Deno несколько лет назад. И затем с выпуском Node.js 21 был представлен собственный клиент WebSocket, основанный на API WebSocket в браузере.

Новая среда Bun

Самым большим дисруптором на бэк-энде JavaScript в 2023 году, однако, стал Bun. Это новая среда выполнения JavaScript, написанная на Zig, которая вышла с потрясающим опытом разработчика и дикими заявлениями о производительности. И после первоначального выпуска было обнаружено немало ошибок, но она по-прежнему остается многообещающим новым способом делать бэк-энд на JavaScript в будущем.

Фреймворк HTMX

И с этим мы рассмотрели 10 различных способов, которыми JavaScript изменился в 2023 году. Но я почти забыл о самом большом из всех – HTMX, фреймворк, который показал нам, что любой может завоевать воображение экосистемы JavaScript, если вы достаточно пошутили и мемили на Twitter.

Но самое главное, как я показал здесь научно, HTMX может фактически устранить тонну JavaScript по сравнению с подходом статус-кво, принятым всеми основными фреймворками. Это идеальный JavaScript-фреймворк для ненавистников JavaScript.

Именно поэтому сегодня я в восторге и почетно представляю команду HTMX с наградой JavaScript Framework of the Year, которая в основном является Нобелевской премией в мире JavaScript.

Вот, о чём идёт речь в видео:

1. Вышла новая версия Vue 3.4, которая вносит изменения, улучшающие производительность и разработку.
2. Внутреннее улучшение заключается в полной переписи парсера шаблонов, что ускоряет компиляцию компонентов.
3. Новый парсер использует токенизатор на основе машины состояний вместо регулярных выражений, что повышает производительность.
4. Изменения в системе реактивности Vue: теперь эффекты, зависящие от вычисляемых значений, запускаются только при их изменении.
5. Улучшения разработчика (DX) включают стабилизацию DefineModel и новую сокращенную запись для vBind.
6. Улучшены сообщения об ошибках и сокращены строки ошибок в продакшене для уменьшения размера бандла.
7. Синтаксис реактивности, который был объявлен устаревшим в Vue 3.3, теперь окончательно удален, но его можно использовать с помощью библиотеки Vue macros.

Ниже — транскрибированный перевод ролика на русский язык.

Vue 3.4 вышел пару недель назад, и я уже давно не делал видео, так что давайте поговорим о нововведениях. Самые значительные изменения касаются внутренней работы Vue, которые улучшают производительность, но также есть некоторые приятные обновления для разработчиков.

Обновление парсера шаблонов в Vue 3.4

Первое внутреннее улучшение – полная переработка парсера шаблонов. Он используется для компиляции наших однофайловых компонентов.

Я даже не буду притворяться, что точно понимаю, что происходит под капотом, но по моим скромным знаниям, полученным из прочтения блога Эвана Ю, нескольких часов просмотра уроков на YouTube и нескольких попыток прочесть исходный код, старый парсер сильно полагался на просмотры строк и регулярные выражения, в то время как новый парсер использует токенизатор конечного автомата на основе HTML парсера 2.

Это означает, что ему нужно пройти по строке только один раз, что дает нам приятный прирост производительности.

Что это значит для нас – компиляции и сборки, скорее всего, увидят улучшение производительности, а другие части экосистемы Vue, такие как Volar или Vue TSC, будут работать быстрее.

Реактивный Vue

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

Давайте посмотрим на это в коде. Допустим, у нас есть ref под названием name, вычисляемое свойство, которое проверяет, является ли имя моим и затем watch эффект, который выводит в консоль в зависимости от того, я это я или нет.

До версии 3.4, каждый раз, когда мы меняем имя, is me будет отмечено как что-то вроде “грязного” ввода, который требует пересчета, но фактически пересчитываться оно не будет, пока у нас не будет чего-то, что считывает это значение, в нашем случае, наш watch эффект.

Так что мы не узнаем, меняется ли is me, пока этот watch эффект не запустится. Но теперь способ, которым вычисляемые значения запускают эффекты, все подписанные эффекты будут запускаться только в том случае, если значение вычисляемого изменится.

Это более точная и эффективная реализация системы пользовательской активности. Если вы видели мое видео о “eager computed values”, результат довольно похож. И даже в документации по использованию вычисляемого свойства в Vue для “eager composable” говорится, что нам больше не нужно это в Vue 3.4. И затем другая половина изменений – это некоторые хорошие улучшения DX, начиная с некоторых изменений в Define Model.

Define Model

Возвращаясь к Define Model, если вы использовали его в Vue 3.3, когда он был экспериментальным, то теперь он стабилен. Если вы не знаете, что это такое, Define Model – это приятный синтаксический сахар, который позволяет нам быстро создавать значения, используемые в двусторонней привязке данных с помощью vModel. Раньше, если вы хотели иметь ref, который моделирует какой-то ввод в дочернем компоненте, этот компонент должен был принимать prop и затем генерировать событие, когда этот ввод меняется.

С Define Model Vue заботится об этом за нас, поэтому нам просто нужно использовать Define Model и все готово.

Новый сокращенный синтаксис vBind

Следующее изменение – новый сокращенный синтаксис vBind. При передаче переменной в качестве prop, иногда имя нашего prop совпадает с нашей переменной. Vue 3.4 дает нам новый сокращенный вариант для этого. Так что вместо того, чтобы говорить “colon title equals title” для привязки переменной с именем title, мы можем просто использовать “colon title” для сокращения.

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

Но если вам нравится этот синтаксис, вы все еще можете использовать его с библиотекой Vue macros.

Вот, о чём идёт речь в видео:

1. Даниэль обсуждает выбор между фреймворками Angular и Vue для разработки пользовательских интерфейсов.
2. Angular, созданный Google в 2010 году, предпочтителен для корпоративных проектов, имеет встроенные инструменты и библиотеки, а также поддерживает динамическую и двустороннюю привязку данных.
3. Angular использует TypeScript, обеспечивает высокую производительность благодаря иерархической инъекции зависимостей и другим функциям, поддерживается Google и легко интегрируется с сторонними приложениями.
4. Vue, созданный на основе вдохновения от Angular, отличается простотой и элегантностью, предлагает гибкость и прогрессивное развитие, позволяя легко добавлять пользовательские модули и компоненты.
5. Vue обеспечивает гибкость интеграции, простоту использования и функциональное расширение с помощью мощных API.
6. Angular и Vue имеют схожие черты: компонентно-ориентированную архитектуру, реактивную привязку данных и декларативный стиль программирования, а также большие сообщества разработчиков.
7. Основные различия между Angular и Vue включают архитектуру (Angular – MVVM, Vue – только ViewModel), реактивность, обработку ошибок, встроенные функции и производительность.
8. Выбор между Angular и Vue зависит от конкретных потребностей проекта и целей разработки.
9. Vue лучше подходит для динамических приложений, проектов, ориентированных на UI/UX, портфолио и одностраничных приложений.
10. Angular лучше подходит для кроссплатформенной и гибридной веб-разработки, крупных проектов и предприятий, требующих серверной отрисовки.
11. Angular и Vue обеспечивают высокооплачиваемые рабочие места, с зарплатами до $125,000 и $156,000 в год соответственно, а также возможности для фриланса.

Ниже представлен транскрибированный перевод видео на русский язык.

Вы наверняка слышали о Angular и Vue. Это два суперпопулярных фреймворка, которые разработчики используют для создания полноценных пользовательских интерфейсов.

Но вам, как разработчику, может прийтись принять непростое решение. Какую из этих двух технологий использовать в конкретном проекте? Меня зовут Даниэль, и сегодня мы поговорим о противостоянии Angular и Vue. Мы изучим их плюсы и минусы, сходства и различия. Мы постараемся понять, какой из этих фреймворков лучше подходит для различных типов проектов.

Преимущества Angular

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

И когда вы понимаете, какая эта цель, легче принимать правильное решение. Angular, Angular, созданный Google в 2010 году. Это лучший выбор для корпоративных проектов благодаря своим обширным функциям и высокой производительности. В отличие от других фреймворков, Angular не замедляет приложения. Он предлагает встроенные инструменты и библиотеки. Его код может быть использован на различных платформах, что делает разработку гибкой.

Плюс, у него есть динамическое связывание пользовательского интерфейса и двустороннее связывание данных, важные элементы его дизайна. И ребята, у Angular есть множество преимуществ, которые делают его таким популярным среди разработчиков. Основанный на TypeScript. Прежде всего, ребята, это TypeScript, язык программирования, созданный Microsoft, который является бесплатным и с открытым исходным кодом. Он добавляет статическую типизацию с возможностью использования типовых аннотаций к JavaScript.

TypeScript, надмножество JavaScript, улучшает качество кода с помощью надежной навигации, рефакторинга и функций автодополнения, что уменьшает ошибки в масштабных приложениях. Поддерживается Google. Еще одно преимущество заключается в том, что фреймворк поддерживается Google. Это включает в себя подробную документацию и возможности для будущего расширения фреймворка. Следующее – высокая производительность. Благодаря иерархической инъекции зависимостей, IV-рендерингу, AOT-компилятору, дифференциальной загрузке и поддержке Angular Universal, производительность фреймворка выдающаяся.

Обновленное руководство. Angular CLI предлагает своевременные рекомендации по зависимостям, загрузчикам и плагинам. Благодаря этому разработчики остаются в курсе последних рекомендаций. Бесшовные интеграции. Angular позволяет легко интегрировать сторонние приложения. Это дает разработчикам гибкость и множество инструментов для упрощенной разработки. Наконец, возможность настройки. Разработчики могут интегрировать элементы и модули из других фреймворков, адаптируя их под свои потребности. Дело в том, что элементы HTML Angular могут быть легко повторно использованы и управляемы путем обертывания их в качестве элементов DOM.

Преимущества Vue

Итак, как вы видите, ребята, есть много преимуществ у Angular. Но теперь давайте посмотрим на Vue. Vue, также называемый Vue.js, это все о чистом и элегантном дизайне. Представьте себе фреймворк, который объединяет мощные веб-инструменты с простотой. Вот что такое Vue.

Теперь вот интересный факт. Создатель Vue был вдохновлен Angular. Он взял это вдохновение и создал Vue, фреймворк, который позволяет легко создавать современные веб-проекты. Одной из выдающихся особенностей Vue является его прогрессивный характер. Он динамичен, что означает, что вы можете настраивать код вашего приложения, не нарушая основной функциональности. Плюс Vue предлагает невероятную гибкость. Вы можете легко добавлять пользовательские модули и визуальные компоненты, настраивая ваши веб-приложения до совершенства.

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

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

Вместо этого он оптимизирует процесс, делая разработку приложений быстрее и более простой. И, наконец, функциональное расширение. Vue предлагает функциональное расширение, предоставляя набор мощных API.

Эти функциональные возможности позволяют вам создавать гибкую и обширную логику компонентов. Так что, ребята, судя по всему, Vue не уступает Angular.

Сходства между Angular и Vue

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

И взамен я прошу просто лайкнуть это видео и подписаться на мой канал, если вам нравится контент, который я делаю. Вот и все. Люди, помните, что создатель Vue использовал Angular в качестве своего вдохновения. Это означает, что у этих двух фреймворков JavaScript много общего.

Итак, давайте поговорим о самых больших сходствах между ними. Архитектура на основе компонентов.

И Angular, и Vue работают как строительные блоки. Они разбивают пользовательские интерфейсы на более мелкие части, называемые компонентами. Эти компоненты похожи на логические кирпичи, которые можно создавать индивидуально. Реактивное связывание данных привязывает ваши данные непосредственно к тому, что видят пользователи. Поэтому, когда ваши данные меняются, ваш дисплей автоматически обновляется, без дополнительной работы. И Vue, и Angular делают это в реальном времени. Декларативное программирование. Vue и Angular могут выглядеть по-разному, но они оба имеют замечательную особенность – декларативный стиль программирования. Вместо перечисления пошаговых инструкций, вы просто описываете, что хотите достичь. Сообщество. У Angular и Vue есть большие сообщества разработчиков, где люди предлагают улучшения и поддерживают фреймворки. Они формируют функции, исправляют проблемы и часто помогают другим разработчикам.

Различия между Angular и Vue

Хорошо, друзья. Vue.js и Angular – это оба инструмента для создания фронтенда приложений с использованием JavaScript. Однако во многих аспектах они отличаются. Эти области, например, включают основную архитектуру, производительность, реактивность и другие.

Но давайте поговорим об этом более подробно.

Архитектура. Angular похож на полноценного архитектора, модель MVVM. Отлично подходит для создания детальных и сложных приложений. Кроме того, он поддерживает все виды серверных языков. Это делает Angular универсальным. Vue похож на декоратор фронтенда, только модель Vue.

Он отлично улучшает внешний вид, но не является универсальным инструментом для всего процесса создания. Проще говоря, Angular – это все в одном. Vue – только для фронтенда. Реактивность. Angular полностью основан на JavaScript. Он отлично подходит для приложений в реальном времени. Vue также использует HTML и CSS и идеально подходит для создания одностраничных приложений.

Он автоматически отображает любые обновления. Обработка ошибок. Angular обрабатывает ошибки во время компиляции. Vue заботится о них на лету во время выполнения. Функции. Angular поставляется с встроенными функциями, такими как маршрутизация, формы и внедрение зависимостей.

Он идеально подходит для крупных проектов. Vue более легковесен и отлично подходит для одностраничных проектов. Производительность. Когда речь идет о скорости, Vue намного быстрее.

Почему? Дело в том, что Vue остается легким с акцентом на слое Vue. Vue также получает ускорение от виртуального DOM, обеспечивая дополнительную скорость на различных платформах. Angular с его многочисленными встроенными функциями немного тяжелее и требует больше времени на выполнение задач.

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

Какой фреймворк следует выбрать для вашего проекта? Vue или Angular?

Итак, принимая во внимание все вышесказанное, что лучше, Vue или Angular?

Честно говоря, как часто бывает с такими технологиями, здесь нет однозначного ответа. Я могу сказать, что у обоих фреймворков есть свои преимущества. Angular надежен и прошел проверку временем, а Vue быстр и прост в использовании. Выбор между ними зависит от ваших конкретных потребностей и целей вашего проекта.

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

Конечно, есть еще один важный вопрос.

Поможет ли изучение этих технологий получить высокооплачиваемую работу?

Если вы планируете стать разработчиком на Angular или Vue, вам не о чем беспокоиться. Согласно недавнему опросу Stack Overflow, Angular входит в топ-5 самых популярных веб-фреймворков.

И Vue не сильно отстает. Это означает, что спрос на разработчиков Angular и Vue остается высоким. По данным Glassdoor, разработчики на Angular в Соединенных Штатах могут зарабатывать до $125,000 в год. В то же время разработчики на Vue могут зарабатывать до $156,000 в год. Фрилансеры на Angular зарабатывают от $16 до $30 в час. И фрилансеры на Vue зарабатывают около $19-35 в час.

Итак, как вы можете видеть, здесь существенная разница в отношении офисных работ и не так много в плане фриланса. Ладно, мои уважаемые разработчики, это все, что у меня есть по сравнению Angular и Vue.

https://www.youtube.com/@Daniel-Dan./videos

Программа состоит из 5 курсов:

• «Погружение в профессию Фронтенд-разработчик»,
• «Веб-верстка 3.0»,
• «JavaScript»,
• «Typescript, инструменты разработчика»,
• «Изучение фреймворка React.js или Vue.js на выбор».

Учащиеся научатся верстать сайты на языках HTML и CSS, «оживлять» веб-страницы, настраивать взаимодействие с сервером с помощью JavaScript, изучат стандарт рынка TypeScript. В процессе обучения они смогут выбрать фреймворк, с которым свяжут свою профессиональную деятельность в будущем: React.js или Vue.js. Кроме того, студенты получат навыки работы с Git и Figma.

Курс «Веб-верстка 3.0» создан в новом игровом формате. Студентам предстоит выполнять задачи от компаний, накапливая баллы за их успешное решение. Количество баллов зависит от выполнения задач разного уровня сложности — легких, средних и сложных. Чем сложнее задача, тем больше баллов. Задания представлены от трех разных типов IT-заказчиков: от компании Газпромбанк, диджитал-агентства Whitemark, а также от проектов на фриланс-бирже «Хабр Фриланс». Такой подход позволит студенту погрузиться в специфику работы в различных направлениях IT, узнать о ролях в команде разработки и лучше подготовиться к выходу на работу.

Обучение на программе проходит по предзаписанным видеолекциям и вебинарам с отраслевыми экспертами. Среди спикеров курса:

• Никита Балихин, Tech Lead сервисной разработки в Газпромбанке,
• Павел Рубан, Lead веб-разработки в Газпромбанке,
• Павел Гонзалес, ведущий фронтенд-разработчик в Skillbox,
• Валерий Кузнецов, фронтенд-разработчик в «Циан»,
• Павел Кольцов, фронтенд-разработчик в «Самолете» и другие.

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

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

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

Программа адаптирована с учетом роста интереса к IT-профессиям — 95% новых пользователей направления «Программирование» начинают обучение без базовых цифровых знаний. Поэтому на курсе студенты получат ответы на основные вопросы, возникающие на старте карьеры в IT. Учащиеся научатся воспринимать информацию на языке разработчика, работать с массивами, освоят необходимые функции и цифровые инструменты. Помимо этого, слушателям расскажут про систему грейдов в IT: как продвигаться по карьерной лестнице и с какими задачами работают специалисты на разных уровнях.

Рекомендованная длительность прохождения программы — девять месяцев. Выпускники оформят более восьми кейсов в портфолио на GitHub и получат возможность попасть на стажировку в Газпромбанк.Тех. По завершении обучения у учащихся будет сертификат государственного образца.

Реклама АО «Газпромбанк» LjN8Jyhqz

Вступление

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

В начале этого года я решил — хватит! Я перейду на один из менеджеров паролей. Все крутые парни пользуются менеджерами паролей. И я стал изучать их.

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

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

Эту проблему, якобы решает облачное хранение. Но облачное хранилище — это всегда чей-то сервис. Мы не можем быть уверены, что этот сервис не сломается или не откажет нам в доступе по любой причине.

Идея

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

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

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

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

В начале года как раз узнал про методологию Feature-sliced design и решил распробовать её на своём новом пет-проекте. В качестве реактивной библиотеки выбрал свою любимую третью Vue. Итак, дамы и господа, встречайте…

Passcryptum

GitHub — Passcryptum

Исходный пароль обрабатывается функцией PBKDF2 SHA-512 262144 итераций. Это серьёзное препятствие на пути у тех, кто захочет получить доступ к нашим аккаунтам путём перебора исходного пароля.

Приложение не хранит пароли, но хранит список сервисов и логинов в зашифрованном виде. Без нашего исходного пароля никто не сможет прочитать даже список сервисов, которыми мы пользуемся. В свою очередь мы, заходя в Passcryptum, сразу видим свои сервисы и можем сразу скопировать логин/пароль.

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

Если есть нужда сменить пароль на аккаунте — у каждого логина есть версия. Инкрементируем версию и получаем новый совершенно уникальный пароль.

Чтобы не вводить каждый раз свой суперсекретный исходный пароль (мало ли где кто подсмотрит), существует возможность задать PIN. Хеш исходного пароля шифруется значением PIN, а также отпечатком системы устройства. PIN можно сколько угодно раз забыть, удалить и установить новый. Главное — помнить свой исходный пароль и вводить его исключительно осторожно.

Заключение

Passcryptum решил мою проблему и я с радостью готов поделиться со всем миром этим инструментом. В Passcryptum нет ничего платного и весь код открыт.

Помимо README.md, я добавил несколько полезных инструкций:

• Алгоритм генерации паролей;
• PIN;
• Рекомендации по использованию.

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

Спасибо за внимание! Каждому человеку, который пользуется паролями (ну то есть просто каждому), искренне советую попробовать Passcryptum.

Ошибка 1. Нет четких границ между слоями приложения

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

Можно выделить три базовых уровня:

• Контроллеры (или хэндлеры) принимают запросы, проводят базовую валидацию (например, через pydantic-схемы) и передают данные дальше.
• Слой бизнес-логики реализует правила работы приложения: транзакции, расчёты скидок, проверку лимитов, работу с несколькими сервисами.
• Слой доступа к данным отвечает за запросы к базе и возвращает данные в удобной для бизнес-логики форме.

Например, в FastAPI проще начать с хэндлеров, которые сразу ходят в SQLAlchemy-модель. Но если сразу заложить сервисный слой, расчёты комиссий и проверку бизнес-правил можно будет тестировать изолированно, не поднимая всю API. Слой репозиториев позволяет в будущем легко заменить Postgres на другую базу или добавить кэш, не переписывая логику приложения.

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

Ошибка 2. Игнор масштабирования с первого дня

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

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

Например:

• Добавить очереди и фоновые задачи через Celery или RQ, если есть риск появления тяжёлых операций (генерация отчётов, массовая рассылка).
• Разносить чтение и запись: даже простое разделение на эндпоинты, где читающие операции не блокируются длительными транзакциями, уже помогает при росте нагрузки.
• Придумать, как кэшировать самые тяжелые запросы: например, использовать Redis, чтобы хранить агрегированные данные, а не считать их каждый раз.
• Закладывать возможность горизонтального масштабирования: не привязывать логику к локальному состоянию приложения, использовать хранилище с возможностью разделения нагрузки, не писать монолит, который нельзя будет разбить на части при росте.

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

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

Ошибка 3. Преждевременное усложнение архитектуры

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

Рядовой пример — проект сразу запускается на Kubernetes с несколькими сервисами, которые обмениваются сообщениями через Kafka. В реальности такие проекты вначале требуют десятков часов на поддержание инфраструктуры, а баги приходится искать сразу в нескольких сервисах, между которыми гуляют события. При этом единственная реальная задача в начале — быстро проверить гипотезы и получить первых пользователей.

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

Что можно делать:

• Запускать монолит на FastAPI или Django, а не дробить на микросервисы до появления реальных узких мест.
• Использовать Postgres без брокеров событий, пока не появятся требования к масштабированию.
• Добавлять кэш Redis точечно, когда видна реальная нагрузка, а не вслепую кэшировать каждый запрос.

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

Если команда делает стартап или MVP, преждевременное усложнение архитектуры только тормозит развитие продукта. Гораздо эффективнее заложить возможности для масштабирования (очереди, фоновые задачи, кэш), но держать архитектуру простой до тех пор, пока проект не начнёт расти и не появятся реальные вещи, требующие изменений.

Ошибка 4. Непродуманная работа с зависимостями

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

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

Чтобы избежать проблем, важно с самого начала заложить порядок в работе с зависимостями:

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

Например, при работе с Python удобным подходом будет использование Poetry: можно зафиксировать версии зависимостей в pyproject.toml, автоматически создавать lock-файл, следить за актуальностью библиотек и легко пересоздавать окружение. Если проект запускается на CI/CD, можно установить точные версии и сразу выявить, где обновление ломает тесты.

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

Ошибка 5. Нет стратегии управления состоянием

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

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

Чтобы избежать хаоса, управление состоянием нужно продумать заранее:

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

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

При работе с фронтендом стратегия управления состоянием не менее важна. Например, при использовании React или Vue проект может сначала обходиться локальным состоянием компонентов, но при росте сложности приложение начинает сыпаться из-за рассинхрона между компонентами. Важно заранее заложить подход с централизованным состоянием, а также понять, какие данные держать в состоянии клиента, а какие запрашивать заново.

Без стратегии управления состоянием проект становится сложным в отладке и поддержке. Грамотное управление состоянием ускоряет разработку и снижает количество багов в будущем.

А какие ошибки допускаете вы? Делитесь в комментариях или в тг-канале Веб-страница.

Это — перевод оригинальной статьи с Medium.com на английском языке. Автор — William Schulte. Далее ведётся повествование от лица автора.

В ходе этого проекта мы рассмотрим:

1. Как настроить функцию search() для обработки ответа от OpenWeatherMap API на основе введенного пользователем почтового индекса США. (В вашем случае, почтовый индекс может быть каким угодно).
2. Как использовать метод JavaScript Object.keys() в функции для округления значений погоды (возвращаемых из ответа) до ближайшего целого числа.

Приложение, которое мы создадим, на самом деле является урезанной, одностраничной версией приложения OpenWeatherMap API dashboard, которое я создал ранее. Если хотите, вы можете посмотреть его репозиторий на GitHub. Для этого проекта мы создадим кое-что попроще.

Давайте начнем!

Настройка проекта

Сначала откройте IDE и скопируйте и вставьте следующий код шаблона в HTML-файл:

Теперь создадим блок скрипта:

Внутри функции setup() добавьте следующие свойства:

Функция Search()

Чуть ниже свойств, которые мы написали, настроим функцию search(), которая будет обрабатывать вызов API OpenWeatherMap:

Чтобы вызов API работал, вам нужно зарегистрироваться для получения ключа API на сайте OpenWeatherMap. После создания учетной записи и получения ключа вставьте его в URL-адрес API в указанном месте.

После ввода 5-значного почтового индекса и нажатия кнопки Enter, API вернет данные о погоде для введенного пользователем почтового индекса (см. интерполированное свойство cityZip.value в URL).

Чтобы увидеть разобранные данные, просто скопируйте и вставьте URL-адрес с ключом API и введенным почтовым индексом в браузер. После этого вы увидите большое JSON-дерево погодных данных для выбранного города.

В данном приложении нам важно получить из ответа API данные о погоде, содержащиеся в следующем объекте:

Хотя по умолчанию эти значения представлены в градусах Цельсия, мы можем преобразовать их в градусы Фаренгейта, добавив "&units=imperial" в конце URL API. После сохранения res.data.main в weatherValue.data мы должны увидеть эти значения, преобразованные в Фаренгейт.

Теперь запустите приложение в браузере. На этом этапе вы должны увидеть такое окно:

Кажется, что все работает нормально. Однако одна из задач этого проекта – возвращать значения погоды, округленные до ближайшего целого числа. Для этого мы используем метод Object.keys() как часть функции для округления значений погоды. Но сначала давайте рассмотрим основную концепцию метода Object.keys().

Метод Object.keys()

Если вы не знали, метод Object.keys() в JavaScript возвращает массив перечисляемых строковых имен свойств данного объекта. Обратите внимание на следующий пример из документации JavaScript MDN:

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

Теперь давайте применим эту концепцию к нашему приложению. Вернемся в наш HTML-файл и добавим код ниже функции search():

Внутри функции roundedValue() мы создадим свойство roundData, которое установим в пустой объект. Затем мы используем метод Object.keys() для создания нового массива, содержащего все ключи из weatherData.value.

console.log(Object.keys(weatherData.value)) должен вернуть следующее:

Далее мы используем метод map() для итерации по вновь созданному массиву ключей, причем каждый элемент в массиве ключей будет представлен элементом key.

Чтобы округлить каждое значение погоды, мы передадим weatherData.value[key] в Math.round() внутри обратного вызова, используя при этом ключевой элемент как индекс для каждого итерируемого элемента weatherData.value.

Наконец, каждое новое округленное значение мы присвоим roundData[key].

После выполнения console.log(roundData) мы должны увидеть новый объект:

В функции setup() мы добавим новое вычисляемое свойство roundedData, которое будет возвращать наша функция roundedValue(). Не забудем включить оба этих элемента в возвращаемую функцию setup.

Давайте также обновим карточку с информацией о погоде в шаблоне, чтобы интерполировать вычисляемое свойство roundedData (там, где это необходимо):

Окончательный код должен выглядеть следующим образом:

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

И вот, у вас всё получилось! Поздравляю вас!

В новой версии разработчики постарались улучшить опыт разработки. К примеру, было улучшено взаимодействие с SFC <script setup> на TypeScript.

Также были решены многие давние проблемы с использованием Vue и TypeScript.

Основные изменения

Обновления зависимостей

Чтобы обновиться до Vue 3.3, нужно также обновить зависимости:

1. volar / vue-tsc@^1.6.4;
2. vite@^4.3.5;
3. @vitejs/plugin-vue@^4.2.0;
4. vue-loader@^17.1.0 (если используется webpack или vue-cli).

Поддержка импортированных и комплексных типов в макросах

До версии 3.3 типы в defineProps и defineEmits могли быть только локальными типами и поддерживали только литералы типов.

Так было потому, что Vue нужно было анализировать свойства props для генерации опций во время выполнения кода.

Теперь, в версии 3.3, компилятор разрешает использовать импортированные и комплексные, сложные типы:

Обратите внимание, что поддержка сложных типов основана на AST, поэтому не все типы могут поддерживаться на 100%. К примеру, условные типы вообще не поддерживаются.

Вы можете использовать условные типы для одного параметра, но не для объекта параметров.

Универсальные компоненты

Компоненты <script setup> теперь принимают универсальные параметры через атрибут generic:

Значение generic работает как список параметров между <...> в TypeScript.

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

Раньше эту функцию надо было включить вручную. Теперь, в последней версии volar/vue-tsc, она включена по умолчанию.

Эргономичный defineEmits

Ранее параметр для defineEmits поддерживал только синтаксис сигнатуры вызова:

Тип соответствует возвращаемому типу для emit, но он короткий и неудобный для написания. В версии 3.3 ввели более эргономичный способ объявления emit:

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

Старый синтаксис сигнатуры всё ещё поддерживается.

Типизированные слоты с defineSlots

Новый макрос defineSlots можно использовать для объявления ожидаемых слотов и их свойств:

defineSlots() принимает только параметр типа, но не принимает аргументы рантайма.

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

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

Значение defineSlots — это тот же объект слотов, который возвращается из useSlots.

Текущие ограничения

1. Проверка слотов еще не реализована в volar/vue-tsc.
2. Тип возврата функции слота может быть любым, но в будущем он может использоваться для проверки содержимого слота.

Существует также опция слотов для использования defineComponent. Оба API используются исключительно в качестве подсказок типа для IDE и vue-tsc.

Экспериментальные функции

Деструктуризация реактивных пропсов

Деструктура реактивных пропсов ранее была частью преобразования реактивности, которое теперь удалено. Сейчас она выделена в отдельную функцию.

Эта функция позволяет деструктурированным пропсам сохранять реактивность и предлагает более удобный способ объявления значений:

Эта функция является экспериментальной и требует явного согласия.

defineModel

Ранее, чтобы компонент поддерживал двустороннюю привязку к v-модели, ему необходимо было объявить свойство и создать событие update:propName, чтобы свойство обновлялось:

Версия 3.3 упрощает этот процесс с помощью макроса defineModel. Макрос автоматически объявляет свойство и возвращает ссылку:

Эта функция является экспериментальной и требует явного согласия.

Другие примечательные особенности

defineOptions

Новый макрос defineOptions позволяет объявлять параметры компонента прямо в <script setup>. При этом не нужен отдельный блок <script>:

Лучшая поддержка Getter с toRef и toValue

toRef улучшен для поддержки нормализации значений, геттеров и refs:

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

Новый служебный метод toValue делает всё наоборот, нормализуя всё в значения:

toValue можно использовать в составных элементах вместо unref, чтобы компоненты принимали геттеры в качестве реактивных источников данных:

Разница между toRef и toValue такая же, как между ref и unref. Разница только в обработке функций-получателей.

Импорт исходного кода JSX

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

Начиная с версии 3.3, Vue поддерживает указание типизаций JSX с помощью параметра TypeScript jsxImportSource.

Улучшение инфраструктуры обслуживания

Вот, что улучшили в выпуске 3.3:

1. Сборки стали в 10 раз быстрее благодаря отделению проверки типов от сводной сборки и переходу от rollup-plugin-typescript2 к rollup-plugin-esbuild.
2. Ускорились тесты за счет перехода с Jest на Vitest.
3. Ускорилось создание типов за счет перехода от @microsoft/api-extractor к rollup-plugin-dts.
4. Комплексные регрессионные тесты с помощью ecosystem-ci позволяют выявлять регрессии в основных зависимостях перед выпуском.

В этом посте рассмотрели основные изменения в версии 3.3. Ознакомиться с полным списком обновлений можно на GitHub.

• «Composition API – это мощнейшее решение, которое в полной мере разрешает проблемы Options API Vue 2 версии, а также предоставляет расширенные возможности в декларировании и управлении данными в фреймворке. Новый API позволяет облегчить реализацию сложных архитектурных решений в крупных и средних приложениях».
• «Я очень взволнован этим новым API. Он убирает зуд, который у меня был в течение долгого времени, пытаясь применить принципы чистого кода в моих интерфейсных приложениях».
• «Код, написанный с помощью нового API, лучше читается, что делает его более лёгким для понимания».
• «Это, безусловно, самое ожидаемое изменение в Vue3. Оно должно помочь с организацией и возможностью многократного переиспользования кода компонентов».

Вот оно, новое слово в компонентостроении, решение всех наболевших проблем, сейчас наконец заживём…

Однако как часто это бывает, реальность оказалась сложнее. Мы активно использовали Composition API более полутора лет в довольно крупном enterprise приложении и мне есть что вам об этом рассказать.

Мы точно идем вперед? Или все новое это хорошо забытое старое

Зайдём издалека, что вообще такое фреймворки и зачем они нам нужны? Отличный ответ на этот вопрос дал Илья Климов в рамках курса по Vue:

Фреймворк инструктирует вас, как писать код.

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

До фреймворков разработчику предоставляли значительно больше возможностей влиять на систему. Однако зачастую дополнительная свобода приводила к увеличению проблем, о многих из которых мы в 2022 уже успели позабыть. Отчасти фреймворки появились как ответ на эту огромную неопределённость (= чрезмерную свободу) предыдущих более низкоуровневых решений (JQuery, Backbone, Vanila JS и т.д.). И Vue отлично справлялся с этой задачей, возможно даже лучше, чем конкуренты.

Чем же так плоха свобода в коде? Прежде всего тем, что ведёт к увеличению проектных знаний, а это, в свою очередь, мешает компании и проекту масштабироваться и развиваться. К примеру, чем больше проектных знаний, тем больше новому разработчику нужно времени на онбординг. Отдельно остро стоит вопрос качества этих знаний — повышается значимость решений отдельного человека, возрастает вероятность ошибок. В данном контексте cвобо­да действий — враг стандартизации и качества.

И с этой точки зрения Composition API — инструмент, увеличивающий свободу. Это движение против стандартизации, предложенной в Options API. Ниже приведу несколько примеров:

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

• Вложенность composable. Ограничений по вложенности composable нет, в документации также отсутствуют рекомендаций на этот счёт.
• Хуки жизненного цикла компонента доступны всем вложенным composable. Фактически мы обращаемся к данным из другого уровня (из самого верхнего, уровня самого компонента) абстракции, нарушается принцип одного уровня абстракции.
• Работа с внешними данными во вложенных composable.

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

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

• Вложенные composable.
• SetupContext и возможность пробрасывать его на любую глубину.
• Emit события из вложенной use-функции. Сайдэффект, оказывающий влияние на весь компонентСтоит также добавить, что переиспользование use-функций из примеров выше в других компонентах может привести к кратному увеличению негативных эффектов.

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

Composition API подталкивает нас к созданию многофункциональных компонентов

Многофункциональные компоненты нарушают несколько общепринятых принципов разработки компонентов:

• Single responsibility principle. Чем больше у компонента responsibilities (зон ответственности, функций), тем сложнее им управлять и его расширять. К примеру, если мы решим хранить все данные в одном месте, компонент будет становиться все больше и больше, что впоследствии может привести к потере контроля.
• F.I.R.S.T. Следует стремиться создавать сфокусированные (Focused), независимые (Independent), переиспользуемыме (Reusable), небольшие (Small) и тестируемые (Testable) компоненты или сокращенно FIRST компоненты. Многофункциональные компоненты зачастую большие, не сфокусированные и их трудно тестировать.

Сравним подходы в аспекте многофункциональных компонентов.

В Options API разрастающиеся опции намекали разработчику о том, что компонент следует декомпозировать. Чем больше функций выполнял компонент, чем толще становились опции, тем менее комфортно становилось с ним работать. Vue выполнял одну из своих важнейших задач — подталкивал разработчика к соблюдению стандартов (в данном случае к декомпозиции). Для нас проблемы начинались примерно с 500 строк — при достижении этой отметки мы сразу приступали к декомпозиции. Это правило позволило нам строить сложные интерфейсы из относительно небольших и простых компонентов-кирпичиков, каждый из которых имел 1–2 ответственности.

В Composition API разрастающийся setup намекает разработчику о том, что следует добавить новую use-функцию. То есть подталкивает нас к наделению компонента новыми responsibilities. Сколькими ответственностями можно наделить компонент перед тем, как он превратится в многофункциональный монстер-компонент? Точный ответ дать трудно, но по нашему опыту, сложность и связность компонента значимо возрастают начиная с 3–4 use-функций.

Пожалуй, стоит подкрепить вышесказанное примером:

Благодаря разделению кода на use функции, мы близки к тому чтобы заблудиться в трёх соснах! При этом соблюдены все конвенции из документации vue. Скажу даже больше, нам никто не мешает добавить ещё одну фичу (в моей практике встречались компоненты с 5–6 фичами-use функциями), никаких соглашений этот шаг не нарушит. Трудно представить, насколько сильно может усложниться код при дальнейшем расширении компонента.

Безусловно, существуют кейсы, когда без многофункциональных компонентов не обойтись. В этом случае Composition API справится с упорядочиванием кода значительно лучше, чем Options API. Однако по моей оценке их немного (подробнее ниже), большинство проблем можно решить классической декомпозицией компонента.

Component vs composable

Как писал выше, Options API подталкивает нас к декомпозиции большого компонента на маленькие, в то время как Composition API предлагает создавать новые use функции.

Попытаемся сопоставить эти два подхода к декомпозиции. Удобнее будет рассматривать компоненты как абстракции в шаблоне, а use-функции – абстракции в логике. Позволю себе громкое заявление: абстракции в логике строить труднее, чем абстракции в шаблоне.

Хорошие абстракции строить сложно. Сразу возникает куча вопросов: На основании чего нам строить абстракции? По фичам? По задачам? Или по сущностям? Что есть сущность? Как отделить одну сущность от другой? Как сформировать барьеры абстракции?

При создании composable разработчику нужно самостоятельно найти ответы на эти вопросы. Для принятия правильных решений необходимы компетенции и серьёзный опыт, которыми обладает далеко не каждый кодер. По сути, необходимы навыки, используемые при построении js-библиотек. Если же их нет, то начинается импровизация (часто с неблагоприятным исходом). Так было и у нас

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

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

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

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

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

Отдельно стоит рассмотреть вопрос взаимодействия между абстракциями.

Правила взаимодействия между компонентами известны, они ограничены и задокументированы (как хорошие, так и плохие практики), довольно просты и прошли проверку временем. props и emits; слоты; сторы; provide/inject.

Правила взаимодействия между composable необходимо сформировать самостоятельно, ведь по сути, use-функции — это кастомные абстракции. При создании composable разработчику необходимо ответить на ряд вопросов:

1. Можно ли менять стейт одного composable в другом composable? (В компонентах нельзя, для изменения стейта есть props и emits).
2. Как быть с вложенными composable? Насколько глубокой может быть вложенность? (Компоненты можно беспрепятственно вкладывать друг в друга и группировать без сильного увеличения сложности).
3. Как работать с данными из внешних источников? Какие сайдэффекты в composable допустимы? (Так как работать с сайдэффектами в компонентах приходится часто, то в большинстве проектов уже пришли к консенсусу по этому вопрос).
4. Как при добавлении нового composable не слишком сильно увеличить связность и сложность? (Добавить новый компонент в разметку проще. Следуем общим правилам и стараемся не плодить многофункциональные компоненты).
5. Какие функции будет брать на себя composable? (Для компонентов есть подсказка в виде интерфейсов) И чем больше use-функций, тем сложнее найти верные ответы.

Откуда корни растут?

Evan You не скрывает, что при создании Composition API вдохновлялся React хуками. В документации даже есть подраздел «Сравнение с React Hooks». За время существования хуков вышло несколько статей с критикой подхода. Обвиняют в том числе за чрезмерную свободу действий и, как следствие, спагетти-код.

Наши правила работы с Composition API

Для того чтобы избежать негативных последствий, описанных выше, мы в Yclients придерживаемся нескольких базовых правил работы с Composition API (перечень не является исчерпывающим и может быть расширен под ваш проект):

• Не рекомендуется использовать watch во вложенных use-функциях. Предпочтительнее watch в корне setup функции (чем очевиднее сайдэффекты, тем лучше).
• Не рекомендуется эмитить события из вложенных use-функций. Предпочтительнее эмитить события в корне setup функции.
• Настоятельно не рекомендуется мутировать аргументы use-функции напрямую. Только через сеттеры. readonly и shallowReadonly приветствуются.
• C осторожностью работать с источниками внешних данных в use-функциям. Работу с данными извне рекомендуется вынести в отдельную абстракцию. Лучше всего взаимодействовать с этой абстракцией в корне setup функции (чем очевиднее сайдэффекты, тем лучше).
• С осторожностью использовать хуки жизненного цикла компонента во вложенных use-функциях. Помнить о том, что хуки компонента во вложенных composable — это сайдэффект.
• Не рекомендуется передавать setupContext в use-функции. Если всё же решили пойти на этот шаг, то лучше передавать только ту часть setupContext, которая необходима этой use-функции. Также настоятельно не рекомендуется использовать getCurrentInstance.
• Всё взаимодействие между composable рекомендуется производить в корне setup функции.
• Настоятельно рекомендуется избегать вложенности в composable. Чем меньше вложенность, тем лучше. Предпочитать композицию use-функции вложенности.

И самое главное: декомпозиция через компоненты предпочтительнее декомпозиции через composable!

Если не получается решить проблему с помощью декомпозиции компонента, переходим к декомпозиции логики через composable

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

Так ли Composition API необходим?

Поделюсь инсайдами с интервью на позицию frontend developer к нам в Yclients. Первая часть собеседования — беседа с кандидатом, целью которой является оценка общего кругозора разработчика. Одним из наиболее популярных топиков является как раз Composition API. Сначала я прошу кандидата поделиться его личным мнением и опытом использования. Чаще всего это восторг и пересказ всё тех же хвалебных статей. В ответ от меня следует вопрос: “Какие главные проблемы предыдущего подхода решает Composition API?”.

Большинство кандидаты в этот момент немного теряются.

Не стану вас томить и сразу перейду к ответу, который дал Evan You в одном из обсуждений на GitHib:

• Большие компоненты (длиной в сотни строк) инкапсулирующие несколько логических задач.
• Потребность в переиспользовании логики между несколькими компонентами.

И я с ним полностью согласен, в этих аспектах Composition API действительно показывает себя с лучшей стороны. А теперь зададимся вопросом, как часто мы сталкиваемся с проблемами выше? В нашей кодовой базе под эти критерии подходят лишь 10–15% от всех компонентов, что также соответствует опыту Anthony Gore:

«Я просмотрел Vue 2 приложения, над которыми работал ранее (в основном небольшие), и обнаружил, что лишь 10–20% компонентов являлись многофункциональными или использовали миксины и могли бы выиграть от Composition API».

Стоит ли ради 10–20% кодовой базы переходить на новый подход? Не приведёт ли этот переход к ухудшению качества кода и усложнению логики (как это произошло в нашем случае)?

Итоги

Использовать Composition API можно и даже в некоторых случаях нужно, однако стоит помнить, что этот подход значительно более требователен к разработчику, нежели Options API. В неумелых руках этот инструмент способен принести больше вреда, чем пользы. Для снижения негативных последствий рекомендуется сформировать правила работы с Composition API. Кроме того, проблемы, для решения которых создавался Composition API, встречаются не так часто, как может показаться на первый взгляд.

И не бойтесь использовать Options API, он живее всех живых:

–  Станет ли Options API deprecated?

–  Нет, мы не планируем этого делать.

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

Примечание Статья написана нейросетью ChatGPT от OpenAI.

1. Что такое React и Vue
2. Что общего между React и Vue
3. Какие отличительные черты у React
4. Какие отличительные черты у Vue
5. Сравнение React и Vue

Что такое React и Vue

React и Vue — это JavaScript-фреймворки, которые используются для разработки веб-приложений.

React, разработанный Facebook, используется для создания компонентно-ориентированных приложений. Vue, написанный Эваном Яо, используется для создания простых и гибких приложений.

Оба фреймворка имеют активно развивающуюся сообщество и широко используются в промышленной разработке.

Что общего между React и Vue

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

Какие отличительные черты у React

React имеет следующие отличительные черты:

1. Компонентно-ориентированный: React ориентирован на создание компонентов, которые можно легко повторно использовать и составлять в более сложные компоненты.
2. Реактивность: React использует реактивную модель, которая автоматически обновляет представление при изменении данных модели.
3. Высокая производительность: React использует алгоритм Virtual DOM, который минимизирует количество изменений, которые нужно внести в реальное DOM, что повышает производительность приложения.
4. Состояние: React использует концепцию состояния, которая позволяет хранить данные, которые изменяются в приложении, в одном месте и управлять ими через специальный механизм.
5. JSX: React использует JSX, который позволяет написать компоненты в HTML-подобном синтаксисе, вместо использования чистого JavaScript. Это позволяет разработчикам легче визуализировать компоненты и более наглядно видеть их структуру.

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

Какие отличительные черты у Vue

Vue имеет следующие отличительные черты:

1. Легкость изучения: Vue имеет простой и интуитивно понятный API, который быстро может быть изучен новичками.
2. Реактивность: Как и React, Vue также использует реактивную модель, которая автоматически обновляет представление при изменении данных модели.
3. Компонентная система: Vue имеет систему компонентов, которая позволяет разбивать приложение на меньшие, легко повторно используемые и тестируемые части.
4. Шаблоны: Vue использует шаблоны в виде HTML-синтаксиса, что позволяет разработчикам легко визуализировать компоненты и более наглядно видеть их структуру.
5. Плагины и расширения: Vue имеет богатую экосистему плагинов и расширений, которые можно использовать для расширения функциональности приложения и упрощения разработки.
6. Простота интеграции: Vue может использоваться как для создания полноценных приложений, так и для интеграции с существующими проектами, благодаря тому, что он может использоваться как на стороне клиента, так и на стороне сервера.

Подробнее об отличительных чертах Vue можно прочитать здесь.

Сравнение React и Vue

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

1. Архитектура: React имеет более модульную архитектуру, где компоненты и состояние являются отдельными сущностями, в то время как Vue имеет более интегрированную архитектуру, где компоненты и состояние являются более связанными.
2. Возможности: React имеет более расширенные возможности для разработки более сложных и масштабируемых приложений, но Vue имеет более простой и интуитивно понятный API, что делает его более подходящим для новичков и менее сложных проектов.
3. Экосистема: React имеет более мощную и масштабную экосистему, с множеством инструментов и библиотек, которые могут быть использованы для разработки, в то время как Vue имеет более маленькую экосистему, но она более интегрирована и легко настраиваема.
4. Использование: React широко используется для разработки крупных и масштабных приложений, таких как веб-порталы и платформы, а Vue широко используется для создания менее сложных интерактивных веб-приложений, таких как корпоративные сайты и интерактивные веб-сайты.
5. Комьюнити: React разрабатывается и поддерживается компанией Facebook, имеет более крупное сообщество разработчиков и имеет более много инструментов и библиотек, которые могут быть использованы для разработки. Vue же разрабатывается и поддерживается сообществом.