Почему все используют Node.js и NPM для компиляции библиотек JavaScript?

Question

Я действительно запутался со всеми в сообществе JS, используя Node.js и NPM со своими JS-библиотеками. Почему мы должны прибегать к таким экстремальным мерам? Какие проблемы это решение для нас?

[Изменить] Я думаю, что мой вопрос был не в этом.

1. Каркасы как ember.js, Batman.js и совсем недавно Yahoo, Мохито требует от меня использовать Node.js - почему эта зависимость от Node.js и НПМ?
2. Почему мы делаем вещи сложными? «Если вы еще этого не сделали, вам нужно будет установить node.js ...». Вы читаете такие сообщения, и вы отключены.

Почему? В JS уже есть проблема с избытком - слишком много активных JS-библиотек/фреймворков на выбор - в результате записи JS-библиотек большинство из них скоро станет неактивным. Есть слишком много вещей для поиска, которые часто приводят к созданию нескольких фреймворков в управлении зависимостями приложений, маршрутизаторах, MVC, шаблонах и т. Д. Кроме того, мы используем Node.js для использования этих libs/frameworks ... будет ли это использование этих библиотек для новых разработчиков JS? JS предназначался для облегчения!

Answer 1

«Если вы еще этого не сделали, вам необходимо установить node.js ...». Вы читаете такие сообщения, и вы отключены. Зачем?

NodeJS - это V8 Google, «работающий на своем собственном». Это JS-движок с дополнительным низкоуровневым API (сеть, ввод-вывод и т. Д.). NodeJS предоставляет «недостающую платформу» для разработчиков JS, которые были ограничены только работой в браузере.

Почему эта зависимость от Node.js и NPM?

Node.js, кроме использования его в качестве приложения (серверов, прокси-серверов, ботов и т. Д.), Его также можно использовать в качестве средства разработки и поддержки инструментов. Возьмем, к примеру, Grunt, который является инструментом автоматизации, доступным для сценариев, который похож на Make. Скрипты в простом JS, вам не нужно изучать другой инструмент или язык для автоматизации. Другим инструментом является Bower, который является интерфейсом управления пакетами. Все, что вам нужно сделать, это bower install jquery, и он устанавливает jquery с этой единственной командой. Не требуется ручная загрузка, копирование и вставка.

НПМ, с другой стороны, является менеджером пакетов Node.js. Это программа, которая управляет модулями, которые вы используете в NodeJS. Не нужно перечислять свои модули вручную, и не нужно помнить их, когда вы разрабатываете где-то еще. Пока у вас есть пакет NPM для вас, переустановка - это только вопрос npm install.

Почему мы делаем вещи сложными?

Мы не знаем. Фактически, мы делаем их легкими для разработчиков. Вместо того, чтобы беспокоиться о своем рабочем процессе, управлять своими библиотеками или делать вещи вручную, вы можете отключить эти задачи до некоторых модулей, существующих в NPM. Тогда вы можете просто сосредоточиться на том, что вы на самом деле делаете.

В дополнение к этому мы используем Node.js для использования этих libs/frameworks ... Как это приведет к использованию этих библиотек для новых разработчиков JS? JS предназначался для облегчения!

Как упомянуто выше, NodeJS - это универсальная платформа. Он может использоваться как сервер (Connect, Express), инструмент автоматизации (Grunt), система управления пакетами (с использованием NPM, Bower и т. Д.), Тестовая платформа (QUnit, Mocha), прокси, игровой сервер, бот-бот ,

И это выгодно, особенно разработчику JS, поскольку это невозможно в JS.

В JS уже есть проблема с избытком - слишком много активных JS-библиотек/фреймворков на выбор - по записи JS-библиотек большинство из них скоро станет неактивным. Есть слишком много вещей, чтобы искать, что часто приводит к множеству различных в приложении - управление зависимостями, маршрутизаторы, MVC, шаблонных, и т.д.

Ну, это хорошо, чтобы иметь богатый набор рамок. После изучения некоторых из них ваша работа будет сокращена наполовину. Разнообразие реализации также хорошо, для решения различных стилей кодирования и различных подходов к реализации. Некоторые библиотеки поднимаются с разных подходов, другие - от несовместимости и/или неполноты других.

Разработчики усердно работают над тем, чтобы облегчить жизнь другим разработчикам, нормализуя причуды JS (потому что поставщики браузеров просто не могут походить на правильные стандарты), и большинство из них выполняется добровольно, например, бесплатное пиво - Вы должны быть счастливы за это. Кроме того, никто не заставляет вас использовать его в любом случае.

Answer 2

Очень часто вам нужны разные сборки вашего javascript. Обычно он распространяется в разных файлах, иногда в coffeescript. Вы часто нуждаетесь в сборке для сборки AMD, а также в CommonJS, а также в обычных минимальных и немимизированных сборках.

Существует также потенциал для разрешения зависимостей.

Я даже видел библиотеку, которая была сборки для JQuery и Protoype ...

Answer 3

Edit: я заметил, отвечая на вопрос, сформулированный в теле вопроса, но пропустил вопрос компиляции в названии.

Какие критерии у вас есть для рассмотрения этой «крайней меры»? Это делается в течение многих лет, ради написания чистого, легко читаемого/написанного кода, но предварительно скомпилированного для оптимизации для проводной передачи (и, возможно, других оптимизаций). Node.js отлично подходит для этого, просто потому, что он также использует JavaScript и, следовательно, знаком с людьми, использующими его для компиляции своего кода JavaScript. Раньше это обычно делалось в чем-то вроде Python, который, хотя и работает, кажется мне менее чувствительным, чем придерживаться общего языка.

Answer 4

Стандарт CommonJS (наилучшим образом реализованный, на мой взгляд, Node.js и NPM) представляет концепцию модулей в Javascript. В течение многих лет, сообщество Perl и Python продемонстрировало, почему модули удивительные:

• Unix-стиль «сделать одну вещи и делать это хорошо» библиотеки, которые являются небольшими и тщательно протестированы от ошибок, которые могут быть объединены легко (без проблем с пространством имен) для решения вашей конкретной задачи.
• Центральный репозиторий модулей с открытым исходным кодом (CPAN, NPM и т. Д.), Из которых вы можете легко извлечь модули (NPM занимает один уровень выше, сохраняя все доступные версии, поэтому вы можете указать, что ваш код использует последней известной «хорошей» версии, а не надеяться, что ничего не сломалось, когда вы передислоцировали CPAN).
• Большая экспертная оценка кода (поскольку они более легко скомпонованы, они используются в самых разных ситуациях, поэтому это помогает уменьшить количество ошибок, а также то, что помогает улучшить модули, чтобы они были более обобщенными).
• Выполнено большое разнообразие задач. Поскольку библиотеки коротки, почти каждый может написать один. Это означает, что для фильтрации требуется гораздо больше дерьма (статьи об широко используемых библиотеках помогают с этим), но это также означает, что библиотека, которая решает некоторые специфические проблемы (например, localizing strings and dates), вероятно, также существует.

А затем модуль Node называется browserify делает сам процесс сборки для вашего кода на стороне клиента невероятно простого, и вы можете использовать почти любой кусок кода, который вы найдете на НОМ.

Это отходит от менталитета «кухонной раковины» библиотек, таких как jQuery (которые разработали собственную систему сборки, чтобы они могли также начать модульную работу с их кодом), которые считают, что им необходимо решить каждую проблему, которую может иметь их пользователь, а не просто давать результаты, которые могут быть использованы другими библиотеками.