В то время как browserify замкнут на npm (хотя это вообще-то пока что самый некостыльный и стандартный способ реализации зависимостей в js), duo вообще игнорит npm. Не понимаю зачем. Уж могли бы сделать его npm-compliant, типа, без указания автора зависимость тянется из npm или по указанию из package.json. Можно было бы безболезненно использовать duo для замены npm, типа мне удобнее забыть о `package.json`, но менять привычку писать обычный node-код я не собираюсь. Можно было бы просто взять и весь текущий код использовать через duo. А так получается, что компонент для duo и компонент для npm это разные вещи. Доверие снижается.
Плюс ребята таргетятся на префиксирование неймспейсов компонентов через указание авторства, но по факту это задачу усложняет, а не решает: большинство имен пользователей на гитхабе набраны в соответствии с локалью, к примеру, вписывать французские или японские ники авторов оказывается большей болью, чем вписывать «хипстерские» названия модулей. Ну и что, что есть tooltip, component-tooltip, micro-tip, tippy, tip, tipster и еще десяток тултипов — это понятнее и лучше, чем aufbersht/tooltip, component/tooltip, jamesc/tooltip, obie/tooltip, elian/tooltip… которые идентифицируются не языковой игрой и впечатлением, а смутным локальным именем автора, которое вообще ни о чем не говорит.
Помимо этого всего, пока ты пишешь стандартный компонент, ты хочешь использовать максимально стандартные и универсальные средства. Если я буду писать компонент для duo, я автоматически срезаю аудиторию не-duo пользователей. Это невероятно глупо. Если же я пишу кастомное приложение и мне нужен удобный инструмент — ума не приложу, почему именно duo — ведь странно не иметь у большого приложения всякие инструменты настройки/сборки.
Таким образом, duo встает на одну ступень с component, за исключением того, что у второго надо сгенерить файл component.json
Скажите своему верстальщику, чтобы вместо шрифта 'Segoe UI' он использовал хотя-бы 'Segoe UI, Helvetica, sans-serif'. Многие ваши работы смотрятся весьма печально на маках и линуксах со сбитыми шрифтами.
Ну под аргументы есть тоже много инструментов: nomnom, yargs, minimist. Они тоже очень удобны и стандартны, в отличие от gulp (с gulp не перейдешь так просто на grunt, или, там, brunch, mimosa итп).
Использование жестко одной системы сборки для всего (как одного фреймворка, UI-библиотеки, и т. п.) противоречит анархичному духу ноды, крупные фреймворки и проекты имеют тенденцию разваливаться. Как минимум, рассчитывать при разработке своего проекта на какой-то один «божественный» фреймворк это недальновидно, как класть все яйца в одну корзину. Штуки, пытающиеся вобрать в себя всё вызывают недоверие. Нужный набор атомарных взаимозаменяемых плагинов, соответствующих концепции разделения ответственности в долгой перспективе выигрывает.
Извиняюсь, поспешил :) Привык работать в концепции browserify с модульными зависимостями как в node, забыл, что не все в курсе могут быть.
Да, lifecycle-events не такой гибкий, конечно. Но для простой задачи забить гвоздь это отличный молоток :)
1. Инкрементальная компиляция — дело компилятора, а не инструмента сборки. Надо смотреть что вы компилируете. Некоторые штуки, типа typescript компилят только изменившиеся файлы. А вот у LESS инкрементальной компиляции нет — каждый раз перекомпилируется вся структура.
2. Можно. У многих инструментов есть свой вотчер, как у browserify — watchify. Но есть и более общие тулзы, типа watch, где можно задать свои действия в колбеке на изменения в директории.
Удобно в теории. На практике с первым багом обертки gulp с невнятным error message понимаешь, что приходится лезть в код модуля, лежащего в основе плагина gulp и писать репорт автору gulp-плагина на гитхаб, который в 50% случаев будет проигнорен, в 50% — пофикшен через 2-3 недели. После n-кратного натыкания на эту ситуацию, понимаешь, что почему-бы просто не сделать build.js, использующий те же нативные модули с внятными ошибками, понятным и хорошо задокументированным API, и если хочется — на тех же стримах (пайпах из gulp, только стандартных).
Этот подход более эффективен в силу того, что авторы конечных модулей, как правило, очень заинтересованы в их успешности и занимаются их поддержкой, в то время как авторы оберток для gulp в целом относятся к ним холодно. Более того, у конечных модулей, возьмем, к примеру, компилятор из ES6 в ES5, как правило, есть множество конкурентов, и если один модуль проваливается, можно просто переключиться на другой. В случае, если использовать обертки gulp, ты автоматически привязан к конкретному модулю.
Но build.js, как правило, также является сложной альтернативой, хотя и уже в разы более гибкой.
Большинство задач, будь то компиляция статики для django или создание нового контроллера для angular легко решается через скрипты npm, запускаясь не `gulp collectstatic`, а `npm run collectstatic`, где в package.json что-то вроде
Но в целом, конечно, дело вкуса. Если большой проект уже на gulp, то перевести его на чистый npm требует усилий. У меня это заняло несколько часов, но результат и сэкономленные поныне нервы стоили того.
Если кому интересно, есть стандартный способ детекции элемента во вьюпорте, реализованный в т. ч. Polymer: это lifecycle события enteredViewport и leftViewport.
Они полноценно реализованы в polymer, или полифиле lifecycle-events.
Lifecycle-events также генерит события attached, detached, сигнализирующие о том, был элемент вставлен или изъят из DOM.
Зачем все эти сложности, если можно все делать npm-ом на системных пайпах? Gulp плагины это всегда обертки, и они либо сквозят багами, либо нет недостающих фич, либо нужных оберток просто нет, в то время как для npm есть вообще все, что может быть для сборки js. К тому-же настроить сборку на npm в разы быстрее и проще, чем через gulp. А главное, npm — стандартный способ, в то время как gulp — костыли.
А кто-нибудь знает как на гитхабе предоставить «общественный» доступ к репозиторию? По типу вики, только чтобы у проекта не было владельца. Т. е. ведь владелец репозитория может, грубо говоря, умереть, тогда никто не сможет этот реп редактировать.
Интересно, а умышленные замедления в интерфейсе с целью применения эффекта жалости к потраченному времени (описанному в этой статье) — можно отнести к плацебо? Так часто делали раньше на всяких сайтах с «психологическими» тестами, где в самом конце спрашивался номер телефона для оплаты результата по смс.
Пользователю жалко потраченного времени — вот он уже и не может отказаться.
Именно. Модель component.io, где компоненты — просто npm-модули, выглядит гораздо привлекательнее. А уже как эти модули обернуты — будь то в веб-компонент, standalone, jquery-плагин, browserify или другой сборщик — это отдельный вопрос, — вопрос потребителя.
Поэтому разработка компонента сразу в целевую систему — странное занятие. Это все приводит к тому, что в мире js есть море дубликатов одного и того же.
По совету 8. Я бы вам посоветовал для этих целей посмотреть на стримы — весь прогрессивный мир их уже давно использует. Порой это даже более удобная высокоуровневая замена промисам.
А какой основной способ отловки утечек? Timeline? Это же долго — ждать два-три срабатывания сборщика, сравнивать остаток, а потом строить гипотезы об утечках. Record heap allocations?
Для начала возьмем less-hat (1000 строк). Потом декларацию переменных и декораторов (1500 строк). Потом декларацию шрифтов, иконок. Рисователь png в base64 (еще 1000 строк). Базовая разметка, сетка. Возможно еще что всплывет, уже не помню. Это все — минимальный остаток, после ревизий, рефакторингов и сжатий, самое необходимое (ведь можно было бы использовать фреймворк). Это все — накладные расходы, т. е. зависимости, которые придется подключать всегда, к каждому отдельно компилируемому входному куску less. Уже такая конструкция сама по себе компилится секунд 10-12 на less 1.7. На 1.3 — сносно, в районе 5-7 секунд.
Насчет размера выходного файла в less — он может быть даже нулевым, но компиляция будет долгой, — дело не только в рендеринге, но и парсинге. lesshat, к примеру, вообще не генерит css, как и всяческие декораторы.
Хотя выходной css на проекте действительно довольно большой — 50Кб после сжатия.
Насчет примечания 2 о том, что нет ни одной причины не использовать последний less — вы заблуждаетесь. LESS 1.7 компилирует примерно в два раза медленнее версии 1.3, при этом не добавляя серьезных удобств и возможностей. На текущем проекте имеется около 15000 строчек less, что приводило к 30-40 секундной компиляции на каждое изменение в стилях, и это на достаточно быстрой машине (последний iMac). Рефакторинг не особенно помогал в этой ситуации, но даунгрейд LESS до версии 1.3 позволил сократить это время до 15-20 секунд, причем как показала практика, обойтись без новых возможностей LESS можно вообще без проблем.
Лучше бы ребята инкрементальную компиляцию имплементировали и занялись серьезно вопросом оптимизации, нежели напичкиванием функционала.
Плюс ребята таргетятся на префиксирование неймспейсов компонентов через указание авторства, но по факту это задачу усложняет, а не решает: большинство имен пользователей на гитхабе набраны в соответствии с локалью, к примеру, вписывать французские или японские ники авторов оказывается большей болью, чем вписывать «хипстерские» названия модулей. Ну и что, что есть tooltip, component-tooltip, micro-tip, tippy, tip, tipster и еще десяток тултипов — это понятнее и лучше, чем aufbersht/tooltip, component/tooltip, jamesc/tooltip, obie/tooltip, elian/tooltip… которые идентифицируются не языковой игрой и впечатлением, а смутным локальным именем автора, которое вообще ни о чем не говорит.
Помимо этого всего, пока ты пишешь стандартный компонент, ты хочешь использовать максимально стандартные и универсальные средства. Если я буду писать компонент для duo, я автоматически срезаю аудиторию не-duo пользователей. Это невероятно глупо. Если же я пишу кастомное приложение и мне нужен удобный инструмент — ума не приложу, почему именно duo — ведь странно не иметь у большого приложения всякие инструменты настройки/сборки.
Таким образом, duo встает на одну ступень с component, за исключением того, что у второго надо сгенерить файл component.json
Использование жестко одной системы сборки для всего (как одного фреймворка, UI-библиотеки, и т. п.) противоречит анархичному духу ноды, крупные фреймворки и проекты имеют тенденцию разваливаться. Как минимум, рассчитывать при разработке своего проекта на какой-то один «божественный» фреймворк это недальновидно, как класть все яйца в одну корзину. Штуки, пытающиеся вобрать в себя всё вызывают недоверие. Нужный набор атомарных взаимозаменяемых плагинов, соответствующих концепции разделения ответственности в долгой перспективе выигрывает.
Да, lifecycle-events не такой гибкий, конечно. Но для простой задачи забить гвоздь это отличный молоток :)
2. Можно. У многих инструментов есть свой вотчер, как у browserify — watchify. Но есть и более общие тулзы, типа watch, где можно задать свои действия в колбеке на изменения в директории.
3. Можно. gulp-webserver, grunt-connect, а также специфичные для проектов: browserify-server,…
Этот подход более эффективен в силу того, что авторы конечных модулей, как правило, очень заинтересованы в их успешности и занимаются их поддержкой, в то время как авторы оберток для gulp в целом относятся к ним холодно. Более того, у конечных модулей, возьмем, к примеру, компилятор из ES6 в ES5, как правило, есть множество конкурентов, и если один модуль проваливается, можно просто переключиться на другой. В случае, если использовать обертки gulp, ты автоматически привязан к конкретному модулю.
Но build.js, как правило, также является сложной альтернативой, хотя и уже в разы более гибкой.
Большинство задач, будь то компиляция статики для django или создание нового контроллера для angular легко решается через скрипты npm, запускаясь не `gulp collectstatic`, а `npm run collectstatic`, где в package.json что-то вроде
Но в целом, конечно, дело вкуса. Если большой проект уже на gulp, то перевести его на чистый npm требует усилий. У меня это заняло несколько часов, но результат и сэкономленные поныне нервы стоили того.
Они полноценно реализованы в polymer, или полифиле lifecycle-events.
Lifecycle-events также генерит события attached, detached, сигнализирующие о том, был элемент вставлен или изъят из DOM.
Отличная статья в тему.
Пользователю жалко потраченного времени — вот он уже и не может отказаться.
Поэтому разработка компонента сразу в целевую систему — странное занятие. Это все приводит к тому, что в мире js есть море дубликатов одного и того же.
Насчет размера выходного файла в less — он может быть даже нулевым, но компиляция будет долгой, — дело не только в рендеринге, но и парсинге. lesshat, к примеру, вообще не генерит css, как и всяческие декораторы.
Хотя выходной css на проекте действительно довольно большой — 50Кб после сжатия.
Лучше бы ребята инкрементальную компиляцию имплементировали и занялись серьезно вопросом оптимизации, нежели напичкиванием функционала.