Что я узнал, когда писал свою первую книгу о продвинутом JavaScript
Я только что закончил писать свою первую книгу (ура!). Это была одна из совершенно безумных идей, родившихся в голове не очень известного веб-разработчика. Это прозвучит еще более безумно, если я скажу вам, что было причиной этого веселого занятия: желание создать свой собственный клон jQuery, BEMQuery. Книга выйдет в июле издательством Гелион (извините, только на польском языке!), но я уже многому научился и хочу поделиться этими новыми знаниями с вами.
Не так-то просто изобрести велосипед
Я имею в виду: посмотрите на jQuery. В нем есть абсолютно все. Анимация, Ajax, манипулирование DOM… Вы просто подключаете его к своему веб-сайту, и все готово. Более того, вся библиотека создана вокруг идеи механизма селекторов CSS (Sizzle в случае jQuery). Передо мной стояла очень сложная задача: создать что-то такое же простое, как jQuery, и (в то же время) лучшее в некоторых аспектах.
Изучив код jQuery, я обнаружил его слабое место: модульность! Да, я знаю, что есть способ создать подмножество jQuery, но это все еще не та модульность, которую мы хотим сегодня, в эпоху ES6+. Вот почему я решил разделить свою библиотеку на небольшие модули, которые можно было бы использовать совершенно независимо друг от друга (совершенно не вдохновленные дизайном CKEditor 5). Поскольку я использовал модули ES6, мне также пришлось писать весь код, используя новую и блестящую версию JS.
Второе большое изменение — это (конечно) двигатель селектора. Я использую не CSS-селекторы, а БЭМ — новый формат, который я изобрел. Краткий пример: block element:modifier эквивалентен .block__element_modifier в CSS. Простая идея, но мне нравится.
Я заново изобрел колесо? Наверное, да, но мое колесо круглее.
Писать книги в LibreOffice — это кошмар
Не потому, что LibreOffice просто «хуже MS Word». Нет. Есть много других проблем, например несовместимость между разными версиями LibreOffice и открытая враждебность между MS Word и LibreOffice Writer. Попытка создать документ, который будет работать в этих двух средах редактирования, — это прямой путь в вонючую яму, полную проклятых посреди ада.
В следующий раз я собираюсь использовать HTML. Или уценка. Или даже Латекс. Но никогда не LibreOffice. Совершенно не стоит нервов.
Вы можете написать книгу за 5 дней (хорошо, 90% из них) вместе с созданием кода, который вы в ней описываете.
Да, МОЖНО одновременно написать 260 страниц и создать сопутствующий код. Однако некоторые из результатов включают в себя получение библиотеки с удивительным количеством 10 методов и засыпание в самые неподходящие моменты и места в течение следующих 3 недель.
Я также узнал, что попытка описать некоторые очень простые концепции, такие как модули или обещания, может занять много страниц и много часов. Просто потому, что для описания модулей нужны все рассуждения о том, почему монолитные коды (типа jQuery) хуже модульных (типа BEMQuery), почему мы должны использовать модули ES6, а затем транспилировать их в формат UMD и т. д.
Так что, если 260 страниц для описания всего 10 методов и звучат очень смешно, то при написании было не так уж и смешно. Это была просто тяжелая работа.
Генераторы хороши, но…
Генераторы — это здорово, это само собой разумеется. Но… попробуй объяснить их в книге — особенно когда они будут использоваться только в одном сверхпростом случае!
Объяснить итераторы, созданные с использованием простых объектов, по-прежнему гораздо проще, чем использовать «эти причудливые новые генераторы».
Для ES6 нет минификатора
Да ничего толкового (кроме какого-то эксперимента). Даже Uglify.js имеет большие проблемы с ES6, а Google Closure Compile может минимизировать ES6 только после транспиляции в ES5.
Вот почему мне пришлось отказаться от написания целой главы об оптимизации доставки кода JS в браузеры.
Node.js выпускается слишком часто
Когда я начал писать книгу, последней версией Node.js была 4.4. Когда я закончил, Node.js 6.2 вышел. Ой.
Конечно, мне пришлось переписать целую главу о поддержке ES6 в Node.js!
Это не смешно, разработчики Node.js!
пакеты npm ‹/3
Мы все хорошо знаем усталость от JavaScript, и это не просто модное словечко — это реальная вещь. Лучший пример? Мой шаблон BEMQuery состоит из 30 модулей, отвечающих за самое основное. 15 из них используются для создания сверхпростых тестов. 8 из них используются для того, чтобы просто связать BEMQuery в один файл в формате UMD.
Не поймите меня неправильно: гипермодуляризация — вещь очень хорошая, но в то же время это просто головная боль. Я решил использовать карму для запуска своих тестов и именно из-за этого был вынужден включать плагины даже для запуска тестов в определенных браузерах. Да, инструмент, созданный для запуска тестов в браузерах, использует плагин для… запуска тестов в браузерах. То же самое с rollup.js, сверхпростым упаковщиком: плагины для всего. Это не неправильно, это просто утомительно.
Проблема в самих модулях? Не совсем. Это скорее проблема с идеей того, как эти модули должны использоваться внутри JS-приложений. Случай с левой панелью показал, что гипермодуляризация работает, когда сообщество ведет себя ответственно. У меня такое ощущение, что мы слишком много пытаемся модульизировать. В то же время у меня также есть ощущение, что некоторые вещи могут быть более модульными. Я считаю, что где-то пролегает тонкая граница разумной модуляризации. Надеюсь, что мы его еще не пересекли.
Кстати, я упоминал, что установка этих 30 модулей дает около 500 зависимостей?
нпм версия ‹3
Я понятия не имел, что в npm есть такая замечательная функция только для того, чтобы упростить публикацию новых semver-совместимых версий наших пакетов. Все, что вам нужно сделать, это ввести npm version major/minor/patch внутри консоли и нажать Enter. Затем npm поднимет версию вашего пакета внутри файла package.json и подготовит для него теги Git. ЧИСТОЕ ВЕЛИКОЛЕПИЕ!
npm-скрипты › хрюкать/глотать?
Я также экспериментировал с отказом от Grunt/gulp в пользу старых простых скриптов npm. Это работает, но это может быть очень утомительно, и через некоторое время загрязнение в нашем файле package.json может быть намного больше, чем мы ожидали.
Для небольших проектов (ну, BEMQuery — это небольшой проектпока) сценарии npm лучше, чем Grunt/gulp (без шаблонов, без зависимых от инструментов плагинов и т. д.), но для более крупных проектов их сверхпростота может быть большой проблемой (нам просто нужен какой-то шаблон в таком большом коде!).
Страницы GH = документация
В моем проекте есть еще один эксперимент: документация публикуется как GitHub Pages и генерируется суперпростым скриптом npm.
Документация создана и опубликована одной простой командой? Может быть, это не удивительно, но я надеюсь, что оно хорошо служит своей цели.
Есть сочетание клавиш Alt+PrtSc
Если вы такой же зануда, как и я, вы, вероятно, не заметили, что вам не нужно использовать Gimp, чтобы отрезать единственное интересующее вас окно от экрана печати рабочего стола ваших мониторов Ultra HD 3. Вы можете просто использовать Alt+PrtSc!
Да, я знаю…
Это все, что я узнал, когда писал свою книгу. Надеюсь, эти советы будут вам полезны!