Pull to refresh
45
0
Dmitry Yv @Dmitry_f

webgl / frontend

Send message
npm install closurecompiler я один додумался и всегда делаю?
Превосходное API, как CLI, так и программно, поддержка пайпов, сорсмапов, хотя последнее никогда не требовалось. Компилится незначитьно дольше углифая.
Но в целом да, uglify2 проще.
Кстати, насчет дублирования. Есть так называемое правило третьего, где рекомендуется фолдить клоны именно на третьем повторении. Почему не на втором — потому что два похожих куска еще не обязательно клоны, есть риск сфолдить преждевременно, потратив время впустую.

В вашем случае, для того, чтобы изменить девелоперский пайплайн — надо глазами пройтись по всему обобщенному пайплайну, на каждом условии вычислять, к dev или к production оно относится. А если появятся переменная ci?

Я к тому, что у вас скорее не про дублирование, а про разделение ответственности.
* globs, а не globules
Проще простого:

"scripts": {
  "build": "node build.js",
  "watch": "watch 'npm run build' ./src/**/*"
}


Хаха! :)

А если серьезно — вы правы, c globules это не так просто сделать, особенно на windows (я пытался, не получилось, на windows много ограничений в shell — нет xargs, нет подстановки комманд, нет globules, нет find *.less -exec cat {} и тд и тп). В то же время на виндах и в gulp с globules не все гладко.

Если же вам известны точки входа less, то все гораздо проще:

"scripts": {
  "build-dev": "npm run lessc-dev && npm run build-js && cat public/css/*.css | gzip-size | pretty-bytes",
  "lessc-dev": "lessc src/less/main.less --source-map | autoprefixer > public/css/main.css",
  "lessc-production": "lessc src/less/main.less | autoprefixer | csso > public/css/main.css ",
  "build-js": "browserify src/js/index.js | ccjs - > public/js/index.js",
  "watch": "watch 'npm run lessc-dev' less/*.less"

  ...
}


В принципе, в небольших проектах точки входа всегда известны. Если же проект гигантский, то тут уж ничего не поделаешь — надо писать скрипт сборки. Но это уже дело предпочтения — писать сборку через gulp или через простые стримы с прямыми зависимостями.
Логично, да, но npm такой же специальный пакет, только нативный :)
Насчет стримов — смотрите, если вам нужны программные стримы, такие, как в gulp — можно пойти путем gulp, создать файл для сборки build.js, где делать все, что угодно и как угодно, не ограничиваясь плагинами gulp, которые по сути обертки над пакетами npm. В том числе вы можете использовать и стримы, и gulp, и что угодно, без каких-либо ограничений.

Но на самом деле это все достаточно сложно для повседневных задач, и практически всегда можно обойтись тасками в "scripts" с нативными пайпами вместо стримов.

Чем это классно? У вас нет лишнего файла gulpfile.js в проекте; вы используете декларативную нотацию тасков, что весьма читабельно; новый пользователь может узнать все возможные операции для проекта прямо из package.json, в одном месте, что удобно; наконец, вы используете нативный инструмент, который гарантированно будет существовать долго и всегда включает все возможные пакеты, в отличие от систем сборки, где их может недоставать.
Вопрос — а почему для сборки в альтернативах вы не рассмотрели npm? Есть неплохая статья, сравнивающая gulp, grunt & npm. Я вот остановился на npm и остался просто в восторге от него.
А почему вы не сделали, чтобы брался ползунок, близкий к месту таппинга, вместо того, чтобы их чередовать?
Автор ничего не сказал про переносимость компонентов реакта. Могу я один и тот же компонент, однажды написанный, использовать в разных проектах? Так, чтобы без копипасты?
Еще кое что.
Вы может и не придадите сейчас значения, но представьте злую иронию, если фейсбук вдруг официально откажется от поддержки реакта? Его ценность резко упадет до странноватого опенсорсного фреймворка, ничем не лучше absurd.js или ractive.js.
В то время как настоящие «боевые» опенсорсные модули будут живы всегда, в той или иной реинкарнации. Не важно, как называется микро-модуль: arr-flatten, array-flatten, amp-array-flatten, _.flatten или это вообще полифил Array.flatten — принципа это не меняет, это — «аксиома».
Я понял. С той или иной степенью манипуляций — вы найдете причины использовать реакт, я найду причины использовать чистые инструменты без посредников. Вы найдете недостатки в нативном js, я найду недостатки в реакте. Мы не найдем консенсус, дискуссия бессмысленна.

Однако я не могу не ответить и оставить неравнодушных с неправильным впечатлением.

Именно вашу реакцию я имел в виду под делюзией — последователи начинают проявлять проективную идентификацию, пытаясь оправдать свое решение и увидеть реакт как «союзник» ES6 там, где на самом деле есть лишь пиар технологии.

С целью интереса (с предубеждением я собираю причины не использовать модные фреймворки), распишу, как react не соответствует FIRST.

Вы, к сожалению, несколько неверно интерпретировали весьма полезные принципы в попытке защитить реакт.
Основной посыл Эдди в том, что сложные компоненты/приложения могут быть единственно надежно построены из атомарных, простых, изолированных и хорошо отлаженных модулей, решающих одну задачу и крайне эффективно. Это все приводит к принципам FIRST, из которых следует взаимозаменяемость компонентов. К этому и сам приходишь через несколько лет разработки компонентов.
Всю концепцию FIRST следует рассматривать в контексте потребителя third-party компонентов.

1. Not Focused
Если бы реакт был действительно фокусирован только на эффективном рендеринге (как вы утверждаете), то это был бы шаблонизатор, который можно использовать точечно как зависимость import render from 'React' (как это делает любой порядочный шаблонизатор), и который можно легко заменить. В данном случае реакт — это цементированный фундамент для построения компонентов только на нем. Почему он не focused? Потому что не разделяет ответственность (SoC), решает целый список задач: создание классов (до ES6 ненативно), шаблонизация, менеджинг состояний, диспетчер событий и пр. аддоны. Focused бы значило, что под каждую задачу есть свой инструмент, а такие инструменты есть.

2. Not Independent
Независимость у компонентов значит, что можно использовать равнозначные компоненты не тревожась, что выкинув что-то одно не сломается другое. К примеру, tooltip не зависит от dropdown, ajax не зависит от dom-traversal. Если выкинуть один — второй будет работать без проблем. В случае с реактом — да, компоненты реакта могут быть организованны независимо друг от друга. Но они все зависят от реакта. Сам по себе реакт и все построенное на нем становится одной жирной зависимостью, которую либо удаляешь полностью со всеми его компонентами, либо не трогаешь, что делает бессмысленным понятие «независимости виджетов реакта». Вы будете использовать реакт с зоопарком виджетов бок о бок с jquery-плагинами/веб-компонентами/простыми компонентами, когда можно было бы этого не делать.

3. Not Reusable
Это значит, что однажды написав компонент (dialog, к примеру), я могу его использовать в каких угодно других проектах. С npm-модулями это работает. С реакт — нет. React is per-project, project-wide. Я не могу заинклудить виджет реакта из соседнего проекта, только скопипастить. В npm/component я всего лишь делаю
npm install component-dialog
. И всё.

4. Not Small
Реакт в базовом минифицированном/зажатом виде — это 36Кб кода + код виджетов. Если учитывать, что размер компонента, такого, как, к примеру, tooltip, составляет всего 7Кб (в среднем — меньше), а средние приложения на чистых компонентах едва достигают 30Кб (что меньше jquery и близко вообще к теоретическому минимуму), то реакт — это большая зависимость, к которой по безалаберности может прибавиться jQuery и бог знает что еще, что в итоге приведет к раздутому JS.

5. Not Testable
То, что вы назвали, не имеет отношения к тестам, это — отладка. Тесты — когда я могу взять компонент, написать для него тест с десятоком манипуляций и описанием нужного поведения и запускать тест каждый раз, когда я изменил код компонента, чтобы быть уверенным, что я ничего не сломал и не потерял старые пофикшенные баги. Все порядочные npm-модули или компоненты это умеют. Для реакта надо мутить что-то свое, так как тестовые фреймворки не понимают по умолчанию ESXML, то бишь JSX. Да и тестовую среду для реакта создавать сложнее, чем для простого модуля.

Помимо всего прочего, реакт недвусмысленно своей концепцией пытается решить то, что решают веб-компоненты (stateless, data-binding), ES6 (templating), только делает он все это весьма специфично. Это конъюнктурная технология, как и coffeescreept, как и jayQuery, и пр. пр., и в скором времени станет достоянием истории.
Классно обменялись аргументами :)
Простите, но не думаю. Реакт с ES6 это делюзия и насмешки над ES6, после расчленения этого самого ES. Это ни разу ни ES уже, а какая-то фейсбук-бутафория.

Реакт нарушает принципы FIRST (отнюдь не менее чем ангуляр).
Любой фреймворк, выглядящий как React.createClass, или в общем случае <GodObject>.<doSomething> просто в наглую тянет весь проект на себя. Это приводит к тому, что тысячи пользователей этого модуля вынуждены будут тоже использовать реакт, в то время как могли бы и не.
Помимо этого, пройдет мода, ES6 с веб-компонентами станет достаточно хорош и везде (2-3 года), а тысячи никому не нужных реакт-компонентов останутся. Новые разработчики просто не будут хотеть изучать реакт для того, чтобы поддерживать эти старые компоненты (зачем, когда можно все делать нативно?) — так, как сейчас никто не хочет изучать mootools или extjs чтобы поддерживать эти компоненты.

Реакт это очередная конъюнктура, в перспективе создаст море проблем. И чем больше разработчиков будут его использовать — тем больше эти проблемы будут.
Печалька. Реакт тащит на себя разработчиков, которые могли бы развивать веб-компоненты, npm-пакеты, es6 — в общем, светлое будущее фронтенда. А они, со своей странной технологией и пиаром…
Интересно, что уровни отношения к происходящему, приведенные в статье, отлично мапятся на уровни сознания по Хокинсу.
Не могу ничего сказать насчет фейковых скачиваний, но это пока что только догадки.
Но насчет настоящих — к примеру, есть твит-бот npm_tweets, который постит твиты с последними обновленными пакетами в npm. На него подписано определенное число людей (немного). Так что каждый ваш npm publish репостится им в твиттер, что обеспечивает некоторый пиар.
Уверен, есть еще подобные штуки.

Как показывает мой опыт, любой мало-мальски полезный package набирает определенное изначальное число скачиваний, и как правило, это каким-то образом пропорционально «серьезности» или «полезности» пакета. Я сомневаюсь, что это делается автоматически или по ошибке. Скорее похоже на обычный трафик.
В теории, если бы в closurecompiler-подобный минификатор был встроен не только детектор мертвого кода, но и детектор функциональных клонов (что весьма несложно ему со своей системой нормализации кода), то решить проблему наличия [неспецифично-]конкурентных модулей в сборках можно было бы достаточно эффективно.
Ну скачиваний много )
Используем npm + browserify для сборки фронтенда. Идет как по маслу, лучше и не представить.
Не очень ясно про число строк — если используются внешние компоненты или модули — смысл их считать? Сборка может получиться толстая, но управляющего кода весьма немного — ~1k строк на весь сайт.
Да, реально проблема.
Особенно при выборе нового пакета. К примеру, is object. Что взять: underscore/lodash, jquery, amp, is-object/isobject, mutype, ...? Миллионы их. И так по каждой мини-задаче. Есть некоторые штуки, упрощающие поиск нужного пакета или показывающие best practice, типа sister для эмиттеров, но это исключения.

В итоге при сборке разные модули используют свои is-object, бандл получается раздутый.

Начал собирать информацию на тему попыток как-то обуздать энтропию npm. Пока что пришел к списку аналогичных пакетов package-analogs, подбираемых вручную. Автоматизировать оценку схожести пакетов можно, по-видимому, каким-нибудь кросс-тестингом и системой поиска функциональных клонов.

Есть еще западные проекты на эту тему, по мотивам Армстронга: cafe-js, но это уж совсем футуризм.
А вы пробовали оформить шаблон в ямене?
Это не просто сказать «вот так я делаю проект — бери это за шаблон». Это разработать целый отдельный проект.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity