Приложение на базе браузера или автономное приложение для GUI?

Другой подход, если вы не хотите давать дополнительные права на передачу и у вас уже установлены Apache или nginx, заключается в использовании Apache или nginx для прокси-пересылки соединений от порта 80 к порту 8080. [112 ]

См. Этот подход:

https://serverfault.com/questions/141904/forwarding-apache-requests-port-80-to-tomcat-port-8080 [114 ]

В целом, это включает установку Apache с mod_proxy, а затем:

ProxyPass        / http://hostname:8080/
ProxyPassReverse / http://hostname:8080/

И вы даже можете изменять имена путей по мере необходимости, если у вас есть другие вещи, которые вы хотели запустить на порту 80 тоже. [116 ]

Эквивалент в nginx также будет простым.

29
задан 01.11.2008, 06:26

11 ответов

Давайте притворимся на мгновение, что усилие/стоимость по разработке/развертыванию/обслуживанию равно, и мы смотрим на него с точки зрения пользователя приложения:

, Который UI пользователь собирается найти более полезным?

с точки зрения [1 111]

  • Простота использования
  • Скорость отклика
  • Знакомые шаблоны навигации/использования
  • Большинство как другие инструменты/приложения, используемые на платформе (т.е., собственный компонент)

, я понимаю, что "полезный" субъективно. Я лично никогда не использовал бы (в качестве пользователя, не разработчика) веб-интерфейс снова, если я мог бы выйти сухим из воды. Я ненависть их.

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

От ракурса разработки

  • Никакие два браузера, доступные сегодня, не представляют точно то же.
  • Даже с Ajax, JavaScript и динамические, быстро реагирующие интерфейсы нетривиальны для реализования/отлаживания.

существуют многие, много автономных приложений GUI, которые просто ужасны, никакой аргумент. Разработка/развертывание и обслуживание для многоплатформенного GUI нетривиальны.

Разрабатывающие хорошие пользовательские интерфейсы твердо, период.

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

я не полагаю, что большинство пользователей использовало бы веб-интерфейс, если дали альтернатива.

IMNSHO

13
ответ дан 14.10.2019, 11:50

Преимущества интерфейса на основе браузера:

  • Легче в управлении: установка на пользовательских машинах не требуется, обновления должны выполняться только на стороне сервера и сразу доступны всем пользователям. Резервное копирование данных может выполняться на одном компьютере, так как данные не будут распределены по нескольким клиентам.
  • Приложение может быть доступно с любого компьютера с помощью браузера.
  • Может легко поддерживать несколько платформ.
  • Требования к памяти и ЦП могут быть значительно меньше на стороне клиента, поскольку на сервере могут выполняться интенсивные операции.
  • Повышенная безопасность: данные хранятся на одном сервере, а не на нескольких клиентских компьютерах, и доступ к ним можно лучше контролировать.
  • Многие другие преимущества централизованной среды, включая ведение журнала, данные, введенные из нескольких источников, могут быть немедленно доступны от других клиентов и т. Д.
  • По моему опыту, часто легче отлаживать и быстрее разрабатывать веб-решения.

Преимущества интерфейса на основе графического интерфейса:

  • Может быть проще разработать более гибкий и гибкий интерфейс.
  • Может использовать специфические для ОС функции, которые могут быть недоступны через браузер.
  • Не обязательно требует доступа к сети.
  • Не нужно беспокоиться о проблемах совместимости браузера.
  • Нет единой точки отказа, если сервер выходит из строя или становится недоступным.
3
ответ дан 14.10.2019, 11:50

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

я видел таблицу в год или два назад, который показал что-то как:




качество UI - Рабочий стол
Гранулярность проверки - Рабочего стола
Скорость отклика - Рабочий стол
Приемлемость для пользователя - Рабочий стол
и т.д. - рабочий стол
и т.д. - рабочий стол
Установка & Поддержка - Браузер
и победы Браузера.

2
ответ дан 14.10.2019, 11:50

Очевидные преимущества для браузера:

  • вы можете представить один и тот же интерфейс независимо от платформы
  • , вы можете легко обновить приложение, и все пользователи имеют одинаковую версию приложение, работающее
  • , вы знаете среду, в которой будет работать ваше приложение (серверное оборудование / ОС), что облегчает тестирование и поддержку по сравнению с множеством конфигураций операционной системы / аппаратного обеспечения, которыми будет приложение GUI. установлен на.

А для графического интерфейса:

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

Также см. Мои комментарии к этому вопросу :

Кросс-платформенные графические интерфейсы - давняя проблема. Qt, GTK, wxWindows, Java AWT, Java Swing, XUL - все они страдают от одной и той же проблемы: полученный графический интерфейс не выглядит родным на каждой платформе. Хуже того, каждая платформа выглядит немного по-другому и чувствует , поэтому даже если бы вы каким-то образом смогли получить инструментарий, который выглядел нативно на каждой платформе, вам пришлось бы каким-то образом кодировать свое приложение, чтобы чувствовать себя нативным на каждая платформа.

Это сводится к решению: хотите ли вы минимизировать усилия по разработке и иметь графический интерфейс, который не выглядит и не совсем подходит для каждой платформы, или вы хотите максимизировать взаимодействие с пользователем? Если вы выберете второй вариант, вам нужно будет разработать общий бэкэнд и пользовательский интерфейс для каждой платформы. [редактировать: или использовать веб-приложение.]

Еще одна мысль, которая у меня только что возникла: вам также необходимо рассмотреть тип данных, которыми манипулирует ваше приложение, и место их хранения, и как пользователи будут относиться к этому. Люди, очевидно, могут хранить данные своего профиля в Facebook на веб-сервере, но они могут чувствовать себя иначе, если вы пишете финансовое приложение, такое как MYOB, и хотите сохранить все свои личные финансовые данные на своем сервере. Возможно, вам удастся заставить это работать, но это потребует больших усилий для реализации требуемой безопасности и обеспечения безопасности базы данных пользователей. В этой ситуации вы можете решить, что общие усилия ниже, если вы используете приложение с графическим интерфейсом.

11
ответ дан 14.10.2019, 11:50

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

, Если Вашей базовой функцией не является сам интерфейс (" , Если это - функция основного бизнеса - делают это самостоятельно, несмотря ни на что. ", видят В защиту Синдрома Not-Invented-Here от Joel на программном обеспечении ), я чувствую, что браузер будет в состоянии выполнить рендеринг формы и обработку лучше, чем необходимость разработать GUI с нуля. Кроме того, не говоря уже об этом занял бы намного более длительное время для кодирования GUI в противоположность генерации HTML-форм и обработке их после того, как они ОТПРАВЛЯЮТСЯ браузером.

то, Что я нашел в прошлом, было то, что меня попросил друг записать приложение для ввода результатов обзора. Сначала, я писал апплет Java для отображения самого обзора со всеми радио-полями, когда он поразил меня, что я буду более обеспеченной записью простого сервера HTTP, который генерировал бы формы и обработал бы их.

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

  1. пользовательский интерфейс
  2. приложение

ввода данных, Если Вы подаете заявку ввода данных, затем оставляет пользовательский интерфейс браузеру и внимание на Вашу базовую функциональность.

4
ответ дан 14.10.2019, 11:50

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

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

Не говоря уже о том, что, если я ввожу достаточно долгий ответ, я теперь заканчиваю с двумя наборами полос прокрутки. stackoverflow.com частично обращается к этому путем предоставления мне текстовой области изменяемого размера, но я все еще должен взаимодействовать с внутренней полосой прокрутки для прокручивания текста, я редактирую, затем прокручиваю целое окно или вниз получить доступ к управлениям приложениями наверху или нижней части окна редактирования.

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

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

1
ответ дан 14.10.2019, 11:50

Все имеет преимущества и disavantages, но:

я должен все же использовать единственное основанное на браузере приложение на localhost, интранет или Интернет, который чувствует себя прекрасно для использования, является быстро реагирующей, и кто пользовательский интерфейс, строго не ограничен ограничениями HTML/JS/CSS.

Примечание: UI Flash/Java-based является исключением (но это еще хуже в некоторых отношениях, и я не думаю, что это действительно, о чем Вы говорите здесь).

0
ответ дан 14.10.2019, 11:50

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

Я все для этого ...

0
ответ дан 14.10.2019, 11:50

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

Веб-интерфейс будет более переносимым, поскольку не привязывает разработку к одной платформе, и если приложение работает в удаленном режиме, его проще обновить и протестировать все (кроме GUI ...) на согласованная среда (ваш сервер). Но вы должны понимать, что, несмотря на то, что все это замечательно и действительно потрясающе, оно также имеет ряд серьезных недостатков. Вы должны не только отлаживать приложение под всеми целевыми системами, но и под каждым отдельным браузером, работающим на каждой отдельной целевой системе ... и не забывайте, что многие версии одного и того же браузера могут сосуществовать в течение некоторого времени, и что настройки каждого браузера вероятно, будут запущены разные наборы (и версии) популярных плагинов, что заставляет его вести себя по-разному, и, вероятно, настройки сети будут настраиваться пользователями. Если приложение находится в удаленном режиме, оно открывает много интересных новых проблем, начиная с другого интернет-провайдера, который может вызвать различные проблемы в середине или простои служб из-за сетевых проблем вашего сервера, компьютеров пользователя или где-то посередине. Удаленное приложение не подходит для всех пользователей в странах, где сетевые услуги имеют низкое качество или не имеют разумной цены; То же самое относится и к вам: вы можете начать предоставлять такую ​​услугу, только если в вашей стране пропускная способность разумна и по разумной цене. И если приложение должно делать что-то нетривиальное в системе пользователя, вы все равно будете обречены на создание большого количества зависимого от платформы кода.

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

0
ответ дан 14.10.2019, 11:50

Браузеры доступны в любом месте, где есть интернет, и вы можете развернуть его на сервере. Настольное приложение должно быть развернуто на их компьютерах, и каждый компьютер имеет свою уникальность даже с той же ОС и той же версией. Это может принести вам много неприятностей. Перейти на веб-сайт.

0
ответ дан 14.10.2019, 11:50

Для этой задачи (на основе ввода текста) отлично подойдет браузер. Вам не нужно ничего, что даст вам настольное приложение (скорость, гибкость)

Существуют недостатки веб-приложения, такие как ..

Это веб-страница. Есть вещи, которые вы просто не можете (легко) сделать

Вы не можете легко сопоставить клавишу ctrl + j, чтобы что-то сделать. Например: Google Spreadsheet пытается сопоставить сочетания клавиш и работает большую часть времени, иногда обработка ярлыка по умолчанию в браузерах вступает во владение ..

Вы не можете делать оповещения Growl (платформа уведомлений OS X). Вы не можете получить доступ к файловой системе. Трудно разрешить доступ в автономном режиме.

Javascript очень загружен процессором.

Попробуйте изменить размер документа Google Spreadsheet или загрузить страницу в Digg (очень тяжелый сайт на JavaScript) - загрузка ЦП браузеров будет некоторое время на уровне 100%. Делать то же самое в родном настольном приложении тривиально

]

При выполнении обновлений вы принудительно применяете их ко всем своим пользователям. С настольным приложением у них есть выбор не обновлять. Например, мне не понравилось одно из обновлений Google Reader, но я застрял. Используя NetNewsWire (настольное приложение), если мне не нравится изменение в последней версии, я могу довольно легко продолжать использовать его (или попробовать и понизить версию)

Ваш веб-сервер должно быть должно быть доступно всегда, навсегда

Если сервер исчезнет, ​​ваши пользователи не смогут обратиться за помощью. Приложение пропало. Если он не работает в течение 10 минут, они не могут его использовать.


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

«Это веб-страница» : Формы и диалоговые окна легко создавать в HTML и javascript (или даже с использованием серверных сценариев, например <?php if(

Для этой задачи (на основе ввода текста) отлично подойдет браузер. Вам не нужно ничего, что даст вам настольное приложение (скорость, гибкость)

Существуют недостатки веб-приложения, такие как ..

Это веб-страница. Есть вещи, которые вы просто не можете (легко) сделать

Вы не можете легко сопоставить клавишу ctrl + j, чтобы что-то сделать. Например: Google Spreadsheet пытается сопоставить сочетания клавиш и работает большую часть времени, иногда обработка ярлыка по умолчанию в браузерах вступает во владение ..

Вы не можете делать оповещения Growl (платформа уведомлений OS X). Вы не можете получить доступ к файловой системе. Трудно разрешить доступ в автономном режиме.

Javascript очень загружен процессором.

Попробуйте изменить размер документа Google Spreadsheet или загрузить страницу в Digg (очень тяжелый сайт на JavaScript) - загрузка ЦП браузеров будет некоторое время на уровне 100%. Делать то же самое в родном настольном приложении тривиально

]

При выполнении обновлений вы принудительно применяете их ко всем своим пользователям. С настольным приложением у них есть выбор не обновлять. Например, мне не понравилось одно из обновлений Google Reader, но я застрял. Используя NetNewsWire (настольное приложение), если мне не нравится изменение в последней версии, я могу довольно легко продолжать использовать его (или попробовать и понизить версию)

Ваш веб-сервер должно быть должно быть доступно всегда, навсегда

Если сервер исчезнет, ​​ваши пользователи не смогут обратиться за помощью. Приложение пропало. Если он не работает в течение 10 минут, они не могут его использовать.


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

«Это веб-страница» : Формы и диалоговые окна легко создавать в HTML и javascript (или даже с использованием серверных сценариев, например [110])

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

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

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

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

POST["email"] ==""){echo("Are you sure you want to continue?); ?>
)

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

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

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

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

2
ответ дан 14.10.2019, 11:50

Теги

Похожие вопросы