Как установить Node.js

29 октября 2020

Устанавливаем программную платформу Node.js, для того чтобы дать JavaScript возможность взаимодействовать с устройствами ввода-вывода через свой API и подключать разные внешние библиотеки.

Установка Node.js на Windows

Для начала необходимо установить правильную консоль для WIndows.

После этого можно переходить к установке Node.js. Для Windows есть только один способ.

Необходимо перейти на официальный сайт https://nodejs.org и на главной странице скачать последнюю стабильную версию.

Официальный сайт https://nodejs.org.

После загрузки инсталлятор следует запустить и установить Node.js, как любую другую программу.

Убедимся, что всё установилось. Для этого в cmder проверим версию Node.js с помощью команды node -v и npm -v .

Проверка версии и установка пакета.

Установка Node.js на OS X

Заходим на сайт https://nodejs.org и на главной странице скачиваем последнюю стабильную версию, нажав на соответствующую кнопку.

Официальный сайт https://nodejs.org.

После скачивания достаточно установить пакет через инсталлятор и можно начинать пользоваться.

Десктопные приложения на html, css и js для windows, mac os, linux. Подробный обзор nw.js (бывший node-webkit)

nw.js – это платформа, которая позволяет создавать кроссплатформенные десктопные приложения для windows, mac os и linux, используя веб-технологии. При этом javascript, html и css используются для построения интерфейса, а node.js(io.js) – для описания основной логики. Кроме того, Вам предоставляется высокоуровневый JS API для доступа ко многим элементам операционных систем (настройкам окна, меню, буферу обмена, системному трею и др.)

Мы все любим веб-приложения! При этом большинство софта, который мы используем на ноутбуках для работы и развлечений, – это десктопные приложения. Да-да, те самые, с иконкой на рабочем столе, которые могут висеть в памяти целыми днями или неделями (файловые менеджеры, системные утилиты, фото, аудио и видео редакторы, IDE, чаты и др.).

Что же не позволяет веб-приложениям выйти на уровень десктопных?

Я приведу всего несколько ограничений, которые есть у всех веб-приложений и которые можно преодолеть, разрабатывая десктопный софт с nw.js. Итак, я хочу, чтобы мое приложение:

• Имело полный доступ к файловой системе, системным процессам, могло выполнять команды в командной оболочке той машины, на которой запущено.
• Могло работать в фоне, запускаться при старте системы и оффлайн.
• Не спрашивало подтверждения доступа при использовании камеры и микрофона.
• Могло использовать Web Gl, Web Audio, Web RTC и т.д. в той версии браузера, которая определена мной.
• Могло создавать элементы управления на уровне операционной системы: меню, окна, иконки в трее (менюбаре), управлять ими.
• Могло создавать несколько окон.
• Могло делать скриншоты.
• Имело доступ к буферу обмена на запись и чтение.
• Могло подписываться на системные сочетания клавиш (в том числе, когда приложение не в фокусе)
• Могло пользоваться системной нотификацией.
• Могло делать кроссдоменные запросы.
• Могло изменять UserAgent
• Могло загружать любые сайты во фрейм, который они не считали бы фреймом.
• Могло включать полноценный полноэкранный режим kiosk-mode (как в десктопных играх).
• Я хочу распространять и рекламировать приложение через магазины приложений.
• И просто, но важно… Я хочу запускать приложение нажатием на иконку!

nw.js позволяет реализовать вышеописанные задумки.

Кстати, если вам удобнее воспринимать видео, нежели читать дальше, то вот запись с моего доклада на Frontend Conf. Но, хочу предупредить, в статье все описано подробне 😉

Почему браузера может быть мало?

Похожие подходы и их недостатки

На данный момент существует несколько различных технологий для создания десктопных приложений на базе веб-технологий. Вот их неполный список:

На мой субъективный взгляд, основным недостатком этих технологий является то, что обычному веб-разработчику придется немало помучиться, осваивая все тонкости API и внутренней философии любой из них. Вам нужно будет перелопатить тонны документации и примеров, чтобы просто начать что-то делать и увидеть первый результат.

С nw.js все намного проще. Если вы разрабатываете веб-приложения и имеете немного опыта работы с node.js, то уже через несколько часов вы поймете как писать и собирать десктопные приложения под mac, windows и linux.

От node-webkit к nw.js. Немного истории

В 2011 году разработчик из Китая Roger Wang основал проект node-webkit, основной задумкой которого стало использование веб-технологий для написания полнофункциональных кроссплатформенных десктопных приложений. Как уже понятно из названия, основными составляющими проекта стали Node.js и Webkit (Chromium).

Шли годы и в апреле 2013-го Chromium, а вместе с ним и проект node-webkit переехал на новый движок Blink (форк Webkit-а). В добавок к этому с января 2015 проект начал использовать io.js вместо node.js.

В итоге изначальное название “node-webkit” стало совсем не актуальным и было принято решение переименовать проект в nw.js. Бытует мнение, что теперь в буквах NW заложен новый смысл – “Native Web”.

Основными спонсорами проекта до сих пор являются intel и Gnor Tech.

Основная идея. Зачем “скрещивать” Chromium c node.js?

Когда мы говорим о десктопных приложениях, мы представляем себе некий графический интерфейс, взаимодействуя с которым мы осуществляем изменения на системном уровне операционной системы (например, копируем файлы, запускаем процессы, выполняем системные команды и т.п.)

Для того, чтобы понять всю мощь идеи nw.js, давайте коротко рассмотрим основные составляющие nwjs.

Chromium – браузер с открытым исходным кодом, который разрабатывается силами Google, Opera Software, Яндекс, NVIDIA и других компаний. В качестве движка для отображения веб-страниц в Chromium используется Blink (форк Webkit). В качестве движка для обработки JavaScript используется v8.

node.js(io.js) – это JavaScript runtime на основе движка v8, изначально используемого в Chromium. Он написан на С++ и работает на уровне протоколов прикладного уровня, где ему доступны множество различных API операционных систем, таких как файловая система и сетевые взаимодействия. В силу этого, node чаще всего используется для построения системных приложений и серверов.

Основной идеей nw.js является объединение Chromium и node.js в единый контекст, используя один и тот же v8. Если сказать точнее, node.js использует v8 Chromium-a. Т.е. при помощи Chromium мы можем создать графический интерфейс на основе html, css, js, как и в любом веб-браузере. Но, в отличие от обычного браузера, nw.js позволяет из этого же контекста вызывать функции node.js для работы с системными API операционной системы.

Давайте разберем простейший пример. При помощи модуля fs для io.js мы будем следить за изменениями какого-нибудь файла в системе. В случае, если файл изменился, отобразим его содержимое в div-e c >

Как мы видим, здесь нет сервера и клиента, нет ajax, нет сокетов, нет http, нет обмена данными по сети. Как мы говорили, вся прелесть nwjs заключается в возможности работы с node.js из контекста Chromium.

Как они это сделали

Разработчики nw.js приложили немало усилий для обеспечения единого event loop и построения “моста” между контекстами node.js и chromium. Здесь можно почитать подробнее о технических деталях и проблемах, возникших при реализации этой задумки.

Начинаем погружение

Для начала скачайте и установите последнюю версию nw.js для Вашей платформы. Далее следуйте указаниям документации для настройки командной строки и алиасов для Вашей операционной системы.

Структура приложения nw.js

Приложение для nw.js состоит из обычных html, css, js файлов, структурированных произвольно. Нет никаких дополнительных правил и условностей по их компоновке.

При запуске nw.js ищет файл манифеста package.json .

Пример package.json

Этот файл ничем не отличается от обычного package.json в node.js, за исключением того, что он содержит дополнительные параметры: window , user-agent , chromium-args , js-flags и другие. Они позволяют nw.js настраивать и контролировать поведение Chromium и его окружения, добавлять флаги при запуске node.js, менять режим отображения, размеры окна, иконки, точку входа в приложение и множество других установок.

Для примера мы создадим файл index.html и добавим немного CSS.

index.html

Затем откроем консоль и наберем:

где my/lovely/app – путь к папке с приложением, а nw – правильно настроенный алиас для nw.js

И все! В результате запустится десктопное приложение, которое выглядит примерно так:

Настройка отображения окна

Результат, который мы видим очень похож на обычный браузер с адресной строкой. В принципе, это и есть браузер! Да-да, тот самый Chromium, о котором мы говорили.

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

Для этого существует целый ряд настроек, доступных в package.json . Давайте подробнее остановимся на некоторых из них.

Для начала можем убрать тулбар.

package.json

При желании можно скрыть фрейм окна.

package.json

Или вообще убрать фон окна, оставив только контент.

package.json

Kiosk-mode

Еще одной мощной опцией является возможность запуска приложений в Kiosk-mode. Этот режим часто используется в десктопных играх, а также на экранах в публичных местах (например, для показа рекламы на больших мониторах). Выйти из приложения, запущенного в Кiosk-mode не так просто как из браузерного fullscreen. Это можно сделать только при помощи методов API nw.js, Alt-Tab или Ctrl-Alt-Del(Windows), поэтому, разрабатывая приложения, работающие в этом режиме, Вы сами должны позаботиться о наличии в интерфейсе некоторой кнопки “Выход”, которая поможет пользователю его закрыть.

package.json

Ну и, наконец, мы просто можем скрыть окно, оставив приложение в фоновом режиме

Элементы интерфейса операционной системы.

Nw.js позволяет создавать и управлять элементами интерфейса операционной системы, характерными для десктопных приложений (меню окна, трей, контекстные меню). Также Вы можете получить доступ к буферу обмена, сочетаниям системных клавиш и т.п.

Для этого потребуется всего лишь подключить модуль nw.gui , который уже есть в стандартной поставке. Он дает возможность абстрагироваться от реализации элементов интерфейса в конкретной операционной системе, предоставляя общий API.

А теперь давайте посмотрим подробнее на некоторые из вышеописанных возможностей.

Создание системных контекстных меню

Вот что мы получим в итоге при клике правой клавишей на окне:

Тонкости nodejs. Часть I: пресловутый app.js

Я работаю с node.js более трех лет и за это время успел хорошо познакомиться с платформой, ее сильными и слабыми сторонами. За это время платформа сильно изменилась, как, собственно, и сам javascript. Идея использовать одну среду и на сервере и на клиенте пришлась многим по душе. Еще бы! Это удобно и просто! Но, к сожалению, на практике все оказалось не так радужно, вместе с плюсами платформа впитала в себя и минусы используемого языка, а разный подход к реализации практически свел на нет плюсы от использования единой среды. Так все попытки реализовать серверный js до ноды не взлетели, взять тот же Rhino. И, скорее всего, node ждала та же участь, если бы не легендарный V8, неблокирующий код и потрясающая производительность. Именно за это его так любят разработчики. В этой серии статей, я постараюсь рассказать о неочевидных на первый взгляд проблемах и тонкостях работы, с которыми вы столкнетесь в разработке на nodejs.

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

Начать хочется с наиболее часто встречаемой и распространенной реализации приложения – главной точкой входа – app.js, на примере веб-приложения с использованием express. Обычно выглядит она так:

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

И так, мы написали hello world. Но, это чересчур абстрактный пример. Давайте добавим конкретики и напишем приложение которое будет выводить список файлов из указаной директории и отображать содержимое отдельных файлов, запрашивая данные из mongo.

Отлично, все просто и наглядно: соединяемся с базой, создаем сервер, назначаем обработчки для путей. Но давайте подумаем, какими недостатками обладает код:

1. Его тяжело тестировать, так как нет возможности напрямую проверить результат возвращаемый методами.
2. Его тяжело конфигурировать – невозможно изменить конфигурацию для двух экземпляров приложения.
3. Компоненты приложения недоступны для внешнего кода, а значит и для расширения.
4. Ошибки никуда не передаются и должны быть обработаны на месте или же выброшены на самый верхний уровень.

На практике это приводит к монолитному коду. И скорому рефакторингу. Что можно сделать? Необходимо разделить логику и интерфейс.
Все что касается работы приложения давайте оставим в app.js, а все что касается веб-http-интерфейса в http.js.

Что мы сделали? Добавили событийную модель для отлова ошибок. Добавили возможность указывать путь к конфигурации для каждого экземпляра приложения.
Таким образом мы избавились от перечисленых выше проблем:

1. Любой метод доступен напрямую через объект app.
2. Управление конфигурацией стало гибким: можно указать путь в консоли или через export APP_CONFIG_PATH=…
3. Появился централизованный доступ к компонентам.
4. Ошибки приложения отлавливаются объектом app и могут быть обработаны с учетом контекста.

Теперь мы можем легко добавить новый интерфейс для командной строки:
или тест
Конечно, приложение теперь выглядит не таким минималистичным, как в примерах, зато является боле гибким. В следующей части я расскажу про отлов ошибок.