Как веб-разработчик я трачу много времени на «кодирование», но на самом деле очень мало времени уходит на ввод Javascript, HTML или CSS в окно SublimeText. «Кодирование» включает в себя тщательный просмотр документации, выборочное тестирование изменений и отладку ошибок. А еще есть ужасная задержка обновления. Любой разработчик, который хоть немного отошел от этапов проекта «Hello World», знает, что «кодирование» означает множество переходов от редактора кода к браузеру. Внесите изменения, обновите. Черт возьми, не то, что я хотел… еще одно изменение, обновление. Здесь я подробно рассказываю о своем опыте экспериментов с различными инструментами разработчика, пытаясь избавиться от утомительной разработки для Интернета и сделать ее увлекательной.

Изменения

Летом 2013 года я принял решение бросить свою скромную, но неудовлетворительную работу в качестве универсального консультанта .NET в Шарлотте, Северная Каролина, чтобы переехать в Сеул, Южная Корея, и присоединиться к маркетинговому агентству стартапов моего друга в качестве ведущего разработчика. . В то время я не был очень хорошим веб-разработчиком. Я немного окунулся в Wordpress и собрал несколько очень скромных сайтов для друзей, но я никогда не тратил много времени на изучение этого ремесла, кроме самых необходимых вещей, необходимых для создания этих нескольких сайтов. Но это было нормально, потому что я был голоден, чтобы учиться по ходу дела, и, надеюсь, смогу заняться некоторыми интересными проектами на этом пути. Первые несколько месяцев на этой должности я работал в основном над сайтами Wordpress и мучительно медленно редактировал CSS вручную в редакторе администратора Wordpress. Фу.

Кодекит

На моем столе появилась работа по созданию рекламного микросайта для нового клиента. Ничего сложного, просто нужно было сделать быстро. Это было похоже на глоток свежего воздуха. Я больше не был привязан к ненужной сложности Wordpress ... Я мог просто писать чистый HTML, Javascript и CSS с легким бэкэндом PHP. Просто, легко. Но я обнаружил, что вручную регулярно обновляю окно браузера . Именно тогда я нашел Codekit. Codekit делает много интересных вещей за кулисами, чтобы помочь новичкам в веб-разработке, но для меня функция автоматического обновления была именно тем, что мне было нужно в то время. По мере того, как крайний срок приближался, и я был глубоко погружен в свои таблицы стилей, настраивая каждый последний пиксель, я был так рад видеть, что мои изменения автоматически отражаются в окне моего браузера.

По мере появления новых проектов я начал расширять возможности Codekit. Я начал увлекаться LESS и SASS для создания более чистого CSS. Узнал об интеграции популярных интерфейсных фреймворков с Bower. Однако в какой-то момент мне захотелось узнать больше о том, что Codekit делает за кулисами.

Хрюканье

Примерно в это же время я унаследовал проект Wordpress (веб-сайт Chattanooga Whiskey), который использовал Grunt для создания и развертывания сайта. Хотя я слышал о Grunt, у меня не было особой мотивации попробовать его, поскольку Codekit отлично работал у меня. Но Grunt был настолько неотъемлемой частью разработки сайта предыдущей командой разработчиков, что было бы контрпродуктивно переделывать его в проект Codekit. После некоторого первоначального вздора я начал понимать силу и гибкость возможности писать код для управления обработкой файлов и автоматическим обновлением, о котором я раньше полагался на Codekit. Не путайте, Codekit - отличный продукт, который позаботился о 90% моих потребностей, но как серьезный разработчик я чувствовал, что важно пойти на один уровень глубже, чтобы понять систему сборки.

По мере того, как я больше работал с Grunt, я начал преодолевать его границы и ограничения. Grunt - это конфигурация вместо кода, которая хороша для быстрого начала работы над небольшими проектами, но имеет тенденцию к сбоям со временем по мере роста сложности вашего проекта. Выполнение задачи, для которой еще нет готового плагина, может стать проблемой. В процессе отладки некоторых пользовательских задач Grunt, которые я написал, я видел все больше и больше сообщений в блогах и статей, в которых заявлялось о превосходстве Gulp (новый вариант средства выполнения задач Node) как инструмента разработки.

Глоток

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

Поэтому я остановился на Gulp как на лучшем инструменте разработчика, который можно добавить в свой набор инструментов, и начал использовать его во всех своих новых проектах. Gulp обрабатывал линтинг JS, транспилинг React jsx, преобразование Jade в HTML, связывание зависимостей и синхронизацию браузера. Я так гордился собой, что наконец-то добрался до современного рабочего процесса веб-разработчиков… пока я не начал свой последний проект, в котором использовался довольно тяжелый Javascript. Я хотел получить зависимости Javascript с помощью операторов require (), но для выполнения этого на интерфейсе потребовались некоторые дополнительные инструменты, самым популярным решением было Browserify. По мере того, как я втягивал все больше и больше зависимостей (React, React DOM, JQuery, Bootstrap, Modernizr), мои перестройки JS занимали все больше и больше… до 4 секунд, что является вечностью, если вы ждете незначительного изменения кода, чтобы отразиться на странице. Я начал чувствовать тот знакомый зуд, что должен быть способ получше ...

Webpack

По мере того, как я пробирался через StackOverflow в поисках решений моих проблем с Browserify, я видел все больше и больше ссылок на Webpack. Я прочитал документацию Webpack и прошел через руководство, но в конце концов отклонил его как слишком большое изменение, чтобы добавить его в незавершенный проект. Тем не менее, мне понравилась идея рассматривать Javascript как единый источник истины и устанавливать зависимости (изображения, CSS и т. Д.) В модули JS, а Webpack обрабатывать детали. Это было немного больше похоже на смену парадигмы с точки зрения традиционного создания веб-сайтов, но я мог видеть преимущества обработки и обслуживания всех файлов из памяти (в отличие от создания файлов для записи на диск) - перестройки JS должны были быть молниеносными быстро… Грааль! К счастью, запуск моего проекта был отложен на пару недель, поэтому я немедленно запустил новую ветку кода, чтобы вырвать мою неэффективную установку Gulp и заменить ее на Webpack.

Мои требования были такими:

  • Быстрая перестройка JS (менее 1 секунды) даже при большом количестве зависимостей
  • Линтинг JS (чтобы быстро отловить ошибки кода перед попыткой объединения)
  • Исходные карты JS (по мере того, как мои проблемы с Browserify усиливались, я отказался от исходных карт, чтобы добиться более эффективного времени сборки, но я начал их сильно скучать)
  • Sass в CSS
  • Jade в HTML
  • Интеграция с браузерами
  • Интеграция с минимальным сервером Node / Express

После пары дней борьбы и обучения (в основном первого) я отобрал установку, которая соответствовала всем вышеперечисленным требованиям. В этот момент я все еще ждал информации о том, насколько далеко продлится задержка в моем проекте, поэтому я воспользовался возможностью более подробно изучить Горячая замена модуля, которая появилась в документации как более продвинутая настройка Webpack. Поскольку мой проект в значительной степени опирался на React, он казался естественным… вдохновленный блестящей публикацией @dan_abramov и сопровождающим его видео на YouTube (ниже), я решил, что мне просто нужно его получить. Возможность сохранять состояние между перестроениями JS звучит потрясающе. Я был взволнован, думая обо всех возможностях повышения эффективности.

В конце концов я очищу свою текущую сборку Webpack и встроу сюда Github Gist. Тем не менее, достаточно сказать, что мой путь от программирования и обновления вручную летом 2013 года до моей текущей настройки с помощью Webpack резко повысил эффективность моей разработки. Теперь я могу кодировать и видеть результаты так быстро, что очень взволнован следующим проектом, который появится на моем пути.