VueJS *

Как я оптимизировала фронт на 40% и никто не заметил

Предыстория

Когда я помогала с поиском сотрудника и просматривала резюме на фронтенд разработчика, очень часто встречала фразу - "Оптимизировал(а) размер бандла на 30% / 40% / 50%, что увеличило ..." как под копирку от ИИ, а у меня из достижений в резюме - "делаю задачи и фикшу баги" 

Ну что ж, возьмем свое приложение и оптимизируем его

О приложении

Это небольшое SPA на Vue 3 для администрирования справочников. Ничего особенного, но это приложение экономит время программистам, которые не лезут в БД, и, как мне кажется, полезно для аналитиков и QA - это позволяет лучше понять, как устроена база, и почему иногда что-то не работает как ожидается.

Начнем оптимизацию

Запускаем npx vite-bundle-visualizer и получаем вот такую красивую розовую визуализацию (прикрепила бы скрин, на то что получилось, но в пост можно одну картинку добавить)

Смотрим роутинг у приложения... Все роуты импортируются сразу. Применяем легкий фикс:

• Оставляем синхронный импорт только для страниц, которые первыми открываются у пользователей

• Остальные подгружаем отдельно с помощью lazy import

// Было:
import PaymentTypes from '@/views/Directories/PaymentType/PaymentTypes.vue';
import OrderTypes from '@/views/Directories/OrderType/OrderTypes.vue';
import Configurations from '@/views/Directories/Configuration/Configurations.vue';
import NewConfiguration from '@/views/Directories/Configuration/NewConfiguration.vue';
import ConfigurationPage from '@/views/Directories/Configuration/ConfigurationPage.vue';
import Source from '@/views/Directories/Source/Source.vue';
import City from '@/views/Directories/City/City.vue';
import Brand from '@/views/Directories/Brand/Brand.vue';
import CloseReason from '@/views/Directories/CloseReason/CloseReason.vue';
import ChangeReason from '@/views/Directories/ChangeReason/ChangeReason.vue';
import Restaurants from '@/views/Directories/Restaurants/Restaurants.vue';
import RestaurantPage from '@/views/Directories/Restaurants/RestaurantPage.vue';
import NewRestaurant from '@/views/Directories/Restaurants/NewRestaurant.vue';
import Discounts from '@/views/Directories/Discounts/Discounts.vue';
import PriceTypes from '@/views/Directories/PriceType/PriceTypes.vue';

// Стало:
  children: [
            {
                path: 'brand',
                name: 'Бренды',
                component: () =>
                    import('@/views/Directories/Brand/Brand.vue'), // <--тут
                meta: {
                    breadcrumbs: ['Справочники', 'Бренды'],
                    requiresAuth: true,
                    permissions: ['admin.admin'],
                    title: 'Бренды',
                    section: 'directories',
                },
            },
...
]

Запускаем снова и уже получаем уже разбитый бандл. Code Splitting работает, вывод сборки теперь показывает множество маленьких JS-файлов для каждой страницы.

Итоги оптимизации:

Уменьшили основной бандл с 245 kB до 148 kB (gzip) — это минус 39%

Что получили:

• ✅ Оптимизировала размер бандла на 40%

• ✅ Улучшила First Contentful Paint

• ✅ Внедрила code splitting

• ✅ Повысила производительность

• ✅ Уменьшила основной JavaScript-файл почти на 40% (в gzip)

• ✅ Уменьшила сырой размер на 46%

• ✅ Теперь загружается только то, что нужно для текущей страницы

Реальность:

• ❌ Съэкономил ли бизнес деньги? - Нет

• ❌ Выросла ли конверсия? - Как? 🌝 это внутренний админ-интерфейс

• ❌ Применили ли чудо-технологию? - Нет, добавили lazy import из коробки фреймворка и рекомендацией из документации

• ❌ Кто-то это заметил? - Только я в отчете, "на глаз" даже мне не заметно

• ❌ Заметил ли пользователь? - Нет, потому что основное время все равно уходит на получение данных с backend

Мысли по этому поводу

И так, мы теперь можем добавить заветную строчку в резюме!

А вы встречаете эту строчку в резюме?

• Какие чувства она у вас вызывает?

• Красный флаг ли она для вас?

• Или наоборот - показатель того, что человек думает о производительности?

Мой канал о поиске работы (ничего не продаю и не рекламирую, только себя)

Выбор вакансии: как я кинулась во всё — и это не дало результата.

Есть разработчики, у которых развитие идёт линейно и предсказуемо: верстальшик → джун фронтендер → мидл → мидл в сильной компании → сеньор/лид/уход в бэкенд

Красиво. Понятно. Логично.

Но у меня кривая черта развития сначала бэк на Java в закрытом предприятии. Потом фулстек в фудтехе: в основном Vue, но ещё и Go (и все сопутствующее), и CUBA Platform (lowcode на java, он же «Тезис»), и n8n.

Широко. Разнообразно. Интересно.

Как я начала откликаться - на всё, что блестит

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

1. Frontend - Vue / React / Angular
   Ну фронт же. Есть мнение, что «не нужно учить конкретный фреймворк — важны принципы».

2. Go
   а почему бы нет? Знаю , умею , курсы закончены, писала на нем

3. Fullstack (Go или JDK + фронт)

4. N8N, автоматизаторы особенно с ИИ
   Интересно. Растущее направление.

5. Lowcode платформы CUBA, тезис, WebTutor - замаскированный под фронтенд Опыт есть. Почему не использовать?

И это фатал еrror

1. Ошибка №1. Переключение контекста
   Очень сложно переключать контекст и даже синтаксис языка - на первом собесе по TS я не смогла вспомнить синтаксис (на ум приходил только java, так как он изучался более долго и в закрытой среде, ирония: хоть я на нем и не пишу, но разбуди среди ночи - код напишу)

2. Ошибка №2. Рынок
   Рассматривать вакансии на Angular, React без опыта в продакшене - на данный момент наивно.
   
   Рынок перегрет:
   - Vue ~ 1000 откликов за неделю,
   - React - 4000 ,
   
   Неужели Арина (или тот кто читает эту статью) ты думаешь, что кто-то будет рассматривать ваше резюме со Vue? Каким бы в целом хорошим инженером вы не были. Рынок не покупает «в целом».

3. Ошибка №3. Fullstack со связкой Go + Vue или JDK + Vue
   Фуллстеки со связкой go или jdk - это бред вакансии, это карьерный тупик.
   - PHP + Vue - норм
   - Node + Vue - норм,
   но Go + Vue - это нонсенс, это только подработка для поддержания штанов. Чаще это небольшие команды, поддержка, нестабильные проекты.

4. Ошибка №4. n8n — нравится, но это уже не совсем разработка
   Автоматизация, интеграции, AI — это интересно. Но это больше аналитика и orchestration, чем классическая инженерия. Если хочешь быть разработчиком — нужно понимать, куда ты смещаешь фокус.

5. Ошибка №5. Low-code — карьерный тупик
   Проблем с окружением больше. Кода меньше. Рынок уже. Ты становишься зависимой от конкретной платформы. И выйти обратно в «чистую разработку» становится сложнее.

Мой Hotfix: Фокус

Я поняла, что на падающем рынке выживают либо "универсалы" c ИИ подбоком, либо эксперты

Моя новая стратегия:

• Vue 3 + TypeScript + Nuxt (как зона роста)

• n8n — как подработку и интересный дополнительный навык.

Иногда рост — это не добавить ещё стек. А убрать лишнее.

Почему у PWA до сих пор нет полноценного «магазина приложений» — возможно ли это вообще?

Всем привет.

В течение последних месяцев, работая с PWA-приложениями, мы постоянно сталкивались с одним и тем же вопросом:

Почему в 2025 году у PWA до сих пор нет настоящего App Store?

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

При изучении существующих PWA-магазинов и каталогов обнаруживаются одни и те же повторяющиеся проблемы.

⸻

1. Установка остаётся непонятной для пользователей

Даже сегодня установка PWA вызывает затруднения у обычных пользователей.

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

Во многих PWA-каталогах всё ограничивается текстовой инструкцией — и на этом взаимодействие с сервисом фактически заканчивается.

⸻

2. Отсутствие доверия

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

Со стороны разработчиков наблюдаются крайности:
• либо любой может опубликовать приложение без подтверждения права собственности,
• либо проверка обязательна, но сложна и ограничена одним способом (например, через DNS-записи).

В итоге доверие не формируется ни у одной из сторон.

⸻

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

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

Экосистема не стимулирует разработчиков поддерживать и развивать свои PWA.

⸻

4. Интерфейс не воспринимается как «нативный»

Это тонкий, но важный момент.

Если магазин:
• выглядит как обычный веб-сайт,
• не вызывает ассоциаций с App Store или Google Play,

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

⸻

При этом сами PWA как технология за последние годы заметно повзрослели: офлайн-режим, push-уведомления, installability, Web APIs.
Однако именно слой распространения и доверия остаётся самым слабым звеном.

⸻

Главный вопрос, к которому мы пришли

Возможно ли вообще создать PWA-магазин, который:
• пользователи будут воспринимать как настоящий магазин приложений,
• не станет источником боли для разработчиков,
• сможет устойчиво развиваться, а не быть заброшенным через несколько месяцев?

Или же сама идея магазина PWA в текущей экосистеме изначально ошибочна?

Будет интересно узнать ваш опыт.

Вы публиковали PWA-приложения в существующих магазинах или каталогах?
Что вызывало наибольшие сложности — у разработчиков или у пользователей?

пет-проект невозможно доделать - только выпустить в открытую бету

Что ж, встречайте открытую бету проекта

📚📚📚📚📚📚📚📚📚📚
SweetReader!
📚📚📚📚📚📚📚📚📚📚

Что это:
Пространство для авторов и читателей, упор сделан на книги с высоким уровнем визуала (графические романы, комиксы, манги, книги с упором на иллюстрации). 

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

На текущий момент это MVP - буквально базовая версия продукта, есть планы по его доработке и даже (о, ужас) "дорожная карта", которую, может быть, я реализую )))

_____

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

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

Обновили кейс с Гринатом — и не просто освежили текст, а напомнили себе, насколько масштабный и значимый это проект.

Разработка Платформы доверенных сервисов (ПДС) продолжается, и вместе с АО «Гринатом» мы последовательно развиваем систему, которая стала цифровым фундаментом юридически значимого документооборота в атомной отрасли.

В рамках проекта мы реализовали:
— выпуск и учёт всех типов электронных подписей (УКЭП и УНЭП);
— автоматизированную систему управления сертификатами и СКЗИ;
— интеграцию с кадровыми базами, ЕСИА и СМЭВ;
— удобные API для других ИТ-систем;
— масштабирование до 100 000+ пользователей.

Впереди — новые этапы развития: интеграция с ЕБС и другими сервисами. Мы продолжаем делать ПДС удобным, масштабируемым и устойчивым решением для всей отрасли.

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

➡️ Читать статью

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

https://www.npmjs.com/package/svgue

Легковесный компонент, без "лишнего багажа" и простой в использовании.

Обновил Блог!

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

Теперь он новый, свежий, минималистичный и с доработками.

Подробнее в статье

Также буду благодарен, если найдёте баги - пишите о них в комментариях.

Если у вас в Vite проекте есть данные в json файлах, то иногда удобней работать с json5 (+комментарии и переносы строк, как минимум)

Для этого надо:

1. Поставить Vite плагин vite-plugin-json5

2. Поставить расширение json5 для VS Code для подсветки синтаксиса

3. Чтобы не ругался TypeScript, прописать в index.d.ts:

declare module "*.json5" {
  const value: any;
  export default value;
}

Стало намного удобней.

Бандл не меняется.

Посчитай свой кредит!

Как и обещал в прошлом посте - чуть более серьезный проект:

Калькулятор Кредита

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

Все инструменты для этого, которые находил, мне не нравились - поэтому сделал свой.

Самый быстрый, удобный и красивый калькулятор кредита!

Сохранение данных (даже в ссылке), диаграмма, таблица платежей и % переплаты - все на месте.

Наслаждайтесь)

Кнопка со счётчиком: React vs Fusor

Fusor это новый способ разработки вэб приложений https://github.com/fusorjs/dom

Производственный календарь

Мини-сервис, который позволит удобнее выяснить свою ЗП (аванс и оплату)

Открыт к предложениям по улучшению

Вышла Vue 3.5.0-beta.1

В ней уже есть useTemplateRef - функция, заменяющая нынешний способ определения шаблонного рефа (template ref).

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

Теперь привязка будет по строковому ключу

При попытке пользователя уйти с сайта (exit-intent), можно показывать сообщение (просьба остаться, предложение сохранить сделанные изменения и т.п.)

Вот Vue 3 композабл для этого
------

_{Telegram-канал о Vue.js и фронтенд-разработке: @vuefaq, вебсайт: Vue‑FAQ.org}

Связи между компонентом и слотом во Vue 3

В отношениях родитель-ребенок-слот содержимому слота ребенок может передавать пропсы, как указано во Vue.js документации:

<!-- <MyComponent> template -->
<div>
  <slot :text="msg"></slot>
</div>

<MyComponent v-slot="{ text }">
  {{ text }}
</MyComponent>

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

<!--   FormField   -->
<script setup>
const touched = ref(false);
</script>

<template>
  <div class="form-field">
    <slot :touch="() => { touched = true }" />
    ...    
  </div>
</template>

<!-- использование -->
<FormField v-slot="{ touch }">
  <BaseInput @input="touch()" />
</FormField>

Этот хак бывает очень полезен и не выходит за рамки правила: "Пропсы вниз, события вверх".

Источник

Аргументация против глобальных автоимпортов (типа тех, что в Nuxt)

1. Это явно - ты всегда видишь, откуда взялся компонент и в один клик можешь провалиться в него, а не в *.d.ts ;)

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

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

4. Не нужно генерировать портянку *.d.ts для того, чтобы редакторы видели их, и, как следствие, без них ты получаешь более качественный тулинг и анализ твоего кода

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

6. Импорты может проставлять сама IDE, а еще их можно сворачивать в 1 строку, если визуально отвлекают

Источник

Разница между адаптивностью (слева) и отзывчивостью (справа)

Во Vue 3, чтобы выделить из компонента отдельно некий функционал с реактивным состоянием, были созданы composable функции (называемые "функциями", хотя по сути это объект созданный через js замыкание - closure).

Чтобы использовать функционал с реактивным состоянием между несколькими компонентами, можно задействовать js модули либо Pinia/Vuex сторы.

Иногда нужно нечто среднее - подобную сущность с реактивным стейтом и функционалом на нем, но используемую в нескольких связанных компонентах (например, в Tabs или каких-то виджетах), - то есть, в некотором локальном контексте. Для этого можно в общем родительском компоненте создать composable, который передать потомкам - либо через provide/inject (лучше), либо через props (не надо).

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

// Vue 3
const app = createApp(App);
app.config.errorHandler = (err) => {
  alert(err);
};

Во Vue можно создать собственный обработчик ошибок и ворнингов для лучшей обработки ошибок для улучшения UX.

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

Обработчик ворнингов работает только в dev режиме.

29 и 30 июня 2024 года Certificates.dev бесплатно на 48 часов откроет доступ к тренировочным материалам на соискание ученой степени Certified Vue.js Developer.

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

------

Наш Telegram-канал о Vue и фронтенд-разработке: @vuefaq и вебсайт: Vue‑FAQ.org.

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

Но:

1. Это не композабл по определению

2. Там не обязательно рефы

3. Они не "глобальны"

В общем случае структура данного объекта - экспортируемые из ES модуля реактивные данные и функции для работы с ними.

Функционально они заменяют "сторы" Pinia. Называть их тоже stores - двусмысленно и нелогично. Вообще, молиться на "глобальный стейт" после появления идеи JavaScript signals и их всевозможных реализаций, включая Vue Reactivity API, архаично.

Мне кажется, самое подходящее название для данной конструкции - [реактивный] бизнес объект (РБО) или Vue Business Object (VBO). В них инкапсулируется логика предметной области и приложения, они не привязаны к конкретным компонентам, и по аналогии с другими языками и фреймворками, этот паттерн - Business Object, - выглядит вполне подходящим.

Техническая реализация может быть через ES классы, ES модули, closures, Pinia stores, с использованием singleton или DI.

Кроме того, позиционирование именно как "бизнес объект" будет требовать явного отделения от него презентационного и инфраструктурного слоев - работы с Backend API, например. То есть, стимулировать использование лучших практик и наработок из других сфер разработки ПО, еще более переводя Vue.js из фреймворка для небольших проектов в разряд enterprise level решений.

--------------

Telegram-канал о Vue и фронтенд-разработке: @vuefaq и вебсайт: Vue‑FAQ.org.