Сергей Волошин
March 30, 2016
За последние несколько лет front-end разработка ушла далеко вперёд. От банальной верстки html-страниц при помощи CSS c минимальной динамикой, задаваемой javascript/jquery, практически не осталось и следа. Если вы не работали хотя бы с одним из сборщиков front-end проектов (grunt, gulp, webpack), не слышали слова "транспайлер" (babel), не знаете, что на front end тоже можно писать тесты (jasmine, mocha, chai), и запускать их автоматически в любом браузере (karma), то вы весьма сильно отстали от жизни. А ведь есть ещё React.js (библиотека для построения интерфейсов), ES6 (новейший стандарт языка javascript, который ещё не поддерживается большинством браузеров, но если очень хочется, то уже можно использовать в production-коде), Node.js (платформа, позволяющая исполнить мечту любого front-end разработчика - писать не только front end, но и back end проекта на любимом javascript) и многое-многое другое.
Но как и любое новшество, данный скачок в развитии имеет две стороны медали. Мы попытаемся разобраться, какие есть недостатки и достоинства в работе с самыми новыми front-end технологиями и как постараться избежать проблем при старте работы с ними.
Работая над проектами в Anadea Inc., мы успели испробовать не только все вышеназванные, но и многие другие инструменты front-end разработчиков. Это был длинный и тернистый путь, и теперь мы хотим поделиться полученным опытом, дабы помочь вам приоткрыть дверь в мир современной javascript-разработки.
Поговорим о преимуществах использования передовых front end инструментов.
Pros
- рост скорости решения задач;
Эта одна из основных причин появления всех вышеназванных инструментов. Благодаря им значительно сокращается время, затрачиваемое на рутинную работу. Например, благодаря, karma вы можете запустить тесты в режиме слежения сразу во всех имеющихся браузерах (а также в вашей виртуальной машине и даже на мобильных устройствах, подключенных к той же локальной сети, в которой находится ваш компьютер) и при каждом сохранении изменений в коде тесты будут автоматически перезапускаться.
Или же для создания нового проекта вы можете начать использовать yeoman(генератор проектов). С его помощью этот этап жизни проекта превратится в запуск одной команды в терминале, которая даст готовую структуру папок и предустановленный набор инструментов. Довольно удобно, если вы делаете много типовых проектов.
- повышение качества кода;
В последнее время стали популярными линтеры (jslint, jshint, eslint) - инструменты, позволяющие определить стиль кода в вашем приложении и указывать на места, где выбранный стиль не соблюдается. В зависимости от настроек окружения, это может происходить во время push'a изменений в репозиторий, во время deploy'a на сервер, либо в реальном времени прямо внутри вашего текстового редактора/IDE. Линтеры позволяют в значительной степени улучшить состояние вашего кода, избежать простых ошибок. Однако линтеры не являются решением всех проблем - они лишь укажут на места, где ваш код явно "плохо пахнет". Но это не исключает изучение pattern'ов и лучших практик программирования, чтение чужого кода, общение с более опытными коллегами и всё так же придётся рефакторить ранее написанный код. Только так удастся добиться повышения качества кода.
- значительное снижение дублирования кода;
Ещё один полезный момент, который можно извлечь из использования линтеров - это возможность отслеживать дублирование в коде и избавляться от него. Но это не главный инструмент сокращения дублирования кода в мире современной javascript-разработки. К основным можно отнести Node.js, который при правильной архитектуре позволяет использовать один и тот же код и на back end, и на front end. Также снизить дублирование позволяет компонентный подход, применяемый многими библиотеками (например, React.js), и удобная система управления пакетами - npm. Компонентный подход позволяет инкапсулировать логику, стиль и отображение. Npm предоставляет несложный способ распространения (share) таких компонентов.
- возможность программирования в реальном времени;
И самый "горячий" плюс в современной front-end разработке это - hot reload - возможность делать изменения в коде и видеть их на экране браузера без перезагрузки страницы и без потери текущего состояния данных. Эта feature доступна на данный момент только тем, кто использует в качестве builder'a проекта webpack. Если вам интересно как это выглядит, можете посмотреть пример с React.js.
Но как уже было сказано выше, современный front end имеет и обратную сторону медали. Давайте посмотрим на недостатки, которые нам удалось выявить в процессе работы с новейшими инструментами javascript.
Cons
- высокий порог вхождения в окружение;
Как бы ни было, за всем разнообразием front-end инструментов скрываются три технологии: javascript, html, css. Но чтобы вывести банальный "Hello, world!" на экран своего монитора современным способом, вам придётся ознакомиться не меньше чем с десятком документаций, написать несколько не самых очевидных файлов конфигурации и запустить череду команд в терминале. Всё это отпугивает как новичков, так порой и опытных программистов, не желающих познавать новое. Настройка окружения действительно важный этап в современном мире front end'a. Хорошая новость в том, что это необходимо будет сделать "практически" один раз. Плохая - если вы постараетесь проскочить этот этап, бездумно скопировав чьи-то решения, то он постоянно будет возвращаться к вам часами серфинга просторов интернета в поисках решения банальных проблем.
- "усталость от javascript инструментов";
В javascript-community всё чаще стал звучать термин "javascript fatigue", под которым подразумевается усталость от разнообразия инструментов и их бесконечных версий. Некоторые авторы называют 2016 "годом борьбы" с побочным эффектом роста числа инструментов и предполагают, что в этом году усилия javascript-сообщества будут направлены на решение этой проблемы.
Суть javascript fatigue сводится к тому, что если вы не следите за числом модулей, подключенных в проект, управление зависимостями превращается в сущий ад. Из-за обновления одного инструмента до новой версии вам придётся обновить ещё три, которые в свою очередь тоже имеют свои зависимости - и так до бесконечности. Если у вас несколько проектов, то приходится держать в голове не только специфику связей между модулями, но и специфику связей между версиями этих модулей, которая в мажорных версиях зачастую меняется кардинально.
- большой выбор способа конфигурации модулей;
Мы долго сомневались, к достоинствам или недостаткам относить этот пункт, но так как статья рассчитана на новичков, то чаша весов всё-таки склонилась к недостаткам. И вот почему.
Практически каждая большая зависимость (webpack, karma, gulp, eslint и т.п.) в вашем проекте будет предоставлять более одного способа конфигурации: с помощью своего конфигурационного файла; через конфигурационный файл родительского модуля; с помощью флагов в shell-скриптах и т.д. Казалось бы, дополнительная гибкость - что плохого? А то, что на начальных этапах вы обязательно столкнётесь с ситуациями, когда настроив один инструмент, захотите добавить второй, расширяющий функциональность первого, и поймёте, что новый инструмент не работает. Виной тому часто становится банальная недосказанность в документациях инструментов о том, как они должны взаимодействовать и неосознанность возможных способов конфигурации этого взаимодействия.
- нехватка ресурсов для поиска ответов;
Из-за неимоверного количества инструментов в мире современного front end'a пытаться удержать в голове знания о каждом становится практически невозможно. Для решения данной задачи программисты часто прибегают к помощи ресурсов для поиска ответов проверенных временем (stackoverflow.com, experts-exchange.com, superuser.com, github.com и др.). Но в нашем случае проблема в том, что инструменты и их новые версии появляются настолько быстро, что мы фактически являемся их бета-тестерами и сталкиваемся с проблемами, нигде ранее не описанными, отчего не можем даже понять, возможно ли их решить или же это баг библиотеки, которую мы решили использовать.
Как избежать проблем
Недостатков мира современного javascript достаточно легко избежать, придерживаясь простых правил.
Старайтесь использовать минимально-необходимый набор инструментов. Сперва может показаться, что для решения задачи куда легче выполнить команду
npm install brilliant-module-that-will-solve-my-problem-by-one-string
и это действительно так на начальном этапе проекта. Но с ростом проекта и с течением времени инструменты устаревают, и приходит время обновлять их. И в этот момент вы испытаете весь ужас своего решения. Может оказаться, что ваш модуль перестал поддерживаться, или он не успел обновиться до новой версии других, более весомых инструментов в проекте, или разработчик решил кардинально изменить интерфейс модуля, и теперь уже решение с его помощью не выглядит столь элегантно.
Если вы только шагнули в мир современной front-end разработки, старайтесь не использовать готовые шаблоны приложений. Их основная проблема - забитость до отказа инструментами, с которыми вы никогда не работали. И когда вам понадобится внести минимальные изменения, может оказаться, что из-за большой связанности инструментов и недостатка знаний в их настройке, вы не сможете получить желаемый результат.
Заключение
Современная front-end разработка находится уже далеко за пределами чистых js/html/css. Число инструментов, призванных помочь разработчикам, растёт в геометрической прогрессии. Но это ведёт не только к позитивным последствиям. Чем больше инструментов, тем сложнее рассмотреть среди них действительно стоящие - те, которые отслужат верой и правдой на протяжении всей жизни проекта и не подведут в ответственный момент. Именно такие инструменты мы попробуем помочь вам выбрать в следующей статье.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.