🎨 Организация стилей в современных веб-приложениях

Когда-то мы писали просто style.css — и всё работало.
А теперь… десятки подходов, библиотек и баталии в комментариях 😅

Вот краткий обзор популярных решений (по моему мнению).

---

💡 Styled-components
📄 [Документация](https://styled-components.com/docs)
💻 [Пример](https://styled-components.com/docs/basics#getting-started)

⏱️ Когда применяются стили: во время выполнения (runtime)
🛠 Настройка Webpack: ❌ не требуется
🔥 Размер бандла: больше, т.к. включает runtime
🚀 Плюсы: удобный синтаксис, динамические стили
⚠️ Минусы: runtime cost

---

💡 Linaria
📄 [Документация](https://github.com/callstack/linaria/tree/master/docs)
💻 [Пример](https://github.com/callstack/linaria/tree/master/examples)

⏱️ Когда применяются стили: build-time
🛠 Настройка Webpack: ✅ обязательна, нужны плагины
🔥 Размер бандла: минимальный — в итоговом JS нет стилей
🚀 Плюсы: без runtime
⚠️ Минусы: сложнее настроить

---

💡 CSS Modules
📄 [Документация](https://github.com/css-modules/css-modules/tree/master/docs)
💻 [Пример](https://github.com/css-modules/webpack-demo)

⏱️ Когда применяются стили: на этапе сборки (build-time)
🛠 Настройка Webpack: да, если настраиваешь вручную
🔥 Размер бандла: небольшой
🚀 Плюсы: простой, без runtime
⚠️ Минусы: не такой гибкий как css in js

---

✨ В итоге:
- Хочешь простоты — CSS Modules
- Нужны динамические стили — Styled-components
- Хочешь скорость и zero-runtime — Linaria

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

#frontend #css #styledcomponents #linaria #cssmodules #вебразработка

Всем привет!

Вижу по вашим реакциям, что мой последний пост вам не особо зашел 😅
А потом совершенно случайно натыкаюсь на этот апдейт от команды styled-components — https://opencollective.com/styled-components/updates/thank-you — и понимаю, что с 18 марта 2025 года библиотека официально признана deprecated.

Причины:

🛑 Команда React де-факто задепрекейтила некоторые API, включая Context API, которое недоступно в React Server Components и не имеет пути миграции.

🌪 Экосистема в целом ушла от концепции css-in-js. Альтернативы вроде Tailwind набрали дикую популярность и вытеснили старые подходы.

👋 Основной мейнтейнер библиотеки (под ником quantizor) больше не использует styled-components в продакшене крупных проектов. А значит, реальные кейсы применения тоже будут постепенно исчезать.

В арсенале у нас по-прежнему остаются CSS Modules и Linaria, которые продолжают жить и развиваться 💪

Всем привет!
И вот — мой первый пост из серии «Борьба с тараканами» (читай: внутренними установками 🪳).

### 🧠 Таракан №1:
«Я почти не пишу код. Боже, я деградирую?!»

Долгое время мне казалось, что всё в нашей профессии крутится вокруг кода.
Типа: я пишу код — значит, делаю что-то важное и сложное.
А всё остальное — «ну это же просто, там думать особо не надо».
(Спойлер: надо. И ещё как.)

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

Как же я ошибалась.

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

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

И честно? По мне иногда дизайн интерфейсов сложнее, чем «просто реализовать по ТЗ».

🧩 А ещё одно важное наблюдение:
Если в команде не налажены процессы, атмосфера токсичная, нет мотивации и ясности — никакой код не спасёт.

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

И да — тимлид вполне может (и должен) брать задачи из бэклога, пусть хотя бы на 20%.
Но главное — понимать, зачем и ради чего ты в этой роли.

---

#тараканытимлида
Продолжение следует 👀

Всем привет!
Недавно задумалась: как же несправедливо, что почти все фронты отлично знают как работают setTimeout и setInterval, но мало кто (по моему опыту на собесах) в курсе про requestAnimationFrame.

📌 На самом деле всё просто. Вот отличная статья, где всё на пальцах:
https://css-tricks.com/using-requestanimationframe/

---

🧠 Что это вообще?

 Метод window.requestAnimationFrame() сообщает браузеру:
> “Эй, я хочу сделать анимацию — позови меня перед следующим кадром.”

Браузер вызовет вашу функцию ровно перед перерисовкой экрана.
Это обычно происходит 60 раз в секунду (60 Гц), но может быть и 120 или 144 Гц — в зависимости от монитора.
(И вам не нужно определять частоту — кайф же!)

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

---

✍️ Синтаксис супер-простой:

function repeatOften() {
  // делаем что-то на каждом кадре
  requestAnimationFrame(repeatOften);
}

requestAnimationFrame(repeatOften);

📌 Вызовите один раз — и функция будет рекурсивно запускаться перед каждым кадром. Идеально для прогресс-баров, скролл-эффектов, игр, всего где нужна плавность.

---

⚠️ Главное — не забывайте вовремя отменять requestAnimationFrame, если он больше не нужен: иначе будет утечка памяти.

🧠 Как ничего не забыть и не продолбать важное?

В своей работе я использую два приложения, которые помогают держать всё под контролем и ничего не забывать:
🗂 [Obsidian](https://obsidian.md/) и ✅ [SingularityApp](https://singularity-app.com/)

Они выполняют разные задачи, и вместе — идеальный дуэт.

---

📘 Obsidian — мое личное хранилище знаний.

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

А ещё — это обычные .md-файлы. Разработчики меня поймут 😉
Можно синхронизировать между устройствами при необходимости и всегда иметь всё под рукой.

---

📆 SingularityApp — мой таск-менеджер на каждый день.

Здесь я фиксирую задачи, даже если они мелкие и несрочные.
Например:
- «Поставить встречу с командой через 2 дня» — чтобы не забыть и не отвлекаться сейчас.
- «Уточнить вопрос после звонка» — небольшая заметка, которая потом напомнит в нужный момент.

Таким образом, я:
— не распыляюсь,
— быстро реагирую,
— держу в голове ровно ноль мыслей 😄

---

📌 Итог: я помню все договорённости, ничего не теряю, и успеваю в 10 раз больше.

#тараканытимлида

Сижу себе спокойно, никого не трогаю — и тут прилетает уведомление от YouTube:

"Почему BFF должны писать именно фронтендеры" 🎯

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

В общем, интересное выступление, рекомендую к просмотру!
👉 https://youtube.com/shorts/1C2nT0FHn1E?si=uN6Ulek19mh1SNNs

Достижение субкадровой интерполяции с помощью GSAP и Web Workers

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

Но пост не об этом!

Недавно я случайно наткнулась на статью:
👉 [Achieving Sub-Frame Interpolation with GSAP and Web Workers](https://dev.to/hexshift/achieving-sub-frame-interpolation-with-gsap-and-web-workers-4a50)

И это как раз в тему — ведь недавно в канале мы обсуждали и Web Workers, и requestAnimationFrame!

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

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

Спасибо, кэп! Как говорится, повторение — мать учения 😄
Статью читать необязательно, но можно пробежаться глазами по коду!

👋 Всем привет!
Вчера прочитала интересную статью:
📎 https://www.smashingmagazine.com/2025/04/building-offline-friendly-image-upload-system/

В ней рассказывается, как создать offline-friendly систему загрузки изображений.

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

📌 В кратце:
Что делать, если пользователь загружает изображение, а в этот момент пропадает сеть? Чтобы не заставлять его делать всё заново, можно:

— сохранять изображение локально через IndexedDB (только при отсутствии сети);
— использовать service worker для отслеживания восстановления соединения;
— запускать отложенную загрузку через Background Sync, как только сеть появится.

P.S. Подробнее про Background Sync — вот тут:
https://developer.mozilla.org/ru/docs/Web/API/Background_Fetch_API

P.P.S. Автор также упоминает об ограничениях. В общем, рекомендую к прочтению.

🧠 Искусственный интеллект, конечно, помогает писать код — но базовые знания человека всё ещё никто не отменял.

Любой код, который сгенерировал ИИ, нужно обязательно проверять. Как говорится: "доверяй, но проверяй". А ещё важно уметь правильно запускать проект — и разбираться, где и что может пойти не так.

🔧 Случай из жизни. Моя подруга вместе с другом делают приложение с помощью ИИ. В какой-то момент она пишет мне: "Фронт не собирается, всё криво и косо, друг уже неделю пытается запустить, но безуспешно".

На созвоне я сразу замечаю, что Tailwind работает неправильно: вижу класс с названием blue, а фон — не синий 🤷‍♀️

⏱️ Разобраться на месте не было времени, попросила доступ к репе. И когда села — сразу поняла: в проекте почему-то три (!) разных файла конфигурации Tailwind, с разными названиями. Поправила за 5 минут — и всё заработало. А еще же нужно было запустить это незнакомое приложение, которое было монолитом, сервер на Uvicorn (с которым я столкнулась впервые) — но и его запустила быстро и пофиксила проблему за считанные минуты.

А друг моей подруги, полагаясь только на ИИ, неделю пытался разобраться 😅

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

🚀 GSAP 3.13 теперь полностью бесплатен!

С релизом версии 3.13, GSAP (GreenSock Animation Platform) стал абсолютно бесплатным — включая все ранее платные плагины. Это стало возможным благодаря поддержке компании Webflow, которая приобрела GSAP и открыла доступ ко всему инструментарию, включая коммерческое использование.

📌 Единственное ограничение: запрещено использовать GSAP в продуктах, позволяющих создавать визуальные анимации без кода и конкурирующих с возможностями Webflow.

🔗 Подробнее:
https://gsap.com/blog/3-13/
https://github.com/greensock/GSAP

Всем привет!
Давайте подведем итоги за последние два месяца — что появилось в этом канале 👇

📌 ДАЙДЖЕСТ: МАРТ & АПРЕЛЬ

🎯 Frontend от меня:

Исторический экскурс от JavaScript до ES Modules – https://news.1rj.ru/str/frontenddevelopernews/4
Как вообще уживаются вместе .cjs, .mjs и .js файлы в одном проекте – https://news.1rj.ru/str/frontenddevelopernews/5
Service и Web Workers – https://news.1rj.ru/str/frontenddevelopernews/9
Пример работы с веб-воркером –https://news.1rj.ru/str/frontenddevelopernews/11
Разбор задачи из bigfrontend.dev – https://news.1rj.ru/str/frontenddevelopernews/14
Организация стилей в современных веб-приложениях – https://news.1rj.ru/str/frontenddevelopernews/15
requestAnimationFrame – https://news.1rj.ru/str/frontenddevelopernews/18


🗺 Frontend-новости:

Устаревание styled-components – https://news.1rj.ru/str/frontenddevelopernews/16
GSAP 3.13 теперь полностью бесплатен – https://news.1rj.ru/str/frontenddevelopernews/25


👩‍💻 Тимлидство:

Из разработчика в руководителя: с какими трудностями я столкнулась – https://news.1rj.ru/str/frontenddevelopernews/12
Я почти не пишу код. Боже, я деградирую?! – https://news.1rj.ru/str/frontenddevelopernews/17
Как ничего не забыть и не продолбать важное? – https://news.1rj.ru/str/frontenddevelopernews/19

💡 Реальные кейсы:

«Теория не нужна!» — реальный кейс с ассессмента – https://news.1rj.ru/str/frontenddevelopernews/10
Как я получила A++ за курсовую на магистратуре в Лондоне – https://news.1rj.ru/str/frontenddevelopernews/13
ИИ помогает писать код — но базу всё равно нужно знать – https://news.1rj.ru/str/frontenddevelopernews/24

📚 Статьи и видео:

Первоначальная производительность загрузки для React-разработчиков: глубокое исследование – https://news.1rj.ru/str/frontenddevelopernews/6
Почему BFF должны писать именно фронтендеры – https://news.1rj.ru/str/frontenddevelopernews/21
Достижение субкадровой интерполяции с помощью GSAP и Web Workers – https://news.1rj.ru/str/frontenddevelopernews/22
Как создать offline-friendly систему загрузки изображений – https://news.1rj.ru/str/frontenddevelopernews/23

---

Дальше — больше! Кажется, я только начинаю набирать обороты.
Спасибо, что вы со мной — обещаю, дальше будет ещё интереснее!

#дайджест

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

А зря. Это действительно важно: нужно понимать не только что должна делать система, но и как она должна это делать. Нефункциональные требования определяют качество работы системы в целом — насколько быстро она откликается, выдерживает ли нагрузку, безопасна ли, доступна ли 24/7.

Недавно нашла отличный гайд от Microsoft по работе с НФТ:
👉 https://github.com/microsoft/code-with-engineering-playbook/blob/main/docs/design/design-patterns/non-functional-requirements-capture-guide.md

А здесь — подробное описание каждого типа требований:
👉 https://microsoft.github.io/code-with-engineering-playbook/non-functional-requirements/accessibility/

P.S. Если будет интересно, могу разобрать НФТ подробнее в отдельных постах 🙂

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

Вот мой топ:

1. 📖 Регулярно читать — статьи, блоги, посты, книги. Развивать насмотренность и расширять кругозор.
2. 📺 Смотреть доклады и обучающие видео — лучше понимать концепции, узнавать о новых подходах, прокачивать навыки "на слух".
3. 🛠 Пилить пет-проекты — отличный способ протестировать новую либу, язык или архитектурный подход.
Да, те самые 10 000 часов, о которых все говорят — можно наработать именно здесь.
4. 🧠 Обсуждать и рефлексировать знания — с коллегами, наставниками, друзьями.
Проговаривание, написание, объяснение другим — всё это закрепляет материал в разы лучше.
5. 📋 Фиксировать и структурировать — вести заметки, таблички, личную вики. Это помогает возвращаться к знаниям и видеть прогресс. У меня есть подобная база в notion.
6. ⚖️ Бережно относиться к себе — выгорание — не миф. Баланс между работой и жизнью — не слабость, а залог долгосрочной продуктивности.

Но следующий вопрос, который мы с вами обсудим — где найти на всё это время? 😂

gRPC против REST: Как выбрать лучший подход к проектированию API

Всем привет! Наткнулась на полезную статью — https://blog.logrocket.com/grpc-vs-rest/
В ней объясняется, что такое REST и gRPC, в чём их ключевые различия и в каких случаях лучше применять тот или иной подход. Есть наглядные примеры.

Вот краткая выжимка, но всё же рекомендую прочитать статью целиком 👇

---

🔍 Основные различия

REST — архитектурный стиль, использующий HTTP/1.1 и JSON. Прост в использовании и широко поддерживается в браузерах.
gRPC — высокопроизводительный фреймворк от Google на базе HTTP/2 и Protocol Buffers. Обеспечивает эффективную, строготипизированную передачу данных между сервисами.

---

⚙️ Сравнение производительности

📦 Сериализация и объём данных

REST:

* Использует текстовые форматы (JSON/XML)
* Более крупный размер данных из-за текстового кодирования
* Читаем человеком, но менее эффективно
* Сериализация/десериализация может быть ресурсоёмкой для больших данных

gRPC:

* Использует бинарный формат (Protocol Buffers)
* Полезная нагрузка на 30–40% меньше по сравнению с JSON
* Быстрая сериализация и десериализация
* Меньшая нагрузка на пропускную способность сети

---

🌐 Сетевая эффективность

REST:

* Основан на HTTP/1.1 (поддержка HTTP/2 ограниченная)
* Один запрос — одно TCP-соединение
* Выше задержка при множестве запросов
* Ограниченное повторное использование соединений
* Сжатие заголовков доступно только с HTTP/2

gRPC:

* Основан на HTTP/2
* Мультиплексирует несколько запросов по одному соединению
* Поддерживает двусторонний стриминг, что снижает задержку
* Постоянные соединения повышают производительность
* Эффективное сжатие заголовков снижает издержки

---

✅ Когда выбрать REST

* Публичные API — когда важна широкая совместимость с клиентами и возможность обнаружения (discoverability).
* Веб-клиенты — для прямой поддержки в браузере без необходимости прокси или шлюзов.
* Простые CRUD-операции — когда достаточно базовых операций с ресурсами.
* Разные языки в микросервисах — если не все сервисы могут поддерживать gRPC.
* Удобная отладка — когда важно уметь просматривать и анализировать содержимое запросов.

---

🚀 Когда выбрать gRPC

* Микросервисная архитектура — когда важна эффективная внутренняя коммуникация между сервисами.
* Polyglot-среда — для совместимости между сервисами с помощью автогенерации кода.
* Реальное время — когда особенно полезны возможности стриминга в gRPC.
* Высокая нагрузка и требования к скорости — идеально для систем, критичных к производительности.
* IoT и мобильные приложения — где важны эффективность использования трафика и энергосбережение

---

P.S. Всё же советую прочитать статью целиком — когда дойдёт до реального выбора между REST и gRPC, вы будете во всеоружии и точно поймёте, какой подход лучше подойдёт именно в данном кейсе 🚀

Всем привет! А мы продолжаем серию постов про #тараканытимлида

И сегодня вашему вниманию следующий по мне актуальный вопрос)

Как мотивировать команду?

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

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

Что реально работает:
– Доверие и свобода. Не контролируйте каждый шаг, дайте человеку пространство.
– Вовлечённость. Делитесь контекстом, рассказывайте, зачем всё это — люди хотят быть частью чего-то большего.
– Обратная связь. Особенно позитивная и своевременная — она способна зарядить человека надолго.
– Развитие. Курс, новая задача, мини-проект, менторство — любые возможности расти.
– Поддержка. Иногда просто быть рядом — уже большая сила.

А что тебя по-настоящему мотивирует?)

🎯 React-разминка!

Всем привет!
Давайте сегодня попробуем решить интересную задачку 🔍

import * as React from 'react'
import { useState, useEffect, useLayoutEffect, useInsertionEffect } from 'react'
import { createRoot } from 'react-dom/client'

function App() {
  console.log(1)
  const [state, setState] = useState(0)

  useEffect(() => {
    setState(state => state + 1)
  }, [])

  useEffect(() => {
    console.log(2)
    return () => {
      console.log(3)
    }
  }, [state])

  useEffect(() => {
    console.log(4)
    return () => {
      console.log(5)
    }
  }, [state])

  useLayoutEffect(() => {
    console.log(6)
    return () => {
      console.log(7)
    }
  }, [state])

  useInsertionEffect(() => {
    console.log(8)
    return () => {
      console.log(9)
    }
  }, [state])

  console.log(10)
  return null
}

const root = createRoot(document.getElementById('root'))
root.render(<App/>)

📌 Вопрос: в каком порядке выведутся `console.log()`?
Пишите свои версии в комментариях!

🧠 Вечером выложу разбор с объяснением + ссылку на задачу, где можно засабмитить своё решение.

🥁 Барабанная дробь!
Правильный порядок вывода console.log:

1  
10  
8  
6  
2  
4  
1  
10  
9  
8  
7  
6  
3  
5  
2  
4

---

### 📘 Разбираемся, почему именно так:

* useLayoutEffect — работает как useEffect, но вызывается до того, как браузер успеет нарисовать изменения на экране - https://ru.react.dev/reference/react/useLayoutEffect
* useInsertionEffect — срабатывает ещё раньше, до useLayoutEffect и useEffect. Предназначен в основном для библиотек (например, для вставки стилей) - https://ru.react.dev/reference/react/useInsertionEffect
* useEffect — срабатывает после маунта и при изменении зависимостей. Думаю, ты его и так часто используешь 😉 - https://ru.react.dev/reference/react/useEffect#useeffect

---

### 🧩 Ход выполнения:

1. Сначала срабатывают синхронные логи:
→ 1, 10

2. Затем отрабатывает useInsertionEffect:
→ 8

3. Потом useLayoutEffect:
→ 6

4. Первый useEffect вызывает setState, происходит обновление состояния и ререндер

5. Перед началом рендера завершают работу остальные эффекты текущего рендера:
→ 2, 4

---

### 🔄 Второй рендер:

6. Опять срабатывают синхронные логи:
→ 1, 10

---

### ♻️ Что происходит с return внутри эффектов?

После каждого рендера, при изменении зависимостей:

> 🔁 Сначала вызываются функции очистки — это return из предыдущих вызовов хуков. Они отрабатывают на старых значениях
> 🆕 Затем запускаются новые эффекты — уже с обновлёнными данными

7. Сначала отрабатывает return из предыдущего useInsertionEffect:
→ 9

8. Затем вызывается новый useInsertionEffect:
→ 8

9. Далее useLayoutEffect:
→ 7 (функция очистки), потом 6 (новый вызов)

10. Первый `useEffect` больше не срабатывает, так как у него пустой массив зависимостей — он выполняется только один раз.

11. Поэтому вызываются только функции очистки из второго и третьего useEffect:
→ 3, 5

12. А затем — их новые вызовы:
→ 2, 4

---

🎯 Задача отсюда:
https://bigfrontend.dev/react-quiz/all-kinds-of-effects

💡 ESLint теперь умеет проверять HTML!

Ещё в 2024 году команда ESLint объявила о планах сделать инструмент независимым от конкретного языка — и начать поддерживать не только JavaScript. С тех пор появилась официальная поддержка JSON, Markdown, а совсем недавно — и CSS.

А теперь отличные новости: с помощью плагина @html-eslint/eslint-plugin можно линтить HTML-файлы! 🎉 об этом было анонсировано 13 мая этого года.

Плагин уже включает набор правил, связанных с:

* лучшими практиками,
* стилем кода,
* SEO-оптимизацией,
* доступностью (a11y).

🔗 Подробнее: https://eslint.org/blog/2025/05/eslint-html-plugin

👩‍💻 Всем привет!

Сегодня хочу поднять интересную тему: а нужно ли вообще делить разработчиков на frontend и backend? И почему в крупных IT-компаниях всё чаще называют инженеров просто software engineers, без уточнений?

До того как я устроилась работать на российский рынок, я позиционировала себя как full stack разработчик. Да чего я только ни делала 😂
Но потом столкнулась с суровой реальностью: пришлось выбрать направление — и я ушла во фронт.

Недавно болтала с другом, который работает в Amazon, и спросила его:
👉 "На чём ты там кодишь?"
Он ответил: "У нас есть свой внутренний язык и ещё TypeScript."
И при этом он не называет себя ни фронтендером, ни бэкендером — просто software engineer.

И вот я задумалась:
🤔 А нужно ли вообще это деление?
🤝 Или в идеале разработчик должен быть универсальным инженером, решающим задачи целиком?

💭 Моё мнение:
Без деления не будет глубины знаний. Но вместе с этим появляется риск узкой специализации — когда человек силён в одном, но теряется в другом. В одиночку таким специалистам сложно закрывать задачи целиком.
С другой стороны — а нужно ли это вообще? 🤷‍♀️
Зачем тогда команда, если ты можешь всё сам?

Хотя всё равно, на мой взгляд, важно, чтобы инженер хотя бы немного разбирался в обе стороны.
Я, например, всегда была немного T-shapeнутой 😂

А что думаете вы? Делитесь опытом в комментах — будет интересно обсудить!

Смотрите как красиво 😍 Мои глаза, уши, голова просто отдыхают смотря на это 😍

https://www.igloo.inc/

Этот сайт был отмечен наградой Site of the Day на Awwwards в 2024 году за выдающийся UX/UI и использование 3D-анимаций, WebGL и интерактивных элементов .
https://www.awwwards.com/sites/igloo-inc