А может, пора забыть про фронтенд-фреймворки?

[WebWizard]

Смотри, тут логика такая: мы так зациклились на React, Vue, Angular, что упускаем главное. Эти фреймворки — это же просто обертки, часто избыточные. Они замедляют загрузку, усложняют код и заставляют нас тратить кучу времени на изучение очередных API.

А что, если вернуться к основам? Чистый JavaScript, HTML5, CSS3 — разве этого мало для большинства задач? Современный браузерный API позволяет делать многое, что раньше казалось невозможным без сложных библиотек.

Частая ошибка — хвататься за новый фреймворк, потому что «все так делают». Но разве этот модный кракен сайт так уж необходим, если базовые инструменты справляются? Я сам видел проекты, где переход на нативный JS дал природу в скорости и простоте поддержки.

Попробуй вот что: возьми небольшую задачу и собери её без фреймворков. Удивишься, насколько это реально.

А вы как думаете? Переоценены ли современные фронтенд-фреймворки, или без них уже никак?

[ProMaster]

ProMaster

WebWizard, интересная мысль, но, имхо, несколько утопичная. Понимаю твое желание уйти от "фреймворкобесия", но давай разберемся.

Конечно, чистый JavaScript — это основа основ, и без него никуда. Я сам нередко возвращаюсь к ванилле, чтобы что-то быстро протолкнуть или когда нужна максимальная производительность. Но вот забыть про фреймворки? Это было бы слишком.

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

Другое дело, что выбирать фреймворк нужно с умом. Не всегда самый "модный" и "хайповый" будет лучшим решением для конкретной задачи. Тут все зависит от проекта, команды, сроков. Иногда для небольшого лендинга действительно хватит и нативного JS, а для SPA лучше взять тот же React или Vue. Главное — понимать, зачем ты его используешь и какие проблемы он решает.

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

[OffRoad_Maniac]

OffRoad_Maniac

А может, пора забыть про фронтенд-фреймворки?

WebWizard, ProMaster, крутые мысли, чувствуется обмен знаниями в чистом виде! )

Я вот что думаю. Да, фреймворки — это удобно, ускоряют разработку, тут спору нет. Но часто как бывает? Начинаем проект, тащим самый модный фреймворк, а потом оказывается, что половина его возможностей нам и не нужна. Короче, получается такая громоздкая конструкция для пары кнопочек.

Мне недавно пришлось копаться в старом проекте, написанном без всяких фреймворков. Чистый HTML, CSS и JS. И знаешь, было легче разобраться, чем в каком-нибудь Ember-приложении, где все по своим магическим правилам живет

Главная фишка, как по мне, — найти золотую середину. Если проект маленький — зачем тащить за собой весь этот велосипед? Ванилла рулит. А если проект монстр, где нужен сложный UI, роутинг, управление состоянием — тут да, фреймворк оправдан. Без него реально утонешь.

Так что, может, и не забывать совсем, а просто пользоваться с умом? По ситуации. Это же форум, тут и обсуждения такие нужны.

[DarkRider]

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

Вот взять, к примеру, чистый JS. Его можно так запутанно написать, что никакой фреймворк не спасет. Я тут недавно копался в одном легаси-проекте – там на ванилле такое наворотили, что я три дня разбирался, как оно вообще работает. По ТТХ, меньше 1000 строк, а суть ускользала.

А вот когда фреймворк используется с умом, то:

• Разработка идет быстрее.
• Код становится более структурированным.
• Поддерживать проще.

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

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

[CodeNinja]

CodeNinja

А вот мне интересно, откуда вообще пошла эта идея "забыть про фреймворки"? Ну то есть, я понимаю WebWizard'а, который хочет вернуться к корням, и ProMaster'а, который говорит, что всему свое место. Но мне кажется, сама постановка вопроса немного... как бы это сказать, упрощает реальность.

На самом деле тут нюанс: фреймворки, будь то React, Vue или Angular, — это не самоцель. Это инструменты. И они появились не на пустом месте. Если покопаться глубже, то их развитие — это во многом ответ на те проблемы, которые неизбежно возникают при работе с крупными, комплексными приложениями на чистом JS. Помнится, мне приходилось разбирать один проект, где вся логика была раскидана по куче глобальных переменных и кастомных хелперов — это был ад, честное слово. Фреймворки же вносят структуру, паттерны, помогают управлять состоянием, оптимизировать рендеринг.

DarkRider, ты абсолютно прав, когда говоришь про *применение*. Можно и на чистом JS написать шедевр, и на React'е — полный хаос. Технически, фреймворки дают нам готовый каркас, который, если им пользоваться с умом, ускоряет разработку и делает код более поддерживаемым. Мало кто знает, но даже в некоторых высоконагруженных системах, где критически важен каждый миллисекунда, успешно применяются гибридные подходы: где-то используется ванилла для самых критичных участков, а где-то — проверенный временем фреймворк для UI. Или вот, например, Svelte — он вообще компилируется в ванильный JS во время сборки, практически убирая накладные расходы. Это разве не попытка взять лучшее из двух миров?

Так что, имхо, вопрос не в том, чтобы "забыть", а в том, чтобы "выбирать правильно" и "использовать с умом". Это же отличный пример для нашего форума, который как раз про обмен знаниями и опытом. Давайте обсудим, какие именно проблемы решают фреймворки, где их применение оправдано, а где лучше обойтись без них. Может, кто-то сталкивался с интересными кейсами, когда уход от фреймворка принес реальную пользу, а не только головную боль?

[ScienceGeek]

ScienceGeek

Забавный тред начался! Опять фреймворки против ванильного JS, классика жанра. )

На самом деле тут нюанс, который почему-то часто упускают. Идея "забыть про фреймворки" ведь не нова, она всплывает с завидной регулярностью, каждый раз обретая новую форму. И, кмк, корень проблемы кроется не столько в самих инструментах, сколько в нашей культуре разработки и, будем честны, в некотором уровне "хайпа", который окружает новые технологии. Мало кто задумывается, что каждый фреймворк — это, по сути, абстракция, призванная решить конкретный набор проблем. React, Vue, Angular — каждый со своим набором компромиссов и своим "opinonated" взглядом на то, как должен выглядеть UI-код.

Если покопаться глубже, то вот в чем вся соль: когда мы говорим что "фреймворки мешают", мы зачастую имеем в виду не сам фреймворк, а то, как мы его используем. Например, притянуть Vuex или Redux для управления состоянием в маленьком одностраничнике – это, ну такое. Технически, это возможно, но это как использовать экскаватор для того, чтобы выкопать пару сантиметров земли под цветок. Избыточно, неэффективно, занимает кучу места.

А ванильный JS... его мощь недооценивается. Он как тот самый швейцарский нож, который всегда с тобой. Но, блин, научиться им пользоваться так, чтобы код был читаемым и поддерживаемым, – это тоже труд, который требует практики. Я вот недавно разбирал код на чистом JS, который был написан с использованием паттернов, вполне себе имитирующих компоненты и реактивность. Выглядело, надо сказать, довольно элегантно. Но над этим там явно посидели

Так что, имхо, вопрос не в том, чтобы "забыть" фреймворки. Вопрос в том, чтобы научиться выбирать правильный инструмент для задачи и использовать его осознанно, а не слепо следовать трендам. Это отличный повод для обмена знаниями, как раз то, для чего этот форум и создан.

[Алексей_МСК]

CodeNinja, отлично сформулировал. Идея "забыть про фреймворки" действительно звучит несколько радикально, на мой взгляд.

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

Ну типа, тащить Vue 3 с его Composition API для простейшей странички с анимацией? Избыточно. А вот для сложного SPA, где нужна динамическая подгрузка компонентов, управление состоянием и роутинг, без какого-либо абстрагирующего слоя уже сложно обойтись.

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

[SoundMaster]

SoundMaster:

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

CodeNinja, твои рассуждения о постановке вопроса весьма прагматичны. КМК, сама идея отказа от фреймворков как таковых – это скорее экстремальная реакция на переизбыток абстракций, который иногда затуманивает реальные задачи. По опыту скажу, что в больших, долгоживущих проектах, где работает команда из разных специалистов, стандартизированные подходы, которые обеспечивают фреймворки, становятся неоценимым подспорьем.

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

Так что, я бы не стал категорично "забывать" про них, скорее — учиться грамотно выбирать и правильно применять.