Десктоп на web что это
Десктопное или веб-приложение: плюсы и минусы
Сегодня поговорим об отличиях десктопных и веб-приложений. Не обещаем, что сможем быть полностью непредвзятыми, но постараемся честно рассмотреть плюсы и минусы.
Итак, веб-приложение работает через браузер, используя его как среду выполнения, десктопное— устанавливается, запускается и работает локально. Сравним их по основным характеристикам.
Веб-приложение не требует установки, все обновления происходят на сервере, доставляются пользователям сразу — достаточно просто перезагрузить страницу или выйти, а потом снова зайти в аккаунт. Но иногда для его работы нужно установить дополнительные библиотеки или использовать защищенные сетевые протоколы.
Десктопное нужно устанавливать на компьютере или мобильном устройстве, обновлять каждый раз, как выходит новая версия. Несмотря на то, что чаще всего процесс автоматизирован — все равно это занимает время пользователей и ресурсы устройств. Дополнительно придется отслеживать версии на каждом компьютере, смартфоне и планшете.
Веб-приложение публикуется на локальном или облачном сервере, там же происходит процесс обновления. При этом сервер нужен в любом случае, даже если решение совсем простое. Ведь кроме фронтенда, с которым пользователи будут работать через браузер, нужно где-то размещать бэкенд.
Десктопное придется устанавливать вручную на каждом устройстве. В компании, где много рабочих мест, это может занять достаточно много времени. Плюс в том, что не обязательно выбирать сервер или искать ресурсы для публикации, если речь не идет о клиент-серверном решении.
Работа веб-приложения зависит не только от того, насколько грамотно оно разработано и характеристик пользовательского устройства, но также от скорости интернет-соединения, работоспособности удаленного сервера.
Десктопное работает автономно, поэтому главное — качество кода и стабильность оборудования, на котором этот код выполняется. Но если связь с сервером необходима — то возникают те же проблемы, что у «конкурента».
Веб-приложение доступно из любой точки мира, с любого устройства, а пользовательские файлы всегда будут под рукой. Но только если есть интернет-соединение или реализована возможность работы офлайн и загрузки-выгрузки данных.
Десктопное доступно всегда — но только с устройства, на котором оно установлено. Чтобы работать с разных устройств, его придется установить на каждом, а также придумать, где хранить файлы, чтобы всегда иметь к ним доступ.
Веб-приложение одинаково хорошо будет работать на любом устройстве, будь то стационарный компьютер, ноутбук, планшет или смартфон — ведь оно практически не зависит от «железа» или операционной системы. Главное — подходящий браузер. Как правило, для работы большинства веб-клиентов подходят Google Chrome, Mozilla Firefox, Safari от Apple или Windows-браузер (Microsoft Edge / Internet Explorer).
Десктопное зависит от операционной системы, процессора, видеокарты, ряда других параметров. Приходится учитывать нюансы каждой среды (в том числе при «отлове» ошибок), писать код с учетом возможных вариантов, нанимать отдельных разработчиков или даже целые команды для версий под разные ОС.
Веб-приложение полностью зависит от браузера и технологий его работы. Поэтому есть ряд ограничений, например — в доступе к аппаратному обеспечению вашего устройства. Это и некоторые другие ограничения обойти невозможно (во всяком случае, сейчас). Но целый ряд задач можно решить по принципу «что нельзя переписать, можно надстраивать или расширять». Редакторы документов, изображений, аудио, видео, 3D графики; системы управления проектами; хранилища файлов; no-code конструкторы — успешно работают в браузерах. Инструменты быстрой интеграции сервисов, а также интерфейсные библиотеки еще больше расширяют существующие возможности.
Десктопное позволяет реализовать буквально любые функции — в этом оно однозначно превосходит web. Во всяком случае, полноценного онлайн аналога Photoshop или Sony Vegas еще никто не разработал. Системные утилиты — определенно сфера десктопной разработки. Как и программы, которые должны долго работать в фоновом режиме — например, чаты или торрент-клиенты — через браузер с ними просто неудобно будет работать. Также такое ПО чаще используется для специфических проектов, с нестандартными интерфейсами или функциями. Поэтому web разработка пока не представляет опасности для desktop программистов— эти технологии будут развиваться параллельно, просто под разные задачи.
По поводу скорости работы все не так однозначно, как может показаться. Несмотря на то, что браузерный клиент постоянно обменивается данными с сервером, быстродействие будет во многом будет зависеть от того, насколько грамотно он спроектирован, «чистоты» кода, возможностей оборудования, стабильности канала связи. Разница в быстродействии, которая очевидна при тестировании, зачастую незаметна для пользователей.
Веб-приложение, разработанное с использованием современных протоколов и средств защиты, способно полноценно обеспечивать сохранность данных. Однако на некоторые моменты разработчики не могут повлиять: браузер, облачный сервер, канал связи — могут повысить уровень безопасности за счет дополнительных средств проверки, но также снизить его за счет своих уязвимостей. Несомненный плюс для пользователей: такое ПО проще контролировать. Ограничения среды снижают вероятность, что оно скрыто получит доступ к файлам или запустит какой-либо процесс.
Десктопное настраивается более гибко, а значит — теоретически при его разработке можно предусмотреть все потенциальные уязвимости. На практике — вряд ли. Впрочем, сделать его полностью безопасным все же можно. Но только если устройство, на котором оно установлено, не будет никуда подключаться, даже к защищенной локальной сети. В противном случае — риск все равно будет.
Однозначно сказать, что безопаснее — сложно (если вообще возможно). На это влияют много факторов, прежде всего — человеческий. А ведь именно в защите от человеческого фактора, в различных его проявлениях, заключается смысл всех мер безопасности.
Но очевидно, что доверие к десктопному ПО выше. Некоторые организации принципиально не соглашаются работать в браузерах, многие пользователи все еще относятся к ним настороженно. Однако ситуация меняется — с развитием технологий растет лояльность людей к ним.
Возможности браузерной разработки огромны, ее потенциал раскрыт далеко не полностью. Технологии развиваются, рынок ИТ растет, предлагая все новые приложения — при прочих равных пользователи будут выбирать web просто потому, что это удобнее. Если говорить о решениях для корпоративных клиентов, то тут браузерные приложения незаменимы. Они гибкие, универсальные, не требуют предварительной подготовки среды, позволяют сэкономить финансы компании, аппаратные ресурсы, время сотрудников.
Но рассмотрим другое мнение. Некоторые разработчики считают, что перспективы далеко не безоблачные. Слишком несовершенны технологии работы браузеров, слишком много некачественного ПО уже «накодили». Поэтому пользователи браузерных решений будут возвращаться обратно к десктопным. Такая тенденция будет продолжаться, пока разработчики браузеров массово используют Java Script. Только когда появится реальная альтернатива — можно будет делать прогнозы на будущее.
Веб-приложения уже сейчас подходят для решения многих задач — как бизнеса, так и обычных пользователей. Если вы решили разработать свое — используйте no-code платформу AppMaster.io.
Готовые блоки кода и визуальные инструменты для работы с ними помогут вам создать готовое веб-приложение и его серверную часть гораздо проще и быстрее, чем методы классического программирования!
Какое бизнес-приложение нужно вашей компании: web или desktop?
Какое бизнес-приложение нужно вашей компании: web или desktop?
Идея написать статью на эту тему возникла в 2020 году, когда к нам с запросом на разработку ПО обратился крупный региональный производитель профлиста. Компании понадобилось приложение для менеджмента заказов на производство и доставку, и уже был определен примерный список требований.
Одним из пожеланий заказчика была разработка именно десктоп-приложения. Однако в процессе обследования и оценки задач мы вместе с клиентом пришли к выводу, что быстрее разработать web-приложение на платформе Jmix (ранее Cuba Platform).
И это далеко не первый случай, когда на этапе дискавери заказчик уверен в преимуществах десктоп-приложений, но в итоге делает выбор в пользу веба. Почему так происходит, какие плюсы и минусы у веба и десктопа, и какое приложение подойдет именно вашей компании — вы узнаете из этой статьи.
Важно! Так как статья ориентирована на читателей, которые знакомы с IT-сферой и разработкой ПО скорее на уровне пользователей, чем на уровне системных администраторов, для начала определим предмет разговора и уточним, что мы понимаем под вебом и под десктопом.
Веб-приложение — программа, которой вы можете пользоваться в любом удобном для вас браузере. Перед первым запуском ее не нужно устанавливать на ваш компьютер, достаточно вести адрес для доступа в строке браузера.
Десктопное приложение — программное обеспечение, которое вы используете в отдельном интерфейсе, а не в браузере. Перед использованием его придется обязательно установить на компьютер пользователя.
Это поверхностная разница на уровне очевидных для пользователя моментов, хотя на самом деле отличий у этих двух типов приложений гораздо больше.
Мифы о десктоп-приложениях
Еще 10-15 лет назад на рынке программного обеспечения царствовали именно десктоп-приложения, а веб только-только начинал развиваться. Процесс массового перехода к вебу происходил постепенно, и вот уже мы открываем большую часть необходимых для работы программ именно в браузере. Но, тем не менее, в представлении многих пользователей именно десктоп остался символом надежности, быстродействия и простоты. Так ли это на самом деле? Рассмотрим и попробуем опровергнуть самые распространенные мифы.
Миф №1 «Десктоп всегда безопаснее, а из веб-приложения нашу информацию могут украсть»
И да, и нет. Если сервер находится «снаружи» организации, и доступ к нему недостаточно защищен, то данные могут украсть независимо от того, будете ли вы пользоваться десктоп или веб приложением. То есть тут мы путаем «технологию разработки» и собственно архитектуру системы, и то, как организована защита передачи данных. Первично именно то, где находится сервер, насколько он защищен, и насколько защищены каналы доступа с клиентских ПК до сервера.
Технология разработки и интерфейс – этот как раз или веб-клиент, или десктоп. Это та часть, через которую пользователь взаимодействует с программой и запускает какие-то процессы. Защитить информацию на этом уровне можно только путем настройки доступа: создать надежные пароли и организовать их безопасное хранение, настроить уровни прав доступа для разных групп пользователей, установить на ПК антивирусы, которые обнаружат вредоносное и шпионское ПО.
Но самое ценное – собственно коммерческая информация, например, список клиентов и договоров – находится в базе данных. Местом ее хранения может быть:
Именно от того, где находится база данных, насколько надежно она защищена, и насколько защищены каналы связи, по большей зависит безопасность коммерческих данных вашей компании. Если разместить базу в публичном облаке, не ограничивая к ней доступ третьих лиц, то будет абсолютно неважно, веб или десктоп клиент используется на машинах пользователей.
Или если облачный сервер защищен от доступа посторонних, но пользователи получают доступ к данным через открытые каналы интернет без использования шифрования (VPN) – ваши данные под угрозой в любом случае.
Миф №2 «Десктоп работает и без интернета, а веб-приложение важна высокая скорость соединения»
Возможно, 10 лет назад это утверждение еще можно было назвать правдивым, но сегодня оно точно перешло в разряд мифов, и вот почему. Как веб, так и десктоп приложению для корректной работы может требоваться интернет, если:
Пример: вам нужно простое десктоп-приложение для ведения сделок и хранения базы клиентов, которое будет работать на собственном сервере в офисе. Для удобства менеджеров в приложение встроена проверка потенциального контрагента по ИНН с указанием возможных рисков.
Для проверки система обращается к открытым источникам в интернете. Если в офисе отключили интернет, менеджеры смогут спокойно работать с самим приложением. Однако автоматическая проверка по ИНН не будет работать до того момента, пока не восстановится соединение.
Если в аналогичном примере у компании не один, а два офиса, а сервер вынесен за пределы офисной сети и доступен только удаленно, при отключении интернета любое приложение будет недоступно.
Миф №3 «Десктопные приложения проще и понятнее, чем веб»
Такое впечатление может сложиться после сравнения какой-то простейшей десктоп-программы, разработанной под конкретную задачу, и сложной многофункциональной веб-системы, такой как Битрикс24. И здесь мы снова сталкиваемся с тем, что выбор технологии разработки не влияет сам по себе на удобство интерфейса. Одинаково непонятную или наоборот удобную для пользователя систему можно построить как в виде «настольного» приложения, так и в его веб-версии.
Совет: Заказчикам бизнес-приложений еще на этапе формирования своих пожеланий разработчику не стоит забывать о такой важной части, как обучение и «онбординг» пользователей. Именно от того, насколько интерфейс приложения учитывает сценарии работы пользователей, и от того, насколько гладко и успешно пройдет обучение, зависит, будут ли сотрудники использовать систему, или внутри коллектива начнется саботаж и деньги на разработку будут потрачены зря.
А еще хотя бы частично автоматизированная схема обучения позволяет не тратить время на обучение нового сотрудника, а позволяет ему самостоятельно познакомиться с основными сценариями в режиме обучения с подсказками, и задать вопросы.
Плюсы и минусы десктоп-приложений
После того, как мы развеяли распространенные мифы о десктопе, стоит разобраться, что на самом деле представляют из себя современные «настольные» программы, и кому они подходят.
Преимущества десктопных бизнес-приложений
Возможные «минусы» выбора десктоп-приложений для бизнеса
Веб-приложения: преимущества и недостатки
Преимущества
Гибкие и кросс-платформенные решения, дешевле разработка
Это одна из главных причин, по которой сегодня веб-приложения практически заменили десктоп. Существующие фреймворки позволяют при разработке учитывать требования практически всех популярных браузеров, а не создавать отдельное приложение или адаптацию под каждый из них. Это делает разработку в несколько раз дешевле и быстрее, а полученные в результате приложения — более гибкими с точки зрения изменений и доработок в перспективе.
В первую очередь кросс-платформенность важна для разработки коммерческих продуктов. Приложение, которое будут использовать тысячи или даже миллионы пользователей из разных стран, должны по умолчанию подходит под большую часть популярных устройств и операционных систем на выбранных рынках.
Но не стоит думать, что при заказе бизнес-приложения для компании на 15-20 пользователей этот пункт не важен. Даже если сейчас вам известно, на каких именно устройствах и платформах будет использоваться разработанное решение, уже через 1-2 года ситуация может измениться.
Например, так произошло при разработке приложения для одного из наших клиентов. После завершения разработки и успешного внедрения клиент решил масштабировать решение на филиал в другом городе. И внезапно оказалось, что в парке пользовательских ПК есть старые машины с операционной системой Windows 7.
Благодаря тому, что приложение было разработано на платформе Jmix, нам удалось успешно запустить программу даже на такой «древней» операционке. Если бы вместо веб-приложения мы разработали десктоп, то заказчику было бы проще купить новые ПК, чем дорабатывать приложение под Windows 7 ради нескольких рабочих мест.
Проще в установке и поддержке
Выше мы уже описывали процесс обновления версии десктоп-приложения. А теперь сравните с вебом: достаточно за 5-10 минут загрузить обновления на сервер и попросить пользователей «перелогиниться» в системе. Даже если в компании более 50-80 пользователей, провести обновление будет намного проще, чем в случае с десктопом.
Недостатки веб-приложений для бизнеса
Можно сказать, что минусами веб-приложений считаются те же моменты, которые относят к плюсам у десктопных, поэтому не будем раскрывать их подробно, а повторим тезисно:
Десктоп или веб: какое приложение подойдет для решения ваших бизнес-задач?
Разработку десктоп-приложения стоит выбрать, когда вашей компании необходима программа для:
Во всех остальных случаях стоит сначала рассмотреть возможность разработки веб-приложения, так как сегодня они способны решать большую часть бизнес-задач, и при этом тратить на разработку меньше времени и средств.
3 in 1: Desktop, Mobile, Web. Кроссплатформенная разработка
Разработка в рамках одного проекта несет в себе ряд преимуществ. Во-первых, это позволяет использовать одну реализацию бизнес-логики программы. Во-вторых, это возможность иметь единый набор юнит-тестов. В-третьих, это использование привычного языка(С++) и среды разработки.
Статья описывает некоторые методы программирования и несколько библиотек помогающие создавать кроссплатформенные приложения.
За основу взят опыт создания небольшого приложения типа «калькулятор»
Кроссплатформенная разработка
Удобно писать один код вместо трех, это значительно сокращает время создания программы. Но к сожалению каждая платформа имеет свой зависимый код(функционал). Часто без функционала предоставляемого конкретной платформой просто не обойтись. Возможным решением этой проблемы являются стратегии проектирования (подробнее можно узнать в книге Александреску «Современное проектирование на С++»). Весь зависимый код выносится в классы настройки, так называемые «policy», которыми в дальнейшем конфигурируются более крупные классы.
Использование кроссплатформенных библиотек(boost, stl и другие) также упрощает разработку.
Использование модели MVC значительно упрощает проектирование приложения, т.к. большинство платформенных зависимостей локализуются в компоненте «Представление(View)».
Htmlayout
Для организации графического интерфейса была использована библиотека Htmlayout, которая позволяет описывать графический интерфейс программы при помощи html и css. Реализация GUI при помощи веб-ориентированных средств несет в себе массу положительных моментов, начиная с большого количества веб-дизайнеров и заканчивая огромным количеством уже готовых вариантов дизайна. А имея в качестве одной из целевых платформ «веб» это уменьшает затраты на реализацию дизайна в виде html+css.
Htmlayout имеет реализацию для Windows Mobile, что позволяет использовать её также для мобильной платформы.
Программа калькулятор
Программа типа «калькулятор» выбрана потому что в полной мере позволяет попробовать реализовать модель MVC и предполагает использование некоторых компонентов библиотеки «boost», которые были мне интересны.
Desktop
Реализация приложения для десктопа(родной для меня платформы), предполагала прежде всего написание моделей данных, используемых в программе и реализацию общей архитектуры программы. Новым моментом для меня было использование библиотеки Htmlayout. Однако никаких проблем с реализацией графического интерфейса с её помощью не возникло.
Как сделать кроссплатформенное десктопное приложение на базе веб-технологий
Дмитрий Дудин (xbSoftware)
Сегодня я вам расскажу про технологию nw.js, большинство слайдов моей презентации будет посвящено ей. Это технология позволяет разрабатывать десктопные приложения и писать их на html, javascript и css. Причем приложение будет кроссплатформенное — под Windows, Linux и Mac. Можно их сбилдить и они будут иметь доступ к графическому интерфейсу системы, т.е. смогут еще работать с менюшками и т.д.
Меня зовут Дима (@nedudi), я работаю в компании XB Software, я из Минска.
Мы делаем всякие Javascript компоненты webix для админок, т.е. для больших объемов данных — можете найти и посмотреть. Еще мы занимаемся аутсорсом, кроме этого, я пишу блог html5.by. Еще у нас в Минске есть фронтенд-сообщество 4front, которое мы организуем, и еще — мы раз в полгода проводим «What the Hack» — это такое мероприятие, где мы делаем бесполезные для жизни хаки, т.е. антистартаперское, но очень крутое.
Мы все очень любим делать веб-приложения. Наверное, все любят делать веб-приложения. Мы их окружаем заботой, прикрепляем к ним какие-то гранты, постпроцессоры, препроцессоры, мы просто тащимся от всей этой разработки. Но, если честно сказать, то большинство приложений, которые мы используем для работы, это все-таки десктопные приложения. Это те приложение, у которых есть иконка на рабочем столе, которые запускаются и могут неделями висеть в фоне. Это какие-то графические редакторы, файловые менеджеры, редакторы аудио, видео, какие-то системные утилиты. И почему бы не писать это все на веб-технологиях? Здесь есть такой барьер — браузер, который очень заботится о нашей безопасности.
Допустим, я хочу написать приложение на веб-технологиях и я хочу, чтобы оно работало по принципу десктопного приложения. Какие барьеры у меня есть? Я их буду выражать как «я хочу»:
Все они примерно пытаются заниматься тем же самым, но, когда мы начинаем читать документацию к ним, становится очень грустно, потому что там есть какие-то свои правила, свои устои. Вам сначала нужно понять их философию, их API. Чтобы написать какое-то простое приложение вам нужно разобрать какие-то примеры документации, и это занимает реально много времени. А, может, вы эту технологию не будете использовать?
С nw.js (http://nwjs.io/) все намного проще. Если вы когда-либо писали веб-приложение, а еще экспериментировали или работали с Node.js, то вы уже часа через два будете иметь возможность написать десктопное приложение под три платформы, которое будет работать.
По моему субъективному мнению, на рынке есть два достойных решения для этого. Это nw.js, о котором мы будем говорить, и Electron (http://electron.atom.io/).
Это, на самом деле, последователь nw.js, он разрабатывается разработчиками Github, которые делают Atom, IDE Atom написано на Electron. Он раньше назывался Atom Shell, и буквально в апреле они его переименовали в Electron.
Мы сегодня будем делать выбор «по звездам», т.е. я зашел на Github, посмотрел у кого из них больше звезд, больше комьюнити, и вы брал для себя одно из них. На самом деле, Electron подает очень большие надежды, поэтому, может быть, через год стоит задуматься, чтобы переключиться на Electron. Надо смотреть, как он будет развиваться. В любом случае у них совсем не много принципиальных различий. Поэтому переключиться через год с nw.js на Electron будет не так сложно. И я в конце расскажу принципиальное отличие между ними.
nw.js проект раньше назывался node-webkit, у него есть история.
В 2011 году у Roger’а Wang’а — разработчика из Китая — появилась идея скрестить Node и webkit, сделать веб-приложение. Назвал он его node-webkit, потому что webkit тогда был рендер-движком Chromium’а, сейчас это Blink. Шли годы, проект развивался, все было хорошо, но к теперешнему моменту он потерял свое название.
В апреле 2013-го Chromium переехал на Blink (http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html, т.е. webkit потерялся, а с января 2015-го проект начал использовать io.js https://groups.google.com/forum/#!msg/nwjs-general/V1FhvfaFIzQ/720xKVd0jNkJ). Тут уже Node.js потерялся. Хотя Node.js, возможно, скоро вернется, судя по новостям. Поэтому проект переименовали в nw.js и заложили в эту nw такой сакральный смысл — native web. Поддерживается он Intel и gnor.net.
У нас есть десктопные приложения. Чем они принципиально отличаются от веб-приложений? Тем, что та машина, которая отрисовывает интерфейс, на ней же в основном происходят и изменения. Т.е. файловый менеджер, который отрисовывает интерфейс, позволяет менять файлы на машине, на которой запущено это приложение. В веб-приложениях, в основном, все организованно по-другому: есть браузер, который что-то отрисовывает, а все изменяется на сервере, который где-то далеко. Поэтому в nw.js разработчики захотели приблизить веб-приложения к десктопным приложениям. Как они это сделали?
У nw.js есть две составные части — это Chromium и io js.
Что такое Chromium? Это браузер с открытым исходным кодом, который очень похож на Chrome, поддерживается он Google, Opera software, Яндексом, Nvidia — большими такими дядьками. У него в основе лежит Blink как движок для рендеринга, движок для javascript — это V8.
Node.js, написанная на С++, работает на уровне протоколов прикладного уровня, у нее есть доступ к каким-то сетевым взаимодействиям, файловой системе и прочим системным фишкам. Т.е. она из-за этого больше используется на серверах и для автоматизации какой-то.
Оба они используют V8. Один и тот же V8. Знаете откуда такое название?
Когда разработчики создавали V8, они взяли за основу такую идею движка… V8 — потому что клапана расположены буквой V и их 8 (клапанов). Двигатель V8 уже давным-давно используется.
В 1902 году, эта штука называлась арианет, по-моему, и в ней уже использовался V8:
А это Chevrolet Camaro 2015 года и в ней тоже используется V8.
Если браузерный V8проживет такую же жизнь, то будет очень классно.
Вернемся к V8. Основная идея — это объединить два этих мира и сделать их рабочими на одном и том же движке в одном и том же контексте. Т.е. вы можете из дома вызывать непосредственно функции Node.js, подключать модули Node.js, передавать объекты по ссылке, работать в едином контексте, иметь один event loop. Если точнее сказать, то здесь Node.js работает на движке V8, который есть у Chromium’а.
Давайте приведу небольшой пример.
У нас есть fs в Node.js для работы с файловой системой. Мы можем смотреть за изменениями в каком-то лог-файле, и если они произошли, то мы берем DOM элемент и отрисовываем в него содержимое этого лог-файла. Просто на сервере это невозможно, на клиенте это тоже невозможно, нет доступа к файловой системе юзера. А в декстопном приложении nw.js все это будет работать отлично.
Как они это сделали?
Было две основных проблемы: это сделать все в одном рабочем event loop, и чтоб оно работало в едином контексте. Т.е. нет какого-то window и global, есть глобальный контекст, в котором есть и Node.js и браузерный javascript. Здесь можно почитать подробнее — https://github.com/nwjs/nw.js/wiki/How-node.js-is-integrated-with-chromium.
Начинаем погружение. Как начать работать с nw.js? Вы заходите на nwjs.io, скачиваете оттуда файл для своей платформы для билдов, и дальше ваше приложение вы можете строить по какому угодно принципу.
Никто вам не говорит, куда класть html, куда — css, вы просто располагаете приложение так, как хотите, полностью всю структуру. Единственное, что вы должны иметь, это package.json. Это файл абсолютно такой же, как в любом Node.js приложении, но у него будут еще несколько дополнительных полей.
Это main — с какого файла начать работу.
Много установок для параметров окна, dependencies, которые нужны для нода.
Потом можно еще передавать туда флаги, с которыми запускается Chromium, флаги, с которыми запускается Node, и еще какие-то системные настройки, коих хватает.
Далее, мы в нашем тестовом случае напишем такое приложение. У нас будет div, у которого есть какой-то контент, добавим немного CSS, и все, что нам нужно запустить, — это nw app. Где nw app — это путь к директории с вашим приложением. При этом на экране вы увидите что-то такое:
Т.е. запустится приложение, появится иконочка. Это очень похоже на браузер. На самом деле, это и есть браузер, это просто обычный Chromium.
Но тут сразу хочется сделать его менее похожим на браузер, потому что это все-таки десктопное приложение, а тут еще много всего там сверху.
Для этого есть множество настроек, коротко пробежимся по некоторым из них. Можно убрать toolbar, это в конфиге.
Будет выглядеть как-то так:
Можем дальше убрать фрейм, т.е. ту штуку с кнопочками.
Уже более похоже на что-то такое декстопное.
Дальше можем сделать это вообще все transparent, т.е. прозрачным:
При этом, у нас будет просто текст в висеть над нашим рабочим столом — никаких признаков браузера:
Можно запустить приложение в kiosk mod’е.
Kiosk mod используется для игрушек, в основном. Еще хорошо используется для всяких терминалов, инфо-киосков, больших всяких панелей, которые отображают меню в Макдональдсе и т.п. Он полноэкранный, из него выйти очень тяжело, из него выходят только описанными методами, либо alt+tab, либо ctrl+alt+del в винде. Поэтому, если вам нужно в kiosk mod’е, выглядит это все вот так, т.е. полностью занимает ваш экран:
Либо вы можете вообще запускать приложение в фоне, вообще без окна, будет вот так:
Что еще есть из красивых всяких плюшек?
Nw.js в стандартном пакете дает вам API для управления какими-то системными элементами интерфейса. Это можно создавать всякие менюшки, иконки в трее, notifications, можно работать с буфером обмена, с системными сочетаниями клавиш, т.е. не браузерными, когда у вас приложение в фокусе, и если вы что-то нажали, у вас что-то произойдет, а сочетаниями клавиш на уровне системы. Т.е. у вас приложения не видно, вы что-то нажали, оно появилось, либо что-то сделало — скриншот или еще что-то. Все это подключается через require nw.gui. Эта штука идет в стандартные поставки, ее подключать ниоткуда не надо.
Коротко пробежимся по ним. Контекстные менюшки.
Создаются очень просто: пишете такой Javascript — нам нужно меню, нам нужны несколько пунктов этого меню, нам нужен один сепаратор, т.е. разделитель между пунктами, и на один из пунктов меню, мы повесим «привет». Получится штука, которую мы повесим на правую кнопочку, и у нас будет такая системная менюшка:
Т.е. она на маке будет выглядеть вот так, на винде она будет выглядеть абсолютно по-виндовому, на убунте или другом линуксе, абсолютно по-линуксовому.
Такая же история. Создаем такую же менюшку, только даем ей роль менюбара. Получаем такую менюшку с вложенными пунктами меню:
Трей или менюбар, в других ОС.
Тоже создаем иконку в трее, можем вешать на нее какие-то выпадающие менюшки, есть иконочка, название, тут какие-то чекбоксики, выпадающие списочки, т.е. все это тоже можно сделать.
Причем, все эти евенты, которые там будут вызываться, будут доходить до вашего браузерного окна, и там можете что-то делать, или в ноде, или в DOM’е, не важно.
Тоже все очень просто. Вы текстом пишете, какое сочетание клавиш вас интересует, пытаетесь зарегистрировать его в системе, если такое сочетание клавиш в системе уже есть, оно вам скажет: «Извини, фейл, нужно что-то другое попробовать». Если все хорошо, он его зарегистрирует и начнет на него реагировать. Т.е. все евенты при нажатии юзером на эти клавиши будут переходить сюда в эктив.
Буфер обмена. Clipboard.
Такая же история. Пока они поддерживают только текстовый клипборд, обещают с разметкой в будущем тоже поддерживать, но пока вы можете положить что-то в буфер обмена и получить что-то из буфера обмена. Т.е. можно уже придумать себе какое-то приложение, где вы нажимаете какое-то сочетание клавиш, и ваш буфер обмена отправляется куда-то в облако, или еще что-нибудь. Здесь главный принцип — не навредить. Потому что nw.js снимает очень много ограничений по безопасности. Вы можете удалять юзерские файлы, вы можете их отсылать куда угодно, вы можете портить все подряд. На самом деле это круто. Свобода — это круто, а не то, что можно все портить.
В приложениях хранение данных можно разделить на две категории: структурированные данные, которые мы обычно храним в каких-то базах данных, и какие-то статичные файлы, т.е. какие-то локальные ресурсы этого приложения, картинки, видео, аудио, промежуточные, которые нам надо хранить. Как пример, если вы пишете десктопную игрушку, то в ней нужно, как минимум, хранить результаты, последние результаты, если вы пишете приложение, то последние открытые файлы, какие-то локальные настройки.
Для хранения этих статических файлов nw.js дате вам такую переменную App.dataPath (https://github.com/nwjs/nw.js/wiki/App), это директория, она будет на каждой ОС разная, но если вы будете использовать именно эту директорию для хранения вашего статичного контента, то вы можете быть спокойны, он там будет хорошо храниться, будет все хорошо. Оно состоит из имени вашего приложения, так что никакого конфликта между приложениями в этой папке не будет.
Для хранения структурированных данных, вы можете использовать все, что уже было создано в Chromium’е (у вас под руками последний Chromium), поэтому Web SQL Database, IndexedDB, Web Storage, Local Storage, Session Storage, Application Cache, все что угодно. Могу только посоветовать: в чистом виде их использовать не очень приятно, поэтому в nw.js были написаны тонны плагинов, я в статье у себя упомянул ссылочку на то, где эти все плагины есть.
Отладка. С отладкой все тоже очень хорошо. Есть такой путь — у вас в тулбаре есть такая шестереночка:
Открывается дебаггер, абсолютно такой же как в Chrom’е последнем. Вы там все дебажите. Ничем не отличается от Chrom’а. Если вы хотите еще больше свободы, вы можете еще запустить nw.js remote debugging port 1234, допустим, и у вас тот же хромовский дебаггер откроется по такому адресу.
Есть возможность Livereload (https://github.com/nwjs/nw.js/wiki/Livereload-nw.js-on-changes), т.е. когда вы меняете код, ваше приложение автоматически обновляется. Они там ничего нового не придумали, они используют плагины, вотчи, которые просто перезагружают это окошко.
Со сборкой приложений (https://github.com/nwjs/nw.js/wiki/How-to-package-and-distribute-your-apps ). Если вы впервые столкнетесь с nw.js, пожалуйста, не старайтесь делать это все вручную. Потому что документация посоветует вам что-то вот такое:
Это страничка документации, и когда ее читаешь, там много всяких dll, каких-то линуксовых заморочек, еще чего-то. Первое ощущение, что все, на этом я закончил работать с nw.js. Но на самом деле, есть прекрасный плагин, называется он node-webkit-builder (https://github.com/mllrsohn/node-webkit-builder):
Там уже вся эта штука описана, автоматизирована и работает. Все, что вам нужно сделать, это скачать его, запустить команду nwbuild с путем к вашему приложению, и можете еще задать много флажков разных, допустим, под какие ОС билдить. При этом он полезет, выкачает последнюю сборку для всех ОС, загрузит себе, все сбилдит, разложит вам по папочкам. Т.е. у вас будет линукс 64, линукс 32, виндовс 64, видновс 32 и т.д. Все эти папочки уже с готовыми файликами для исполнения. Все, что вам остается, это их открыть либо под виндой, либо под линуксом, либо под маком.
Что у меня получилось? После запуска этой команды, так приложение выглядит на маке:
Правда, шрифта робота в винде нет, поэтому шрифт поехал, но я его просто не подключил.
И так выглядит под убунтой:
Т.е. менюшки выглядят так же, как любые убунтовские менюшки.
Хочется сравить nw.js и Electron. Потому что Electron все больше набирает обороты. На самом деле, nw.js и Electron отличаются совсем немножко.
Есть такая история, которую рассказывал Роджер Ванг в одном из докладов, то, что когда он разрабатывал node-webkit на одной из стадий им заинтересовались разработчики Github. И начали какие-то вопросы задавать: что, как, почему? И какие-то у них были идеи по совместному использованию этого всего. И с ним работал его интерн, т.е. рядом чувак, который тоже что-то там пишет, помогает. Вот и через какое-то время этого наняли в Github, который начал писать Electron. Потом они сделали Atom Shell, потом Atom, потом Electron. Поэтому концептуальных различий между ними очень мало. Различия есть, но для конечного разработчика они очень небольшие.
Первое — это точка входа, т.е. в nw.js, мы сразу открываем какой-то файлик index.html и показываем его в окошке. В Electron вы работаете больше с Javascript, т.е. вы сразу не показываете никакого html. Вы в Javascript создаете это окошко, и потом его показываете. Это, наверное, все различия. В Electron у них разные принципы построения билдов, что в принципе нас не волнует, потому что я все равно не хочу читать всю ту документацию. Измененный против оригинального Chromium’а, т.е. ребята в Electron, который бывший Atom Shell, не захотели изменять Chromium, они как-то там выкручиваются, чтобы, вообще, никак не патчить Chromium и использовать тот, который есть. В nw.js они его пропатчивают и убирают какие-то настройки безопасности и еще что-то.
И еще одно различие — в контексте. В nw.js контекст общий, если вы насоздаете много окошек, то в Electron он разный. В принципе, для простых приложений, это не особо важно. Подробнее с точки зрения разработчиков Electron, чем они отличаются от nw.js (там, конечно, уклон в сторону Electron), можно почитать здесь — https://github.com/atom/electron/blob/master/docs/development/atom-shell-vs-node-webkit.md.
И несколько хороших примеров. Примеры — это не самые успешные продакшн приложения, но это просто приложения, разные по своей сути. Может, вас натолкнет на какие-то мысли, идеи, что бы разработать.
Первое — это Popcorn Time. Приложение, которое позволяет стримить из торрентов кино и сериалы.
В отличие от таких подобного рода приложений, оно абсолютно user friendly, оно нигде вам не говорит с какого торрента и как оно все это стримит, вы заходите, там много сериалов, вы выбираете один из них и смотрите. Написан на nw.js, работает под маком, виндовс и линукс.
Есть приложения больше системные. Эта штука такая mongo management studio, очень напоминает php my admin толmко для mongo. Еу, такое gui для mongo.
Есть Light table — редактор, очень похож на Sublime или Atom. Они утверждают, что он намного круче, потому что у него какая-то определенная философия. Я ее не постиг, но есть адепты…
Есть вот такие штуки — вы можете почувствовать себя в роли радиоведущего, стримить свое аудио в массы:
Есть очень похожие клоны десктопных приложений, например, показывающие весь ваш диск вот так вот размеченный:
Вы можете посмотреть, где лежат большие файлики и их поудалять.
Есть обертки для веб приложений, т.е. такие обучалки, которые… по-моему, эта обучалка сама как десктопное приложение мало чего делает, она просто берет контент из веба и отображает его в приложении.
И вот, единственное, что я нашел на русском языке на nw.js, эта штука для быстрой сдачи налогов:
Я думал, что в России налоги никто не сдает, оказывается, для этого даже софт предусмотрен. И штуку эту начали разрабатывать в 2013 году, она была предназначена для телефонов отдельно, для десктопов отдельно и отдельно для терминалов и инфо-киосков. Эта версия для терминалов, т.е. в терминалах вы тоже можете увидеть приложения, разработанные на nw.js. Но все-таки я был прав, что налоги в России никто не сдает, поэтому она так и загнулась в 2013 году и дальше у нее никакой судьбы не было.
Еще очень много приложений они у себя в репозитории ( https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companies-using-nw.js ) собирают. Если вы что-то хорошее напишете, дополнительный какой-то маркетинг, может, от этого вам будет, вы можете тоже там у них в репозитории разместить, и ваше приложение будет в этом большом списке. Список очень большой, там около 100 приложений.
Хотелось бы сделать какие-то выводы. Стоит ли писать приложения на веб-технологиях под десктоп?
Что мне кажется, субъективно, но хочу поделиться.
Во-первых, это самая легкая кроссплатформенность. Т.е. вам практически, ничего не надо делать, все за вас сделает сам инструмент, и вам понадобятся какие-то сложные билды только в случае, если вы делаете что-то такое очень экстраординарное. В типовых случаях все будет и так хорошо билдиться.
Работает достаточно быстро. Конечно, можно сказать, что приложения будут работать быстрее, которые написаны на IT-технологиях, но если взять соотношения скорости работы к деньгам и ресурсам, затраченным на разработку, то, возможно, nw.js будет намного далеко впереди.
Нарастающий тренд — все и всё пишут на вебе везде, для квадрокоптеров, телевизоров, холодильников и, в том числе, для десктопа сейчас, почему бы нет? Просто писать приложения для себя. Т.е. написать такое приложение, допустим, у вас есть какой-то скрпит, который чего-то там билдит, потом тестирует, и потом выкладывает на продакшн или на стейджинг. И вы хотите сделать это вручную, не какими-то тулзами, а вручную. Обычно вы запускаете в консольке какие-то команды. Но вы хотите, чтобы это мог делать, допустим, тестировщик, или вы хотите, чтобы это мог делать верстальщик, который не хочет вообще видеть вашу консоль. И для этого можете написать простенькое десктопное приложение с тремя кнопочками (это займет минут 20), которое будет в командной оболочке запускать нужные команды, при нажатии на эти кнопочки.
Если остались вопросы, то смотрите еще:
Контакты
Этот доклад — расшифровка одного из лучших выступлений на конференции фронтенд-разработчиков FrontendConf.
Ну и главная новость — мы начали подготовку весеннего фестиваля «Российские интернет-технологии», в который входит восемь конференций, включая FrontendConf.