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

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

(А как сравнивается разработка приложения Flash или Silverlight?)

нет

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

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

Я не могу комментировать Flash или Silverlight, потому что я не использую ни того, ни другого.

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

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

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

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

А потом самое интересное. Что лучше? Браузеры, которые обновляются почти прозрачно, очень регулярно, как Chrome? Или те, которые выпускают обновления безопасности только ежемесячно, а основные функции - каждый каменный век (например, IE)? Ответ не так очевиден, как вы можете подумать, потому что некоторые из этих частых «прозрачных» обновлений могут нарушить ваш код, и вам нужно будет следовать этому и быстро реагировать. Или следите за бета-версиями и предварительными выпусками при разработке и тестировании. Для всех браузеров вы по глупости сказали, что хотите поддержать (удачи).

Да, и давайте не будем забывать о UI. Вы также сталкиваются радость решить , хотите ли вы последовательный интерфейс ЧЕРЕЗ всех целевых платформ или последовательного интерфейса WITHцелевая платформа каждого хоста. Видите все эти маленькие кнопки, которые вы можете просматривать на веб-страницах? Вы хотите, чтобы они были везде одинаковыми или интегрировались в среду, используемую вашим пользователем? Конечно, эта проблема не нова и существовала для других моделей разработки, но здесь она кажется более важной и зависит от типа целевых пользователей и их ожиданий. Публичный конечный пользователь, как правило, хочет, чтобы вы интегрировались с его платформой, но все равно хочет, чтобы вы «вау!» они с причудливыми вещами - в то время как корпоративный пользователь захочет что-то похожее на настольное приложение И мобильные платформы получили новое измерение для всего этого.

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

Как и многие вещи, это обоюдоострый топор.

Примечание: у меня есть сильное предубеждение против Интернета, потому что я в основном большая куча недоделанных технологий (и я вежлив здесь), вплоть до уровней OSI, на которых мы продолжаем добавлять слои дерьма, скрывающие проблемы, не решая их по-настоящему или исправляя их.

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

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

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

РЕДАКТИРОВАТЬ: другие вещи, чтобы рассмотреть ...

Прием на работу

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

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

восприятие

Никто никогда не будет относиться к вам серьезно, когда вы говорите: «Я веб-разработчик». Это для подкласса программистов, разработчиков, не так ли? Те, кого ты игнорируешь и издеваешься издалека, и не присоединяешься, когда идут за кофе. :)

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

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

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

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

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

самое большое переосмысление перехода от настольного компьютера к вебу: веб-приложение по сути не имеет состояния

понять эту часть, и вы хорошо.

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

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

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

На мой взгляд, Flash-приложение может быть, а может и не быть веб-приложением. Что-то вроде AIR может заставить некоторые Flash-приложения работать на настольном компьютере, и на этом основаны некоторые приложения, например, Twhirl, так что это не сразу.

Веб-разработка не обязательно хуже , просто она совсем другая.

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

• HTML
• Javascript
• CSS
• Некоторый серверный язык (Java / PHP / что угодно ...)
• СУБД (или некоторая постоянная технология магазина)
• ... и, возможно, многие другие вещи, такие как Flash, Silverlight и т. д.

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

нет

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

Веб-API (html, CSS, Javascript и DOM) являются эквивалентом API Win32. В конце концов, все сводится к тому уровню API, но вы с ума сошли, если программируете прямо на нем без библиотеки, чтобы абстрагироваться от беспорядка, многословия и непоследовательности.

Так что будьте осторожны с выбором фреймворков. Некоторые проблемы возникают из-за плохих инструментов (например, проблемы совместимости браузера).

Можно иметь чистую и согласованную веб-платформу с одним языком. Например, если вы хотите, чтобы он был «все время java», вы можете использовать GWT и писать как код на стороне клиента, так и код на стороне сервера в Java. Или, если вы предпочитаете, чтобы это был весь javascript, вы можете выбрать что-то вроде Ext JS для клиентской стороны и node.js для серверной стороны.

Я слышал, что это описывается как «... проклятие моего существования», и я бы согласился. Мне предложили $$$ час, чтобы заняться веб-разработкой HTML, и я отказался. Это такая большая боль. Я провел большую часть времени в HTML и недавно начал работать с «платформой Flash». Это одна из самых сложных фреймворков, которые я когда-либо видел, и никто даже не знает об этом. Когда люди поднимают Flash, они думают о Flash, как и 10 лет назад. Это выросло ... много. Я снова люблю писать программы.

У него все еще есть свои недостатки. Ошибки иногда остаются навсегда, но это поправляется (спасибо Стиву Дж.).

Кстати, у разработчиков Flex есть серьезный недостаток. Ко мне обращалось так много компаний, что это плохо. Если вы знаете свой CS, то потратьте 6+ месяцев на изучение хардкора Flex, а затем позвоните мне. Я передам все предложения о работе, которые я должен отклонить.

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

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

Клиент будет вносить изменения. В конечном итоге вы будете тратить все свое время на то, чтобы делать «что должно быть просто» и ненавидеть свою жизнь Вы станете гуру и будете знать вещи, которые не хотите знать. Я знаю, это звучит драматично, но я не приукрашиваю проблемы, с которыми вы столкнетесь. Рамки сделают это проще. Если вы настойчивы в работе с HTML, то, чтобы подготовить себя, заново создайте один из ваших любимых сайтов в HTML, убедившись, что он соответствует дизайну и функциональности во всех браузерах, которые он поддерживает. Удалите проблемы, с которыми вы сталкиваетесь, прежде чем приступить к работе. Такие вопросы, как лучшие инструменты дизайна, лучшие фреймворки javascript, лучшие инструменты отладки, лучшие IDE и т. Д.