Как утверждают сами авторы[2] новой системы, основной причиной является возможность запуска js кода на различных платформах: в браузере, на сервере или телефоне — то есть сейчас вы можете написать свой код на js один раз и запустить его в любом месте, но с этим могут возникнуть некоторые проблемы.
Всё равно непонятно, как из этого вытекает необходимость своей системы пакетов. Всего того же самого можно добиться на базе существующей системы. Содержимое npm и bower может быть совершенно различным. Так что их можно использовать как транспорт, при этом не нужно всё это заново писать:
Добавление, обновление и удаление пакетов, используемых в проекте, из командной строки;
Вывод списка установленных пакетов;
Кеширование пакетов — нет необходимости каждый раз загружать одинаковые пакеты для различных проектов;
Поиск пакетов по удаленному хранилищу, также поиск может осуществляться по закешированным пакетам;
Версионирование согласно спецификации Semantic Versioning и управление версиями пакетов;
Я думаю лучший вариант для тех, кто хочет сейчас запилить себе пакетную систему, это использовать npm в качестве менеджера пакетов, и использовать его без registry, вместо него использовать GitHub, как это сделали в bower (впрочем, registry тоже можно).
При этом к таким пакетам нужно предъявить некоторые дополнительные требования (интерфейс), которые и будут делать их конкретным пакетом конкретной местячковой системы. Т.е., пакет будет одновременно пакетом npm и более конкретным пакетом (например пакетом метеора), потому что в нём будет какое-то специфичное содержимое. Пакетам можно добавить какой-нибудь специальный тег, например <имя вашей пакетной системы здесь>-package и так их можно будет выделить в отдельную группу пакетов npm.
Просто даты такая сумрачная материя, что только кристально чистые адепты могут не натворить в ней делов.
А поскольку таких нет, и все мы люди и иногда ошибаемся, то и получается такой результат.
На эту тему есть отличный сборник заблуждений: habrahabr.ru/post/146109/
Если ничего не менять, то после node test_requester.js нужно нажать Enter один раз, чтобы запустить запросы.
Сервер запускается как node test_httpserver.js.
Для этих целей в package.json зарезервирован блок scripts.
Для второго можно использовать npm start, указав start-команду. А первое похоже на тест, поэтому для него вполне можно применить npm test. Указывается test-команда. npm scripts
Больше спасибо за статью. Уже когда-то натыкался на сниппет, по созданию большого webview на весь экран с помощью PyGTK и даже где-то его сохранил, но ваш пример информативнее. Меня не покидает желание забабахать дестктопный виджет с кучей свистелок и метрик, в духе тех, что частенько проскакивают на лоре.
Что касается нескольких файлов, то тут я согласен. И чем больше файлов, тем сильнее преимущество AMD. Лучший кейс для AMD это WebView мобильного девайса.
Что касается разработки, то browserify умеет делить кусок на бандлы. А ещё есть кеширующие сборщики.
Я не говорю об использовании функции require напрямую. На клиенте CommonJS требует сборки. Но так как AMD тоже, вообще говоря, лучше собрать, чтобы уменьшить количество файлов, мы получаем одинаковые условия. При этом, CommonJS: менее громозкая структура файла, множество пакетов npm, возможность разделять код с сервером.
Эталонному килограмму исполнилось 3.626140006389238 × 119 периодов излучения, соответствующего переходу между двумя сверхтонкими уровнями основного состояния атома цезия-133 (в покое при 0 К при отсутствии возмущения внешними полями).
Так же как CommonJS больше подходит для вне-браузерной среды, цепочные определения модулей с их требованиями, идеально вписываются во внутри-браузерные сценарии использования.
Не согласен. CommonJS подходит для браузера, но для вебного. AMD же идеально подходит для мобильного WebView браузера, где накладные расходы на количество файлов (обращений к диску) не так велики, как выигрыш от ленивости. В вебе же — наоборот. Если AMD используется в вебе, то всё равно нужно сконкатенировать все определения и добавить в них имена, а затем использовать минимальный загрузчик, типо almond. Это уже нельзя назвать «идеалом».
Хм, знаете, я не думаю, что передача Reduced через возвращаемое значение это стейт. Это просто бокс для значения. А вот хранение результата где-то в вызывающей функции и его использовании при появлении void 0, вот это уже стейт.
Да, хочу сказать, что я лично не выступаю за вариант с обёрткой, я, скорее, придерживаюсь вашей точки зрения, что лучше использовать существующее значение (undefined), тем более оно подходит по семантике. Так что я ни в коем случае не спорю с вами, скорее пытаюсь выжать из идеи всё до конца.
Можно :) Но тогда придётся создавать и ловить конкретное исключение, чтобы не маскировать другие исключения в случае, например, каких-то ошибок в логике функции.
Кстати, в LoDash для прерывания используется return false. Оба варианта — слаботипизированные breaker/Reduced :)
Ещё можно использовать объект, ссылка на него будет уникальной, а в новом стандарте вообще есть тип Symbol.
Тут главная разница в том, что Reduced содержит не только метку, но и сам результат, который далее анбоксится. Все остальные варианты перекладывают задачу на управляющую функцию transduce. Вероятно, Ричу более нравится «чистый» подход, с хранением результата, а мы в JS привыкли к флаговым значениям.
Спасибо за статью и за ссылки. В презентации Рича очень хорошо всё рассказано.
Мне как-то приходила мысль, что после абстрагирования функции, которая передаётся в filter/map, есть какой-то ещё шаг, который заключается в абстрагировании от самого итерационного процесса. Тогда мне показалось это овер-инжинирингом и я отбросил эту идею. Сейчас же, когда filter/map появляется в таком количестве разных контекстов, становится очевидно, что это следующий разумный шаг в поднятии абстракции.
Например, как вы подметили в статье (и в презентации тоже был про это слайд), что FRP реализует свои filter/map и весь остальной зоопарк, но сущность их не меняется. Например в JS мы уже имеем приличный utility-belt в виде LoDash, как было бы славно их просто применять к FRP или к другим контекстам.
Скрытый текст
Ещё мне подумалось, что можно прокачать reduce, так, чтобы он сам скармливал трансдьюсеру верный step и устанавливал сам себе верный seed. Также, вероятно, эта функция будет разруливать ранний останов.
О reduce я когда-то написал статью, там упоминается тот факт, что другие функции высшего порядка сводятся к reduce. Думаю, кто-нибудь найдёт эту статью интересной.
Всё равно непонятно, как из этого вытекает необходимость своей системы пакетов. Всего того же самого можно добиться на базе существующей системы. Содержимое npm и bower может быть совершенно различным. Так что их можно использовать как транспорт, при этом не нужно всё это заново писать:
Я думаю лучший вариант для тех, кто хочет сейчас запилить себе пакетную систему, это использовать npm в качестве менеджера пакетов, и использовать его без registry, вместо него использовать GitHub, как это сделали в bower (впрочем, registry тоже можно).
При этом к таким пакетам нужно предъявить некоторые дополнительные требования (интерфейс), которые и будут делать их конкретным пакетом конкретной местячковой системы. Т.е., пакет будет одновременно пакетом npm и более конкретным пакетом (например пакетом метеора), потому что в нём будет какое-то специфичное содержимое. Пакетам можно добавить какой-нибудь специальный тег, например <имя вашей пакетной системы здесь>-package и так их можно будет выделить в отдельную группу пакетов npm.
А поскольку таких нет, и все мы люди и иногда ошибаемся, то и получается такой результат.
На эту тему есть отличный сборник заблуждений: habrahabr.ru/post/146109/
Для второго можно использовать npm start, указав start-команду. А первое похоже на тест, поэтому для него вполне можно применить npm test. Указывается test-команда.
npm scripts
Что касается разработки, то browserify умеет делить кусок на бандлы. А ещё есть кеширующие сборщики.
До этого использовал следующий паттерн:
Также работает в обоих вариантах, но чувствительно к количеству аргументов и обвязка громоздкая.
Да, хочу сказать, что я лично не выступаю за вариант с обёрткой, я, скорее, придерживаюсь вашей точки зрения, что лучше использовать существующее значение (undefined), тем более оно подходит по семантике. Так что я ни в коем случае не спорю с вами, скорее пытаюсь выжать из идеи всё до конца.
А ещё там
лёгкийстёб над Ричем и пасхалка в одном из слайдов.Ещё можно использовать объект, ссылка на него будет уникальной, а в новом стандарте вообще есть тип Symbol.
Тут главная разница в том, что Reduced содержит не только метку, но и сам результат, который далее анбоксится. Все остальные варианты перекладывают задачу на управляющую функцию transduce. Вероятно, Ричу более нравится «чистый» подход, с хранением результата, а мы в JS привыкли к флаговым значениям.
Мне как-то приходила мысль, что после абстрагирования функции, которая передаётся в filter/map, есть какой-то ещё шаг, который заключается в абстрагировании от самого итерационного процесса. Тогда мне показалось это овер-инжинирингом и я отбросил эту идею. Сейчас же, когда filter/map появляется в таком количестве разных контекстов, становится очевидно, что это следующий разумный шаг в поднятии абстракции.
Например, как вы подметили в статье (и в презентации тоже был про это слайд), что FRP реализует свои filter/map и весь остальной зоопарк, но сущность их не меняется. Например в JS мы уже имеем приличный utility-belt в виде LoDash, как было бы славно их просто применять к FRP или к другим контекстам.
О reduce я когда-то написал статью, там упоминается тот факт, что другие функции высшего порядка сводятся к reduce. Думаю, кто-нибудь найдёт эту статью интересной.