Фреймворки JavaScript считаются вредными

Первый вопрос, который вы всегда задаете сейчас, когда пишете новое веб-приложение, - а какой интерфейсный фреймворк мы будем использовать - Ember, Angular или React?

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

В наши дни почти каждое веб-приложение создается с использованием одной из этих трех или аналогичных фреймворков. И они используют фреймворки для CSS, фреймворки для сборки, фреймворки для тестирования и фреймворки для других вещей. Мы больше не пишем код на JavaScript, CSS или HTML; мы пишем код на псевдоязыках, созданных разработчиками фреймворка.

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

Нам нужны не фреймворки, а un -frameworks, или анти -frameworks, или никакие фреймворки вообще. Я делаю предложение в конце этого эссе; читать дальше.

Подход, ориентированный на рамки, особенно удивителен в Америке, все еще характеризующейся индивидуалистическим мышлением «не наступай на меня», либертарианским и ковбойским менталитетом. В высшей степени странно, что американские разработчики применяют патерналистский подход сверху вниз к архитектуре компьютерных систем, который мы видим в фреймворках.

Но в чем на самом деле проблема JS-фреймворков? В конце концов, разве они не делают за вас тяжелую работу? Разве они не позволяют вам сосредоточиться на проблеме? Разве они не избавляются от ненужного шаблона? Разве они не обеспечивают концептуальную структуру вашего приложения? Разве они не принимают за вас трудные решения?

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

Кроме того, поскольку это «фреймворк», цель которого - делать за вас как можно больше вашей работы, включая работу, о которой вы даже не подозревали, что вы этого хотите, существует неизбежная тенденция к выходу за рамки всех разумных границ, как с точки зрения размера (помните, мы должны загрузить JS для этих фреймворков), так и с точки зрения размера - с сотнями или даже тысячами классов и объектов, интерфейсов и API.

Ниже я расскажу о специфическом фреймворке под названием Ember.js, потому что это то, с чем я знаком. Судите сами, относятся ли мои комментарии к другим фреймворкам.

Разработчики Ember заявляют, что их архитектура действительно модульная и насколько легко было бы теоретически заменить новый маршрутизатор или механизм шаблонов. На практике этого никогда не делают, потому что это было бы похоже на трансплантацию мозга. Они даже не говорят о замене местами в новой объектной модели, потому что вся система основана на жесткой классической парадигме ООП, которая противоречит тому, как JavaScript предпочитает обрабатывать работу с объектами. Вся выбранная ими модель MVC была заимствована из других проектов MVC, которые были разработаны для сервера, без учета того, что означало иметь MVC на клиенте - и теперь, спустя годы после того, как Ember начал широко использоваться, они стали предлагая убрать букву «С», уже убрав букву «V».

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

Ember придерживается политики шестинедельных выпусков. Это может показаться вам неоправданно быстро - потому что на самом деле это неоправданно быстро. Одна из причин того, что выпуски такие частые, - это исправление ошибок, возникающих из-за того, что выпуски такие частые. Другая причина в том, что у дизайнеров фреймворка появилось несколько новых интересных идей. Разработчики могут пропустить шестинедельные выпуски, но это означает пропустить исправления ошибок, которые нарушают работу их приложений. Вместо этого разработчики могут ждать и обновляться каждые три месяца, но к этому моменту объем промежуточных изменений настолько велик, что обновление может быть очень болезненным и привести к ошибкам и рискам. Подобные проблемы с обновлением можно увидеть и с другими фреймворками JS.

Ключевая проблема фреймворков заключается в том, что когда я дохожу до того, что он не может делать то, что мне нужно, я падаю с обрыва. В этот момент мне нужно взломать фреймворк или переписать его части, которые мне нужны. Но подождите: нельзя ли решить все эти проблемы с помощью концепции надстроек к фреймворку? Собственно, совсем нет. Оставляя в стороне вопрос о том, действительно ли я могу найти надстройку, которая мне может понадобиться, или надстройки хорошо спроектированы, поддерживаются, поддерживаются или поддерживаются в актуальном состоянии с помощью фреймворка, что слишком часто не тот случай, дополнительные интерфейсы часто бывают сложными и содержат ошибки; Я могу в конечном итоге потратить на отладку надстройки больше времени, чем экономлю. Само понятие надстройки фреймворка является окончательной отговоркой автора фреймворка: «пусть они используют надстройки».

Маленький грязный секрет JS-фреймворков, а не только Ember, заключается в их ужасной производительности на мобильных устройствах. Во-первых, нам нужно загрузить огромную среду выполнения при медленном соединении. Затем у нас есть огромное количество кода фреймворка, работающего на устройстве, которое имеет более медленный процессор для начала, но может также иметь плохой JS-движок. Результатом могут быть задержки в секундах или даже десятках секунд просто для отображения страницы. У этой проблемы нет простого решения.

Огромная проблема фреймворков заключается в том, что они не успевают за изменениями в окружающих технологиях. Часто ключевым элементом фреймворков является «заполнение дыр» - предоставление решений, которые не могут предоставить базовые базовые технологии. Однако структуры обычно в конечном итоге заполняют дыры способами, несовместимыми с тем, как технологии могут развиваться или, в конечном итоге, будут развиваться; или они построены таким образом, что затрудняет или делает невозможным использование преимуществ новых технологий. Ember будет очень сложно адаптировать свою архитектуру для использования преимуществ веб-воркеров, если взять только один пример. Также потребуется масштабная переработка архитектуры, чтобы воспользоваться преимуществами JS-прокси. В случае, если структура обновляется для использования преимуществ новых технологий, обычно требуются навязчивые архитектурные изменения, которые вызывают проблемы управления версиями, описанные выше.

Мы можем видеть это на примере CSS и чрезвычайно популярного фреймворка Bootstrap, использование которого настолько широко распространено, что теперь появляется в описаниях должностей. Ключевым аспектом Bootstrap было заполнить дыры из-за отсутствия возможности упорядочивать вещи на страницах, проблема, которая теперь в значительной степени решается с помощью flexbox, который доступен во всех поддерживаемых браузерах. Тем не менее, люди по-прежнему застряли в гетто Bootstrap, имея неопределенный путь обновления до альфа-версии 4.0, которая поддерживает flexbox. Хотя мы можем не захотеть называть их фреймворками, препроцессоры CSS, такие как SASS, также являются классическими фреймворками для заполнения дыр, которые способствуют плохой практике CSS и вводят дополнительные громоздкие шаги сборки. Мания по поводу фреймворков сейчас дошла до того, что на странице Википедии по фреймворкам CSS перечислено более двух десятков; у нас также есть фреймворки, которые создаются поверх других фреймворков.

Что касается строительства, возможно, нам не следует называть grunt, gulp или broccoli фреймворками, но они действительно являются формой фреймворка для строительных проектов. И снова они руководствуются принципом отец-знает-лучший, решая за вас, как должен быть построен ваш проект, и дают вам небольшие места для развешивания украшений. Большая часть или все это новое поколение фреймворков сборки, созданных миллениалами, игнорирует десятилетия солидной работы, проделанной над системами сборки, такими как GNU make - большинство из них, вероятно, даже не слышали о ней - и по сути изобретают колесо, за исключением эти колеса часто имеют некруглую форму и фактически не катятся по земле.

Решение

Просто откажитесь от фреймворков.

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

Ваше приложение - это не то, что вы зависаете от фреймворка; это то, что вы сочиняете.

Фото Рикардо Гомес Анхель на Unsplash