Приложение на основе браузера или автономное графическое приложение?

Ответ 1

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

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

И для GUI на основе:

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

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

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

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

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

Ответ 2

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

Какой пользовательский интерфейс пользователь найдет более полезным?

в терминах

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

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

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

С точки зрения развития

• Сегодня нет двух доступных браузеров. Точно так же.
• Даже с Ajax, javascript и динамическими, отзывчивыми интерфейсами нетривиальны для реализации/отладки.

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

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

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

Я не верю, что большинство пользователей будут использовать веб-интерфейс, если ему предоставлена ​​альтернатива.

IMNSHO

Ответ 3

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

Если ваша основная функция не является самим интерфейсом ( "Если это основная бизнес-функция - сделайте это самостоятельно, независимо от того, что.", см. В защите синдрома Not-Invented-Here от Joel on Software), я чувствую, что браузер сможет выполнить визуализацию формы и работать лучше, чем создавать графический интерфейс с нуля. Кроме того, не говоря уже о том, что для кодирования графического интерфейса потребуется гораздо больше времени, а не генерировать HTML-формы и обрабатывать их после того, как они будут отправлены браузером.

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

Что действительно происходит, так это то, развивается ли вы:

• пользовательский интерфейс
• приложение для ввода данных

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Есть обратные ссылки на веб-приложение, например..

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

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

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

Javascript очень тяжелый процессор.

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

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

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

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

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

"Это веб-страница": формы и диалоговые окна легко обрабатываются в HTML и javascript (или даже с использованием серверных скриптов, например <?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?>)

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

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

Мое решение - это

• Веб-приложения, очевидно, идут в браузерах
• Сетевые приложения, которые не нуждаются в доступе к клиентскому компьютеру, отправляются браузером
• Любое приложение, к которому нужно обращаться больше, чем клиент за раз, выполняется браузером
• Приложения, которые будут использоваться на одного клиента без очевидной потребности в сети с gui, и это может включать в себя программное обеспечение, которое требует большой безопасности при его использовании (одна и та же безопасность может быть адресована для браузера, хотя).

Это чему-то научилось с трудом. Одна из основных причин этого заключается в том, что клиентам проще устанавливать и управлять приложениями на базе браузера намного проще, чем на основе gui, например, где использование JavaWebStart означает, что клиенту потребуется минимальная JRE и их симпатии, тогда как браузеру нужна только ссылка.

В любом случае решение действительно ваше!. Как разработчик Java с использованием JavaFX и Swing может решить мою проблему с этой проблемой.