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

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

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

    "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 или через простые стримы с прямыми зависимостями.
  • Приятная сборка frontend проекта
    +1
    Логично, да, но npm такой же специальный пакет, только нативный :)
    Насчет стримов — смотрите, если вам нужны программные стримы, такие, как в gulp — можно пойти путем gulp, создать файл для сборки build.js, где делать все, что угодно и как угодно, не ограничиваясь плагинами gulp, которые по сути обертки над пакетами npm. В том числе вы можете использовать и стримы, и gulp, и что угодно, без каких-либо ограничений.

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

    Чем это классно? У вас нет лишнего файла gulpfile.js в проекте; вы используете декларативную нотацию тасков, что весьма читабельно; новый пользователь может узнать все возможные операции для проекта прямо из package.json, в одном месте, что удобно; наконец, вы используете нативный инструмент, который гарантированно будет существовать долго и всегда включает все возможные пакеты, в отличие от систем сборки, где их может недоставать.
  • Приятная сборка frontend проекта
    +1
    Вопрос — а почему для сборки в альтернативах вы не рассмотрели npm? Есть неплохая статья, сравнивающая gulp, grunt & npm. Я вот остановился на npm и остался просто в восторге от него.
  • О input[type=range], параметре multiple и как сделать, чтобы всё работало
    0
    А почему вы не сделали, чтобы брался ползунок, близкий к месту таппинга, вместо того, чтобы их чередовать?
  • Нетрадиционный обзор React
    +3
    Автор ничего не сказал про переносимость компонентов реакта. Могу я один и тот же компонент, однажды написанный, использовать в разных проектах? Так, чтобы без копипасты?
  • Анонс React Native
    –1
    Еще кое что.
    Вы может и не придадите сейчас значения, но представьте злую иронию, если фейсбук вдруг официально откажется от поддержки реакта? Его ценность резко упадет до странноватого опенсорсного фреймворка, ничем не лучше absurd.js или ractive.js.
    В то время как настоящие «боевые» опенсорсные модули будут живы всегда, в той или иной реинкарнации. Не важно, как называется микро-модуль: arr-flatten, array-flatten, amp-array-flatten, _.flatten или это вообще полифил Array.flatten — принципа это не меняет, это — «аксиома».
  • Анонс React Native
    –2
    Я понял. С той или иной степенью манипуляций — вы найдете причины использовать реакт, я найду причины использовать чистые инструменты без посредников. Вы найдете недостатки в нативном 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, и пр. пр., и в скором времени станет достоянием истории.
  • Анонс React Native
    0
    Классно обменялись аргументами :)
  • Анонс React Native
    –2
    Простите, но не думаю. Реакт с ES6 это делюзия и насмешки над ES6, после расчленения этого самого ES. Это ни разу ни ES уже, а какая-то фейсбук-бутафория.

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

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

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

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

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

    Есть еще западные проекты на эту тему, по мотивам Армстронга: cafe-js, но это уж совсем футуризм.
  • Yeoman для новичков
    +2
    А вы пробовали оформить шаблон в ямене?
    Это не просто сказать «вот так я делаю проект — бери это за шаблон». Это разработать целый отдельный проект.
  • Yeoman для новичков
    +7
    Странная тулза.
    А я просто дербаню куски из папки с соседним проектом — выходит довольно быстро. Ну и `npm init` там.
    А тут — сначала изучи как пользоваться яманом, потом изучи какие генераторы есть, потом изучи что генератор может нагенерировать, потом проверь рабочее ли все это, потом изучи структуру нагенерированного — подходит ли под привычный флоу.

    Так если надо автоматизировать по 5 проектов в день — может и ок. Но вообще это же одноразовая операция.
  • Проблема «7-го января»
    0
    Воу. Как-то писал в службу поддержки яндекс билетов с невозможностью выбрать 7 января в календаре. Теперь, кажется, пофиксили.
  • GitHub опять разблокировали
    +1
    Немного ставит в тупик такой момент.
    У гитхаба же есть всякие сервисы-зеркала, типа rawgit.

    Пример.
    Берем вот это «запрещенное в России» весьма увлекательное чтиво: https://raw.githubusercontent.com/stevebest/suicide/master/suicide.md — «контент не найден».
    Меняем raw.githubusercontent.com на rawgit.com или cdn.rawgit.com — и все прекрасно работает.
  • Раскол nodejs
    +1
    Милота. Давно пора. Надеюсь nodei.co тоже обновят стиль бейджев, чтобы вписываться.
  • Дайджест российских программ поддержки ИТ-стартапов #1
    –2
    Лучшая программа поддержки IT-стартапов в России — это блокировка гитхаба. Надо же когда-то отдыхать‽
    * извиняюсь за оффтоп.
  • Роскомнадзор заблокировал 7 страниц GitHub
    +1
    Беспредел.
  • Будущее [отсутствие] интерфейсов браузеров от Яндекса
    +10
    Нет. Вкладки снизу — неприятно. «Безопасная» сторона экрана пропала, ощущение, что перед носом надоедающая клякса. Особенно на гитхабе неприятно, где по центру черное пятно. Помимо этого, приходится теперь в разы значительнее «чесать» трекпад/передвигать мышь с одного конца экрана в другой, переключаясь между адресной строкой/новой вкладкой.
    Fixed шапка тоже вызывает вопрос — заголовок дублирует информацию на вкладке, зачем он нужен? Почему бы не оставить только вкладки, а адресную строку показывать при клике на вкладку — и все?
    Анимации преувеличенные и с задержками (на табах в частности) — их можно отключить?
    Блюр порой заметно затормаживает прокрутку — вызывает ощущение медленного компьютера. Как и вообще любая история с попыткой ввести что-либо в «адресную» строку — почему это все так тормозит? Код на JS написан что-ли?

    Также присутствует постоянное ощущение, что вещи случаются не там, где происходит клик/взаимодействие.

    Моя негативная капля.
  • jQueryUI timePicker — виджет для выбора времени
    0
    Самый крутой из трех. Выбор ближайшей к клику стрелки — самое естественное пользовательское взаимодействие — как бы ты и сделал с реальными часами. Анимации и смену циферблатов если убрать — вообще идеально будет.
  • Как использовать психологические принципы для увеличения конверсии
    +1
    «Arrow shape» это по-вашему «форма курсора»? Вы серьезно? Долго пытался понять, что же имеется в виду под формой курсора в вашем переводе о кейсе evernote. Плюнул и пошел читать оригинал. Оказалось, там и информации больше.
  • Марк Андрессен: почему оптимизм — всегда выигрышная стратегия
    +2
    Крутой мужик. Два очень правильных взгляда на вещи. «Что будет, если сработает?» вместо «Сработает ли?» и про сохранение рабочих мест в силу неограниченных потребностей.
  • Разбор Underscore
    0
    es5-shim это из серии underscore — полифилл всего, но уже концептуально лучше. Самым рациональным решением выглядит использование сервиса полифиллов и/или autopolyfiller.

    А про изменения — наверное, это дело вкуса. Мне комфортнее либо рассчитывать на железобетонность стандартов, либо иметь возможность влиять на инструмент. В случае же, когда на инструмент влияет кто-то посередине, при этом не дает другим так просто этот инструмент настраивать под свои нужды — я предпочитаю использовать нативные средства напрямую. Потребность в котроле, видимо. Но тут я могу находиться в иллюзии насчет неизменности и неконтролруемости стандартов (возможности моего участия в этом).
  • Разбор Underscore
    0
    5Кб сжатые (15Кб минифицированные) для некоторых модулей это очень много. Некоторые компоненты суммарно весят в разы меньше. Представьте, если component/events был бы на underscore? А ведь предпосылки есть.

    О forEach я хотел сказать очевидное — библиотеки нужны, если они предоставляют что-то большее, чем существующие инструменты. В случае с underscore — API в пределе отражает 1:1 стандартное поведение. А зачем мне 1:1 стандартное поведение, если это задача полифиллов? Казалось бы, underscore может предложить что-то больше, как, к примеру, `$.each`, который, не гнушается вызывать `break` по `return false`. Но нет. Если я попробую написать реквест или сделать PR на эту тему — мне откажут, так как API устоялось и меняться не будет, в т. ч. в силу большого комьюнити. В итоге мне надо писать свой велосипед.

    Это второе затруднение «божественных» библиотек — большое комьюнити блокирует развитие и замедляет изменения и принятие PR. es6-collections, к примеру, был пофикшен и переписан польностью из-за нескольких реквестов всего за пару дней. С underscore вообще какие-либо изменения едва возможны.
  • Разбор Underscore
    0
    Не спорю, underscore — хороший тулкит, целый ящик с инструментами для разработки приложений. Подключил и пользуешься. Тут все — и типы, и списки, и объекты, и горка кокаина.
    Возможно, для разработки больших приложений это и сэкономит несколько минут на упрощении логики и читабельности.
    Но ставить весь код на такую жирную зависимость страшно. А что если не все знают underscore? А что если я часть кода захочу реиспользовать — таскать этого толстяка везде? А что если underscore сломается в IE9 или мне потребуется несколько кастомное его поведение? К примеру, `.each`, как выяснилось, не может прерваться в середине цикла (обсуждение на stackoverflow) — таких затруднений возникает множество.
    В нативном JS таких беспокойств нет — лишь беспокойства о наличии полифиллов, которые весьма и весьма низки, благодаря сервису полифиллов.
  • Разбор Underscore
    0
    Не знаю. Можно прогнать test.js по разным браузерам, если сильно нужно. Попробовать XHR-polyfill. Как правило, помогает. Ничего смертельного для IE они в коде не использовали, навскидку.
  • Comment from a drafted post.
  • Разбор Underscore
    0
    <joke mode="Petrosyan">А зачем вам полифиллить утилиту загрузки хрома под виндой?</joke>
  • Разбор Underscore
    +1
    В Lodash все распилено по модулям, не нужен целый lodash — используйте отдельный модуль с lodash- префиксом.
  • Разбор Underscore
    +3
    Underscore, как и jQuery — это конъюнктурные библиотеки. Когда они возникли, не существовало развитого JS, как и модульности; надежы на развитие языка не было. Сейчас 60% их функционала присутствует в нативных средствах и покрываются полифиллами, для других 40% есть отдельные, качественные решения.
    Не нужно грузить jQuery если вам нужен ajax (fetch polyfill), css или селекторы.
  • Разбор Underscore
    0
    А следование SoC и использование CommonJS-модулей, ответственных за отдельные задачи — чем вам не пример хорошего дизайна?

    Кстати если конкретно об underscore говорить, то давно уже лучше использовать полифиллы для массивов/объектов на стандартные методы (map, forEach, ...), чем библиотеку «всего».
  • Duo.js — новое поколение пакетного менеджера для фронтэнда
    0
    Судя по скомпиленному результату — нет. Надо модуль отдельно указывать в component.json, чтобы он тянулся [откуда угодно].