Современный фронтенд неизлечимо болен

Волею судеб мне пришлось глубоко погрузиться в промышленную фронтенд разработку. До этого у меня были некоторые свои небольшие проекты, но писал я их в одиночку и не знал всех best practice. Следовал логике что чем проще, тем лучше, и они как-то работали. Пример можно посмотреть на GitHub GeoPuzzle - там используется React вместе с bootstrap, получилось достаточно минималистично. Сейчас же я работаю с крупным проектом на сотни компонент, несколько десятков страниц и сложной бизнес-логикой. И вот мои мысли спустя месяц после начала.

Vue.js и Composition API 🔗

Vue.js версии 2 использовал Options API. Это сравнительно простое API, которое определяло ряд секций внутри компонента: модель данных (data), методы (methods), lifecycle хуки (mounted). Следуя им было чёткое понмание и разделение ответственности каждого куска кода. Нужно было вычисляемое свойство - размещаем функцию обработки в разделе computed, все данные описаны в data и т.п. Надо было лишь помнить все возможные разделы, которые можно было использовать. Но я даже не отношу это к минусам, т.к. современный мир фреймворков очень большой и помнить всё наизусть почти нереально. Можно сказать, что это была необходимая сложность для работы именно с Vue; подобная проблема есть и с Django, и с Angular и т.п.

Во vue.js 3 сменили парадигму на Composition API. Если вкратце, то пишите внутри что угодно, а вовне можете использовать всё, что было возвращено с помощью return из этого куска кода. Круто, свобода же?! Но у этой свободы есть и обратная сторона: если Options API заставлял хоть как-то структурировать компоненты, то во vue 3 код может легко превратиться в big ball of mud. Теперь фреймворк не бьёт вас по рукам, заставляя делить код на компоненты и разносить по ним логику - это отдано на откуп разработчикам. И вы уверены, что квалификации хватит, чтобы продолжать писать лёгкий и поддерживаемый код? Посмотрев репозитории на github, компоненты на 200-500 строк уже не редкость. ИМХО, работать с таким становится очень сложно, но далеко не у всех есть чуйка “что-то как-то сложно, надо рефакторить”. Люди быстро привыкают к плохому и не любят перемен (также, как слово “рефакторинг” не любит бизнес); вот и продолжают жевать кактус, превозмогая сложность, вместо того, чтобы избавиться от неё.

А почему Composition API вообще появился? Дословно: “However, Options API poses serious limitations when a single component’s logic grows beyond a certain complexity threshold.” https://vuejs.org/guide/extras/composition-api-faq.html#more-flexible-code-organization. И вместо того, чтобы разбить логику компонента на составные части, решили всё собрать в одну кучу. Фреймворк здесь явно кричал “ребята, хватит всё пихать в один модуль - разбейте”.

В примере выше мог быть такой рефакторинг:

• убрать дублирование мутаций FOLDER_OPEN_PARENT и FOLDER_OPEN
• вынести модалку по созданию каталога в отдельный компонент
• вынести работу с Apollo в чистые js функции

Но нет - решили, что фреймворк плохой, раз мешает писать как сейчас удобно, и убрали все ограничения. К чему это ведёт я уже написал выше. Выходит, что Composition API легализует создание God object’ов.

Экосистема javascript 🔗

В мире javascript библиотек не меньше, а скорее всего даже больше чем в каком-либо другом. Этим часто демонстрируют превосходство экосистемы и её зрелость, но!

Примитивность кода 🔗

Очень много библиотек крошечного размера. Взять тот же left-pad - библиотека из одной функции в 20 строк?! Я не в претензии к разработчику, код должен переиспользоваться, но это наглядный пример незрелости самого языка. Такие вещи обычно включают в стандартные библиотеки. left-pad появился в 2011 году, а лишь в 2019 признан deprecated в пользу String.prototype.padStart(), да и то последняя помечена как экспериментальная. Я понимаю всю сложность разработки стандарта, но теперь, когда у нас осталось по сути 2 реализации, можно же договориться? :)

Качество кода 🔗

Ошибки есть везде, с этим надо просто смириться. В основном я работаю с python и привык к удобству его библиотек. Если ставишь какую-либо зависимость и работаешь с ней стандартным образом, то проблем как правило нет. Раз в год баги, конечно, попадаются, и приходится их фиксить у себя в репозитории и ждать когда вольют в апстрим. Происходит это довольно быстро и проблем не вызывает. В случае javascript нежданчик может прилететь откуда угодно. Из недавнего - проблема с jest и useContext. Хотя казалось бы - всё делал по инструкции. Нас пересадили на функциональные компоненты, но тулинг до сих пор сырой. Вот и приходится большую часть времени искать обходные пути вместо того, чтобы делать бизнес-задачи.

Проблема выбора 🔗

Неожиданно, но проблема выбрать библиотеку под задачу. mobx vs redux vs flux vs rxjs? i18n-react vs react-i18next vs react-intl vs react-localization vs react-localize? и так далее… Прям NIH синдром какой-то. Каждый старается сделать что-то своё, а не улучшить существующие. Вот список из ~90 state-менеджеров, к счастью, большая часть из них заброшена. Подобное есть и в других языках программирования, но по количеству звёзд на github обычно можно выбрать самое популярное решение. Более того, “популярное” решение может через пару лет перейти в категорию “стыдно говорить”.

Сложность дебага библиотек 🔗

Во всех своих статьях Абрамов делает ремарку “you don’t need to know this to be productive in React”. Но мне кажется как раз изучение как работает фреймворк/язык/библиотека и позволяет становиться продуктивным разработчиком! Наши инструменты не кофемашина с 4 кнопками - это сложные вещи, которые скрывают от нас огромную часть логики. Но! Их пишут тоже люди, так что там иногда бывают ошибки. И как раз хороший разработчик может заглянуть внутрь и разобраться как если не исправить, то хотя бы митигировать проблему.

В случае javascript вы вынуждены работать с библиотекой как с чёрным ящиком. Код в node_modules зачастую поставляется без исходников, а это исключает возможность лёгкой его модификации и дебага. Нет, вы, конечно, можете пойти на github, скачать исходники, подбросить их в node_modules, там скомпилировать, но вряд ли вы этим будете заниматься. Скорее пойдёте на github в поисках подходящего ишью. Эх, прощай инженерная культура. Когда людям было интересно разобраться что внутри и самим найти проблему.

Сложность дебага своего кода 🔗

Chrome Dev Tools - невероятно мощная штука! Я в восторге насколько досконально он позволяет разобрать что же происходит со страницей. Но, к сожалению, отладчик там зачастую бесполезен. На скрине некоторая точка останова, сможете понять как мы сюда пришли? javascript настолько погряз в “асинхронности” и фреймворках, что ваш код выполняется внезапно. Тут под “асинхронностью” я понимаю работу через saga, redux, flux - которые являются прокси-кодом к вашему. Т.е. по стектрейсу зачастую нельзя понять как вы оказались в этом месте. Да, можно помечать исходники как black box, но вы устанете это делать.

Ненужные понятия 🔗

Моё знакомство с экосистемой javascript началось со статьи Каково оно учить JavaScript в 2016.

Здесь про конифгурирование webpack 3 дня, babel, typescript, bundle,

Переусложнённость кода 🔗

https://www.stsdevweb.com/reactjs/reactjs-redux-saga-reselector-architecture

Если js плохой, зачем я вообще на нём пишу? 🔗

Javascript не плохой и не хороший - он как перфоратор, всего лишь один из инструментов. Какие-то вещи на нём решаются легко, какие-то проблемно. Даже разработчики Electron признали, что выбрали неправильную технологию, и переписывают на Rust. И это нормально - люди пробуют разные подходы; ошибиться здесь не страшно - хуже упрямствовать в неверных суждениях.

Могло сложиться ощущение, что я ненавижу javascript всем своим существом, но нет. Я буду продолжать его использовать в своей работе. Временами жевать кактус, иногда находить обходные пути для упрощения разработки. Проблемы есть в каждой экосистеме. И хоть мне нравится Django, но статье Окей, Джанго, у меня к тебе несколько вопросов я поставил плюсик, т.к. автор хорошо расписал вещи, над которыми ещё надо поработать.

Вот с чем я не смогу согласиться - с “best practice” по разработке на js и принятыми большинством подходами. Глобальное состояние типа redux я буду использовать только в крайнем случае; сайд-эффекты буду стараться инкапсулировать в компоненты, а не писать очередную сагу; использовать функциональные компоненты только если там действительно нет стейта… Но это лично мои предпочтения. Мне кажется, что такой код будет проще и в разработке, и в сопровождении.

=====================

Почему javascript не должен быть вашим первым языком программирования

• фреймворки не мотивируют писать хороший код
• низкое качество библиотек
• невозможность покопаться внутри
• webpack, который преобразует код
• лишние понятия, которые необходимы для изучения
• redux головного мозга, ограничивающий видение и подходы

https://habr.com/ru/company/ispmanager/blog/686080/ https://habr.com/ru/company/ispmanager/blog/689818/