TGViewer
<divelopers> <divelopers> @alexnozer_dev · 1.18K subscribers
Post #377 1.07K
Фреймворки не нужны?

Недавно видел фрагмент со стрима Тимура Шемсединова, затем реакцию на этот фрагмент автора канала «Фронтенд как проблема». Тимур высказал мнение: «в современном мире фронтенд фреймворки не нужны, это инерция».

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

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

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

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

Можно выбрать Vue и использовать только 20% возможностей. Остальные 80% живут в кодовой базе (node_modules), скачиваются, обновляются, проходят процесс сборки (анализ графа зависимостей, Tree Shaking, удаление неиспользуемого кода).

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

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

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

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

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

#js
  • 👍 15
  • ❤ 4
  • 🔥 1
  • 😎 1
More from @alexnozer_dev
  1. Sep 21, 2026Реализация пользовательских атрибутов Под конец прошлого года я рассказывал об API пользов…
  2. Sep 14, 2026Подклассы Event вместо CustomEvent Многие библиотеки предоставляют систему событий в качес…
  3. Sep 11, 2026Эволюция стилей в темах Shopify Адам Ватан на днях поделился новостью, что Shopify выкупил…
  4. Sep 9, 2026Persistent Widgets Многие сайты не должны быть SPA. Но иногда эта архитектура продиктована…
  5. Sep 7, 2026Processing Instructions и маркеры В DOM всё представлено в виде узлов (Node) разных типов.…
  6. Sep 1, 2026@scope и потоковая передача HTML Ноам Розенталь поделился интересной техникой, в которой с…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →