Десктопное приложение или веб-клиент – вот в чем вопрос!

«То о бэнтли я мечтал, то о мазерати,
То рыбалка, то футбол, то с друзьями пати…»
Группа Жуки

​Захотелось мне что-то провокационной статьи, так сказать, взбодрить чем-то наше профессиональное сообщество. Хватит заумных статей и философских рассуждений. Итак, делимся на две команды: «любители Соса-Cola – горнолыжники – виндсерферы» против «любители Pepsi – сноубордисты – кайтеры». Счет на табло 0-0, начинаем!

Правила игры и критерии оценок

Сначала давайте определимся, что же будем считать десктопным приложением, а что – веб-клиентом:

• Десктопное приложение – клиентское программное обеспечение, реализующее Windows Forms интерфейс. Приложение инсталлируется на рабочую станцию пользователя и запускается локально. Или запускается удаленно. Допускается вариант запуска такого приложения с использованием ввода URL адреса в браузере, но от этого веб-клиентом не становится, также как и благодаря запуску с помощью различного рода эмуляторов;
• Веб-клиент – клиентское программное обеспечение, представляющее собой браузер и использующее http/https протоколы. Приложение не требует инсталляцию или загрузку программных модулей на рабочую станцию пользователя. Допускается установка дополнительных общесистемных библиотек и использование защищенных сетевых протоколов, и от этого десктопным приложением не становится.

При использовании любого из перечисленных клиентских приложений может применяться трехзвенная архитектура. Аллилуйя! Термины «толстый» и «тонкий» клиент сюда не вплетаем. Веб-клиент можно создать совсем не «тонким», ровно также как и с десктопного приложения по максимуму снять обработку бизнес-логики.

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

• функциональность, простота использования и быстродействие;
• возможность кастомизации и стилизации;
• мобильность и легкость обновления;
• масштабируемость и кроссплатформенность;
• безопасность и надежность.

Для простоты будем считать, что каждое удачное попадание – 1 очко, так как бессмысленно сравнивать, что важнее – мобильность или безопасность.

Надеюсь, разобрались, и можно начинать «играть». Звучат гимны команд, понеслась…

Первый период

В каждой второй конкурсной документации (если не чаще) в разделе технических требований можно заметить требования к наличию веб-клиента или веб-доступа. Возникает резонный вопрос «Вам вот это зачем, помимо того, что это модно?»

Как правило, обоснования такие:

• мобильность (можно войти в систему с любого компьютера подключенного к интернету);
• легкость развертывания и обновления (не требуется переустановка программных модулей на рабочих станциях пользователей);
• простота создания тестовой и продуктивной среды (на сервере приложений развернуто два веб-приложения к одной БД, таким образом, тестирование новых версий программного обеспечения отдельными группами пользователей становится удобным и сравнительно «безопасным», так как всегда можно вернуться к действующей версии системы обратившись к ней по другому адресу);

Часть этих преимуществ можно достичь и в варианте с десктопным приложением используя RDP доступы, доменные политики и прочее. Но в целом, удар из штрафной площади и 1-0 в пользу веб-клиента. Свисток, центр поля.

Безопасность и надежность – очень серьезный вопрос. Некоторые организации принципиально не хотят и не предоставляют возможность работы в корпоративных системах за пределами своего домена. Необходимость применения средств криптографической защиты информации (СКЗИ) и электронной подписи (ЭП) уже давно никому доказывать не надо, за нас это делают регуляторы. Для использования данных технологий необходимо обращаться к сторонним библиотекам, не все веб-приложения это «любят» и имеют ограничения. Стабильность работы самих браузеров также является потенциально узким местом, причем повлиять на это разработчик бизнес-приложения может не всегда. Оффлайн работа, объективно, чаще и проще реализуются с использованием десктопных приложений. В принципе отдельных организаций пока еще пугает работа в браузере (да-да в том самом, в котором сотрудники просиживают часами в социальных сетях, выкладывая туда всю свою подноготную). Это прорыв по флангу и счет 1-1. Звучит свисток, первая половина игры закончена, команды уходят в свои СЭД закрывать накопившиеся поручения.

Второй период

Все покупатели хотят видеть «свой» продукт, отличный от множества других. Конечно, сложно на это надеяться, покупая массовый коробочный продукт. А сделать его «под заказ» значительно дороже и рисково. Но только не в IT области.

Повальная мода на скины, по-моему, уже прошла, или я постарел, и иметь не классическую «морду» аудио-проигрывателя мне уже не принципиально. Тем не менее, возможность изменить цветовую раскраску, логотипы, иконки, шрифты базовых интерфейсов – хороший бонус для клиента. Десктопные приложения могут предоставлять возможность применения цветовой темы, настройки отдельных интерфейсных элементов, но веб-приложения, применяя каскадные таблицы стилей, с этим справляются явно лучше. Возможность кастомизации определяется степенью развития самого программного продукта и тип клиентского приложения тут не должно иметь особой роли. Счет 2-1 и «браузерники» вырываются вперед.

Функциональность – важнейшее требование к любому программному продукту. Исторически считается, что десктопные приложения более функциональны и эргономичны. Если пытаться разрабатывать веб-клиент с нуля, то так оно и будет. Но с годами были разработаны целые интерфейсные библиотеки, позволяющие творить «чудеса»:

• иерархические списки с возможностью перемещения колонок и наложения фильтров;
• функции drag&drop к любым элементам с любыми визуальными эффектами;
• интерактивные панели и деловая графика;
• встраивание аудио и видео проигрывателей (хотя кому-то больше нравится слово «выигрыватель»);
• обработка всевозможных событий;
• и многое многое другое.

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

Современный пользователь компьютера не меньше времени проводит в браузере, чем тратит его на работу с десктопным приложением. И первый вариант работы сложнее ему не кажется. Зато возможность масштабирования в браузере, отдельным категориям пользователей, приносит ощутимую пользу. Опасность у ворот команды веб-клиента была устранена. Счет по-прежнему 2-1.

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

Разрабатывая веб-приложения с соблюдением стандартов можно надеяться, что программное обеспечение будет корректно работать во всех браузерах, по крайней мере, в первой пятерке. Чуда тут не происходит, и существует масса нюансов связанных с различной интерпретацией одной и той же разметки. Разработчики каждый день видят в системах баг-трекинга заявки из разряда «функция А не корректно работает в браузере Б, а в остальных браузерах все ОК». Но эти труды стоят получаемых бонусов.

Когда пользователь заходит на рядовой публичный сайт в Интернете он надеется увидеть корректное представление страниц с сохранением всей заложенной функциональности. Причем, посетитель сайта не хочет знать «под какие устройства» сайт создавался (стационарный компьютер или ноутбук, планшет или смартфон), это его вообще не должно беспокоить. Почему же ровно также не рассуждать пользователю корпоративной информационной системы. Зачем пользователю, находящемуся вне офиса и имеющему на руках планшет за 1000$ переживать, что он не сможет исполнить поручение, выданное ему в СЭД. Надо ли сотруднику при выборе планшета изучать вопрос, а сможет ли он конкретно с этого планшета (с его операционной системой), корректно работать в десятках корпоративных систем своей организации. А если завтра он купит другой планшет (с другой программной платформой), система на нем будет ровно такой же, к которой он привык или уже другой, а придется что-то заново скачивать и устанавливать?

В идеале, я бы хотел, что бы разработчики бизнес-приложений сосредоточились на самих продуктах, а не тратили время на разработку одного и того же под разные платформы (те же яйца только в профиль). И одним из путей вижу применение в качестве клиентских приложений полнофункциональных веб-клиентов с адаптивным веб-дизайном. Это красивая комбинация заканчивается неберущимся ударом, и счет становится 3-1. Веб-клиент заслуженно побеждает десктопное приложение. Крики радости, брызги шампанского, смазливые девицы окружают победителей.

Послесловие

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

Десктопные приложения на JavaScript. Часть 1

Ни для кого не секрет, что в наше время JavaScript стал одним из самых популярных языков программирования. В далекие 90е годы, в момент зарождения языка, когда он был создан с единственной целью добавить интерактивность веб страницам и улучшить процесс взаимодействия с пользователем, кто бы мог подумать, что он достигнет столь небывалых высот. Ведь сейчас на нем можно делать практически все что угодно. Хотите написать сайт: и бэкэнд и фронтэнд на JavaScript? пожалуйста! Хотите написать мобильное приложение на JavaScript? нет проблем. Программируете микроконтроллер – и тут вам на помощь придет JavaScript.

Есть конечно небольшие минусы в подходе использования JavaScript везде, но если поразмыслить, то сколько времени и сил можно сэкономить, изучив всего лишь одни язык, особенно, если то же самое приложение должно работать на разных платформах. Разных платформах говорите? Хм… Точно – разных платформах – теперь JS может позволить себе десктопные приложения для Windows, Linux, Mac, как спросите вы? Ответ прост: встречайте – NW.js.

По первым буквам можно прочитать – Node.js + Webkit, если данные понятия вам пока не знакомы, то скоро вы поймете о чем идет речь.

Node.js – программная платформа, основанная на движке V8, который транслирует наш скрипт в машинный код. Данная платформа была создана в 2009 году преимущественно для работы с бэкэндом сайтов.

WebKit — свободный движок, разработанный компанией Apple. Впервые был анонсирован в составе Safari в 2003 году
Итак, коду, написанному на JS для данной технологии, будут доступны как Node.js модули, так и стандартный браузерный API (соответственно WebKit)

Быстрый старт

Все это конечно хорошо, но с чего же начать? На github можно найти и скачать репозиторий с исходным кодом. Так же здесь можно найти прямые ссылки для скачивания под ту платформу, на которой будет вестись разработка. Помимо прочего нам понадобится установленная node.js.

После того, как необходимое ПО скачано и установлено, вы написали свое приложение на любимом JS (как это сделать читайте далее) и локализовали все в одну папку. Полдела сделано, теперь остается самое сложное и долгое – упаковать все в один файл и подготовить для распространения. Для упрощения вы можете воспользоваться готовыми библиотеками, например nw-builder. Установка библиотеки не составит труда, если вы уже работали с node.js. Как известно, в состав node.js входит менеджер пакетов npm, с которым нужно работать из командной строки. Для того, чтобы поставить какую-либо библиотеку, необходимо выполнить команду:

Обратите внимание, что библиотеку можно ставить, как локально, так и глобально, для локальной установки используйте опцию —save-dev, для глобальной -g. Таким образом поставим наш сборщик для NW.js глобально, выполнив команду:

Для того, чтобы собрать наше приложение, необходимо выполнить команду (с большим количеством опций можно ознакомиться в документации):

В качестве имени платформы могут быть следующие значения: win32, win64, osx32, osx64, linux32, linux64.

Во время разработки нет нужды каждый раз собирать приложение, можно просто запустить его как есть и оно откроется в отдельном окне. Для этого нужно запустить приложение nw.exe из командной строки и передать в качестве параметров путь к папке с вашим приложением. Кроме того, если вы работаете под Windows, можно просто методом drag-n-drop перетащить папку с исходным кодом приложения на JS (обратите внимание, что именно папку целиком) в nw.exe.

Hello, world!

Теперь, когда вы знаете, как запустить приложение, как собрать его в один файл, давайте напишем что-нибудь. По традиции знакомство с новой платформой начинается с написания приложения Hello, world.

Для данного приложения, нам даже не понадобится JavaScript, только HTML. Создадим папку с названием HelloWorld. Поместим внутрь файл index.html со следующей разметкой:

Кроме того для каждого приложения под NW.js необходим файл, который обязательно должен называться package.json. Из него будет браться информация для построения приложения. Создадим простейший вариант файла и поместим в папку HelloWorld. Итак:

Содержимое файла понятно без пояснений (обратите внимание, что обязательные поля только main и name). В main необходимо записать файл с разметкой, который будет являться точкой входа в приложение. Секция window настраивает параметры окна (в данном случае мы отключаем панель инструментов и задаем размеры окна 500×200).

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

• icon – указываем путь до иконки (переопределить стандартную)
• position – можно указать позицию окна при загрузке (null, center или mouse)
• min_width, min_height, max_width, max_height – ограничение размеров окна
• resizable – логическое значение, которое показывает можно ли пользователю изменять размеры окна
• fullscreen – включить полноэкранный режим
• kiosk – включить режим киоска
• transparent – сделать окно прозрачным

Приложение создано и можно его запустить. После запуска (о том как это сделать, смотри раздел выше) вы должны получить следующее окно:

Приложение написано, но в нем всего один div элемент и совсем нет логики, а что делать, если у нас богатая на элементы разметка и сложная логика? На помощь к нам приходит элемент конфигурационного файла toolbar, который мы установили в false. Для того, чтобы сделать доступными средства отладки, необходимо установить toolbar в true. Проделав это при запуске приложения мы получим следующее окно:

После нажатия на кнопку в верхнем правом углу откроется еще одно окно, в котором будут отображены знакомые инструменты разработчика:

Работа с нативными контролами

NW.js позволяет работать с нативными контролами. Рассмотрим работу на примере меню. Для работы с нативным UI контролами в nw.js необходимо использовать модуль nw.gui, который можно подключить следующим образом:

Общий шаблон для использования контролов:

Таким образом для создания элементов меню можно воспользоваться следующей конструкцией:

Кроме того любые свойства созданного нами объекта можно легко изменить стандартными конструкциями JS, например так:

Меню создано, теперь нужно его заполнить, для манипуляции дочерними элементами существуют методы:

Кроме того для более гибкого добавления элементов в menu можно воспользоваться методом insert, в параметрах которого необходимо передать MenuItem и номер позиции, куда его вставить (позиция перед первым элементом соответствует 0).

Для доступа к созданным элементам можно использовать свойство items:

Обратите внимание, что нельзя напрямую создавать элементы:

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

Для более удобной работы с контролами, они унаследованы от EventEmitter, поэтому хорошая новость в том, что мы можем легко работать с событиями, например так:

Меню было создано, но если запустить приложение, то никакого меню вы не увидите. Для отображения меню существует метод popup, в параметрах которого необходимо передать координаты для отображения меню.

Для демонстрации основных возможностей меню добавьте следующий скрипт к созданному ранее проекту Hello, world:

После запуска приложения, мы можем увидеть созданное контекстное меню для body. Таким образом, мы можем определить контекстное меню для любого элемента.

Итак, теперь кроссплатформенные приложения может создавать каждый, но за все нужно платить. В данном случае мы жертвуем как скоростью, так и занимаемым объемом памяти (собранное приложение получается достаточно большим, более 50 Мб). Список приложений, созданных, используя данную технологию можно найти на github.

Во второй части статьи мы рассмотрим технологию более подробно.