Давайте немного подумаем о том, что мы создаем, когда мы создаем вещи для Интернета.
Мы создаем традиционные веб-сайты — все же, я бы сказал, подавляющее большинство контента в Интернете. Они ориентированы на документы, хотя они могут — и даже более того — включать интерактивный контент, похожий на приложение.
Мы также сейчас часто создаем больше приложений, меньше документов. Это, как мы знаем, продолжалось довольно долго, но большую часть времени большая часть логики нашего приложения находилась на сервере, а клиент был в значительной степени тупым интерфейсом.
В последние годы (хотя примеры этого, такие как Google Maps и Gmail, встречаются довольно давно), наши клиентские приложения стали более сложными, в частности благодаря возможности отправлять данные, а не целые страницы на сервер и с сервера. В наши дни мы называем это Ajax, хотя, когда люди начали это делать, у него не было имени.
За последние три или четыре года, благодаря успеху платформ мобильных приложений, таких как iOS и Android, мы ожидали, что мобильные приложения (особенно), работающие в браузере, будут более похожи на нативные.
И в ответ на это возникла особая архитектура для создания таких типов нативных приложений: одностраничное приложение (SPA).
Разработчики, создающие эти SPA, обнаружили, что существуют определенные проблемы при разработке их с помощью веб-технологий: в частности, производительность и способность этих приложений работать, когда пользователь находится в автономном режиме.
Это вызвало кризисный менталитет у многих разработчиков в сети. У нас, кажется, есть зависть к приложениям. Веб-технологии сами по себе слишком медленные. Веб-ландшафт движется не так быстро, как родные платформы, такие как iOS и Android. Веб-приложения не работают в автономном режиме. Прокрутка «джанки».
В ответ на эти различные опасения, а также в ответ на растущую сложность вещей, которые мы сейчас создаем с помощью веб-технологий, мы увидели взрыв фреймворков, библиотек, инструментов сборки, языков, которые компилируются в JavaScript, и препроцессоров для CSS.
Я не говорю об этой критике, эти проблемы не реальны, не болезненны и не нуждаются в решении. Но я думаю, что мы должны быть очень осторожны, как мы решаем их. И я не уверен, что мы достаточно осторожны.
Легче жить через сложность
Рич Хики, изобретатель Clojure , говорит о том, как мы, разработчики, часто ищем легкости за счет сложности того, что мы создаем. Вы можете посмотреть, как он говорит об этом здесь . Вы действительно должны. Это хорошо стоит времени.
Легкость, отмечает он, — это то преимущество, которое мы получаем как разработчики. Мы запускаем Yeoman и получаем все строительные леса и инфраструктуру, необходимые для нашего последнего проекта, одним нажатием кнопки. Но сколько взаимозависимостей, сколько ненужной сантехники у нас сейчас есть, на что опирается наш проект?
Насколько сложнее наше приложение? Сложность — это аспект того, что мы строим. И чем сложнее что-то, тем сложнее его отладить и поддерживать.
В наши дни трудно представить, что многие сайты создаются без использования монолитной библиотеки, такой как jQuery, библиотеки пользовательского интерфейса и даже большей инфраструктуры. Вот как мы «решили» вызов все более сложных вещей, которые мы собираемся создать.
Но все это влияет на производительность нашего сайта, поэтому нам нужно минимизировать и объединить наши файлы.
Это означает, что нам нужны инструменты для выполнения этих задач сборки.
Что затрудняет отладку, поэтому нам нужны исходные карты.
И, конечно, CSS сложен и в нем отсутствуют такие вещи, как переменные и циклы (потому что вы знаете, что это декларативный язык программирования), поэтому нам нужны препроцессоры, чтобы сделать CSS более похожим на императивную парадигму программирования.
Что означает еще больше инструментов для сборки.
И еще большее расстояние между нашим исходным кодом и системами, которые мы создаем.
И еще больше слоев абстракции.
И, конечно, это означает, что нам нужны исходные карты для отладки нашего CSS.
И потому, что это сложно, и из-за того, что фигурные скобки болезненно набирать — как, конечно, слово «функция» — нам нужно работать в CoffeeScript, что означает больше предварительной обработки, больше инструментов сборки, больше исходных карт, больше абстракции.
Опять же, я не говорю, что все это плохо при любых обстоятельствах. Но каждый инструмент, каждый элемент технологии должен тщательно оцениваться каждый раз, когда мы используем его. В конце концов, иногда все, что мы создаем, — это простой, старомодный, ориентированный на документы веб-сайт. Как и в случае с ReadWrite, нужно ли его создавать с помощью Twitter Bootstrap? На каждой странице нужно в среднем 19 фреймов и столько же связанных файлов скриптов?
Да, инструменты могут сделать нашу жизнь проще. Мы набираем меньше нажатий клавиш и фиксируем больше кода. Но, как давно узнали инженеры-программисты, большая часть жизни приложения находится не в его первоначальной разработке. Это в поддержании этого. Это то, что мы в сети имели возможность игнорировать до сих пор. В конце концов, сколько вещей вы построите, будет длиться годами, десятилетиями? Мы все еще в основном строим, чтобы бросить и начать все заново.
Поскольку системы, которые мы создаем, все чаще заменяют традиционные корпоративные, клиент-серверные, настольные и мобильные приложения (да, так и будет ), эта роскошь создания одноразового кода без реальной заботы о том уровне сложности, на котором основан наш код, пройдет.
Нам пора взрослеть и начать учиться на более чем 50-летнем наследии разработки программного обеспечения.
Потому что, как и во всей истории, если мы не будем учиться на этом, мы обречены повторить это.
Эта статья была адаптирована Джоном из его речи на конференции Full Frontal JavaScript, состоявшейся в ноябре 2012 года в Брайтоне, Великобритания.