Обновить
512K+

JavaScript *

Прототипно-ориентированный язык программирования

217,67
Рейтинг
Сначала показывать
Порог рейтинга

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

Но недавно все-таки удалось использовать паттерн фабрику для фронта и моему счастью не было предела, когда после 30-минутного рефакторинга разъехавшейся вёрстки через Claude, я попросила: "брат, слушай это ж паттерн фабрика, сделай BaseModal тонким, который просто решает, какой компонент отрисовать"

Технически, классический GoF Factory Method подразумевает наследование, а здесь у меня скорее Simple Factory — функция, выбирающая что создать. Но в обиходе все называют это "фабрикой", и я не буду усложнять.

Классический паттерн фабрика на Java:

// Интерфейс
interface Modal {
    void open();
    void close();
}

// Конкретные реализации
class Dialog implements Modal { ... }
class BottomSheet implements Modal { ... }
class FullscreenSheet implements Modal { ... }

// Фабрика — решает какой класс создать
class ModalFactory {
    static Modal create(String type, boolean isMobile) {
        if (!isMobile) return new Dialog();

        return switch (type) {
            case "bottom-sheet" -> new BottomSheet();
            case "fullscreen"   -> new FullscreenSheet();
            default             -> new Dialog();
        };
    }
}

// Использование
Modal modal = ModalFactory.create("bottom-sheet", isMobile);
modal.open();

Как это работает во Vue?

На фронте есть <component :is="..."/> - динамический компонент, который рендерит то, что ему передадут. Это и есть наш аналог ModalFactory.create(...).

<!-- BaseModal.vue — фабрика -->
<template>
    <component
        :is="modalComponent"
        v-bind="$props"
        @close="emit('close')"
    >
        <slot />
    </component>
</template>

<script setup>

// Фабричный метод — выбирает компонент
const modalComponent = computed(() => {
    // Desktop → всегда Dialog (центрированный)
    if (!isMobile.value) return BaseDialog

    // Mobile → зависит от mobileStyle
    switch (props.mobileStyle) {
        case 'fullscreen':
            return BaseFullscreenSheet
        case 'bottom-sheet':
            return BaseBottomSheet
        default:
            return BaseDialog
    }
})
</script>

Получился BaseModal, который сам почти ничего не делает.

Он не знает, как устроен dialog.
Не знает, как анимируется bottom sheet.
Не знает, как выглядит fullscreen-модалка.

Он просто маршрутизирует:

BaseModal.vue  
  ├─ BaseDialog.vue    
  ├─ BaseBottomSheet.vue    
  └─ BaseFullscreenSheet.vue  

А каждая конкретная реализация живёт отдельно и отвечает только за себя.

Почему это лучше, чем один большой компонент?

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

<!-- Каша в template -->
<div
    class="modal"
    :class="{
        'modal--open': open,
        'modal--mobile': isMobile,
        'modal--desktop': !isMobile,
        'modal--fullscreen': isMobile && mobileStyle === 'fullscreen',
        'modal--bottom-sheet': isMobile && mobileStyle === 'bottom-sheet',
    }"
>

А потом туда добавляются:

  • разные анимации

  • разные отступы и размеры

  • разное поведение закрытия

  • разные transition

  • разные layout-правила

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

С фабрикой проще:

  • BaseDialog отвечает за centered dialog

  • BaseBottomSheet отвечает за bottom sheet

  • BaseFullscreenSheet отвечает за fullscreen

  • BaseModal только выбирает, что показать

То есть вместо одного монолита появляется тонкий слой выбора и несколько изолированных компонентов.

И кстати, поделитесь: насколько паттерны актуальны сейчас? Или про них всё рассказали 20 лет назад и хватит говорить о них?

Теги:
+2
Комментарии2

Как настроить доступ к Избранному — без ЛК и авторизации на сайте

Привет, Хабр! Меня зовут Катя Плаксина, я фронтенд-разработчик в Далее. Хочу поделиться решением, которое позволило реализовать возможность сохранения в Избранное без авторизации для пользователей одного крупного портала.

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

В чем технический вызов

Если страница работает через SSR, например, на Astro, серверу нужны данные заранее. Но если весь «источник правды» лежит в localStorage, сервер их не видит — браузерное хранилище доступно только на клиенте. 

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

Разделяем хранилище на два слоя

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

Легкий SSR-снапшот размещаем в cookie, кладем только favorites_preview:

  • первые 3–4 ID в каждой категории,

  • активные теги,

  • размер.

Сервер читает cookie и рендерит превью Избранного.

Что происходит после гидратации

Когда страница загрузилась, клиент сравнивает cookie и localStorage, дотягивает расхождения, корректно показывает или скрывает пустые состояния.

Чтобы избежать ошибок:

  • Добавляем mounted-флаг — не используем браузерные API во время SSR.

  • Настраиваем синхронизацию между вкладками через системное событие storage.

  • Используем кастомное событие favorites:changed для текущей вкладки. Storage в ней не срабатывает.

В итоге состояние Избранного остается консистентным во всех вкладках.

Почему не хранить всё только в cookie

Можно было ограничиться одним механизмом — хранить Избранное полностью в cookie. Но у такого подхода есть явные минусы:

  • cookie ограничены по объему,

  • перегрузка HTTP-запросов,

  • неудобное управление состоянием на клиенте.

Если хранить всё только в cookie, страдают производительность и масштабируемость решения.

Что получаем в итоге

  • На клиенте остается полноценное управление состоянием через localStorage.

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

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

Буду рада узнать о вашем опыте реализации подобных задач в комментариях.

Теги:
+1
Комментарии0
Герое-подобная игра в браузере
Герое-подобная игра в браузере

Поскольку в голосовании в предыдущей статье победил вариант с AI, сделал пока простенький его вариант.

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

На очереди: стрелки, летуны и статичные объекты.

Ссылки, чтоб потыкать: netlify, ITCH.

Теги:
+2
Комментарии0

Мультиязычность. Ад для разработчика.

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

И понеслась...

Процесс перевода движка
Процесс перевода движка

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

Вайбкодеры меня наверняка закидали бы тапками, мол - все можно автоматизировать и перевести хоть тонну файлов за 20 минут. Но - мне это не в кайф =)

Кто хочет помочь в процессе перевода, а заодно и движок потестить - милости прошу: https://github.com/pechoradev/BloggyCms

Теги:
+2
Комментарии4

Вышла пятая версия открытого проекта windows95 с исходным кодом полностью на JavaScript. «Это Windows 95, работающая в приложении Electron. Да, это полная версия. Извините», — пояснил разработчик решения.

Проект работает в Windows, а также на macOS и Linux, что подарит вам ностальгию или возможность обойти ограничения старой операционной системы независимо от вашей текущей платформы.

Теги:
+4
Комментарии2

Вместе с сообществом Moscow JS приготовили классную программу с двумя потоками докладов про:

  • performance и масштабирование фронтенда,

  • внедрение LLM в продукты и процессы,

  • изменение инженерной практики и культуры

От X5 Tech — сразу два прикладных кейса:

  • Как внедрять LLM в прод без перестройки архитектуры

  • Web-First в мобильных приложениях: офлайн, файлы, Workbox и ключевые подводные камни

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

📆 30 апреля, 18:30
Москва, Мясницкая, 13, с20

🔗 Регистрация по ссылке

Программа:

«Перформанс без головной боли: Системная оптимизация фронтенда в большой команде» (Мирзоев Руслан, Premier.one)

Доклад основан на реальном опыте команды из 24 разработчиков, столкнувшихся с критическими показателями LCP. Мы разберем комплексный подход к ускорению продукта: от «фундамента» (анализ бандла, Tree Shaking и борьба с циклическими зависимостями) до продвинутых стратегий рендеринга, таких как ISR и оптимизация внутренних запросов при SSR (перевод на internal hosts).

Вы получите набор готовых рецептов по работе с ассетами (SVG, шрифты, сжатие) и узнаете, как выстроить культуру производительности с помощью Performance Budgets, чтобы предотвратить регрессии в будущем

«Веб-компоненты: плохая реализация хорошей идеи» (Евгений Кучерявый, larana.tech)

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

«LLM в продакшене: от идеи до внедрения за неделю» (Артем Шкуренко, Х5 Tech)

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

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

«Вторая жизнь инженерных практик: как ИИ делает сложные подходы наконец-то удобными» (Вадим Царегородцев, Frontend Guild Lead в островке)

За последние годы индустрия накопила множество инженерных практик: ADR, Clean Architecture, TDD, архитектурные границы, строгие правила зависимостей.

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

Появление LLM меняет эту ситуацию.

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

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

«А доки где? Пишем продуктовую документацию» (Егор Левченко, Wildberries & Russ)

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

«Секретная жизнь фотографий в Клубе Тайных Покупателей X5» (Артур Басак, Х5 Tech)

Поговорим о подходе Web-First в мобильных приложениях. В частности о том, как работать с файлами, про удобство и ограничения Workbox, нюансы оффлайн-режима и о какие подводные камни можно споткнуться.

Инженерная культура и переход на «бигтех-рельсы»

Круглый стол с экспертами: Глеб Михеев, Роман Троицкий (состав уточняется…)

Модератор: Иван Сизов, техлид фронтенд X5 Digital

Теги:
+4
Комментарии0

Вторая часть курса по JavaScript уже доступна 💻

Привет, Хабр! Массивы, объекты, операторы, DOM — если вы еще не работаете с ними, проходите бесплатный курс «Первые шаги в JavaScript». Во время обучения вы освоите базовый синтаксис и конструкции языка, а затем напишете пет-проект.  

Вторая часть состоит из пяти модулей. После курса вы сможете:

  • изучать более продвинутые фреймворки и библиотеки;

  • понимать архитектуру простых веб-приложений;

  • писать скрипты, управлять DOM и изменять интерфейс веб-страниц.

Осваивайте практические навыки с помощью IT-инфраструктуры Selectel — промокод на бесплатный доступ уже ждет на курсе. После успешного прохождения финального теста пришлем именной сертификат.

Начните обучение прямо сейчас →

Теги:
Всего голосов 4: ↑3 и ↓1+7
Комментарии3

Cursor или Harvi Code: какой ИИ для кодинга в 2026 году реально работает в России без VPN и головной боли с платежами

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

Cursor — это сейчас, пожалуй, самый продвинутый AI-редактор на рынке. По сути, это VS Code, в который встроили настоящий искусственный интеллект на стероидах. Composer позволяет одной командой править сразу десяток файлов, агент понимает весь проект, хорошо справляется с рефакторингом, поиском багов и даже архитектурными решениями. Качество кода от Claude Sonnet 4.5 или свежих GPT часто вызывает искреннее «вау».

Но есть большая ложка дёгтя. Cursor — американский продукт, и российские карты он не принимает. Чтобы купить подписку Pro, приходится либо использовать виртуальные карты через крипту, либо платить посредникам (Oplatym и подобные), либо покупать готовые аккаунты (что рискованно). Сам редактор после оплаты работает без VPN, но первоначальная настройка оплаты — это отдельный квест. Бесплатная версия быстро упирается в лимиты, особенно если активно юзаешь мощные модели.

Harvi Code Первый в России AI кодинг-агент. Российский ответ на все эти заморочки. Это полноценный AI-агент прямо внутри VS Code. Пишешь задачу в чате — он генерит код, рефакторит, фиксит баги, работает с контекстом всего проекта. Не тормозит, контекст держит хорошо, интерфейс привычный.

Самое приятное — модели на любой бюджет. Есть топовые (Claude Sonnet 4.5, GPT-5.4 и другие). А главное — очень низкая стоимость токенов. Для каждой модели есть свой коэффициент стоимости. Для большинства повседневных задач их хватает с головой, и можно вообще почти не тратить деньги. Оплата — российскими картами или СБП, без всяких посредников и VPN.

Коротко по делу:

  • Если тебе нужен мощный multi-file agent и ты готов один раз настроить оплату через проверенного посредника — бери Cursor. Он до сих пор в топе по возможностям.

  • Если хочешь работать стабильно, без лишних телодвижений и не думать каждый месяц про «как бы оплатить» — Harvi Code сейчас выглядит гораздо практичнее для российского разработчика.

А вы как сейчас кодите с ИИ? Пробовали оба варианта? Что в итоге оставили в основном редакторе? Пишите в комментариях, интересно почитать реальный опыт.

Теги:
Всего голосов 4: ↑0 и ↓4-4
Комментарии0

Обновления в подборках обучающих материалов и курсов от Selectel

Привет, Хабр! На дворе пятница, а значит, пришло время для нашей нерегулярной рубрики с полезными материалами для новичков. Как всегда, все бесплатно, учитесь и развивайтесь. И вот с чем я сегодня пришел.

  • Начало работы с ML-моделями. Это подборка статей в Академии Selectel. Изучите базу по алгоритмам, научитесь подбирать железо и настраивать инфраструктуру и мое любимое — подборка в подборке — узнаете, что еще полезного по теме можно почитать/посмотреть.

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

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

Теги:
Всего голосов 4: ↑4 и ↓0+8
Комментарии0

Всем хабровчанам удачной недели!

Хотел поинтересоваться такой темой как школа «Result/University». Кто обучался, как быстро удалось найти работу? Какова оценка по 5 шкале?

Смогут ли ребята ввести в данную тему с минимальными рисками?

Теги:
Всего голосов 2: ↑0 и ↓2-2
Комментарии21

Solid.js должен был исправить React…но доказал, что React был прав

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

Представьте: одни данные загрузились, другие ещё нет. Что покажет интерфейс? Фейковый фронтенд, который обманывает пользователя. React решал это с помощью отложенного обновления. Тогда Solid решили встроить ассинхронность прямо в реактивность. Появилось управление загрузкой, ожиданием и обновлениями — реактивность как она есть. Становится понятно, что и та, и та команда приходят к одному выводу с разных сторон, но Solid делает ее частью системы, засовывает ассинхронность прямо в реактивность и внезапно оказывается, что React не был таким уж и плохим дизайном, просто команда React-а пришла к этой проблеме гораздо раньше, чем остальные.

И главный вопрос: что важнее — устоявшийся подход React или более чистая, но сложная реактивность Solid? Или дело вовсе не в фреймворке, а в том, как ты управляешь асинхронностью?

https://dev.to/playfulprogramming/two-react-design-choices-developers-dont-like-but-cant-avoid-d6g

Подписывайтесь: YouTube | VK | Twitter

Теги:
Всего голосов 2: ↑0 и ↓2-2
Комментарии2

Представлен открытый мультиплатформенный проект Snowify. Это аналог Spotify в виде музыкального плеера с кодом на JavaScript без рекламы и без регистрации. Музыка стримится с YouTube Music. Все функции Spotify на месте: списки треков, текст песен, плейлисты с рекомендациями и даже синхронизация с облаком. При этом в интерфейсе нет ничего лишнего, что отвлекало бы от музыки. Проект поддерживает кастомные плагины.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии2

Расширение AI-Less Habr — Чистим Хабр от ИИ

Надоела лента, забитая ИИ? У меня есть готовое решение для вас. Shut up and take my money:

Интерфейс расширения
Интерфейс расширения

Расширение для Chrome (и совместимых браузеров) позволяет скрывать статьи про «Искусственный интеллект». Скрывается не контент, написанный ИИ (LLM), а контент про ИИ (что сейчас обычно под этим подразумевается). Бесконечные статьи об очередной революции, вызванной тем, что такая‑то LLM модель опередила конкурентов на 0.1 балл в одном из 186 имеющихся бенчмарков, и вот этот вот всё.

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

Есть следующие возможности:

  • скрывать хаб «Искусственный интеллект»

  • скрывать по словам в заголовке (настраиваемый список)

  • скрывать по тегам (настраиваемый список)

  • инвертированный режим (показать, попадающее под фильтры, и скрыть остальное)

По умолчанию включено только скрытие хаба «Искусственный интеллект». Фильтры по словам/тегам с большей вероятностью допускают ложноположительные срабатывания, поэтому выключены по умолчанию. По этой же причине в фильтрах по словам по умолчанию нет слов «ии»/«ai», так как есть достаточно много статей, содержащих что‑то вроде «без ИИ». Внимательно относитесь к добавлению слов в фильтры, чтобы минимизировать ложноположительные срабатывания.

Теги:
Всего голосов 16: ↑16 и ↓0+22
Комментарии4

Ближайшие события

Сделал интерактивный квиз!

Ознакомительная статья

экран лобби, стримит хост
экран лобби, стримит хост


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

Делал долго, мой магнум опус.

Теги:
Всего голосов 4: ↑3 и ↓1+2
Комментарии0

Гибкое управление фокусом элемента

Chrome в 145 версии добавил параметр focusVisible в метод focus:

input.focus({ focusVisible: true });

Как вы уже, наверное, догадываетесь, это позволяет самостоятельно управлять тем, будет ли элемент при ручном вызове фокуса, помимо CSS-псевдокласса :focus, соответствовать ещё и :focus-visible.

Ранее без данного параметра браузер самостоятельно решал этот вопрос.

⚙️ Поддержка браузерами широкая
🔗 Мой телеграм канал

Теги:
Рейтинг0
Комментарии0

Как я оптимизировала фронт на 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

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

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

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

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

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

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

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

Теги:
Всего голосов 8: ↑6 и ↓2+5
Комментарии4

Недавно общался с крупной зарубежной продуктовой компанией. Штат 500–1000 человек, вроде зрелые процессы, ЗП у разрабов 5000 баг-репорты по ISO/IEC/IEEE 29119. И при этом:

«Не успеваем уделять время автотестам. Сфокусированы на скорости разработки и релизах.»

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

— «Слишком частые релизы» → А не потому ли они такие частые, что баги проскакивают на прод?

— «Требования постоянно меняются» → Тем более — как вы контролируете, что старое не ломается?

— «И так работают наизнос если еще и тесты заставить писать — выгорят» → А не от бесконечного ли футбола с багами они выгорают?

А как у вас? Есть автотесты на проекте? Или тоже «не до них»?

Я написал целую статью на эту тему, если все выше вам откликается рекомендую к прочтению: Нет времени на тесты — через неделю релиз

Теги:
Рейтинг0
Комментарии0

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

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

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

Но у меня кривая черта развития сначала бэк на 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 — как подработку и интересный дополнительный навык.

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

Теги:
Всего голосов 5: ↑3 и ↓2+2
Комментарии5

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

Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).

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

С чего начали

Для обычных пользователей:
• Email / пароль
• Google
• GitHub

Для разработчиков — жёстче:
• Обязательная привязка Google
• Обязательная привязка GitHub

Логика казалась разумной:
«Разработчик = есть GitHub»
«Двойная верификация = меньше спама»

На практике это не сработало.

Первые тревожные сигналы

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

Сначала списывали на:
• новый продукт
• низкое доверие
• отсутствие аудитории

Но после общения с разработчиками (в том числе через Habr) картина прояснилась.

Что отпугивало разработчиков

  1. Новый сервис → нежелание делиться данными

Даже если это «просто email», психологический барьер остаётся.

Когда с первого шага нужно:
• линковать внешние аккаунты
• проходить несколько этапов подтверждения
• подключать сторонние сервисы

это воспринимается как лишний фрикцион.

Особенно для соло-разработчиков и небольших команд.

  1. Git ≠ GitHub

Ключевой инсайт.

Мы обнаружили, что:
• не все хотят логиниться через GitHub
• часть использует GitLab или Bitbucket
• некоторые принципиально не хотят связывать GitHub с новым сервисом

Обязательная привязка GitHub стала серьёзным барьером.

А мнение стандартных пользователей разделилось:

Часть говорила:

«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».

Логика простая:
• если есть Google / Facebook / Discord — значит не ноунейм
• интеграции с крупными сервисами повышают доверие

Это не про безопасность — это про ощущение легитимности.

Другие говорили ровно противоположное:

«Слишком много кнопок — ощущение перегруженности».

И это тоже справедливый аргумент.

Что мы изменили

  1. Упростили форму для пользователей

Оставили:
• Google
• Facebook
• Discord

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

  1. Git-провайдеры вынесли в отдельную группу

Под отдельной кнопкой:
• GitHub
• GitLab
• Bitbucket

Для разработчиков это стало понятнее и логичнее.

  1. Убрали обязательный GitHub

Теперь для developer-аккаунта нужно подключить любой Git-аккаунт, если ни один не подключён.

Без принудительного GitHub.

Первые цифры (осторожно)

Прошла всего неделя, выборка маленькая, платформа всё ещё молодая.

Тем не менее:
• Зарегистрированные пользователи: +13%
(было 0–6% в неделю)
• Зарегистрированные разработчики: +16%
(было 0–3%)

Похоже, это те разработчики, которые знали о платформе, но их останавливало требование GitHub.

Выводы (пока не финальные)
• OAuth — это не только безопасность, но и психология доверия
• Жёсткие требования на старте почти всегда бьют по росту
• Git ≠ GitHub — и это важно
• Много провайдеров могут как повышать доверие, так и перегружать UI

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

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

Теги:
Всего голосов 4: ↑3 и ↓1+2
Комментарии2
1
23 ...