Усталость от Javascript

Несколько дней назад я встретился с другом и заглянул за чашечкой кофе.

Саул: Как дела?
Я: «Устал».
Саул: Семья?
Я: «Нет, Javascript».

Точнее, я имел в виду React и прилагаемую к нему экосистему Javascript.

Для начала учтите, что

спросил, почему React подавляет новичков:

Если вы используете React, вы, вероятно, разделяете тот же опыт с

:

В сообществе React существует серьезная проблема, которая калечит новичков и мешает экспертам.

Слишком много инструментов.

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

В конечном итоге проблема заключается в том, что , выбрав React (и, по сути, JSX), вы невольно попадаете в запутанное множество инструментов сборки, шаблонов, линтеров и поглотителей времени, с которыми нужно иметь дело, прежде чем вы когда-либо что-нибудь создадите .

Котельные плиты и генераторы - не ответ.

Yeoman & Plop может уменьшить количество операций копирования и вставки между проектами.

Однако сгенерированное совпадение никогда не бывает однозначным и не может быть.

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

Когда генератор является хорошим решением для повторяющегося кода, лучшим решением будет абстрагировать его в более простой API.

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

Я испытал это на собственном опыте с несколькими генераторами, включая мою собственную разработку / wordpress .

Слишком много API. Слишком много настроек.

Пример этого можно увидеть в

Благодаря отличному сборщику ответов , библиотеки, такие как Redux , React Router , Webpack и экосистема React, в значительной степени выбрали дискретную модуляризацию за счет кратких API-интерфейсов, переложив свои архитектурные основы на пользователя и, как следствие, опыт разработчика в совокупности.

По отдельности API-интерфейсы невелики, но даже меньшая их часть создает почти непонятный беспорядок кода для каждой новой пары глаз.

Даже если они содержатся в «шаблонном» проекте, созданы генератором или спрятаны в файле finalCreateStorev3SeriousThisTime.js , мы создали « крысиное гнездо» проводки, которое заставит плагины WordPress покраснеть.

Больше абстракций. Меньше кода.

Конечно, эти API-интерфейсы необходимы для наличия меньших по размеру, развязанных, тестируемых и, следовательно, высококачественных библиотек.

Однако нам нужна абстрактная золотая середина между зависимостями проводки и генерацией шаблонов .

Абстракции необходимы, чтобы снизить когнитивную нагрузку на то, как все работает, чтобы вы могли сосредоточиться на творчестве.

Боритесь против строк кода.

Любой крупномасштабный проект уже будет содержать значительный объем кода.

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

Следовательно, инструментальная оснастка должна быть по возможности минимальной .

Рассмотрим этот наспех составленный список альтернатив :

• Предоставьте самоуверенный, одобренный автором API - оболочку или библиотеку для теоретических 90% случаев использования.
  (Сокращение шаблона для React + Router + Redux само по себе было бы огромным улучшением для многих.)
• Публикация прецеденты пресетов родственной (например , Бабель es2015 , реагирует и т.д.) предустановки.
• Используйте соглашения об именах папок и файлов для автоматического обнаружения специфичных для приложения маршрутов, действий, тестов и т. Д.
  (Это уже обычное дело для тестирования (например, Mocha ) и обслуживания общедоступных активов, но каким-то образом каждый проект волшебным образом требует конфигурации единорога.)
• Инструментарий быстрой разработки приложений (RAD), управляемый сообществом, значительно откладывает необходимость явной конфигурации до тех пор, пока не будет определена область применения.

Инструменты RAD

Следуя приведенным выше обсуждениям в Твиттере, многие справедливо признают, что универсального решения не существует.

Однако, если мы начнем с намерения просто создать прототип, лежащие в основе абстракции не имеют значения.

Связанный,

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

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

• budō
• nwb
• защита
• Rackt-Cli
• rwb

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

Фактически, мой друг чувствует, что возникает такая же закономерность:

2016 год, вероятно, будет включать серьезное целенаправленное объединение проектов, инструментов и языковых функций для объединения лучших и самых ярких пакетов / инструментов / шаблонов в более формализованные проекты. -

в State of the Union.js

Вперед в захватывающий 2016 год! :)