Как я перестал верить технологиям
Hype.js занимает 50 килобайт, работает в полтора раза быстрее React и совместим с его компонентами. В нём уже есть маршрутизация и сборщик, а серверный рендеринг работает из коробки. Разметку можно вынести в обычный HTML, константы препроцессора доступны прямо в приложении. За разработкой стоит Amazon. Кажется, можно заканчивать конференцию и идти переписывать проект.
У этого фреймворка только одна проблема: его не существует. Я его придумал. Собрал знакомые обещания, добавил громкое имя и несколько убедительно выглядящих цифр. Ни одной настоящей задачи он не решил, но захотеть его уже можно.
Библиотека, которая просуществует вечно
Когда я начинал заниматься веб-разработкой, мы радовались выпадающему меню и кнопке, которая меняла картинку при наведении. Потом появились библиотеки, и вместе с ними появилась надежда: наконец-то кто-то придумал, как всё делать правильно.
Первой такой библиотекой для меня стала Prototype.js. Я любил её, писал на ней проекты. Её использовала 37signals, на ней работал Basecamp. Хороший инструмент с понятными примерами применения.
А потом один из разработчиков Prototype, известный как kangax, заговорил о проблемах изменения встроенных прототипов. В Prototype так добавляли методы стандартным объектам JavaScript, например массивам. Вокруг этого поднялась большая волна: так делать нельзя, подход неправильный, библиотека обречена.
Я испугался. Если умные люди говорят, что инструмент плохой, наверное, пора искать другой. Сейчас, в 2016 году, можно оглянуться и увидеть, что никакой немедленной катастрофы не произошло. Prototype продолжает жить, в прошлом году вышел очередной релиз. Продукты 37signals не перестали работать от того, что мы разочаровались в способе их разработки.
Но я уже ушёл в Dojo Toolkit. Мне хотелось чего-то фундаментального, и Dojo умел, кажется, всё. Даже с офлайном он работал в то время, когда для браузеров это было большой редкостью. Только жить с таким количеством возможностей оказалось тяжело. Мне требовалась небольшая часть, а разбираться приходилось со всем этим хозяйством.
Следующей была YUI. За ней стояла Yahoo, а значит, думал я, здесь всё надёжно и надолго. Такая компания точно знает, что делает. YUI в итоге закрыли.
До jQuery я всё-таки дошёл, хотя прежде считал его просто набором функций и искал чего-то более фундаментального. Но почти сразу ушёл и с него. Постоянно менять библиотеки надоело: JavaScript я знал и мог писать сам.
У каждой библиотеки были свои возможности и ограничения. Только выбирал я их во многом по чужой уверенности. Один человек убедительно объяснил, почему всё плохо. Другой пообещал, что теперь будет хорошо. Я шёл за ними.
Демо получилось, CRM нет
Веб-интерфейс MobileMe меня когда-то по-настоящему впечатлил. Почта и календарь работали как приложение, без постоянных перезагрузок. Захотелось сделать так же.
Под капотом был SproutCore. Я попробовал разобраться, но примеры казались запутанными, кода было много, а ясности мало. И тут появился Backbone. Красивый, небольшой, понятный. Вот он, подходящий инструмент.
В компании уже работала CRM. Обычное серверное приложение: открыл страницу, что-то изменил, отправил форму. Всё необходимое оно делало. Но мне захотелось второй версии, современной и без перезагрузок.
Я придумал полное управление с клавиатуры. Стрелками перемещаешься по списку, по Enter открываешь карточку. Табом выбираешь поле, переходишь к редактированию, сохраняешь. Escape возвращает в список. Для человека, который целый день работает с карточками, это выглядело удобным решением.
На одном списке и одной карточке всё получилось прекрасно. Я решил сложную задачу и был очень собой доволен.
Потом началась остальная работа. За красивым примером обнаружилось большое приложение с разными интерфейсами. Для него приходилось писать множество обходных решений. Backbone помог быстро сделать впечатляющее демо, но оставшиеся задачи никуда не исчезли. Мой выбор инструмента их местами ещё и усложнил.
Мне нравилось придумывать управление с клавиатуры. Доводить до конца остальные экраны, разбирать ограничения библиотеки и заниматься рутиной нравилось гораздо меньше. В такой момент очень хочется попробовать другой фреймворк: кода пока немного, можно начать заново и в этот раз выбрать правильно.
Эту CRM я так и не дописал. Старая версия работала, поэтому от новой можно было отказаться. Я отказался. Технически интересная задача оказалась решена, а новой версии продукта не появилось.
Digitale заработала ценой сна
Со следующей историей такой выход уже не подходил. В 2012 году я делал сайт конференции Digitale. Нужно было регистрировать участников и продавать билеты, работать с заявками и личными кабинетами. Конференция должна была состояться, отношения со спонсорами уже были. Отложить всё потому, что разработчику надоело, нельзя.
Для сайта я выбрал Node.js. Несколько месяцев до этого читал, как здорово писать JavaScript на сервере. Асинхронность, скорость, восторженные отзывы. Хотелось попробовать в настоящем проекте.
На практике мне понадобились авторизация и платёжные системы. Готовых подходящих модулей не нашлось, пришлось писать самому. С отправкой почты модули уже существовали, но заставить их нормально работать тоже оказалось отдельной задачей.
Всё постоянно обновлялось. Я начал проект на Node.js 0.6, закончил на 0.8. Вместе с Node.js менялись зависимости, и на каждое такое изменение уходило время. Сам сайт при этом всё ещё нужно было сделать.
Я его запустил. Только значительную часть этой работы сделал вместо сна. Тратил всё свободное время, чтобы успеть к сроку, и к концу проекта был совершенно вымотан.
Мог ли я выбрать другой инструмент? Конечно. Я знал Ruby и PHP, мог взять Rails или знакомый PHP-фреймворк. Авторизация и платежи от этого никуда бы не делись. Для посетителя сайт выглядел бы точно так же. Зато мне не пришлось бы одновременно с разработкой продукта осваивать молодую платформу и дописывать недостающие инструменты.
В докладах «36» и «Пять минут» Вадим Макишвили говорит о том, что ресурс человека не бесконечен. Мне эта мысль очень близка после Digitale. Мы охотно считаем время выполнения кода и гораздо реже считаем собственные ночи, потраченные на то, чтобы этот код наконец заработал.
Академия началась с Bootstrap
В HTML Academy мы поступили иначе. В 2012 году первый сайт сделали на Bootstrap. Он и выглядел как Bootstrap: мы почти ничего не меняли.
Можно было потратить время на собственный дизайн и вёрстку. Но нам сначала нужно было проверить идею интерактивных курсов. Сделать содержание и понять, нужно ли оно людям. Мы выбрали эту работу.
Через два года сайт всё ещё был на Bootstrap. Мы его немного причесали, но ничего принципиально не изменилось. Курсы от этого хуже не стали, продукт продолжал развиваться. И только в 2016 году появилась новая главная страница без Bootstrap. К этому моменту мы понимали, зачем её меняем, и могли позволить себе такую работу.
Две миллисекунды и несколько переездов
С препроцессорами у меня происходило примерно то же самое. Сначала я выбрал LESS. Мы тогда в основном использовали миксины, чтобы писать свойства с префиксами. Автопрефиксера ещё не было, поэтому я собрал свою библиотеку таких миксинов.
Потом вокруг стали говорить, что LESS плохой, а Sass хороший. Я решил, что люди наверняка всё сравнили и разобрались. Перешёл на Sass. Для моих задач изменилось немногое: прежде переменные начинались с собачки, теперь с доллара. Работать было удобно в обоих случаях.
Затем Ти Джей Холовейчак показал Rework. Идея была интересная: писать CSS с возможностями будущих спецификаций, а преобразовывать его в то, что браузеры понимают сейчас. Я даже не успел толком применить Rework в работе, как появился PostCSS Андрея Ситника. Перешёл на него.
Дальше началась гонка скорости. У Sass стал быстрее парсер, об этом написали. Я вернулся на Sass: хотелось, чтобы стили собирались на пару миллисекунд быстрее. Потом Андрей выпустил обновление, и быстрее снова стал PostCSS. Можно переезжать обратно.
В каждом отдельном переходе находилось какое-то объяснение. Но если посмотреть на всю цепочку, становится неловко: сколько времени я потратил, чтобы сэкономить эти миллисекунды?
У людей, которые строили свои компоненты поверх Bootstrap, выбор вообще часто происходил за них. Bootstrap использовал LESS, значит, и компоненты писали на LESS. Bootstrap решил переходить на Sass, пришлось переписывать компоненты. На момент этого доклада уже обсуждался и возможный переход на PostCSS. Привязанность к инструменту легко превращалась в обязанность следовать за его авторами.
При этом сама задача могла оставаться прежней. Мы всё ещё делали сайт, только между нами и результатом появлялось всё больше настроек. Сборка усложнилась настолько, что для неё стали искать отдельных специалистов. Уже можно встретить вакансии, в которых главное умение человека связано с конфигурацией Webpack. Иногда кажется, что сначала нужно построить целую инфраструктуру, а потом наконец заняться страницей.
Что стоит смена инструмента
Мне нравится возиться с технологиями. Поэтому я не предлагаю перестать ими интересоваться. Мне хочется перестать принимать чужой восторг за основание переписать работающий проект.
В докладе «Антихайп» Андрей Листочкин приводил пример разработчиков на Ember. Пока окружающие спорили, что выбирать между Angular и React, эти люди продолжали работать. Непопулярность инструмента в очередной дискуссии не означала, что на нём нельзя делать продукты.
Правда, со стороны компании у этой истории появляется ещё один вопрос. Если специалистов мало, их дольше искать и дороже нанимать. Это тоже часть выбора. Популярность может помочь с наймом, но количество разговоров о технологии ещё не говорит, сколько людей умеют применять её в реальной работе.
Если команда хорошо знает Angular, а заказчик требует переписать всё на React, разговор стоит перевести в сроки и деньги. Новый инструмент придётся изучать прямо в проекте. На это уйдёт время, которое иначе можно было бы потратить на сам продукт. Такое решение нужно обосновать, даже если идея уже очень понравилась заказчику.
У разработчика здесь есть своя ответственность. Мы участвуем в создании продукта и принимаем решения, а не просто выдаём код по чужому списку. Где-то выбор делает сам разработчик, где-то руководитель команды. В любом случае о последствиях можно договариваться.
Для меня разумно работать тем, что хорошо знаешь, и следить за тем, что происходит вокруг. Если я умею решить задачу на обычном JavaScript, мне не обязательно брать фреймворк. Если вы знаете конкретный фреймворк и он подходит, нет причины от него отказываться только потому, что кто-то разлюбил его в интернете.
Следить за изменениями не значит перепробовать каждую новинку. На городском митапе можно за вечер услышать чужой опыт и обсудить его. В «Веб-стандартах» мы собираем новости и разбираем их в подкасте, чтобы не каждому приходилось тратить на это столько же времени. А чужую оценку всё равно стоит проверять: ни моё мнение, ни уверенность другого докладчика не заменят собственного понимания.
При этом новые способы мыслить бывают важнее новых библиотек. Попробовать другой язык или разобраться с реактивным программированием полезно, даже если завтра это не потребуется в проекте. Такой опыт расширяет кругозор. Установить ещё один инструмент для уже знакомой задачи и разобраться с непривычной идеей для меня разные занятия.
Что слышит начинающий разработчик
С опытом проще отделить полезное от рекламы. Новичку гораздо труднее. Он ещё не знает, нужен ли ему React, а вокруг уже все обсуждают, какой React правильный.
Андрей Захарченко, который собеседовал наставников в HTML Academy, рассказывал о кандидате в верстальщики. На вопрос о построении сетки тот объяснил: берёшь нужный класс Bootstrap, добавляешь элементу, и сетка готова. Как она устроена дальше, человек не знал.
Человек научился пользоваться классами Bootstrap, но знание вёрстки этим не исчерпывается. Точно так же можно научиться соединять jQuery-плагины или готовые React-компоненты и получать работающие страницы. Но если всё внутри остаётся чёрным ящиком, любая задача за пределами README становится проблемой.
Олег Мохов приводил похожий пример с собеседования на JavaScript-разработчика. Кандидат знал, что контекст можно сохранить стрелочной функцией, но не понимал, как с ним работали до ES6. Новый синтаксис оказался единственным ответом на вопрос о поведении языка.
Мы сами помогаем этому случиться, когда со сцены перечисляем только достоинства инструмента. Меньше кода, быстрее разработка. Получается тот самый Hype.js: всё прекрасно, а с ограничениями человек познакомится потом, за свой счёт.
Мне кажется, выступая перед другими разработчиками, мы обязаны говорить и о недостатках. Объяснять, для каких задач инструмент подходит и где окажется лишним. Не высмеивать человека за LESS или PHP, не превращать собственный выбор в обязательное условие входа в профессию.
Опыт должен помогать нам быть менее категоричными. Особенно когда нас слушают люди, которым пока трудно возразить.
Доделать продукт
У меня были и собственные фреймворки. Это тоже не избавило от всех проблем: их нужно поддерживать, а мир за это время продолжает меняться. Именно поэтому мы часто выбираем чужую библиотеку. Кто-то уже тратит время на её развитие, и нам не приходится делать всю эту работу самим.
Считать стоит своё время, а не только возраст инструмента. Если знакомое решение продолжает помогать, можно работать дальше. Если ради него приходится всё чаще отвлекаться от продукта, есть повод искать другое. А если на отдых не остаётся сил, это тоже часть результата технического решения.
С доведением работы до конца сложнее. После интересного прототипа неизбежно остаётся рутина. Один мой коллега старается находить в таких задачах что-то новое: разобраться с алгоритмом, попробовать незнакомый приём. Не обязательно ради этого менять весь фреймворк.
И команде иногда полезно дать немного больше свободы внутри задачи. Чтобы человек мог чему-то научиться, пока доводит её до конца, а не откладывал всю интересную работу до следующего переписывания. Мне такой подход ближе, чем бесконечный поиск инструмента, на котором наконец не останется рутины.