📎 React, Vue, Svelte — разные догмы, одни и те же боли

Кажется, вот он — новый порядок, чистый код, свежий старт. А потом снова файл на 600 строк и состояние, которое живёт своей жизнью. И вы ловите дежавю.

❓ Что бы вы сделали:

🔥 — Выбрали новый фреймворк
❤️ — Переписали старый проект с нормальной архитектурой

🔤 Как это сделать — разбираем на курсе «Архитектуры и шаблоны проектирования» (−40%)

🐸 Библиотека фронтендера

#code_battle

🧑‍💻 Clean Architecture vs Pragmatic Architecture

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

🈂️ Clean Architecture

— Чёткие слои и зависимости
— Контракты, интерфейсы, unit-тесты
— Легко масштабировать и поддерживать

🈂️ Pragmatic Architecture

— Меньше слоёв, больше пользы
— Фокус на фичах, а не абстракциях
— Решения под задачу, а не под учебник

Голосуем реакциями:

👍 — Clean Architecture
❤️ — Pragmatic Architecture

🐸 Библиотека фронтендера

#code_battle

👍 Задача для джуна+

Что выведет этот код и почему ❓

Подумайте, в каком порядке выполняются присваивания и как JS обрабатывает ссылки на объекты. Это частый вопрос на собесах, где проверяют понимание порядка вычисления выражений и поведения ссылок.

💭 Ответ оставляйте в комментариях

🐸 Библиотека фронтендера

#code_challenge

😸 Разбор задачи

Ранее мы выкладывали задачу для джуна+.

Сегодня разберем, что происходит в этом коде и как работают присваивания и ссылки на объекты в JavaScript.

🔤 Разбор:

1. let a = { n: 1 }; — создаём объект { n: 1 } и присваиваем его переменной a.

2. let b = a; — b теперь ссылается на тот же объект, что и a.

3. a.x = a = { n: 2 }; —

• Присваиваем новому объекту { n: 2 } переменную a.

• После этого свойству x объекта { n: 2 } присваиваем сам объект { n: 2 }.

4. console.log(a.x); — выводит undefined, так как свойство x в новом объекте { n: 2 } не было установлено.

5. console.log(b.x); — выводит объект { n: 2 }, потому что b ссылается на старый объект { n: 1 }, который теперь имеет свойство x, указывающее на { n: 2 }.

✅ Ответ:

• a.x — undefined
• b.x — { n: 2 }

🐸 Библиотека фронтендера

#code_challenge

🕹 npm install: хитрость фронтендера

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

➕ Проверяем пакет перед установкой

➕ Копируем команду из StackOverflow и надеемся, что заработает

Голосуем реакциями:

👍 — Осторожность
❤️ — Копипаст

🐸 Библиотека фронтендера

#code_battle

Каким будет результат ❓

Опрос ниже 🔜

🐸 Библиотека фронтендера

#code_challenge

🧪 Unit-тесты vs QA протестирует

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

🟣 Unit-тесты

— Баги находятся на этапе разработки
— Быстрый feedback loop
— Рефакторинг без страха
— Разработчик = ответственность за качество

🟣 QA протестирует

— Быстрее пишу код без тестов
— QA всё равно найдёт баги
— "Я же не тестировщик"
— Баги уходят в прод, но это не моя вина

💭 А в вашей компании есть правило «нет тестов — нет мержа»? Или «работает — не трогай»?

Голосуем реакциями:

👍 — Пишу unit-тесты перед коммитом
❤️ — Тесты есть, но не всегда
🤔 — QA справится, они для этого есть
🔥 — Продакшн и есть тестовая среда

🐸 Библиотека фронтендера

#code_battle

💡 JavaScript-разминка

Что вернёт код на картинке выше ⬆️

Массив вроде есть, но что хранится в array[0]…

🐸 Библиотека фронтендера

#code_battle

🤟 Попробовал Vue — и не жалею

Пять лет на React — и вдруг понял, что жизнь без useEffect реально возможна. Ниже — коротко, в чём именно разница 👇

➡️ Реактивность без боли

🟢 React:

const [count, setCount] = useState(0)
setCount(count + 1)

🟢 Vue:

const count = ref(0)
count.value++

Просто работаешь с переменной — и всё обновляется. Никаких setState, никаких магических зависимостей.

➡️ Computed > useMemo

🟢 React:

const filtered = useMemo(() => items.filter(i => i.active), [items])

🟢 Vue:

const filtered = computed(() => items.value.filter(i => i.active))

Во Vue не нужно думать про зависимости — оно само знает, когда пересчитать значение.

➡️ Template против JSX

<div v-for="item in items" :key="item.id"> читается легче, чем {items.map(item => <div>...)}. v-if, v-show, v-model — три директивы, которые убирают сотни строк boilerplate.

➡️ Меньше кода — меньше багов

🟢 React:

useEffect(() => {
if (email && !isValidEmail(email)) setError(‘Invalid’)
else setError(’’)
}, [email])

🟢 Vue:

const email = ref(’’)
const error = computed(() => email.value && !isValidEmail(email.value) ? ‘Invalid’ : ‘’)

Что реально зацепило:

1. Нет useEffect hell — watch и watchEffect проще и читаемее.

2. v-model — двустороннее связывание без боли и бойлерплейта.

3. Меньше бандл: React + ReactDOM ≈ 45 KB (gzip), Vue 3 ≈ 34 KB (gzip).

Что не зашло:

— Экосистема меньше

— TypeScript-интеграция всё ещё местами шероховата

📌 React — мощный фреймворк. Но Vue решает те же задачи проще: меньше бойлерплейта, меньше магии, больше ясности.

На работе продолжаю React (экосистема, команда, легаси). Но когда сажусь за свой проект в выходные — открываю Vue.

🐸 Библиотека фронтендера

#code_battle

Опрос ниже ⬇️

🐸 Библиотека фронтендера

#code_challenge

🫥 Как я перестал бороться с TypeScript

После того случая я перестал спорить с TypeScript. Решил внедрить его хотя бы частично — просто чтобы понять, действительно ли он чего-то стоит. И вот тут началось самое интересное.

🧽 На проекте был модуль оплаты. Мелочь: функция принимала price, а я случайно передал туда строку из инпута. JS, конечно, не возмутился — просто сложил две строки:

function calcTotal(price) {
  return price + 2000
}

calcTotal("4000") // "40002000»

На проде чек вырос в два раза, клиент — в гневе. А я — с новыми седыми волосами.

С TypeScript такого бы не случилось:

function calcTotal(price: number) {
  return price + 2000
}
// Argument of type 'string' is not assignable to parameter of type 'number’

После этого я посмотрел на TS по-другому. Он не просто проверяет типы — он ловит ошибки до того, как они становятся проблемами.

Поначалу раздражает:

«Зачем всё это?»
«Слишком строго!»
«Лишний бойлерплейт!»

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

🤨 Теперь я воспринимаю TypeScript не как обузу, а как коллегу, который делает код-ревью мгновенно и честно.

🐸 Библиотека фронтендера

#code_battle

Опрос ниже ⬇️

🐸 Библиотека фронтендера

#code_challenge

📎 5 ESLint-правил, которые реально спасают

1️⃣ eqeqeq — только строгое сравнение

Пример:

if (user.id == “123”) — опасно
if (user.id === “123”) — безопасно

Двойное равенство делает скрытые преобразования типа:

0 == “0” → true

2️⃣ no-implicit-coercion

Пример:

const str = “” + value — неявное приведение
const str = String(value) — явно и понятно

3️⃣ no-unused-vars + no-undef

Ловят опечатки до запуска:

const userName = “Alex”
console.log(usrName) — ESLint сразу найдёт ошибку

4️⃣ no-console

console.log(“ДЕБАГ!!!”, userData)

Если забыть убрать — может утечь чувствительная информация в продакшене

5️⃣ prefer-const

let config = {…} — переменная не переназначается

ESLint подскажет заменить на const

Если нужно — могу сделать версию ещё короче (в один экран).

🔥 Тот же кейс, но с TypeScript

function processPayment(amount: number) {
  api.charge(amount)
}

processPayment(«100»)

// string is not assignable to number

P.S. Если не готовы к TS — начните хотя бы с этих 5 правил.

🐸 Библиотека фронтендера

#code_battle