Недавно я наткнулась на статью «How Functional Programming Shaped Modern Frontend» и неожиданно поймала себя на мысли: мы уже настолько привыкли к функциональному программированию (ФП) в JavaScript, что забыли, как всё начиналось и почему многие идеи казались почти спасением. Чтобы лучше понять эволюцию, я решила посмотреть, что писали разработчики о ФП во фронтенде 10 лет назад, примерно в 2013-2016 годах.

Контраст получился довольно яркий: от искреннего восторга до постепенного прозрения.

Я решила поделиться своим анализом, основанным на современных наблюдениях и на тех статьях прошлого, где ФП воспринималось как путь к «правильному» фронтенду.

Почему функциональное программирование вообще заняло такую роль

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

В начале 2010-х JavaScript-приложения становились всё более сложными, разработчики искали спасения в функциональном программировании. jQuery-код был слишком императивным, слишком хрупким и уже точно не масштабировался. А сообщество хотело предсказуемости, и здесь ФП предложило понятную модель: UI = f(state).

То есть интерфейс — это результат чистой функции, а состояние изменяется контролируемо.

React, который появился тогда ещё в виде классовых компонентов, был далёк от чистого функционального стиля, но заложил для него фундамент. Elm, как чисто функциональный язык, повлиял на формирование взглядов, а Redux взял эти идеи и упаковал их в практичную для индустрии формулу: однонаправленный поток данных, иммутабельность, явные действия. React Hooks только закрепили эту тенденцию.

Тон того времени можно увидеть, например, в статье «Functional Reactive Programming in JavaScript» за 2013 год, где автор, полный энтузиазма, описывает, как реактивные стримы помогают писать «чистое» и декларативное поведение UI. В других публикациях тех лет функциональный стиль преподносился как философия: мол, вот он путь к понятному, поддерживаемому фронтенду.

Сейчас это всё выглядит чуть наивно, но тогда казалось, что разработчики нашли Святой Грааль.

Но веб — это не чистая функция

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

• CSS специально устроен так, что стили распространяются за пределы компонента.

• DOM — это огромное изменяемое дерево, которое браузеры оптимизируют десятилетиями.

• Пользовательские действия непредсказуемы, асинхронны и могут происходить одновременно.

• HTML — декларативный язык, который сам по себе описывает структуру и семантику без единой строчки JavaScript.

Веб-платформа не чистая и не стремится такой быть. Она эволюционировала, чтобы обеспечивать обратную совместимость и гибкость. Это не баг, а фича.

Как начали изобретать абстракции поверх платформы

К середине 2010-х желание «очистить» фронтенд от беспорядка привело к появлению огромного числа абстракций, порой вопреки природе веба.

Проблема CSS —> CSS-in-JS

В 2014 году Вьё (Vjeux) опубликовал заметку о фундаментальных проблемах масштабирования CSS. Его мысли были понятны: глобальность, конфликты, порядок подключения, всё это реально мешало.

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

Проблема событий —> Synthetic Events

React добавил Synthetic Events, чтобы унифицировать API. На деле просто появился дополнительный слой между разработчиком и платформой.

Проблема модалок —> игнорирование

Годами разработчики реализовывали свои модальные окна вручную, создавали порталы, ловили фокус, писали обработчики escape. И ведь всё это браузер уже умел делать нативно! Просто сообщество не доверяло платформе.

Проблема навигации —> переизобретение маршрутизации

Вместо того, чтобы использовать встроенные механизмы браузера, фреймворки строили собственные маршрутизаторы. Простая навигация превращалась в цепочку эффектов и изменяемых стейтов.

Проблема форм —> кастомные фреймворки

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

Проблема SSR —> гидратация всё усложнила

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

К 2016 году ФП-энтузиазм дошёл до пика, даже вышла книга «Functional Programming for JavaScript Developers», призывающая открыть «силу ФП для создания надёжных web apps»...

Почему этот путь казался логичным?

Важно понимать контекст. В 2013-2015 годах многие проекты действительно разваливались из-за непредсказуемых мутаций. В этой среде подходы React выглядели действительно рабочим средством. И это было правдой — React решал реальные проблемы.

Проблема была в другом. Вместо того, чтобы использовать ФП-идеи там, где они уместны, индустрия начала применять их везде. React стал настройкой по умолчанию. Вакансии требовали React, потому что его знали разработчики. А разработчики учили React, потому что его требовали вакансии. Цикл замкнулся.

Переосмысление: 2020-е и возвращение к платформе

Последние годы наблюдается отчётливый разворот:

• Astro делает ставку на островную архитектуру и минимизацию клиентского JS.

• HTMX показывает, что гипертекст всё ещё мощный инструмент.

• SvelteKit компилирует код и избегает тяжёлых рантаймов.

• Qwik уходит от полной гидратации и загружает код лениво.

Эти инструменты не отказываются от функциональных идей, они отказываются от попыток переделать веб под ФП. Они принимают платформу такой, какая она есть: с DOM, CSS, с нативными событиями и HTML, который умеет очень много без единой строчки JavaScript.

ФП остаётся полезным внутренним принципом, но перестаёт быть архитектурной религией.

Вместо заключения

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

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

Лично мне близок порядок: когда код можно объяснить несколькими базовыми правилами, когда он предсказуем, тестируем и не превращается в набор хаотичных мутаций. Я люблю, когда проект живёт по понятным принципам.

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

Получается, что вопрос уже не в том, «Нужно ли фронтенду функциональное программирование?», а в том, каким оно должно быть именно для веба.

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

Телеграм-канал Alfa Digital, где рассказывают о работе в IT и Digital: новости, события, вакансии, полезные советы и мемы.

Может быть интересно: